编程技术-CobaltStrike分析1 - stager 生成流程分析

最近论坛发布了CS4.8的破解版，抱着学习的心态准备重新分析分析一遍相关内容，本文章将会是一个系列文章，围绕 CS马的生成流程、逆向分析、常见特征检测和对抗分析，由于本人不擅长流量侧的分析，因此没有分析流量侧相关的内容。

1 WindowsExecutableDialog

CS 客户端页面的相关操作都可以在\aggressor\dialogs中找到，本文接下来将基于 windows 可执行 stager 进行分析，所以首先会找到对应WindowsExecutableDialog，其页面和对应的操作如下所示：

跟进dialog/DialogManager.java 的 action函数，记住这边传递过来的 str 是 Generate

继续跟进 action_noclose 函数：

在点击按钮之后新建了线程然后调用了 dialogAction 方法，而 WindowsExecutableDialog 实现了 DialogListener，同时 override 了 dialogAction 方法，其关键代码如下，其中生成 payload 的函数就是 getPayloadStager。

继续往下跟进 ScListener.java 查看 getPayloadStager 函数：

查看 Stagers.java 的 shellcode 函数：

有三个参数，第一个是上层传递下来的 listener，第二个是 payload 名称，第三个是上层传递下来的参数，标识了 payload 的位数。

调用 GenericStager 的 create() 方法生成对应的 shellcode，GenericStager 是一个抽象函数，其不同的 listener 和架构的实现均存在 stagers 目录下，这里以windows/beacon_http/reverse_http，模式的listener为例，其对应的实现是 BeaconHTTPStagerX64：

同时 BeaconHTTPStagerX64 继承 GenericHTTPStagerX64

而 GenericHTTPStagerX64 又继承 GenericHTTPStager，GenericHTTPStager 实现了 generate() 方法，这也是 payload 生成的位置：

在最后调用了 post 方法：

创建一个新的线程，调用 dialogResult 方法，该方法位于 WindowsExecutableDialog.java

由于选择的是64位 windows exe，因此调用图中的 patchArtifact 进行 patch

跟进另一个 patchArtifact

调用 _patchArtifact，这里就是最终处理的位置，第一个参数是写入的 payload 信息，第二个参数则是传递过来的字符串 artifact32.exe

2 beacon config

这里就以 beacon 类型生成为例说明, 函数调用顺序如下所示

其中beacon config生成的位置在

仔细观察 exportBeaconStage：

在后面会调用beacon_obfuscate 混淆 beacon config