Cobalt Strike的raw payload原理

在Cobalt Strike的攻防世界里，payload的形态直接决定了它能否穿过层层防御的关卡。除了那些被安全软件高度关注的生成格式，raw payload——一种纯粹的二进制“原料”——为攻击者提供了一种回归本质的隐匿路径。理解它的原理，就像拆解一个精巧的时钟，你能看到的不仅是齿轮的转动，更是时间本身如何被悄然窃取。

Raw Payload：未被包装的“源代码”

与Cobalt Strike直接生成的EXE或DLL不同，raw payload（通常保存为.bin文件）本身并不是一个可执行文件。你可以把它想象成一卷未冲洗的胶卷，或者是一段尚未被编译成机器码的汇编指令序列。它本质上就是Beacon shellcode的原始字节码转储。在生成时，操作者会特意剥离掉所有PE（可移植可执行）文件的结构头、导入表、重定位信息等“元数据”，只保留最核心的、能在内存中直接运行的那部分指令。

这带来了一个最直接的好处：静态特征几乎消失。传统杀毒软件依赖的文件结构分析和特征码匹配，在面对一坨没有头尾的二进制数据时，很容易失焦。它既不是标准的EXE，也不是已知的脚本，就像一个没有标签的罐头，安检机器难以判断里面装的是什么。

从“原料”到武器：加载器的桥梁作用

但raw payload自己不会跑，它需要一个“放映机”来播放这段胶卷。这个放映机，就是独立的加载器（Loader），例如HanzoInjection这样的工具。加载器的任务非常明确：

• 读取：以二进制文件形式，将raw payload的字节序列完整读入进程内存。
• 分配：在目标进程（可能是自身，也可能是通过进程注入技术选择的另一个合法进程，如explorer.exe）的地址空间中，申请一块具有执行权限的内存。
• 写入：将payload字节码复制到这块可执行内存中。
• 执行：通过创建远程线程、APC注入或回调函数等方式，将CPU的执行流跳转到这块内存的起始地址。至此，Beacon shellcode被激活，开始与团队服务器建立连接。

这个过程实现了文件与行为的分离。防守方可能在磁盘上发现一个可疑的.bin文件，但如果没有加载器，它毫无威胁。而加载器本身，可以是一个看似无害的、甚至带有合法签名的工具，或者被深度定制化以规避检测。

隐匿性的双重博弈

Raw payload策略的隐匿性，体现在两个层面，其实也是一场风险转移的博弈。

首先是静态层面。正如前文所述，剥离了PE结构的payload如同一张白纸，极大增加了基于文件的静态检测难度。攻击者甚至可以进一步对raw payload进行简单的编码或加密，让字节序列看起来更加随机，把检测压力完全抛给加载器的解密例程。

但真正的博弈点转移到了动态和行为层面。加载器执行内存分配、权限更改、代码写入和线程创建这一系列操作，恰恰是EDR（终端检测与响应）和高级杀软紧盯的高危行为序列。防御者的注意力，从“文件是什么”被引向了“程序在做什么”。一个编写拙劣的加载器，其产生的系统调用序列和内存操作模式，会比payload本身更快地触发警报。

所以，高水平的攻击者会精心打磨加载器，采用诸如直接系统调用（Syscall）、回调函数执行、进程镂空（Process Hollowing）或模块不落地等技术，来模拟合法软件的行为模式，试图在动态检测的视野下“隐身”。

原理之外的现实考量

理解原理是一回事，在实战中应用又是另一回事。采用raw payload方案，意味着攻击链多了一环，复杂度随之增加。你需要管理两个组件：payload文件和加载器。部署上，要么分两次投递，要么将它们捆绑（这又可能引入新的特征）。

更重要的是，这种“分离术”在红队评估中是一把双刃剑。它提供了规避传统AV的潜力，但也留下了更丰富的行为日志供蓝队分析溯源。一次成功的绕过，可能源于加载器技术足够新颖；而一次失败的触发，往往是因为加载器的行为在EDR眼里太过“经典”。

说到底，raw payload不是什么魔法。它只是将攻击载荷的生命周期，从一个完整的可执行文件，拆解成了“存储态”和“执行态”。这场猫鼠游戏的核心，始终围绕着如何在内存中悄无声息地完成那惊险的一跳。当防御者开始普遍关注内存行为与进程关系时，攻击者的创造力，就不得不从文件格式的把戏，转向更深层的系统交互艺术。