基于异常行为检测CobaltStrike-安全客

前言

在很多攻击活动中，我们都能看到 CobaltStrike 的身影，所以，对于防御者，了解其在各个攻击阶段的行为特征是非常有必要的

上篇文章——《威胁狩猎的最佳实践》里提过一些检测方法，本文正好以CS为例，介绍下behavior-based的检测手段

全文结构参考ATT&CK攻击框架展开，主要涉及CS内置或者常用的使用姿势，检测思路仅供参考

攻击阶段

Execution

CS中有很多用于后渗透的攻击模块，它们的加载通常是借助调用Windows DLL的方式来实现

这意味着攻击者在使用这些内置工具的时候，CS会临时拉起一个进程并使用rundll32.exe实现恶意代码注入

更重要的是，为了传递输出信息，这些攻击模块会通过命名管道(named pipe)的形式与beacon产生通信

通常情况下，CS会采用以下默认的风格给管道进行命名：

\postex_*
\postexssh*
\status_*
\msagent_*
\MSSE-*
*-server

当然，攻击者能够自行修改命名方式，不过这一点容易被很多人忽视，大家也可以检视下自己平上时有没有这样的习惯，更多内容请参考官方文章

那么站在防御者的视角，我们可以使用 sysmom 等日志采集工具观测到以下行为：

除了关注管道的命名风格，CS在利用rundll32.exe进行代码注入的过程中，也有一定的行为特征，比如下图中的父子进程关系和参数调用：

虽然我们的操作系统在日常活动中也会经常用到rundll32.exe，但这里有所不同的是——它被调用时不带任何参数，这种调用过程同样值得防守方加以关注

对于windows上这类常见的系统进程，日后我会再专门写些文章去深入分析它们的行为基线，此处留个坑先…

Defense Evasion

在这一攻击阶段，CS中最常用的手法就是进程注入(process injection)

例如通过远程代码注入伪装成svchost.exe，或者注入lsass.exe后从内存中提取访问凭证

要想达到优秀的检测效果，我们最好双管齐下，一是理解攻击原理，二是理解日志记录的原理

关于CS实现进程注入的过程，可以参考官方的这段说明，这里我拿其中的配置文件为例：

process-inject {
    # set how memory is allocated in a remote process
    set allocator "VirtualAllocEx";

    # shape the memory characteristics and content
    set min_alloc "16384";
    set startrwx  "true";
    set userwx    "false";

    transform-x86 {
        prepend "\x90\x90";
    }

    transform-x64 {
        # transform x64 injected content
    }

    # determine how to execute the injected code
    execute {
        CreateThread "ntdll.dll!RtlUserThreadStart";
        SetThreadContext;
        RtlCreateUserThread;
    }
}

参考上述执行流程，我们可以将其分解成四步：

获取远程进程的句柄
在远程进程中开辟内存空间
将shellcode复制到远程进程
在远程进程中执行shellcode

结合sysmon的监测能力，先拿两类日志为例吧：EID 8 和 EID 10

在上述流程的第一步，使用OpenProcess获取进程句柄的活动会被sysmon记录成EID为10的日志

而该日志类型有两个字段值得我们关注——TargetImage和GrantedAccess

前者就是目标进程，后者与访问权限相关，不同位掩码代表的权限关系如下：

Access	Mask
PROCESS_CREATE_PROCESS	0x0080
PROCESS_CREATE_THREAD	0x0002
PROCESS_DUP_HANDLE	0x0040
PROCESS_SET_INFORMATION	0x0200
PROCESS_SET_QUOTA	0x0100
PROCESS_QUERY_LIMITED_INFORMATION	0x1000
SYNCHRONIZE	0x00100000
PROCESS_QUERY_INFORMATION	0x0400
PROCESS_SUSPEND_RESUME	0x0800
PROCESS_TERMINATE	0x0001
PROCESS_VM_OPERATION	0x0008
PROCESS_VM_READ	0x0010
PROCESS_VM_WRITE	0x0020

拿mimikatz使用过程中涉及到的权限为例：

Command	Sysmon 10	Security 4663 Kernel Object
lsadump::lsa /patch	GrantedAccess 0x1438	AccessMask 0x10
lsadump::lsa /inject	rantedAccess 0x143a	AccessMask 0x10
lsadump::trust /patch	GrantedAccess 0x1438	AccessMask 0x10
misc:memssp	GrantedAccess 0x1438	AccessMask 0x10
Procdump mimidump	GrantedAccess 0x1fffff	AccessMask 0x10
Task Manage minidump	GrantedAccess 0x1400, 0x1000, 0x1410 and 0x1fffff	AccessMask 0x10
sekurlsa::*	GrantedAccess 0x1010	AccessMask 0x10

这其中，0x1fffff 较为惹人注目，其意味着被赋予了所有权限，而我们的CS在代码注入活动中正是这样表现的：

到了进程注入的最后一步时，CS经常会调用 Win32 API CreateRemoteThreat，而这又会引起sysmon中日志类型ID为8的注意

这类日志不仅会记录API调用过程中的源进程和目标进程，还会记录新线程的起始地址和起始函数等信息

针对这一类行为的检测，同样可以从两方面入手，一是建立行为基线

生产环境中会调用 CreateRemoteThreat 的进程不多，常见的有反病毒程序和svchosts.exe、services.exe、wininit.exe等

参考 sysmonconfig.xml 等配置文件，可以维护一份白名单，对基线外的异常行为加以关注

另一方面，日志中的 StartAddress 等字段同样能起到一些辅助作用，Olaf Hartong 以前针对这一检测点专门写过<a href=”https://medium.com/@olafhartong/cobalt-strike-remote-threads-detection-206372d11d0f”>文章

尽管在后续版本中有所变化，但是这一思路仍然能应用在检测技巧中提高相关进程行为的风险暴露程度