文章作者：黑白天实验室
Beacon 通常是反射加载到内存中，还可以配置各种内存中混淆选项以隐藏其有效负载。
Beacon 可以配置各种内存中混淆选项以隐藏其有效负载。例如，obfuscate-and-sleep 选项会试图在回调之间屏蔽部分 Beacon 有效负载，以专门避开基于特征的内存扫描。
Obfuscate and Sleep是一个Malleable C2选项，在Cobalt Strike 3.12.引入。启用后，Beacon将在进入Sleep状态之前在内存中混淆自身。
那么我们先使用默认的关闭Obfuscate and Sleep来查看CobaltStrike进行进程注入会的具体情况。
然后我们把进程注入到微信中。
注入微信进程
正常执行命令
然后我们在目标主机中使用Process Hacker 2进行检测查看：
查找调用 SleepEx 的线程来定位内存中的 Beacon，一般在比较活跃的之中。
然后，我们可以将关联的内存区域进行分析，转到Memory查看分析这个偏移量。
我们可以对比看一下Beacon的情况：
转到Memory查看分析这个偏移量并对比一下：
可以看到我们可以看到我们的整个beacon在内存中未加密。
检测这样没有加密的beacon不难，我们在最简单的做法是，从这个区域挑选一些独特的字符串并将它们用作我们的检测的特征就行。
rule cobaltstrike_beacon_strings{meta:author ="Elastic"description ="Identifies strings used in Cobalt Strike Beacon DLL."strings:$a = {70 6F 77 65 72 73 68 65 6C 6C 20 2D 6E 6F 70 20 2D 65 78 65 63 20 62 79 70 61 73 73 20 2D 45 6E 63 6F 64 65 64 43 6F 6D 6D 61 6E 64 20 22 25 73}condition:any of them}
当然上面的我只是举个例子，在实战中还得细一点。
国外也有个安全研究人员给出了个yar
rule cobaltstrike_beacon_strings{meta:author = "Elastic"description = "Identifies strings used in Cobalt Strike Beacon DLL."strings:$a = "%02d/%02d/%02d %02d:%02d:%02d"$b = "Started service %s on %s"$c = "%s as %s\\%s: %d"condition:2 of the}
同时Cobalt Strike给出了一种Bypass方法
# Obfuscate Beacon, in-memory, prior to sleepingset sleep_mask "true";
Set sleep_mask “true”; 设置使beacon在睡眠之前混淆内存中的代码,睡眠后对自己进行混淆处理
可以看到在混淆内存中的代码，然后我们使用前面的规则并不能检测到了beacon
其实如果你刷新几次也可以发现解密的beacon,因为在每次使用beacon，都会重新加密数据和字符串。
那么我们也可以多检测几次也可以检测到：
因为我现在使用的4.3的Cobalt Strike，使用 13 字节的 XOR 密钥，
如果是4.2以下Cobalt strike 使用的是使用简单的单字节 XOR 混淆，使用下面的yar一样可以检测：
rule cobaltstrike_beacon_xor_strings{meta:author = "Elastic"description = "Identifies XOR'd strings used in Cobalt Strike Beacon DLL."strings:$a = "%02d/%02d/%02d %02d:%02d:%02d" xor(0x01-0xff)$b = "Started service %s on %s" xor(0x01-0xff)$c = "%s as %s\\%s: %d" xor(0x01-0xff)condition:2 of them}
这里不多讨论。
侵权请私聊公众号删文
如有侵权请联系:admin#unsafe.sh