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

admin 2022年4月23日02:34:24CobaltStrike逆向学习系列(10)-TeamServer启动流程分析已关闭评论120 views字数 1819阅读6分3秒阅读模式

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

0x01 基本校验与解析

先取了默认端口

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

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

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

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

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

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

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

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

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

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

0x02 初始化

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

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

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

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

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

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

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

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

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

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

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

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

在中间直接创建了新线程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0x03 启动 Listeners

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

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

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

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

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

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

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

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

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

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

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

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

这里用的是 HTTP

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

接着初始化了 RSA 公私钥

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

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

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

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

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

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

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

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

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

就完成了监听的启动

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

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

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

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

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

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

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月23日02:34:24
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   CobaltStrike逆向学习系列(10)-TeamServer启动流程分析http://cn-sec.com/archives/916927.html