Cobalt Strike 的通信过程 & 协议

目录

通信流程

下载 Beacon

第一次心跳

 AES 密钥和 HMAC 密钥

获取下发命令

发送命令执行结果

扩展

---

这篇文章的主要内容是利用流量分析 Beacon 与 Cobalt Strike 服务端之间的通信过程，包括上线、心跳、命令下发与返回命令结果。当然，流量是加密的，需要一些辅助工具或脚本，其中的功能包括提取公钥/私钥，数据包解构与字段分析等等。

通信流程

先从 payload 开始说起。

Cobalt Strike 提供了两种类型的 payload —— staged（有阶段的）和 stageless（无阶段的）。有阶段是类似于小马拉大马的过程，先上传一个小马到受害者主机，执行后再通过这个小马下载功能更强大的大马去执行，而无阶段是直接上传大马去执行。

比较下来，staged 比 stageless 多一次下载大马的过程，所以前者的通信过程要比后者的多一次请求-响应。

这里以 staged payload 做描述，文件名为 beacon.exe，设置的监听器是 windows/beacon_http/reverse_http，即 HTTP 类型的 beacon。

通信的流程如下：

图中描述了 4 次交互过程，如果是 stageless payload 省略第一次请求-响应，换句话说，直接到上线的步骤。以下这 4 次交互过程进行说明：

1. 第一次请求时， beacon.exe 程序请求下载完整的 payload；

2. 下好 payload 就直接在内存里运行，也就是说 beacon 开始运行，它做了如下操作：

（1）收集主机信息，生成用于协商的原始密钥 raw key，还有一些其他数据；

（2）用 RSA 公钥加密这些数据，将其存储在请求包的 cookie 中，然后发送给 CS 服务器。

这是第一次心跳，之后 beacon 进入睡眠时间。而CS 服务器收到后，做以下操作：

（1）用 RSA 私钥解开密文，从中提取主机信息和 raw key；

（2）在 target 列表生成一个新的主机；

（3）基于 raw key 生成 AES KEY 和 HMAC KEY，用于后续的加密通信。

3. 睡眠时间过后，beacon 再次发送心跳包，这次发送的目的是询问 CS 服务器是否有命令下发。

如果有，CS 服务器将包含命令的数据用 AES 加密得到密文，以及用 HMAC KEY 计算出 hash ，以 (AES 密文+hash) 的格式存放在 response  报文的响应体中。

如果没有，就跟第一次心跳一