域滲透 | SMB的原理與外部C2的應用
SMB Beacon 與命名管道
在 Windows 中，無管理員權限的情況下，即無法添加白名單。
當嘗試使用 Bind() 綁定一個 TCP Socket 時，Defender 會彈窗提示是否允許此程序進行網絡連接，只有用戶點擊允許訪問才可放行。
這個情況下，回連 C2 服務器要使用SMB協議。
SMB協議
根據 微軟官方文檔說明
官方文檔
https://docs.microsoft.com/zh-cn/windows/win32/fileio/microsoft-smb-protocol-and-cifs-protocol-overview
服務器消息塊 (SMB) 協議是網絡文件共享協議，如 Microsoft Windows中實現的稱為 Microsoft SMB 協議。定義特定版本的協議的消息數據包集稱為方言。常見的 Internet 文件系統 (CIFS) 協議是 SMB 的方言。SMB 和 CIFS 也可用于 VMS、多個版本的 Unix 和其他操作系統。
在 OSI 網絡模型中，Microsoft SMB 協議最常用作應用程序層或演示文稿層協議，并且依賴于較低級別的協議進行傳輸。Microsoft SMB 協議最常使用的傳輸層協議是通過 TCP/IP (NBT) NetBIOS。但是，Microsoft SMB 協議還可以在沒有單獨的傳輸協議的情況下使用，Microsoft SMB 協議/NBT 組合通常用于向后兼容性。
Microsoft SMB 協議中使用的安全模型與 SMB 的其他變體使用的安全模型相同，由兩個級別的安全性（用戶和共享）組成。共享是可由 Microsoft SMB 協議客戶端訪問的文件、目錄或打印機。
- 用戶級身份驗證指示嘗試訪問服務器上的共享的客戶端必須提供用戶名和密碼。進行身份驗證后，用戶可以訪問服務器上不受共享級別安全性保護的所有共享。此安全級別允許系統管理員專門確定哪些用戶和組可以訪問共享。
- 共享級身份驗證指示對共享的訪問由分配給該共享的密碼控制。與用戶級別安全性不同，此安全級別不需要用戶名進行身份驗證，也不會建立用戶標識。
在這兩個安全級別下，密碼會在發送到服務器之前進行加密。Microsoft SMB 協議支持 NTLM 和較舊的 LAN 管理器 (LM) 加密。這兩種加密方法都使用質詢-響應身份驗證，其中服務器將發送一個隨機字符串，客戶端返回一個計算的響應字符串，該字符串證明客戶端有足夠的憑據進行訪問。
在本人防火墻上默認配置如下：
這里可以看到，在 Windows 中，防火墻通常默認允許 SMB 協議出入站，因此，如果有什么功能或機制可以用于與外部機器進行通信的，SMB 協議無疑是一種很好的選擇。而命名管道就是基于 SMB 協議進行通信的，所以我們可以基于命名管道與外部機器進行通信，從而建立控制通道。
命名管道
“命名管道” （IPC)又名 “命名管線”，但是通常都叫命名管道，是一種簡單基于 SMB 協議的進程間通信（Internet Process Connection - IPC）機制。在計算機編程里，命名管道可在同一臺計算機的不同進程之間或在跨越一個網絡的不同計算機的不同進程之間，支持可靠的、單向或雙向的數據通信傳輸。
和一般的管道不同，命名管道可以被不同進程以不同的方式方法調用（可以跨語言、跨平臺）。只要程序知道命名管道的名字，任何進程都可以通過該名字打開管道的另一端，根據給定的權限和服務器進程通信。
默認情況下，我們無法使用命名管道來控制計算機通信，但是微軟提供了很多種 Windows API 函數，例如 ：
- 用于實例化命名管道的服務器端函數是 CreateNamedPipe
- 接受連接的服務器端功能是 ConnectNamedPipe
- 客戶端進程通過使用 CreateFile 或 CallNamedPipe 函數連接到命名管道
在微軟的官方文檔中對命名管道安全性有詳細描述
官方文檔
https://docs.microsoft.com/zh-cn/windows/win32/ipc/named-pipe-security-and-access-rights
調用 CreateNamedPipe 函數時，可以為命名管道指定安全描述符。安全描述符控制對命名管道客戶端和服務器端的訪問。如果指定 NULL，則命名管道將獲取默認的安全描述符。命名管道的默認安全描述符中的 ACL 向 LocalSystem 帳戶、管理員和創建者所有者授予完全控制權。他們還向“每個人”組的成員和匿名帳戶授予讀取訪問權限。
外部 C2 的通信模型
外部 C2 系統是用于實現 C2 通信的一種規范。
在 Cobalt Strike 4.0+ 中，對監聽器類型做了擴充，加入了外部 C2 的 Payload 選項。CS 允許用戶在遵循外部 C2 規范的前提下，使用此接口定義自己的外部 C2 協議。
（圖片來源：https://leanote.com/api/file/getImage?fileId=5e257c57ab64411ab6006f44）
在 Cobalt Strike 中使用的是 SMB Beacon
Windows 將命名管道通信封裝在 SMB 協議中。因此得名 SMB Beacon。SMB Beacon 使用命名管道通過父 Beacon 進行通信。這種點對點的通信對于在同一臺主機上的 Beacon 生效。它也可以在整個網絡上運行。
參考鏈接
http://blog.leanote.com/post/snowming/8b7ce0f84c03
SMB Beacon 使用場景：
當前已拿到了目標內網中的一臺機器的 beacon shell，然后又通過其它方式搞到了同內網下的另一臺 windows 機器的本地 administrator 密碼且這臺機器的 SMB[445 端口]能正常通信。
但是由于各種各樣的原因限制，那臺 windows 機器并不能正常訪問外網，也就是說沒法再正常的反彈 beacon shell 了，那么其他那些反向監聽器也就全都用不上了，而我現在就想通過當前僅有的這個 beacon shell 能不能把內網那臺不能正常訪問外網的機器也一塊給帶出來呢？答案是肯定的，bind_pipe（CS SMB 協議 payload 的名字） 就是專為適應這種實戰場景而設計的。
SMB Beacon 使用步驟：
1. 探測內網 445 端口開放情況，建立 SMB 監聽器2. 使用欲橫向主機的憑據填充令牌：beacon> shell net use \\172.31.51.190\admin$ /user:"administrator" "test1234@" 3. 橫向建立SMB Beacon：beacon> jump psexec64 172.31.51.190 smb 4. 取消鏈接unlink [ip address] [session PID]5. 再次鏈接到 SMB Beaconlink [host] [Pipename]
要銷毀一個 Beacon 鏈接，在父會話或子會話中使用 unlink [ip address] [session PID] 。這個 [session PID] 參數是要取消鏈接的 Beacon 的進程 ID。該值用于當有多個子 Beacon 時，指定一個特定的 Beacon 來斷開鏈接。
此 SMB Beacon 不會離開并消失。相反，它進入一種等待其他 Beacon 連接的狀態。我們可以使用 link 命令來從將來的另一個 Beacon 恢復對 SMB Beacon 的控制。
為了與正常流量融合，鏈接的 Beacon 使用 Windows 命名管道進行通信。這個流量被封裝于 SMB 協議中。對于此方法有一些警告：
- 具有 SMB Beacon 的主機必須接受 445 端口上的連接。
- 只能鏈接由同一個 Cobalt Strike 實例管理的 Beacon。
注意：使用 SMB Beacon 的前提是憑據必須是 administrator 的。否則 jump psexec 橫向可能失敗
通過 SMB 協議繞過防火墻建立 C2 信道可以作為本地權限提升漏洞的利用鏈中的一步。
進一步可以利用命名管道的模擬客戶端功能來獲取 system 權限，MSF 的 getsystem 功能就是通過此方法實現的。
外部 C2 的通信流量融合
外部 C2 規范允許將 Beacon 的通信（回連團隊服務器或連接到其他 Beacon）方式拓展到幾乎任何需要的方式。可以拓展通信協議、提供工具集本身不支持的通信方法。在 Cobalt Strike 的特定場景中 —— Beacon 可以通過 HTTP/S 和 DNS 協議出口 C2 流量；并通過 SMB 的命名管道和 TCP socket 鏈接到其他的 Beacon 。
通過合法服務（例如 Office 365、Google云端硬盤、Dropbox、Slack或其他任何服務）出口C2 流量，可以使得 C2 流量充分融合到正常流量，尤其是如果你的目標使用這些服務作為其日常業務的一部分時。在某些情況下，你甚至可以通過目標自己的應用傳輸 C2 流量，例如通過他們自己的 OneDrive 傳輸 C2 數據。
通過文件共享、活動目錄或任何可以被寫入/讀取的應用進行的內網 C2 通信也很難被檢測到，這也有助于繞過不同類型的防火墻限制。
比起來，可拓展 C2 的好處就是配置簡單，外部 C2 的好處是隱蔽性更好、繞防火墻等限制的效果更好，可以拓展協議，但是實現起來比較難。
而GitHub上也有外部C2相關的內容與工具：
Github C3地址：
https://github.com/Rvn0xsy/Cooolis-ms
預防
微軟在保護SMB流量中提到幾種方法：
阻止入站 SMB 訪問
阻止來自企業硬件防火墻的 internet 上的 TCP 端口445入站。阻止入站 SMB 流量阻止從 internet 進行訪問，從而保護網絡內的設備。
如果希望用戶在網絡邊緣以入站的狀態訪問其文件，可以在 QUIC 上使用 SMB。默認情況下，這會使用 UDP 端口443，并為 SMB 流量提供 TLS 1.3 加密安全隧道（如 VPN）。
阻止出站 SMB 訪問
阻止在公司防火墻上向 internet 出站 TCP 端口445。阻止出站 SMB 流量會阻止網絡內的設備使用 SMB 向 internet 發送數據。
如果使用 Azure 文件存儲 SMB，請將 vpn 用于出站 vpn 流量。通過使用 VPN，可以將出站流量限制為所需的服務 IP 范圍。
清點 SMB 使用情況和共享
你可以使用以下工具和功能來幫助你清點 SMB 訪問權限：
- 使用 文件共享 腳本來檢查服務器和客戶端上的共享。
- 使用注冊表項
Security Settings\Advanced Audit Policy Configuration\Audit Policies\Object Access\File Share啟用SMB 入站訪問的審核線索。由于事件數可能很大，請考慮在指定的時間內啟用或使用 Azure Monitor。
檢查 SMB 日志可了解哪些節點正在通過 SMB 與終結點通信。你可以決定是否正在使用終結點的共享并了解哪些共享存在。
配置 Windows Defender 防火墻
使用防火墻規則來添加額外的連接安全性。配置規則以阻止包含異常的入站和出站通信。一種出站防火墻策略，阻止在托管網絡內部和外部使用 SMB 連接，同時允許訪問最小服務器集，而無其他設備為橫向防御深層度量值。
另外也在防止 SMB 流量從橫向連接進入或離開網絡中更詳細提到Windows防火墻相關
位于網絡邊緣的外圍硬件和設備的防火墻應阻止來自 Internet) 的未經請求的通信 (以及從 internet (發) 到以下端口的傳出流量。
源自 Internet 或目的地為 Internet 的任何 SMB 通信不太可能是合法的。
主要案例可能適用于基于云的服務器或服務，例如 Azure 文件。應在外圍防火墻中創建基于 IP 地址的限制，以僅允許這些特定終結點。組織可以允許端口 445 訪問特定的 Azure 數據中心和 O365 IP 范圍，以啟用混合方案，其中本地客戶端 (位于企業防火墻后面) 使用 SMB 端口與 Azure 文件存儲通信。還應僅允許 SMB 3。x 流量，需要 SMB AES-128 加密。 對于Windows SMB 共享的客戶和服務器，可以使用 Windows Defender 防火墻 阻止所有入站 SMB 流量，以防止來自惡意或受攻擊設備的遠程連接。在Windows Defender 防火墻中，這包括以下入站規則。
可以看到默認未開啟防火墻
禁用 SMB 服務器（如果未使用）
使用策略進行測試和部署
檢測
參考
https://www.4hou.com/posts/B8nx
檢測一般的點對點惡意流量和惡意命名管道可能非常困難，但并非不可能。通常，檢測植入工具自身的惡意行為，比檢測點對點協議要更為容易。
但是，有一些指標可以被發現。其中，許多檢測都需要對某些指標進行基線測試，并將新行為與此基線進行比較，以便進一步了解事件發生的異常情況。
主機檢測
安全事件標準OSSEM
https://github.com/OTRF/OSSEM/
- 已知的惡意命名管道名稱：這種檢測方式最為明顯，也最容易得出結果。C2框架可能會使用容易被檢測到的默認命名管道名稱。例如，Covenant使用gruntsvc作為默認管道名稱，而Cobalt Strike使用msagent作為默認管道名稱。這兩個管道名稱都可以在兩個框架內輕松更改，但使用這一指標來檢測未更改默認值的攻擊者可能會非常有效。
Sysmon可以用于收集有關命名管道的信息。創建命名管道時，會生成Sysmon事件ID 17。我們可以根據已知惡意管道名稱列表來檢查PipeName字段。
- 與命名管道相關的異常進程：為了正確利用這種檢測方式，組織中應該使用一種方法來收集與命名管道相關的進程，并對其進行基線化。同樣，Sysmon事件ID 17具有此檢測所需的所有信息。我們應該在一段時間內收集這些事件，并將新事件與其基線進行比較。
例如，Chrome有一組通用的命名管道，它們通常采用“mojo.#####.#####.##################”的格式，其中#代表一個數字。
例如：
如果針對與命名管道相關的進程進行基線化的結果顯示，C:\Program Files (x86)\Google\Chrome\Application\chrome.exe從不或者幾乎沒有創建不匹配“mojo.####.#####.####################”格式的命名管道，那么如果存在一個新事件，顯示C:\Program Files (x86)\Google\Chrome\Application\chrome.exe創建了一個不符合上述格式的新命名管道（例如：pipe123），這就是異常的：
像這樣的異常命名管道可能值得我們的研究。在理想情況下，該檢測應該與其他主機指標共同使用，以便為潛在的攻陷判斷添加額外的上下文。
- 異常命名管道安全描述符：如本文前面所述，Covenant將單個安全描述符應用于其命名管道，允許Everyone組進行FullControl。這不是絕對必要的，但可以提高運營者的可用性。例如，對父Grunt上的令牌操作這樣的操作，可以改變用戶與命名管道交互的方式，并且如果安全描述符僅限于特定用戶，可以實現限制使用命名管道。例如，我們可以看到Grunt命名管道使用James Forshaw的NtObjectManager項目來應用這個安全描述符：
組織可以利用這一方法，與可用性進行權衡，通過搜索安全描述符來識別潛在的惡意命名管道。如果單獨使用這一檢測方法，可能會導致誤報。理想情況下，這應該被用作增強其他相關指標嚴重性的補充指標。
網絡檢測
用于識別點對點流量的基于網絡的檢測，必須依賴于受影響組織的內部網絡上捕獲地數據。在許多組織中，都不會收集這些數據。但我們認為，組織至少應該在內部網絡的某些關鍵節點收集內部網絡流量。具體而言，這一收集的位置和收集的數量，應該始終針對于特定的組織。
網絡流量模式通常可以從基于主機的指標推斷出來。例如，從一個系統到另一個系統的的Windows事件4624（登錄事件）意味著從第一個系統到第二個系統的網絡連接。但是，從主機收集的數據存在一個缺點，就是它更容易受到攻擊者對受損終端的操縱。
下面提到的一些檢測方式，一些可能依賴于從網絡明確收集的數據（即：“網絡流”數據），同時還包含一些可以基于主機日志推斷的網絡活動，并且還有一些可以通過任一方式來收集。
- 遠程連接到命名管道：點對點命令與控制依賴于遠程訪問的命名管道。我們可以收集從遠程系統訪問的命名管道基線。要收集這些數據，可以通過兩種方法。一種方法是純粹的網絡方式，使用某種網絡鏡像或流量收集工具，可以檢查SMB網絡流量，以查找被訪問的命名管道。舉例來說，我們可以使用Wireshark看到訪問命名管道的流量。
第二種方法是基于主機的方法，我們可以使用Sysmon 事件ID 18，它負責記錄到命名管道的新連接，并識別并非來自當前主機的連接。事實證明，當遠程訪問管道時，Image字段設置為System。但遺憾的是，我們沒有得到原始主機名，但至少我們可以確定遠程訪問管道：
- 異常的主機到主機流量：這種最終的檢測方式比檢測命名管道更為有效。我們可以通過將正常的內部主機到主機的流量進行基線化，來嘗試識別主機到主機的流量。在對這類活動進行基線化處理之后，會發現某些高價值服務器可能永遠不會或幾乎不會與主要包含用戶工作站的某些子網建立網絡連接。如果突然發現從這些高價值服務器到工作站子網的大量網絡連接，那么就可以說這一行為是異常的，并值得后續調查。這種檢測方式同樣依賴于合適的基線，并且可能會發生誤報。理想情況下，這種檢測方式應該作為補充指標，以增加其他相關指標的嚴重性。
我們在這個行業相遇，也會在這個行業各自奔赴前程。希望下次我們會在頂峰相遇。
