0x00 背景

CobaltStrike（简称CS）作为一款渗透测试神器，采用C/S架构，可进行分布式团队协作。CS集成了端口转发、服务扫描、自动化溢出、多模式端口监听、Windows exe与dll 木马生、Java 木马生成、Office 宏病毒生成、木马捆绑等强大功能，深受广大红队同学的喜爱。为了规避侦测，红队往往会对CS采用一些隐匿手段，常见方式有云函数和CDN等。这些隐匿手段隐匿了CS的真实IP，诸如DDoS之类的流量无法穿透CDN到达CS，常规的攻击方式难以对CS服务器形成有效干扰和打击。只能止步于此了吗？有没有反击CS的奇技淫巧？答案当然是肯定的！接下来带各位看官体验一种批量伪造肉鸡来戏耍CS的新方法，希望各位蓝队同学引（付）以（诸）为（实）戒（践）。

0x01 CS上线流量特征分析

首先，我们先研究下CS上线的流量有无特征。图1使用Wireshark分析HTTP型Beacon的上线包。

图1

肉眼来看，上线包的敏感信息隐藏到了Cookie中，特征非常明显。通过进一步分析，我们发现上线包的请求Cookie值是受控主机元数据经过非对称加密后的密文，CS服务器接收到Cookie值后进行解密从而获取到受控主机信息。受控主机元数据包含了若干敏感信息，如图2所示：

图2

此处划重点，HTTP型Beacon 上线包的核心在于Cookie，而Cookie是对受控主机元数据的非对称加密的密文。

0x02 HTTP Beacon重放实验

由于HTTP属于明文传输协议，HTTP型Beacon的上线过程存在中间人重放的可能。

我们做了一个简单的测试，验证了这种可能性（此处迫于运营小姐姐压力，稍微有凑字数嫌疑）。

首先抓取测试环境中的HTTP Beacon上线请求，使用Python脚本（如：图3）进行重放（注意：Header头信息不能错误，CS Server对Header头检查非常严格）。

图3

结果显示，重放Response符合我们的预期，CS Server成功响应了我们的请求。（如：图4）

图4

此外，红队同学在使用CS时候会自定义Malleable C2 Profile修改默认流量特征，但是这个对中间人重放没有影响。

新的问题产生了。

中间人重放的方法，只能伪造已经上线的主机，不能伪造新的受控主机。

这句话翻译过来就是，没啥鸟用。

好了，字数凑够了。书接上回，言归正传。

现在聚焦最迫切的问题：有没有办法伪造全新的受控主机呢？

答案当然是肯定的。

0x03 新主机伪造

我们先看一个效果图（如：图5）。

图5

短时间内大量主机上线。想想1分钟上线了千八百个主机，红队同学是不是有点慌？这是如何做到的呢？

我们以Stager型Beacon为例，按照KillChain模型从攻击者角度回顾下CS上线流程（如：图6）。

图6

攻击者利用CS Server生成新的Beacon监听（包括一对非对称公私钥）并生成Stager；

攻击者投递Stager到受控主机；

受控主机在Exploit阶段执行小巧的Stager；

受控主机根据Stager Url请求特征向Beacon Staging Server下载体积较大更复杂的Stage到本地，Beacon Staging Server会校验Url的合法性；

Stage解密并解析Beacon配置信息（比如公钥PublicKey、C2 Server信息）；

Stage通过公钥PublicKey加密主机的元数据并发送至C2 Server；

C2 Server用私钥解密数据获取主机元数据。

从上述流程中，我们能Get到2个核心点：

Stager Url校验算法

Beacon配置的解密算法

与CS Server合法通信的问题等价转换为获取Stager Url和Beacon解密问题，即：

CS/C2 Server合法通信  = （Stager Url校验算法，Beacon解密算法）

只要拿到了（Stager Url校验算法，Beacon解密算法），相当于我们掌握了与CS/C2 Server合法通信的凭据。我们分别对上述2个核心点进行分析。

0x04 Stager Url校验算法

Stager Url校验算法在公开的NSE脚本中可以找到，关键函数包括：checksum8、MSFURI、isStager。

其中，MSFURI函数从大小写字母+数字的字符数组中随机指定长度的字符序列并调用checksum8函数计算字符序列的ASCII和与256的模是否等于固定值（32位Stage与64位Stage分别使用92、93作为固定值），如果相等返回字符序列，否则继续直至找到符合条件的字符序列。MSFURI（如：图7）、checksum8（如：图8）、isStager（如：图9）函数的定义：

图7

图8

图9

如果找到符合条件的字符序列，则作为Stager Url向Beacon Staging Server发送下载请求。Beacon Staging Server在_serve函数中校验Url的合法性，如：图10。

图10

至此，我们获取到了Stager Url的校验算法，手动下载Stager。下载效果如图11下：

图11

很好！已经成功一半了。接下来，我们再来研究Beacon配置的解密算法。

0x05 Beacon配置解密算法

感谢前人栽树！

之前已经有人发布了Beacon配置的解密算法，比如JPCERT的Volatility插件cobaltstrikescan（https://github.com/jpcertcc/aa-tools/blob/master/cobaltstrikescan.py）、美国SentinelOne安全公司开源的CobaltStrikeParser工具（https://github.com/Sentinel-One/CobaltStrikeParser）等。

具体的解密算法此处不再赘述，感兴趣的同学可参考上述的开源工具。解密结果如图12所示：

图12

从解密的配置中可以看到PublicKey和C2 Server地址。

OK！2个算法我们都已经搞定，接下来就该反击CS了！

0x06 反击！

万事俱备，只欠东风！

想象以下场景：蓝队同学防守时获取到了一个CS的上线地址。

首先，构造Stager Url下载Stage，如果在抓到CS上线地址的同时抓到了Stage，此步可跳过。

然后，解析Stager Beacon的配置文件，得到了PublicKey公钥与C2 Server地址。

最后，构造虚假主机元数据，加密发送至C2 Server。

Github上开源的CobaltSpam（https://github.com/hariomenkel/CobaltSpam）已实现此功能，但CobaltSpam上线的主机信息都是随机生成，很容易被识破。因此，需要将主机信息伪造的更加准确，提高混淆度。

最终，通过修改CobaltSpam代码，添加自定义的更加精准的主机信息，达到了我们想要的效果，如：图13。

图13

最终效果见下图（图14）！！！

图14

0x07 结语

通过这种以假乱真的方法，蓝队同学可很好的混淆红队同学的视线，以此来反制攻击者。

对于低级的攻击者而言，目前不能够很好的防御这种攻击手段。

同样，上面提及的2种算法可用于Beacon Staging Server和C2 Server的挖掘。

目前，防御上述反制的方法，可通过修改CS代码上述2种算法的逻辑，阻止虚假主机上线和C2挖掘。

在HVV过程中，如果发现红队的CS木马样本或者CS服务器，我们可以用上述方法来混淆红队同学的视线、拖延他们的时间，让红队同学陷入怀疑人生的地步。

参考链接：

1. 360 浅析CobaltStrike Beacon Staging Server扫描

2. stager解密脚本

3. CS beacon通信分析

4. CobaltSpam

5. HarioMenkel