【天穹】当木马开始向 AI 请教:一例“LLM 辅助规避”样本的完整剖析

· 2026-10-29 18:33 · 22 阅读

星图实验室 2026-10-29 18:33 北京

一、概述

过去的免杀,拼的是样本作者的经验;现在,攻击者把这道选择题交给了大模型。

近期,天穹沙箱捕获一份 x64 样本 9b5b0529dba5a43ebd01ba354ee30a25.x64.exe。样本启动后不到 3 秒,便向 api.openai.com 发起了一次标准的 Chat Completions 请求:它先把自己的运行环境“体检”一遍——进程列表、驱动列表、Hook 数量、AMSI 状态、内存与 CPU 信息——再把这份结构化情报,连同 39 种规避技术的清单一起发给 gpt-4o-mini,要求模型扮演“顶级红队操作员”,从中挑选最有效的规避方案,并给出置信度、成功率和备选技术。

天穹沙箱将这一行为标记为 “LLM 辅助规避”(危险级),并完整留存了请求报文。这是一个很有代表性的变化:攻击逻辑不再写死在代码里,而是在运行时向外部 AI 要答案,把“免杀决策”外包了出去。

但故事没有停在“问 AI”。同一次分析中,沙箱还捕获到:探测 amsi.dll、恢复 notepad.exe 线程、覆写 ntdll.dll 代码段以解除 Hook、连接 192.168.1.135:4444。随后,天穹智能体给出两个关键结论:一,样本属于公开学术研究框架 COGENT;二,样本内嵌一个可用的 OpenAI API Key,C2 是裸 TCP 反向 shell。这说明它并非一个只会执行固定动作的普通木马,而是一个内置“大脑”的攻击型木马。

这也是天穹智能体“动静结合”的工作方式:沙箱负责捕捉动态行为,智能体负责将行为与代码、情报进行对齐。沙箱回答“做了什么”,智能体回答“是什么、怎么做”——二者协同,完成了样本分析上的闭环。

二、样本信息

图1 沙箱综合评价

图1 天穹沙箱综合评价

从静态特征看,样本的“外壳”并不张扬:整体熵值 6.95 落在正常区间,但 .data 段熵值高达 7.94,提示高熵载荷被收拢在单个节内。

三、行为还原:从环境侦察到“自己动手”

1. 环境侦察

样本启动后没有急着外联,而是先做了一轮典型的环境探测:

  • 通过 CreateToolhelp32Snapshot / Process32FirstW 遍历进程列表,采集当前运行的进程;

  • 通过 PSAPI 的 EnumDeviceDrivers 枚举内核驱动;

  • 探测 Hook 数量与 AMSI(反恶意软件扫描接口)状态;

  • 通过 GlobalMemoryStatusEx、GetSystemInfo 获取内存、CPU 等主机画像;

  • 通过 IsDebuggerPresent、CheckRemoteDebuggerPresent 检查调试器。

这些动作本身并不罕见,罕见的是它们被结构化打包成了下面这段 JSON,并在同一秒内发往了大模型:

    {
    "processes": ["MsMpEng.exe", "9b5b0529dba5a43ebd01ba354ee30a25.x64.exe"],
    "drivers": ["WdFilter.sys", "kbdclass.sys"],
    "hooks": { "count": 0, "apis": [] },
    "amsi_status": "not_present",
    "system_info": { "process_count": 96, "memory_gb": 15, "cpu_count": 8 }
    }

    MsMpEng.exe 与 WdFilter.sys 正是 Microsoft Defender 的进程与过滤驱动。样本要的不是泛泛而谈,而是让模型先了解目标环境里装了什么安全产品,再给出针对性的规避方案。

    2. 智能决策

    天穹沙箱在 WinHttpSendRequest 处完整捕获到了请求体。核心内容如下(节选):

    图2 模型请求

    图2 模型请求提示词

    这段提示词的信息量很大:

    1. 角色设定

      :明确要求模型扮演“顶级红队操作员与恶意软件分析师”;

    2. 输入情报

      :把目标主机的进程、驱动、Hook、AMSI、资源信息作为决策依据;

    3. 候选方案

      :给出 39 项规避技术的“武器库”,要求模型从中择优;

    4. 输出约束

      :要求返回 edr_identified(识别出的 EDR 产品)、recommended_technique(推荐技术)、confidence(置信度)、reasoning(技术理由)、success_probability(成功率)与 alternative_techniques(备选方案);

    5. 温度参数

      :temperature: 0.7,意味着同一环境多次询问可能得到不同答案,攻击路径不再是固定值。

    也就是说,样本把“面对 Defender 该用哪一招”这类原本依赖作者经验判断的问题,变成了一次在线 API 调用。智能体在静态代码中还原出,请求中的 User-Agent 被伪装成 Chrome/120,让这次调用在流量侧更接近普通浏览器行为。

    3. 兜底决策

    如果说“问 AI”是这个样本最醒目的标签,那么接下来的一组行为,才真正体现了它的完整能力。模型请求发出约 42 秒后,样本开始转入本地动作链:

    1. 探测安全软件

      :检查 C:\Users\lichao\Desktop\amsi.dll 是否存在(本次返回 c0000034,即对象名未找到);

    2. 检测分析环境

      :调用 NtQueryInformationProcess(31),判断自己是否运行在调试或分析环境中;

    3. 跨进程恢复线程

      :恢复 c:\Windows\System32\notepad.exe 的 5060 线程执行,疑似注入;

    4. 代码覆写 / API Unhooking

      :从系统目录读取 ntdll.dll 的原始代码段,覆写内存中被 Hook 的模块,以规避安全监控;

    5. 变更权限

      :尝试调整进程权限(本次失败,返回 106);

    6. 连接 C2

      :向 192.168.1.135:4444 发起 TCP 连接。

    这组动作与”问 AI”形成了呼应:样本既会把”选哪一招”交给模型,也内置了 AMSI 探测、ntdll 解钩、线程恢复、C2 反连等可独立执行的”Plan B”。智能体结合沙箱行为与静态代码确认,API unhooking、内存/反射模块加载骨架等能力在代码中已经实现,并非完全依赖模型回复。

    本次分析中,由于无法访问 api.openai.com,沙箱未捕获到有效的模型响应;但样本仍然继续执行了后续动作。这也说明,把全部行为都归因于”模型回复”并不准确——它更像是一套 “AI 决策 + 本地兜底” 的组合。

    图3 高危行为

    图3 “高危”行为

    图4 行为逻辑图

    图4 样本行为逻辑图

    4.网络活动

    图5 网络活动

    图5 网络活动

    从流量上看,样本访问的是 OpenAI 官方域名,走标准 443 端口与 TLS,请求方法、路径、JSON 结构与正常业务调用几乎没有区别。如果只按域名或端口做封堵,这条链路很容易被归入“正常 SaaS 流量”。

    真正暴露意图的是另一条连接:192.168.1.135:4444/TCP。4444 是经典的反向 shell 端口;智能体结合沙箱流量与静态代码进一步确认,这是一条明文、无加密、无鉴权、无心跳的原始反向 shell,cmd.exe 的三个标准句柄被绑定到 socket,断线重连 5 次。沙箱侧捕获到的 TCP 状态变化,也与”连接尝试—被拒绝—重试”的过程吻合。

    四、智能体分析

    沙箱解决的是“它做了什么”,智能体则把沙箱行为与静态代码对上,回答“它是什么、怎么做的”。

    图6 智能体样本定性

    图6 天穹智能体分析报告

    1. 凭据与配置:可用的 OpenAI Key

    智能体在静态代码中提取到内嵌的 OpenAI API Key(sk-proj- 前缀,使用 0xAA 混淆)。这意味着样本不仅可以“问 AI”,还可能消耗他人的额度、留下调用痕迹。智能体建议立即吊销该 Key,并审计其历史调用(模型、时间、来源 IP、token 消耗)。

    同时,样本使用三重 XOR 混淆:0x55 用于载荷、C2 与 EDR 名称,0x5A 用于 API 名、api.openai.com、.text 段名与 cmd.exe,0xAA 用于 API Key 与变质 Stub;批量解密依赖 SSE 密钥表,API 全部动态解析。这也是静态分析中需要重点还原的部分。

    2. 反分析:约 20 秒时间炸弹与四重检测

    样本在 main 中设置了 5 亿次空循环,并以 GetTickCount64 作为阈值(约 19.9 秒);同时通过 PEB BeingDebugged、CPU 核数 <2、内存 <2GB、Sleep(0x5DC) 计时四重条件检测沙箱。此外,它还会以 SEC_IMAGE 方式重新映射磁盘上的 kernel32,回写 .text 段以清除用户态 inline hook。

    这解释了为什么动态分析只看到了攻击链的一部分:样本本身就有较强的时间与环境对抗设计。天穹沙箱的默认时长分析窗口、真实应用环境(Office/PDF/Chrome)与行为监控,仍然捕获到了 LLM 调用、AMSI 探测、ntdll 覆写与 C2 连接等关键证据。

    图7 智能体情报拓线

    图7 天穹智能体情报拓线:COGENT 归属

    五、天穹沙箱 + 智能体:让“AI 行为”成为可观测证据

    这份样本的价值,不只在于它是一个后门,更在于它展示了一种新的攻击范式:恶意逻辑开始借用外部大模型的判断力。天穹沙箱与智能体从四个层面给出应对:

    1. 识别“调用大模型”这件事本身

    天穹沙箱内置针对大模型调用的行为识别能力。样本访问 api.openai.com 时,沙箱没有把它简单归为一次普通 HTTPS 请求,而是结合请求路径、报文结构与提示词语义,将其标记为 “LLM 辅助规避”(危险级),并映射到 ATT&CK 矩阵中的网络通信类技术项。

    2. 完整留存请求体,让提示词可回溯

    沙箱捕获了完整的 POST 数据,包括模型名称、消息内容、39 项技术清单与输出格式要求。对分析人员而言,这不是一条“访问了 OpenAI”的日志,而是一份新型的攻击指令。

    3. 把侦察、决策、执行串成一条证据链

    进程遍历、驱动枚举、AMSI 探测、ntdll 覆写、线程恢复、DNS 解析、TCP 连接在报告中按时间线排列。原本需要反复逆向才能拼出的“先看环境、再问 AI、最后反连”的流程,可以在沙箱报告中直接读取。

    4. 智能体动静结合,双引擎互证

    智能体将这些动静态证据纳入研判,最终给出 COGENT 归属结论。而唯有会 “思考” 的沙箱,才能同时回答这三个问题:”它做了什么””它是什么””它怎么做到的”。

    当攻击者开始向 AI 请教,防守方需要的不是更长的黑名单,而是能看懂“它在问什么”、也能追到“它最后做了什么”的沙箱。

    六、IOC

      恶意文件(SHA1)
      5ce104df7cded4ef8439e69887b332b35538d41a 样本

      报告链接:(https://sandbox.qianxin.com/tq/report/toNewReport.do?rid=b480688eb8f81fc76549ac18415dc2d6&sk=99430062)

      天穹智能分析平台(联系我们申请账号):https://sandbox.qianxin.com

      天穹智能分析平台持续迭代升级,致力于为每一位样本分析人员打造更高效、更智能、更易用的分析平台——这始终是我们不变的初心与追求。

      如果您希望深入了解平台功能,或在使用过程中遇到任何问题,欢迎随时联系我们。您的反馈,是我们进步的重要动力!

      跳转微信打开

      本文转载自微信公众号「奇安信技术研究院」,查看原文。版权归原作者所有,如有侵权请联系删除。