CobaltStrike WebServer 4.4 特征分析
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