文章总结： 作者通过搭建AI分析实验室发现，合理引导下的LLM能显著提升恶意软件分析效率，如快速生成脱壳脚本。然而LLM生成的报告和判定结论仍存在错误，不可直接采信。文章建议将其作为辅助工具，优先生成可验证的脚本而非单纯报告，并强调工具集成与专家验证的重要性，同时需警惕其被滥用为虚假信息源的风险。 综合评分： 89 文章分类： 恶意软件,AI安全,实战经验,逆向分析,安全工具

LLM 恶意软件分析实战：正确的使用方式

Karsten Hahn Karsten Hahn

securitainment

2026年3月8日 17:55 中国香港

| 原文链接 | 作者 | | — | — | | https://blog.gdatasoftware.com/2026/03/38381-llm-malware-analysis | Karsten Hahn |

LLM 刚流行起来的时候，我内心是抵触的。我担心很多人不会把 “LLM 并不总能输出事实” 这个警告当回事，虚假信息在未来几年可能会成为一个严重的问题。

我的担忧果然成真了，而且蔓延到了我最钟爱的领域：恶意软件分析。我看到有人在网上发布看起来很专业的 AI 生成分析报告，里面充满了错误和臆断，却赢得一片叫好。一些安全研究人员坦言，他们经常把混淆代码粘到 AI 对话框里，让 AI 去反混淆，然后直接把结果当作事实——尽管他们心里清楚其中大概率存在幻觉。理由很简单：因为省事。然而，恶意软件分析报告中的事实准确性至关重要。缺乏事实准确性的分析不仅毫无价值，甚至可能造成危害。

尽管内心充满负面情绪，我还是决定亲自试一试，彻底测试一番。是什么让我改变了想法？我被 AI 打败了。

图 1：对一个干净文件生成的 AI 垃圾分析报告

我们很多逆向工程爱好者都泡在 Discord 频道里，交流学习资源、新工具和恶意软件报告。初学者经常来请教样本分析的问题。有一天，有人求助如何对一个恶意软件样本进行脱壳。我立刻着手处理，但花了半个小时才推进到第二阶段，而且只是稍微给他们指了指方向。就在我发完消息十秒钟后，一个经验同样不多的逆向工程新手就搞出了一个覆盖所有阶段的脱壳脚本。我震惊了——我在这个领域已经干了 11 年，自认为经验相当丰富。至少丰富到能判断出一个初学者的分析不可能 那么快完成。于是我问他们是怎么做到的。答案你大概已经猜到了：AI。而且这是一次很好的 AI 应用，因为脱壳脚本可以轻松验证——在样本上跑一下就知道结果了。

于是，我终于放下情绪，咽下自尊心，搭建了自己的 AI 分析实验室，看看它的实际表现如何，以及能否成为我工具箱中的得力助手。

LLM 分析实验室搭建

我的配置如下：两台虚拟机，一台运行 Remnux，另一台运行 Windows 10。在 Remnux 虚拟机上，我安装了 Claude 和 OpenCode，并部署了以下 MCP 服务器：

• remnux
• remnux-docs
• x64dbg
• virustotal
• ssh-mcp
• ghidra-mcp

图 2：基于 LLM 的分析实验室

ssh 和 x64dbg MCP 连接到 Windows 10 虚拟机。这台虚拟机除了内部网络适配器外完全隔离，专门用于运行恶意代码；而 Remnux 则供 AI 进行静态分析。Remnux 虚拟机需要联网，AI 客户端才能正常工作。

一开始我测试了三个模型：OpenAI GPT 5.1、OpenAI GPT 5.1-mini 和 Claude Sonnet 4.6。

我从简单的样本入手——一个利用较早期公式编辑器漏洞 (CVE-2017-11882) 的 Office 文档。

我先试了 GPT 5.1-mini，想看看更便宜的模型能否胜任分析工作。然而结果令人失望。简单的初步分类确实能做，但同样的事情我写个小脚本就能自动化——完全不需要 LLM。而面对更复杂的任务，模型频繁得出错误结论，根本没有产出任何有用信息。我放弃了这条路——除了哈希值和概览元数据，什么有价值的东西都没得到。

以公式编辑器漏洞为例，GPT 5.1-mini 告诉我样本是干净的，因为不包含宏，但发现了一个”非常可疑”的域名：decalage.info。这很逗，因为 decalage.info 其实是 oletools 的官方网站——一套用于逆向分析 MS Office 文件格式的 Python 工具。工具在输出中打印了自己的域名，而模型无法区分工具头部输出和真正从样本中提取的信息。后来 GPT 5.1 也犯了同样的错误。我试着引导 GPT 5.1-mini 通过模拟执行某个文件来获取下一阶段的 URL，但它多次尝试使用 Unicorn 均告失败。我再试一次，明确告诉它对 shellcode 文件使用 Speakeasy（因为这是我自己用过的有效方法），它又失败了。此后我再也没用 GPT 5.1-mini 做过类似尝试。

GPT 5.1 和 Sonnet 4.6 的表现与 mini 模型截然不同——当然需要做一些调整。

对于公式编辑器漏洞利用样本，GPT 5.1 需要人为引导方向。它最初尝试提取宏，但失败了。GPT 5.1 注意到这是一个异常样本，却找不到任何恶意行为的证据。不过，当我明确告诉它去查找公式编辑器漏洞利用时，它成功找到了加载下一阶段的 shellcode，用 Mandiant 的 Speakeasy 进行模拟执行，并输出了下一阶段的 URL。

Sonnet 4.6 自动判断出这可能与公式编辑器漏洞利用有关，给出了正确的判定并定位了 shellcode 的位置。不过，它无法自行提取下一阶段的 URL。于是我明确要求 Sonnet 找到下一阶段的 URL——值得一提的是，我之所以知道存在这个 URL，完全是因为我此前已经分析过该样本。Sonnet 用正则表达式在所有提取的文件中搜索 URL 模式，但一无所获，因为 URL 是由 shellcode 在运行时动态构建的。于是我引导它使用模拟执行，这次立刻就成功了。

接下来我换了一个更难的样本。这个样本我花了大约六个小时用”老派的笨功夫”才完成分析，并编写了一个可通用适用于同类样本的静态解密脚本。给 AI 的任务也一样：搞清楚如何提取和解密文件，然后用 Python 编写解密脚本。这一次，LLM 的表现让我大为震撼。

GPT 5.1 和 Sonnet 4.6 都成功了——但它们只用了 30 分钟就生成了一个针对该样本的 Python 脚本，而不是六个小时。即使算上我花一个小时验证输出（对任何 LLM 输出都应该这样做）并将脚本改进为通用版本，效率提升依然非常显著。这最终让我确信，LLM 是逆向工程师工具箱中的得力工具。

在对比测试中，Sonnet 4.6 更便宜，完成相同任务时稍慢一些，但结果质量与 GPT 5.1 大致相当，而且我也不想在这上面花太多钱。因此，我后续只使用 Sonnet 4.6 和 Opus 来完善实验室和分析流程。首要目标是生成事实正确且易于验证的报告。

为此，我创建了一个报告 skill，它不仅列出最终分析结果，还要求 LLM 详细列出分析师验证每一项结论所需的步骤。此外，我添加了多轮验证环节，专门核查 IP、哈希值、文件名、路径、注册表键、偏移量、行号等关键数据。遗憾的是，这些验证环节会消耗大量 token，因为需要重新分析样本以提取关键信息。LLM 会将验证环节中发现的修正内容追加到报告末尾。

我用自己非常熟悉的样本来压力测试这套流程——这些样本我都写过分析报告，所以核实事实非常容易。以下是我的收获：

报告不可信

即使经过五轮验证，报告的关键信息中仍频繁出现错误，包括 IoC、文件间的关联关系、持久化位置等。LLM 生成的分析报告在本质上就是不可信的。我担心生成报告的便捷性会诱使人们误以为报告内容都是事实——就像漏洞赏金计划正被 LLM 生成的漏洞报告所淹没，开源开发者不得不花费大量时间审阅 AI 垃圾 pull request 一样。

判定结论不可信

判定结论是最不可靠的部分。LLM 频繁地错误评估其发现的重要性，原因在于它们会做出错误假设并草率下结论。如果它们能访问 VirusTotal 的结果，往往会过度依赖扫描器来形成判定。在我的工作中，这是不可取的，因为我们处理的恰恰是扫描引擎或其他自动化手段失效的样本。我可以通过要求 LLM 在判定时忽略 VirusTotal 结果来部分缓解这个问题，但这并没有从根本上解决错误判定的问题。

要纠正这些偏差，需要经验丰富的分析师提出针对性问题，找出误判的根源，并引导 LLM 走向正确的方向。

就目前而言，LLM 的判定结论不可信！

图 3：LLM 在验证环节中发现了错误。判定结论在整个对话过程中变化了三次。

工具至关重要

分析的质量和速度在很大程度上取决于是否为样本配备了合适的工具，以及是否提供了清晰的工具使用说明。因此，随着实践的积累，针对特定样本类型创建 skill 是很有必要的——比如一个专门的 JavaScript 分析 skill，描述哪些工具最适合使用。否则 LLM 会浪费大量 token 在试错上，每次都要重新摸索什么工具对当前样本有效。

引入无头模式的 Ghidra MCP 也大幅提升了分析效果。在此之前，LLM 使用 Remnux 内置工具进行反汇编，虽然结果相同，但 token 开销要大得多。反编译的输出比反汇编更简洁，应优先使用。

我使用的 x64dbg MCP 非常消耗 token，但它仍然很有价值，因为有些样本通过调试分析更为高效。

SSH MCP 使 LLM 能够使用 PowerShell 动态分析 .NET 二进制文件或动态反混淆脚本。LLM 甚至能通过 PowerShell 终端调用 Sysinternals 工具完成基本的监控任务。不过，LLM 需要明确的说明才会记住这种可能性。

LLM 能在更短时间内覆盖更多内容

LLM 的一大优势在于它们能在较短时间内自动深入审查复杂的程序和安装包。我们有时会收到包含数千个相互关联文件的程序安装包。人工不可能逐一查看，所以我们要花大量时间确定重点区域，并且不得不在某个节点终止分析。

LLM 的速度要快得多，因此它能发现我们可能遗漏的有价值区域、指标和文件。例如，它在某个样本的一个配置文件中检测到了一个包含项目名称的调试路径残留。这个样本我一年前曾详细分析过，是一个由上万个文件组成的大型应用程序。我几乎不可能靠人工找到这个痕迹。

LLM 拥有更广泛的知识面

每个逆向工程师都有自己擅长的领域和大量的专业知识。恶意软件分析师经常组团协作撰写分析报告，原因之一就是为了汇集每个人的专长。

然而，LLM 在我们不太熟悉的领域确实懂得更多。在我的实验中，LLM 能用我根本不会想到去查找的信息来为分析发现提供上下文——因为我甚至不知道存在这些知识。特别是当你独自分析恶意软件、没有团队支持时，这种背景知识是极大的帮助，不仅能提升报告质量，还能让你在过程中学到不少东西。

生成脚本，而非仅仅生成报告

脚本的优势在于 LLM 拥有一个反馈回路——脚本是否正常工作，运行一下就知道了。这种反馈回路在报告的大多数其他部分是不具备的。

因此，让 LLM 生成配置提取器、静态脱壳器或反混淆脚本，可以大幅节省验证报告数据的时间。只需简单检查脚本是否在”作弊”（例如直接打印一个幻觉生成的 C2 URL 而不是真正去提取），然后在样本上运行即可。例如，一个脱壳脚本不仅能验证被脱壳的载荷是什么、两个阶段之间的关系如何，还能验证加密载荷存储在哪里、以何种方式存储、以及解密需要哪些算法。

我已经将一个关键分析步骤加入了流程：要求 LLM 将反混淆脚本创建为可复用的文件，而不是在命令行中编写一次性脚本。

搭建自己的实验室很简单

搭建一个自主运行的 LLM 分析实验室比你想象的要容易，也不需要最新最强的硬件。但请务必使用一台与日常主机隔离的设备。

我花了一个周末搭建好了实验室。我用的是一台大约 12 年前的旧笔记本电脑，已升级到 16 GB 内存。我给 Remnux 分配了 4GB，给 Windows 虚拟机分配了 8GB。宿主系统是 Debian。

由于内存较低，这个实验室无法同时运行 x64dbg Windows 虚拟机和 Ghidra。因此，我必须提前决定让 LLM 使用哪个工具。如果不需要 Windows 虚拟机，我就给 Remnux 分配 12 GB，这样它可以同时进行两项分析而不会发生抖动 (thrashing)。抖动是指系统将更多时间花在内存管理上而非执行实际代码，最终导致系统卡死。如果经济条件允许，我建议至少配备 32 GB 内存——按照目前的内存价格，这并不算贵——因为每次都要纠结是否使用调试器、还要在两种配置之间手动切换，实在太烦了。

好消息是，LLM 可以帮你完成大部分搭建工作。你只需自己安装好 Remnux 和 Claude，然后告诉 LLM 你想安装什么，检查它的操作是否正确并批准即可。这是虚拟机，所以万一出了问题，恢复到之前的快照就行。每次重大变更后都记得做快照。

按 token 计费用来测试模型是可以的，但长期使用非常昂贵。一次分析的费用很容易在 5-20 欧元之间。对于大多数用途来说，订阅制更划算。

虚假信息的时代

一个不争的事实是，自主 LLM 分析是我们工具库中非常实用的工具，它大幅缩短了分析时间。分析自动化在过去极难实现，因为每个样本都需要独特的方法和工具。但 LLM 能够自主决定下一步该做什么。如果使用得当，我们逆向工程师可以借助它们提升效率，而不必牺牲质量。

但我也清楚接下来必然会发生什么：基于 LLM 自动分析样本的付费服务将会涌现，就像那些恶意评分过于激进的自动化沙箱一样，它们会被当作”事实机器”卖给没有逆向工程背景的人。因为只需按一个按钮就能生成看起来很专业的结果，大多数人会对其产生误解。即便对于专业人士来说，区分真实与虚构也会变得更加困难——毕竟，这些报告在技术上看起来确实很有说服力。

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：securitainment Karsten Hahn Karsten Hahn《LLM 恶意软件分析实战：正确的使用方式》