CobaltStrike WebServer特征分析 - 網安 - 專業的網絡安全產業、社區、知識平臺

WebServer特征

本文簡單介紹了Cobalt Stike 4.4版本的一些特征以及緩解措施。

webserver處理邏輯漏洞

請求狀態碼異常

正常的服務器對于uri的開頭不為/的情況，一般都會產生400的狀態。

而teamserver在處理的時候，返回了404，

在處理OPTIONS請求時候，更是uri都不看，直接返回200，并且在后面會加上Allow: OPTIONS,GET,HEAD,POST

正常的網站感覺還是干不出來這種事情的。

beacon&stager uri異常訪問

對于更特殊的請求，類似的情況如下，更是直接暴露了profile的http配置以及beacon。

profile的流量情況：

beacon：

uri匹配問題

可以看到對于beacon.http-get、beacon.http-post的uri后面可以隨意增加的，profile很靈活導致了webserver沒辦法做精準的匹配。

checksum8特征

checksum8算法可以匹配多個值，如aaa9等，個人理解本意是在profile沒有設置uri的時候，具有一定的隨機性，多個uri都可以獲取beacon，但是問題在于profile中 set uri之后，該算法依然可用（可能為了兼容msf的請求），配合默認解密方法可以獲取完整的配置。

WebServer流程、特征分析

UA校驗

我們對核心邏輯_serve進行簡單的分析。可以看到先經過了一個UA的黑白名單，可以在profile中進行配置。默認黑名單有curl* lynx* wget*。

如果不符合UA檢測，則返回404，并在console中輸出。

處理OPTIONS請求

這塊發現teamserver是沒有對uri做校驗的，直接返回200，并添加了一個Allow的header。

webserver核心邏輯

Webserver封裝了一個名字叫hook的Map，里面push了多個WebService的實現，Map的key為uri，在監聽創建的時候，默認會push上述4個WebService進去。

beacon.http-get
stager
stager64
beacon.http-post

其中beacon*類型為MalleableHOOK，負責處理beacon的通訊，如心跳，命令執行等，stager*類型為MalleableStager，負責推送beacon。

當通過UA檢測后區分了7種情況：

1.匹配響應一般的uri，用于host file，powershell script等一些情況 （beacon&stager uri異常訪問的原因）
2.匹配響應用戶配置的beacon.post/get,stager/stagerx64的請求
3.匹配響應目錄的uri，自動補全結尾的/，沒有找到場景
4.匹配以http://開始的uri，沒有找到場景
5.匹配stager64的uri，主要用于響應64位場景下checksum8算法生成的uri（uri長度有限制，checksum8特征的原因）
6.匹配stager的uri，主要用于響應32位場景下checksum8算法生成的uri（uri長度有限制，checksum8特征的原因）
7.所有條件輪空的處理

當第匹配到uri為hooks的key時，就會返回對應的響應，也就產生了beacon&stager uri異常訪問的問題。

當所有條件輪空時，也就是第7種情況，會再次通過checksum8算法匹配uri是否返回beacon的響應，與上文相比，去掉了uri長度的限制。此外，也會判斷是否stager關閉導致異常。如果i遍歷完成，返回404，由于對uri有特殊的情況，沒有判斷uri是否需要以/開頭。因此產生了一系列的特征。

這里比較有趣的是，while的條件是startsWith與isFuzzy判斷，通過對WebService所有實現類進行分析。MalleableHook的isFuzzy為true。也就是說WebServer對于beacon的交互的uri在后面隨便加東西都可以匹配、響應profile配置。個人感覺這也算是teamserver的特征吧。

特征修改

主要處理了/的問題和checksum8的問題，其他問題暫時不處理了，頭大。

webserver處理邏輯漏洞

請求狀態碼異常、beacon&stager uri異常訪問都是由于沒有校驗/的問題導致的，由于我使用的是javaagent，對于大段的代碼修改比較麻煩，我選擇在WebServer中serve進行修改。增加了一個/的檢驗，不過http://開頭的請求可能會收到影響，目前還清楚是什么功能，還需要進一步測試一下。

checksum8特征

checksum8特征有很多緩解的方法。

1.修改checkSum8的92L與93L為非默認的值（可破解）
2.更換算法（成本較高）
3.固定URI（容易形成新的特征）
4.kill stager（依賴客戶端操作）
5.設置host_stage（無法使用stager）

我同樣在serve函數中進行了patch，廢掉了checksum的匹配，缺點是必須配置profile的，可能也會有其他的問題，待測試。

    set uri_x86 "xx";
    set uri_x64 "xx";

javaagent實現

             else if(className.equals("cloudstrike/WebServer")){
                    ClassPool classPool = ClassPool.getDefault();
                    CtClass cls = classPool.get(className.replace("/","."));
                    CtMethod readResource = cls.getDeclaredMethod("serve");
                    readResource.setBody(
                            "{"+
                            "   if(!$1.startsWith(\"/\")) {" +
                            "       return $0.processResponse($1, $2, $3, $4, false, null, new cloudstrike.Response(\"400 Bad Request\", \"text/plain\", \"\"));" +
                            "   }" +
                            "   if(isStager($1)||isStagerX64($1)){" +
                            "       return $0.processResponse($1, $2, $3, $4, false, null, new cloudstrike.Response(\"404 Not Found\", \"text/plain\", \"\"));" +
                            "   }" +
                            "   return handleRanges($2, $3, $0._serve($1, $2, $3, $4));" +
                            "}");
                    return cls.toBytecode();
                }

效果

stager不會帶出了

異常的404也順帶解決了

aaa9已經無法請求

其他特征

本文主要分析了webserver的幾個特征，內存特征就不再這里提了，javaagent也是可以緩解的。4.5雖然對javaagent做了檢查，但是依然很好繞過。4.6貌似server和client分開了，可能就比較麻煩了。

參考：

https://cloud.tencent.com/developer/article/1967094?from=article.detail.1818330
https://github.com/Like0x/0xagent/blob/main/PreMain.java
http://cn-sec.com/archives/300922.html checksum8