CobaltStrike 流量分析與入侵檢測

作者：ainrm@藪貓科技安服團隊
公眾號：藪貓科技（歡迎關注）https://mp.weixin.qq.com/s/CjsqWrm70HVEnolZrRD8oA

一、前言

Cobaltstrike是一款用于團隊協作的內網滲透工具，在攻防、測試中扮演著重要角色，其功能強大、使用人數眾多，已被各大安全廠商列入重點"照顧"對象。常見的檢測方式有基于內存和基于流量兩種，本文從流量角度出發，通過抓包、解包來分析c2與beacon間的通信過程，并嘗試從中提取流量特征轉化為ids檢測規則。

二、流量分析

2.1 http-staging

01 stage下載

stager可執行文件artifact.exe運行后會有一個payload下載過程，使用http協議從指定服務器下載stage。

其中http請求路徑不唯一，但都符合一個checksum8規則，即：路徑的ascii之和與256取余計算值等于92。

/Yle2、/cKTZ、/wQPD

而下載的文件約211kb，解析后可以看到回連地址、加密字段、公鑰等配置信息。

02 beacon上線

隨后beacon按設置的頻率以get方法向c2服務器發起心跳請求，通過cookie攜帶靶機信息。

此時client界面可以看見目標機器上線：

03 命令下發

c2服務器如果有任務下發，則放入http心跳請求返回包中。

當前下發的命令：whoami

04 結果回傳

beacon端處理完成后，通過post方法回傳數據。

備注：https-beacon在http-beacon的基礎上加入了tls層對流量加密，其他過程相似。

2.2 dns-stagless

01 beacon上線

與staging階段不同，stagless不需要額外加載stage，運行dns-beacon.exe后，beacon端向發起一個A記錄查詢，查詢內容為16進制字符串地址，表示靶機已上線，c2服務器收到請求后回復0.0.0.0表示確認消息。

此時，客戶端可以看見一個不同于http(s)上線的黑框記錄。

02 beacon激活

客戶端控制臺輸入checkin或其他指令激活窗口，dns-beacon服務器支持A、TXT、AAAA三種方式下發payload，激活后默認使用TXT記錄，流量中表現為0.0.0.243，除此之外還可以通過mode指令切換為A、AAAA記錄，流量中表現為0.0.0.241、0.0.0.245，隨后beacon端發起以www為首的A記錄請求，向c2服務器傳遞靶機基礎信息。

03 命令下發

beacon準備接收c2任務，先發送以api開頭的A記錄請求告知c2服務器可以開始下發任務，即圖中的0.0.0.243-TXT方式，隨后發起以api開頭的TXT記錄請求等待c2服務器返回數據。

04 結果回傳

beacon端執行完命令后，再向c2服務器發起以post開頭的A記錄查詢回傳執行結果。

三、特征提取

上一節對使用默認配置文件的cobaltstrike交互過程進行了分析，流量中存在很多特征，但在實際攻防、測試中紅隊常使用Malleable-C2-Profiles來修改c2配置實現應用層流量混淆，從而繞過部分安全設備監控，這里就以profile為界限將特征劃分為基礎特征和強特征兩個方向，即：

基礎特征：使用默認配置時存在的特征，可通過修改profile文件或證書將其隱藏；
強特征：需要修改cobaltstrike源碼才能較好去除的這部分特征。

3.1 基礎特征

01 http請求

http-beacon通信中，默認使用get方法向/dpixel、/__utm.gif、/pixel.gif等地址發起請求，同時請求頭存在cookie字段并且值為base64編碼后的非對算算法加密數據。

# default c2-http profile
# define indicators for an HTTP GET
http-get {
    # Beacon will randomly choose from this pool of URIs
    set uri "/ca /dpixel /__utm.gif /pixel.gif /g.pixel /dot.gif /updates.rss /fwlink /cm /cx /pixel /match /visit.js /load /push /ptj /j.ad /ga.js /en_US/all.js /activity /IE9CompatViewList.xml";

    client {
        # base64 encode session metadata and store it in the Cookie header.
        metadata {
            base64;
            header "Cookie";
        }
    }

    server {
        # server should send output with no changes
        header "Content-Type" "application/octet-stream";

        output {
            print;
        }
    }
}

02 https證書

https-beacon通信中，默認使用空證書建立加密通道，流量中可以看見這一過程。

03 dns異常返回值

dns-beacon通信中，默認使用cdn.、www6.、api.、www.、post.為開頭發起dns請求，并且查詢結果伴隨0.0.0.0、0.0.0.80、0.0.0.241等非常規ip。

3.2 強特征

01 chechsum8

運行staging模式的pe文件，會向指定服務器的checksum8路徑發起請求來下載stage。

即使通過profile文件改變下載地址，但c2服務器依然會對checksum8地址請求作出響應。

# https://github.com/threatexpress/malleable-c2/blob/master/jquery-c2.4.6.profile
http-stager {  
    set uri_x86 "/jquery-3.3.1.slim.min.js";
    set uri_x64 "/jquery-3.3.2.slim.min.js";
    ...
}

02 ja3/ja3s

ja3和ja3s分別代表tls握手階段的client-hello、server-hello的數據集合計算出的哈希值（md5），相同版本相同系統下指紋相同，該特征與操作系統、cobaltstrike版本有關，profile文件無法對其修改。

win10-https-beacon-ja3指紋：72a589da586844d7f0818ce684948eea

centos-cs4.4-ja3s指紋：fd4bc6cea4877646ccd62f0792ec0b62

3.3 小結

四、規則編寫

根據前面提取的特征，共整理出 17 條 ids 規則。這一節對其中的5條進行講解，其余規則和過程文件已上傳至github

4.1 checksum8檢查

同時命中以下三條規則則觸發告警：

由客戶端發起并與目標服務器建立連接：flow: established, to_server;
請求路徑長度為5：urilen:4<>6;
調用lua計算路徑的ascii之和并與256做取余操作，結果為92：luajit:checksum8_check.lua;

完整規則：

# suricata規則
# http-beacon-staging，向c2服務器發起get請求，下載大小約210kb的stager，請求地址符合checksum8規則
# 調用lua檢查uri是否符合checksum8規則：計算uri的ascii之和并與256做取余計算，余數為92則符合規則
alert http any any -> any any (gid:3333; sid:30001; rev:1; \
    msg:"http-beacon-checksum8-path-parse"; \
    classtype: http-beacon; \
    flow: established, to_server; \
    urilen:4<>6; \
    luajit:checksum8_check.lua; \
)


# checksum8_check.lua
function init (args)
    local needs = {}
    needs["http.uri"] = tostring(true)
    return needs
end

function match(args)
    local uri_raw = tostring(args["http.uri"])
    local uri = string.sub(uri_raw, 2, -1) -- 去除uri中的"/"
    local sum = 0

    for i=1,#uri do
        local x = string.sub(uri,i,i)
        sum = sum + string.byte(x)
    end

    if (sum % 256) == 92 then
        return 1 -- 符合checksum8規則，匹配成功
    else 
        return 0 -- 不符合checksum8規則，匹配失敗
    end
end

4.2 ja3/ja3s檢查

滿足其中之一則命中規則觸發告警：

采用黑名單機制，正則匹配由beacon端發起請求的ja3指紋；
采用黑名單機制，正則匹配由c2端返回的ja3s指紋。

完整規則：

# https-beacon-ja3指紋，client-hello
alert tls any any -> any any (gid:6666; sid:30005; rev:1; \
    msg:"https-beacon-ja3-hash"; \
    classtype: https-beacon; \
    ja3.hash; pcre:"/652358a663590cfc624787f06b82d9ae|4d93395b1c1b9ad28122fb4d09f28c5e|72a589da586844d7f0818ce684948eea|a0e9f5d64349fb13191bc781f81f42e1/"; \
)


# https-beacon-ja3s指紋，server-hello
alert tls any any -> any any (gid:6666; sid:30006; rev:1; \
    msg:"https-beacon-ja3s-hash"; \
    classtype: https-beacon; \
    ja3s.hash; pcre:"/fd4bc6cea4877646ccd62f0792ec0b62|15af977ce25de452b96affa2addb1036|b742b407517bac9536a77a7b0fee28e9/"; \
)

4.3 異常dns檢查

01 A記錄異常返回

同時命中以下兩條規則則觸發告警：

dns流量內容包含二進制數00 01 00 01 00 00 00：content:"|00 01 00 01 00 00 00|";
dns返回包以0.0.0.241結尾：content:"|00 00 00 f1|"; nocase; endswith;

完整規則：

# dns-beacon，匹配dns-beacon發起上線/心跳請求后，c2服務器的返回包，選擇后續使用A記錄
# Type: A, Class: IN, 0.0.0.241
alert dns any any -> any any (gid:9999; sid:30011; rev:1; \
    msg:"dns-beacon-live-response"; \
    classtype: dns-beacon; \
    content:"|00 01 00 01 00 00 00|"; \
    content:"|00 00 00 f1|"; nocase; endswith; \
)

02 txt記錄異常返回

同時命中以下四條規則則觸發告警：

由c2端發起請求：flow:to_client;
dns流量內容包含api字符：pcre:"/api/";
dns流量內容包含二進制數00 01 00 01 00 00 00：content:"|00 01 00 01 00 00 00|";
dns返回包以0.0.0.50結尾：content:"|00 00 00 50|"; endswith;

完整規則：

# dns-beacon，匹配dns-beacon使用TXT方式向c2服務器發起payload下載請求后，c2服務器的返回包
# api ==> TXT 
# Type: A, Class: IN, 0.0.0.80
alert udp any any -> any any (gid:9999; sid:30015; rev:1; \
    msg:"dns-beacon-getpayload-response"; \
    classtype: dns-beacon; \
    flow:to_client; \
    pcre:"/api/"; \
    content:"|00 01 00 01 00 00 00|"; \
    content:"|00 00 00 50|"; endswith; \
)

4.4 測試

01 白流量

hexdump抓取訪問baidu站點流量，測試結果沒有產生誤報。

02 http-beacon

識別出stage下載、心跳請求、執行結果回傳三種流量。

03 https-beacon

識別出ja3、ja3s、cert三種cs流量。

04 dns-beacon

識別出心跳請求、結果回傳、元數據提交、payload下載四種cs流量。

五、總結

cobaltstrike默認配置文件具有較為明顯的流量特征，容易被監管設備查殺，使用malleable-c2、證書等手法能夠在一定程度上混淆流量，但在整個tcp/ip模型中依然存在蛛絲馬跡，無法脫離cobaltstrike框架。對攻擊方來說想要究極隱藏，筆者認為還得要從源頭入手，在魔改cs或自研網絡通信模型上想想辦法，同時這對防守方來說提出了更高的要求，能否應對來自高級攻擊者發起的挑戰。

六、參考

https://www.52pojie.cn/thread-1426936-1-1.html
https://www.52pojie.cn/thread-1607839-1-1.html
https://suricata.readthedocs.io/en/latest/rules/index.html
https://wbglil.gitbook.io/cobalt-strike/cobalt-strike-yuan-li-jie-shao/cs-mu-biao-shang-xian-guo-cheng

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1922/

[匿名用戶]: yuuki 2022-09-17

您好，我在嘗試過程中遇到了這個問題，請問您知道是什么原因嘛，煩請指導一下，謝謝。 17/9/2022--11:31:35- <Info> -unknown key and/or value:k='http.uri',v='true' 17/9/2022--11:31:35- <Error> - [ERRCODE:SC_ERR_LUA_ERROR(212)] -no setup function in script 17/9/2022--11:31:35- <Error> - [ERRCODE:SC_ERR_LUA_ERROR(212)] -couldn't initialize script 17/9/2022--11:31:35- <Error> - [ERRCODE:SC_ERR_FATAL(171)] -Error during setup of lua output.Details should be described in previous error messages.Shutting down...

回復

Paper - 安全技術精粹

CobaltStrike 流量分析與入侵檢測

目錄

一、前言

二、流量分析

2.1 http-staging

01 stage下載

02 beacon上線

03 命令下發

04 結果回傳

2.2 dns-stagless

01 beacon上線

02 beacon激活

03 命令下發

04 結果回傳

三、特征提取

3.1 基礎特征

01 http請求

02 https證書

03 dns異常返回值

3.2 強特征

01 chechsum8

02 ja3/ja3s

3.3 小結

四、規則編寫

4.1 checksum8檢查

4.2 ja3/ja3s檢查

4.3 異常dns檢查

01 A記錄異常返回

02 txt記錄異常返回

4.4 測試

01 白流量

02 http-beacon

03 https-beacon

04 dns-beacon

五、總結

六、參考