CobaltStrike逆向学习系列(10)：TeamServer 启动流程分析

这是[信安成长计划]的第 10 篇文章

关注微信公众号[信安成长计划]

0x00 目录

0x01 基本校验与解析

0x02 初始化

0x03 启动 Listeners

在之前的分析中，都是针对 CobaltStrike 整体通信流程的，也就忽略了中间的一些细节，其中一些细节对理解整个 CobaltStrike 也是非常重要的

0x01 基本校验与解析

先取了默认端口

接着对 Java 环境及一些参数进行了验证，并校验了 license

这里重点看一下对于参数的检测，可以看到有校验两个参数是否存在，当你在跑 Controller 的时候，最好也一样将其参数加上，不然有可能会出现一些莫名其妙的问题

对于 IP 等内容的判断就不重点关注了，看一下他在解析 C2Profile 时候的对比，如果有指定的话，会走下面那个流程，直接将地址传入 LoadProfile

而在默认情况下，则调用了 LoadDefaultProfile，但它实际还是调用了 LoadProfile，然后直接加载了 resources 中的默认文件

之后就到了最关键的初始化环境的地方

0x02 初始化

先在 C2Profile 中增加了两项内容，license 认证中的水印与当前的路径，具体作用暂时也不清楚

接着初始化 Resources 对象，并传入了 this.calls，它是一个 HashMap，对于后续所有的调用都至关重要

在初始化 Resources 的时候，对两个内容进行了初始化，它们内部都创建了新线程，根据名字也可以明显的看出，ServerBus 是 TeamServer 所有运行内容的通道，所有的调用都是从这里走的，Archiver 属于日志类型的操作了，在调试的时候，时不时出现的 archiver 类型的数据包也就是从这里出来的

在 ServerBus 中，除了将 calls 传入之外，就直接 new 线程了

整个的逻辑也很明确，与 TeamQueue 等文件的处理方式是类似的，在接收到信息以后，从 calls 中获取到对应的类型，然后调用对应的 call 来完成后续的流程处理

再来看一下 Archiver 的相关处理，除了后面会 broadcast 信息之外，刚开始的 PersistentData 还是比较重要的

在中间直接创建了新线程

处理逻辑跟前面也差不多，判断是否有数据，如果有处理

大致也就猜出来是将数据存储到文件中

回到主流程中，接着将 C2Profile、IP、密码等信息也存储到 this.resources 中

然后往 this.calls 中存入了几个测试数据

对于这种 Test 的操作，在 CS 中也有很多，还有一个专门用来负责处理断言操作的类

然后往 this.calls 中存入了数据

这些实际上才是最关键的内容，根据上面 ServerHook 可以看到，在执行的时候，会根据这个类型来决定调用哪个类中的 call，也就决定了最终的处理流程

接下来的一众操作都是这个样子，为后续处理做了相当充足的工作

而且中间也能够看到很多东西了，发布任务时候的 beacons.task，启动监听的 listeners.go 都是在这里设置的，所以也就是说在 Controller 与 TeamServer 通信时，所传输的 beacons.task 等，最终都是在 ServerHook 中根据之前存储好的类型来最终决定处理流程的

经过这一波操作，this.calls 已经增加到了 64 个，接着又进行了一堆操作，增加了对数据的处理

所遍历的就是下面这些内容

然后通过如下的方式来进行了批量的添加，this.calls 最终达到了 106 个

接下来就是之前分析的与 Controller 进行通信的部分了

0x03 启动 Listeners

为了验证前面所提到的流程，这里用启动监听来作为说明

跟入后可以发现，它在 ServerBus 中增加了一项

所以就直接在 ServerBus 的处理线程中截取到

取出类型是 Listeners，就直接调用到了 Listeners 中的 call 方法，但是很明显它什么也没干，又用刚才的逻辑调用到了 beacons.start

一样通过刚才的逻辑进入相应的处理

在其中它根据 Listener 初始化了相对应的监听

这里用的是 HTTP

接着初始化了 RSA 公私钥

如果文件存在的话，就不会再生成了，所以还是自己做一份为妙

然后也将这些信息存储到了 BeaconC2 当中

接着就根据刚才初始化到信息启动相应的监听

然后将监听类与 Payload 存储到一个 HashMap 当中

就完成了监听的启动

接着又用同样的逻辑调用了 listeners.set_status，然后将信息存储到 Listeners 的 Map 当中

然后又调用了broadcast，通过 BroadcastWriter 将信息回传到 Controller

这样也就完成了所有的操作