AI恶意软件分析需要证据包

Zane St. John买了一台便宜的Android投影仪，发现可疑的DNS流量，并使用Claude Code作为逆向工程助手，检查设备预装的应用。¹

真正有意思的地方，并不是AI代理参与了恶意软件分析。这个说法很快就会变得司空见惯。更值得关注的是产物形态：观察到的网络行为、包名、反编译后的代码路径、命令输出、笔记，以及可供人工检查的可观测指标。使用代理做恶意软件分析，只有当输出不再像一个答案，而更像一份案卷时，才值得信任。

AI恶意软件分析需要证据包。代理可以加速解包、反编译、搜索、摘要和假设生成。但分析人员在信任结论之前，仍然需要哈希、工具版本、命令、提取出的可观测指标、来源路径、不确定性标签，以及从主张到证据的追踪。

要点速览

Microsoft Research将Project Ire描述为一种自主恶意软件分类代理：它会对软件进行逆向工程，并在验证器判断是否有足够依据支持恶意软件判定之前，生成一条证据链。² Zane对Android投影仪的调查展示了同一种模式，只是规模更小：代理可以帮助个人分析人员处理APK、日志、字符串和可疑代码路径。¹

安全的产品启示很明确：应把AI恶意软件分析员当成工作台，而不是权威。工作台可以提取、整理并连接证据。它不应接触在线基础设施，不应编写利用程序客户端，不应在普通工作站上执行未知载荷，也不应替代人类对影响范围的判断。真正有用的输出，是审查者能够复现的证据包。

关键要点

面向安全团队： - 要求代理提供证据包，而不是判定。 - 将样本身份、命令日志、工具版本、提取出的可观测指标和主张依据放在一起。 - 任何动态执行、网络接触或涉及凭据的分析，都必须先经过人工批准。

面向代理构建者： - 恶意软件分析工作流应默认采用只读静态分析。 - 将提取、假设、验证和报告拆分为不同步骤。 - 保留原始产物和来源位置，方便人工审计整条链路。

面向产品团队： - 不要把“自主恶意软件分析”包装成魔法。 - 展示代理检查了什么、推断了什么、没有验证什么，以及人类仍然必须决定什么。 - 先构建审查包，再构建夸张的仪表盘。

Android投影仪案例证明了什么

St. John的调查始于观察到的行为：投影仪在正常使用前发出了DNS请求。¹这一点很重要，因为怀疑来自设备本身，而不是模型。代理是在分析人员已经提出一个值得调查的问题之后才介入的。

随后，工作流进入常见的逆向工程分析面：

文章提到了常见的Android逆向工程工具，例如adb和jadx。¹这些工具本身并不能让结论成立。它们让产物变得可检查。jadx自称是一个命令行和GUI反编译器，可将Android Dex和APK文件转换为Java源代码，并能解码Android资源。³ Apktool自称是用于逆向工程Android APK文件的工具，覆盖manifest、resources、smali和重建工作流。⁴

代理的优势位于中间环节。它可以搜索陌生的包、总结代码、提出可能需要检查的区域，并维护待办清单。分析人员仍然需要把每一条主张与原始产物逐一核对。

AI把逆向工程变成案件管理

传统恶意软件分析本来就会产出案卷。案卷可能包括哈希、样本来源、字符串、域名、IP地址、互斥体、注册表项、文件路径、截图、反汇编笔记、沙箱输出和最终判定。

代理改变的是这项工作的速度和规模。它们可以读取更多文件、写下更多笔记，并生成比单个分析人员手动输入更多的假设。没有更强的输出约束时，这种速度会制造信任问题。一个自信的摘要，可能掩盖错误推断、遗漏的分支，或幻觉生成的API名称。

Microsoft的Project Ire指向了更好的形态。Microsoft表示，该系统能够自主分析和分类软件，并为其发现构建证据链。²其设计包含逆向工程工具，以及一个检查证据是否支持判定的验证器。²这个验证器的想法，比品牌名称更重要。恶意软件分析需要一个独立的证据裁判，而不只是一个流畅讲述结论的叙述者。

在更小的工作流中，也应采用同样的拆分：

代理可以做很多事。关口决定什么值得相信。

Android提供了有用的静态分析面

Android恶意软件分析有一个实际优势：在执行应用之前，APK已经暴露出多个静态分析面。

Android安全文档列出了明文通信、动态代码加载、不安全的广播接收器、硬编码密钥和权限相关错误等风险类别。⁵ MITRE ATT&CK for Mobile包含Broadcast Receivers和“在执行环境中下载新代码”等技术，为分析人员把观察到的行为映射到攻击手法提供了词汇。⁶

因此，静态优先的证据包很有价值：

这张表避免了一个重要错误：它没有先要求模型判断“是不是恶意软件”。它要求系统保留证据，以便之后可以审查判定。

证据包

有用的AI恶意软件分析包应具备可预测的结构：

主张映射是证据包的核心：

最后一行保护的是分析人员。恶意软件判定会带来后果。误报可能损害供应商，或干扰事件响应。漏报可能让用户继续暴露在风险中。模型不应绕过证据获得捷径。

代理应该拒绝什么

即使目标是防御，恶意软件工作也需要拒绝边界。

在以下情况发生前，代理应拒绝或要求明确的人工授权：

• 接触在线命令与控制基础设施；
• 为疑似后门或更新器编写客户端；
• 从攻击者控制的基础设施下载第二阶段载荷；
• 在隔离实验室之外运行未知样本；
• 在分析中使用真实用户凭据、个人账户或生产网络；
• 在负责任披露之前发布可能识别受害者的实时指标；
• 将防御性调查转化为利用说明。

OpenAI的本地shell文档警告，允许代理运行任意shell命令可能很危险，并建议在把命令转发给shell之前使用沙箱，或严格的允许/拒绝列表。⁷ Anthropic的Claude Code最佳实践指南强调代理工作中的验证标准和上下文管理。⁸恶意软件分析两者都需要：行动之前有命令限制，信任之前有证据限制。

拒绝边界应直接出现在任务中：

静态分析这个APK。
不要执行它。
不要接触远程基础设施。
不要编写漏洞利用或客户端代码。
只返回带有文件路径、命令和置信度标签的证据。
将每一条缺乏支持的主张标记为未验证。

这类指令本身并不能让工作流安全。它为钩子、沙箱和审查者提供了可以执行的具体约束。

判定仍由人类负责

AI代理可以在恶意软件分析会话中节省数小时。它可以把一堆APK缩小为一份可疑包清单。它可以总结类、解包intent过滤器、识别配置字符串，并生成报告草稿。这些收益很重要。

但代理不应负责最终判定。

分析人员负责：

• 授权分析样本；
• 决定是否动态运行任何内容；
• 解释意图和影响；
• 与受影响的供应商、用户或平台沟通；
• 做出修复和披露决策；
• 确定报告中的最终措辞。

这样的分工让代理保持有用。模型承担耗时的关联和整理工作。人类保留伦理、法律和上下文责任。

如何构建工作流

从一个小型静态分析循环开始：

1. 对样本做哈希，并记录来源。
2. 将manifest、资源、字符串和反编译代码提取到只读工作目录。
3. 要求代理创建带来源位置的发现清单。
4. 让第二轮检查挑战每一条发现，并标记缺乏依据的主张。
5. 构建证据包。
6. 决定证据包是否足以支持进入动态实验室分析。

代理提示应要求结构化输出：

对每一条发现，包含：
- 主张
- 产物路径
- 生成该产物的命令
- 来源摘录或符号
- 置信度
- 什么会推翻该主张
- 是否需要动态分析

这种输出没有“投影仪有恶意软件”那么刺激，但有用得多。

证据关口在这里直接适用。没有证据的主张，不应进入最终答案。审查包才是新的最终答案同样适用：交付物不是文字摘要，而是让另一个人能够验证工作的包。

常见问题

AI代理能做恶意软件分析吗？

可以，但有边界。代理可以帮助完成静态分析、摘要、反编译导航、可观测指标提取和报告起草。但如果没有可复现证据和人工审查，它们不应成为恶意软件判定的最终权威。

在恶意软件上使用Claude Code或Codex安全吗？

只有在受控的防御性工作流中才可以。不要在普通工作站上运行未知样本，不要接触在线基础设施，也不要向代理提供凭据或不受限制的shell/网络访问。更安全的起点，是在隔离工作目录中进行静态分析。

恶意软件分析证据包应包含什么？

至少应包含：哈希、样本来源、工具版本、命令、manifest事实、提取出的可观测指标、代码位置、从主张到证据的映射、置信度标签，以及未验证工作清单。

AI判定算证据吗？

不算。模型的陈述是一种解释。证据来自产物：哈希、日志、命令、代码路径、manifest、观察到的网络行为，以及可复现的分析步骤。

代理应该把发现映射到MITRE ATT&CK吗？

应该，但前提是证据支持这种映射。没有产物支持的技术标签，只是装饰。应把ATT&CK Mobile当作词汇表，而不是证明的替代品。⁶

结语

AI不会把分析人员从恶意软件分析中移除。它改变的是分析人员应当提出的要求。

薄弱的输出，是自信的判定。强有力的输出，是可复现的证据包：样本身份、命令、产物、可观测指标、主张依据、不确定性和下一步行动。

代理可以让逆向工程更快。证据包让它更可信。

参考资料