文章总结： 文档分析了恶意子文件检测的难点及解决方案。攻击者利用子文件分散信息导致上下文缺失，使沙箱检测失效。应对策略包括：通过父文件关联反证恶意性；利用相似性算法比对已知样本；运用大型语言模型（LLM）理解代码意图以突破人工局限。文章指出防御需持续进化以应对不断变化的攻击手段。
综合评分： 88
文章分类： 恶意软件,逆向分析,AI安全,漏洞分析,威胁情报

检测恶意子文件的困境与应对方法

原创

jishuzhain

OnionSec

2026年1月2日 17:44
广东

如果你经常观察各类网络安全事件，一定会发现其中会出现对应不同平台的恶意软件，而这些恶意软件呢又时不时会释放出子文件，往往会关联到不定数量的恶意子文件。于是乎一旦发生一件网络安全事件就会涉及多个恶意文件，理想的事后补救场景是我们需要及时把它们全部揪出来，同时彻底清除，让受影响的资产恢复如初，这部分要求快，越快越能证明安全防护的价值，完成这些步骤仅仅是合格的网络安全厂商的及格线。我这里会摒弃网络安全市场PPT形式的吹嘘风格，聚焦于现实与事物发展变化的普遍规律，因此不会写一定能防范于未然，没有人能敢打包票。由于网络安全行业比较特殊，最新的攻击往往是人与人之间的持续对抗，由人设计的防护系统始终无法实现最完美的防御。优秀且体现现实价值的做法是在入侵前期就能被防护机制遏制，且黑客不断攻击尝试时也面临不断失败，最终被安全运营团队发现后及时人工介入加强整体防护并复盘该组织已经出现的风险。基于可验证可比对的条件下，如果以上两类场景均不及预期，那么可以说提供的网络安全防御能力是不合格的。以上的体会与思考，我们心里有杆秤即可。

黑客或者说网络安全爱好者选择多个恶意文件实施攻击行为的目的是什么呢？答案是现实所迫，攻击的目的是非法获得控制权实施任意意图，这部分能力依赖于各类操作系统平台所能提供的能力上限，本质上想要做的越多越需要更多地编写代码实现功能，每一类代码都携带有攻击者的个人属性或编写风格。对黑客来说入侵直至成功的过程中出现越多的步骤或者动作都会进一步加大被发现痕迹的概率，因为新动作或者步骤引入了新因素，新因素就带来了新概率。但是如果将动作或者步骤压缩至最少，那么最少的步骤下必然需要信息量极大的数据载体，信息量极大又会引出同样的问题，被发现的概率变大。综合起来，不断地摸索发现适中的步骤数量与多子文件结合能获得平衡，使得入侵过程显得比较安静，不会引起注意。

为什么恶意子文件的检测会存在困境呢？

检测恶意文件的本质是判定任意程序是否具有恶意意图意义的语义特性，意图是一种经过人的数据分析抽象出来的概念，换言之它无法直接被显示出来，它只能被证明出来，例如我在走路，你无法基于我走路的这个照片判断我将走向哪个方向，只有我有稍微的转身动作后你才能猜测出我可能是有往某个方向走去的意图。一旦我们获取的有意义的意图信息越多越能实现低误报地检出恶意文件，反之则会存在大量误报。恶意子文件天然就缺失部分意图，这是攻击者希望实现的目的，多个子文件实现了信息的分离，信息数量一分离，单个文件的信息含量便会直接降低，相当于实现了减法。因此针对子文件的单独检测会天然存在恶意意图语义特性少等现象，最终影响对它的检测效果。

子文件检测或查杀效果差的原因：

1、如果子文件属于本地Loader（加载器），当缺失必要的上下文信息（例如命令行参数）或文件（例如依赖加载同目录的加密载荷文件），在沙箱环境无法释放出完整行为，缺失必要行为来分析意图，进而影响检测。同理，事物实质上是正反对应的，当子文件被转移到新环境时由于缺乏必要的上下文信息，理论上对新环境是无害的。恭喜，又躲过一劫。

2、如果子文件属于data（加密载荷）类型，那么当缺失必要的上下文信息（例如依赖被Loader加载），在沙箱环境无法释放出完整行为，影响检测。同理，当子文件被转移到新环境时由于缺乏必要的上下午信息，仅仅属于数据，理论上对新环境是无害的。

3、如果子文件属于下载器（Downloader），与之通信交互的C2服务器一旦失效，在沙箱环境同样无法释放出完整行为，一旦缺乏关键的语义意图举证信息就会影响检测。

可以说检测恶意子文件的条件比较苛刻，因此对它的检测天然就存在困境。那么我还是想检测并把它们揪出来怎么办？恭喜你，你现在正在思考的难题也是当前网络安全威胁每天都需要面对的难题，检测恶意文件如何又快又全又准确是一个充满了挑战的问题。

回到最初的原点，我们希望能通过意图来精确检测恶意子文件，那么我们所有的目的都是围绕这个观点来实施。2025年初提出了基于关联关系来检测MSI类型的“打包”类文件，那么这里首要采用的思路也是如此。我们基于强关联关系证明其恶意意图来论证该子文件为恶意的，通过子文件找到强关联的父文件（或者说是母体文件），父文件大概率携带充分的信息量可以基于各类手段（不限制方法，动静结合都可）来通过数据分析获取意图，只要证明了父文件为恶意的，那么进一步可以证明子文件也是恶意的。

如果想尽了各种方法或者受限于数据有限等因素，无法找到任何与子文件关联的父文件，那么此时该如何检出恶意子文件呢？比较能想到的方法是基于相似关系来辅助检测，基于相似方法的理论基础前提是这个世界并没有那么巧合的事情，恶意子文件与现实正常文件编写的代码风格一致，或者非常相似，在极低概率的条件下我们将其归类到不可能事件，那么只要两者相似就证明它们也应当是存在强关联关系。基于这种观点，一旦我们具有恶意子文件的基础数据库，那么基于相似就可以再次判断未知子文件是否为恶意。实现相似所需要的对象或者相似性算法，可以自行发散，这里提及一下常见的。例如利用ssdeep算法证明它们的导入表函数相似，可获取的可见字符串存在极高的相似性，二进制文件整体的ssdeep值相似，利用反编译工具对其整体反编译输出得到的数据也存在极高相似等。

如果父文件找不到，恶意子文件的基础数据库也没有收集到位，任何想基于强关联关系的方法都失效的情况下，如何检出恶意子文件呢？我们还是要回到最初的原点，通过哪些方法能数据分析来证明它的意图？专家或者其余分析人员通过反编译工具对未知子文件实现分析，在阅读工具输出的伪代码后基于知识以及经验实现代码理解分析输出结论，如果能有把握直接证明其存在恶意意图那么该问题已经解决，可判断未知子文件为恶意文件。如果无法直接证明其存在恶意意图，那么只能基于历史分析经验在脑中分析其代码编写风格，评估其编写风格是接近恶意文件还是正常软件，这个评估过程在以往往往是基于数据统计分布的方法来证明，基于专家或分析人员所见过的恶意文件编写风格的数量来反映出判断的准确性，如果以前没有见过，那么该问题无解，因为没有见过所以无法判断。2022年11月前，理解代码意图一直是很困难的事情，即使这么多年机器学习深度学习强化学习一直在进步，致力于解决现实问题，但是对于代码任务去准确理解还是不够完美，随着11月后大型语言模型（LLM）产生落地，让这类代码任务的解决引来了转机，基于LLM理解代码意图的方法来证明子文件为恶意的，已经能被证明是可行的且能达到专家级别的理解力，它解决了两种专家没有办法同时满足或再增强的能力，第一种是它见过的代码风格多（人脑不擅长大规模记忆），第二种是它具备准确的代码理解能力，本质上是新手段解决旧问题。因此如何在低成本使用LLM解决代码理解任务进而推动对未知子文件的检测是需要不断探索的路径，之前写到让AI 与 AI IDE协作提高分析效率也是属于抛砖引玉了。

以上的过程顺利的话能解决大部分恶意子文件的检测，但是现实情况是会遇到极端情况，极端情况也是由黑客不断摸索实验得到的防检测方法。假设它将小段恶意代码嵌入在巨量正常业务代码的正常软件中，那么如何检测这个子文件呢？能解决这类极端情况往往具备极大的价值，这个问题留给读者思考吧。

世界上并没有100%安全的防护系统，我们能做到的是不断思考摸索，持续去接触研究最新的攻击与威胁，这是事物发展的规律。

免责声明：

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

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

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

本文转载自：OnionSec jishuzhain《检测恶意子文件的困境与应对方法》