Zombie ZIP这个畸形压缩包技术在圈子里传开之后我第一时间就去复现了一轮。老实说第一次看到分析报告的时候我还有点不太相信一个ZIP格式居然能让绝大多数杀毒引擎集体“失明”这在2024年听起来像是童话故事。但当我亲手构造出第一个绕过样本看着本机杀毒软件毫无反应地把带毒压缩包放行的时候说实话心里凉了半截。这篇文章我不打算教你怎么构造恶意样本去攻击别人那是红线。我要做的是把Zombie ZIP的技术原理拆开揉碎讲清楚然后重点说一个更关键的问题作为防守方我们到底应该怎么在这种“解析器分道扬镳”的攻防对抗里守住阵地。如果你是安全研究员、恶意样本分析工程师、邮件网关运维或者就是单纯对压缩包解析机制好奇的开发者这篇内容都值得你花十分钟读完。1. 内容整体设计与思路拆解1.1 先搞清楚Zombie ZIP到底“怪”在哪ZIP格式本身并不复杂它甚至算不上一个严格的“标准”更多时候我们依赖的是各实现之间的约定俗成。一个正常的ZIP文件核心结构就三块从文件开头按顺序排列的一个个本地文件头Local File Header和数据区文件末尾的中央目录Central Directory以及最后收尾的中央目录结束记录End of Central Directory Record。大多数人的理解是解压工具读取中央目录拿到每个文件在文件中的偏移量然后把对应区域的本地文件头和数据解出来。这种理解没有错但它只是“教科书版本”。Zombie ZIP的精髓在于本地文件头里的字段和中央目录里的字段可以不一致而且很多解析器根本没有验证这种一致性。比如说本地文件头里写入的压缩文件名是readme.txt实际的压缩数据里存的是payload.exe而中央目录里声明的又是另一个名字。这时候杀毒引擎在扫描过程中到底该信哪个有的引擎信本地文件头有的引擎信中央目录还有的引擎干脆把两者都枚举出来扫一遍。问题就出在这里当引擎和最终解压工具信任了不同的字段恶意代码就从夹缝里溜过去了。1.2 为什么“歧义”比“恶意”本身更致命杀毒软件的静态扫描引擎本质上是一个高度追求速度和稳定性的解析器。厂商为了保证用户体验必须在一秒内处理海量文件。这就意味着很多杀毒引擎的ZIP解析器是“简化版”的它们只处理最常规的字段组合代码里充斥着对畸形输入的异常兜底——最常见的行为就是“解析不了就跳过”。这种设计在正常文件上没有问题但一旦遇到刻意构造的文件就会产生一种很有趣的现象杀毒引擎和真正的解压工具比如WinRAR、7-Zip、Windows资源管理器解析结果完全不同。攻击者要的就是这种不一致。Zombie ZIP之所以能绕过绝大多数引擎根本原因是它把ZIP格式里“允许歧义”的空间变成了武器而不是说它使用了多么高深的密码学或加密技术。用生活的话来说杀毒引擎和一个普通用户看到的是同一个ZIP文件但杀毒引擎看到的是一个无辜的文本文件列表而用户的解压工具解出来的是另一个东西。这个过程里杀毒引擎并没有故障它只是被精心设计的格式歧义骗了。1.3 这种技术影响的主要场景Zombie ZIP的攻击场景非常清晰。最典型的三个是钓鱼邮件附件、网页下载链接里的压缩包、以及各种网盘分享中的伪装文档。这类攻击不需要任何系统漏洞不需要用户关闭安全软件只需要用户像平时一样双击打开一个压缩包。影响范围之所以大是因为压缩包是现代恶意软件分发的基础设施。从银行木马到勒索软件大量恶意Loaders的首发载体就是ZIP/RAR。如果压缩包这一层能被稳定绕过后面不管挂的是什么恶意载荷杀毒引擎都看不见。2. 核心细节解析与实操要点2.1 本地文件头与中央目录的“对不上”是怎么来的ZIP规范中本地文件头LFH和中央目录CDH字段的数量、名称、压缩方式理论上应该一致但规范并没有强制解压器做交叉验证。构造一个Zombie ZIP的基本思路就是打磨这种不一致。我不打算贴完整的恶意样本构造代码但你至少要理解关键差异点。最常见的畸形手法包括中央目录中文件的压缩方式compression method写的是0x0000store即不压缩但本地文件头里写的是0x0008deflate。杀毒引擎扫描时信了中央目录认为这是不压缩的纯文本而解压工具按本地文件头走实际是deflate解出来的恶意代码。中央目录中文件大小字段写了一个很小的值比如0字节而本地文件头中数据区实际有几百KB。引擎扫描时发现只有一个空文件直接跳过解压时却能看到真实数据。文件名编码上动手脚通过添加空字节或在文件名里混入Unicode控制字符让引擎在输出文件名时得到完全不同的字符串从而把检测特征文件伪装成一个无害文件名。这些手法单独拿出来任何一个都不算新鲜但Zombie ZIP的高明之处在于把这些手法组合起来并且针对不同杀毒引擎的解析习惯做适配。2.2 双重压缩与流式写法的“障眼法”另一个我在分析样本时经常遇到的构造是嵌套ZIP。外层是一个正常的ZIP容器里面放的依旧是一个ZIP文件但内层文件的很多字段是故意损坏的。大多数杀毒引擎的递归解压深度限制在3-5层而且每层解压时都会做“信任决策”。一旦内层文件损坏到让引擎觉得“这不是合法ZIP”递归扫描就中断了。但用户的解压工具往往对损坏有极高的容忍度。WinRAR和7-Zip在碰到中央目录异常时会尝试扫描文件中的本地文件头这叫“暴力扫描”或“数据恢复模式”照样能把内层内容解出来。结果就是杀毒引擎觉得它已经“扫描到最深层”了实际上离真实载荷还差着十万八千里。值得注意的是Zombie ZIP还大量利用ZIP64和Data Descriptor这两个特性。流式写入ZIP时CRC和大小字段在数据之前可能是不确定的ZIP规范允许把这些信息放在压缩数据之后的一个数据描述符里。杀毒引擎如果没实现数据描述符解析就会直接放弃扫描该条目。而现代解压工具为了兼容流式压缩几乎都支持这个特性。这就又制造了一个“引擎看不懂但工具能解”的缝隙。2.3 为什么不是所有杀毒引擎都会中招我在写这篇分析的时候特意对比了多款主流杀毒引擎对一个Zombie ZIP样本的检测结果。结论确实像标题说的那样绝大多数引擎会miss但依然有一两款能拦住。那它们凭什么呢拦住的那几款要么是把文件内容和文件名同时做了哈希匹配要么是对ZIP解析后的每个本地条目都做了沙箱解包和内容嗅探而不是单纯信任某一个目录结构。还有些引擎会执行“双解析”策略先用严格的规范解析器扫一轮再用宽容解析器扫一轮最后对比两者结果差异大的直接拉高恶意分数。这说明Zombie ZIP并不是真正无敌的。它只是在攻击“解析器的单一路径信任”只要防御方愿意付出双倍甚至三倍的CPU开销这种绕过是可以被大幅消解的。3. 实操过程与核心环节实现3.1 安全分析师如何解剖一个畸形ZIP作为防御方当我们在沙箱里捕获到一个疑似Zombie ZIP的样本第一步不是直接扔进虚拟机双击而是做静态结构分析。我最常用的工具是zipinfo -v、7z t -v和binwalk。这三个工具的输出放在一起对比基本能看出一大半问题。用zipinfo -v看某个ZIP的详细结构时重点看每一条Central Directory entry和对应的Local Header。正常文件这两个地方显示出来的压缩方法、文件大小、CRC应该是一致的。如果出现明显不一致你就知道这里有问题了。如果你在一个疑似ZIP上执行7z t它显示“Everything is Ok”但用其他解压工具或者自己写脚本解析时出现错误这也说明ZIP的结构是不标准的。或者反过来7z t报错说中央目录损坏但Windows资源管理器能正常打开那同样值得警惕。实际分析时我习惯用一个小脚本动态对比两份结构把不一致的地方直接打印出来。这种脚本没有危险只是解析字段做对比。对于一个200MB的ZIP文件解析一遍的耗时通常在几秒内。借助这种差异对比五分钟内就能给一个样本定性是普通损坏还是刻意构造的对抗样本。3.2 验证引擎“绕过”的合规方式有些做安全研究的朋友会问我既然标题说“绕过绝大多数杀毒引擎”那我手头有一个恶意样本的变种怎么验证它到底能不能过引擎我的建议是不要拿真实恶意样本去裸奔测试更不要用线上平台传真实恶意载荷。合规的做法是在隔离环境里用无害的EICAR测试文件作为载荷构造一个畸形ZIP然后用本地安装的杀毒引擎和VirusTotal的“私有扫描”入口做验证。EICAR文件本身没有危害它只是安全测试的“模拟子弹”。在隔离环境中通过构造EICAR类别的Zombie ZIP然后观察杀毒引擎是否报警比直接传真实勒索软件要安全得多。EICAR被报毒说明引擎在压缩包解包后识别到了特征没有报毒说明这个结构的ZIP在当前引擎的解析路径上有绕过空间。整个过程不涉及真实恶意样本的落地安全且合规。3.3 防御方真正该做的四件事如果你是企业安全工程师看完Zombie ZIP的分析后可以立刻着手做的防御工作有四件事。第一统一解析策略。在邮件网关和EDR的压缩包处理环节不要让底层库“按默认配置走”。至少要开启“严格模式”对中央目录和本地文件头的差异做检查差异超过阈值直接判定为可疑。这就要用到有完善ZIP解析接口的引擎比如有些网关允许写解析策略脚本你要确保代码里做了字段级比对。第二关闭“看见坏文件就跳过”的容错机制。大多数杀毒引擎碰到解析失败的文件会直接跳过并认为“安全”这是Zombie ZIP嵌套构造能存活的主因。在网关侧你应该设置策略对结构异常的压缩包一律拦截并进入人工分析队列而不是静默放行。第三把“压缩包内嵌压缩包”的层级压到2层以内。Zombie ZIP大量利用递归解压的深度限制如果你的网关支持最大解压层数设置不要默认设成10层设成2层就够了超过直接拦截。这样虽然会误伤一些正常场景但在安全与可用性的天平上这个尺度对企业来说通常是划算的。第四给沙箱增加“宽容解析器严格解析器交叉比对”的逻辑。我在实际测试中发现单纯的静态扫描很难抓住所有Zombie ZIP变种。如果你有EDR或沙箱可以把同一个压缩包分别用两种解析策略跑一遍对比它们最终解出来的文件列表是否完全一致。不一致的样本可以直接打上可疑标记。这个方法实现起来不复杂但效果立竿见影。3.4 YARA规则能做点什么Zombie ZIP在二进制结构上是有迹可循的YARA规则在这方面帮了不少忙。我不建议一个麻醉药下去直接匹配某个恶意文件的Hash那样太脆弱了。更好的做法是匹配ZIP结构中的异常特征组合。比如我实际用过的规则逻辑大致是在一个ZIP文件里先找到Central Directory的PK\x01\x02标记再找到Local File Header的PK\x03\x04标记然后提取两处的compression method字段如果同一个文件名在这两处记录的值不一样就命中。用这个思路写出来的YARA规则对已知Zombie ZIP结构有很好的查杀效果。要注意的是YARA规则不能写成对所有ZIP都告警这样误报率会完全不可接受。好的做法是只匹配“同文件名在不同结构块中字段冲突”的高度特异性模式然后把判定交给后续的治理流程。4. 常见问题与排查技巧实录4.1 为什么同一个样本我今天测能杀明天测就miss了这是个很有意思的现象。我实际遇到过不止一次。原因并不是杀毒引擎“变笨了”而是云查杀贡献了大部分检测结果。你今天测试的时候文件名特征哈希可能正在云端召回所以杀毒软件直接拦了。但如果这个样本在本地缓存池里掉出又或者云端侧更新了拉黑策略第二天的结果可能就不一样。所以你在验证一个Zombie ZIP样本是否“绕过”的时候一定要把本地静态特征和云查询结果分开看。最稳妥的评估方式是断网测试断网状态下如果引擎还能拦截说明本地特征库起作用如果断网后不拦截就说明该引擎的本地解析器可以被绕过。这个区别非常关键。4.2 怎么快速判断一个ZIP是不是“故意畸形”还是“无意损坏”实际工作中最大的坑就是这个。企业邮件网关每天都会遇到大量损坏的ZIP附件不一定都是攻击。如果遇到畸形结构就全部拦截业务投诉会淹没你。我的判断方法分两步。第一步看畸形是否集中在关键字段上。普通损坏一般是数据区截断或者CRC对不上很少会出现“本地文件头压缩方式和中央目录压缩方式不一致”这种刻意构造的差异。第二步看文件名。攻击者为了让用户打开解压后的文件文件名通常会伪装成发票、合同、简历等有诱导性的名称。如果一个结构异常的ZIP里还有诱导性文件名基本就实锤了。4.3 沙箱为什么也会漏报很多团队配上EDR沙箱后觉得可以高枕无忧了。但Zombie ZIP对沙箱的绕过思路是反着来的它知道沙箱会执行解压后的文件所以它赌的是沙箱根本解不到那一层。具体来说攻击者在ZIP里放一个多级嵌套的畸形容器然后在内层放真正的恶意文件。沙箱如果解压层级不够深或者碰到异常字段就终止任务就永远看不到攻击载荷。我在调试沙箱时发现很多商业沙箱对“递归解压失败”的处理策略是直接跳过而不是继续尝试用另一种解析算法去读取。这个坑非常普遍。应对办法是给沙箱配置一个“失败后降级解析”的回退策略优先用严格模式解析失败后自动切换到宽容模式再试一遍同时把两次结果存储下来供分析师查看。4.4 关于检测率的几点独家心得拦Zombie ZIP这件事网上很多分析报告都把重点放在“这个技术多么吓人”上。但我自己跑完几轮对比测试后真实的感受是它吓人的地方不是什么高深数学而是大部分厂商都在省成本。杀毒引擎不实现完整的ZIP字段交叉验证不追踪数据描述符不做双解析器结果比对这些都不是技术做不到而是性能开销受不了。所以作为防御方你的出路其实很明确要么在网关侧用专门的ZIP解析库做深度检查要么接受一个现实——终端杀毒对这类畸形压缩包的检测率短期内不会有大飞跃。我个人建议自建一个轻量检测服务专门处理入站压缩包。内部逻辑就是简单的结构差异比对加文件名语义分析。第一步解析出结构差异第二步对文件名做伪装词检测第三步把高可疑对象送人工队列。整个流程跑一遍单个文件耗时不会超过50毫秒但能把Zombie ZIP这类绕过拦下一大半。实际部署的时候我踩过几个坑。最典型的一个是当你把Windows网络共享上的压缩包拿去做结构差异比对时如果你直接读取的是NTFS的解析结果可能已经经过了一层系统级缓存导致你看到的文件和原始字节并不完全一致。正确的做法是直接读取原始二进制流用独立库解析不要依赖系统自带API。另外一个坑是不同编程语言标准库对ZIP的支持程度差异极大有的现代化语言标准库根本读不了畸形ZIP跑一半直接抛异常。所以做这个检测服务语言选型上宁可用成熟的老牌解析库C/C实现也别图新鲜用实验性库稳定性是第一位。Zombie ZIP这玩意儿说到底就是一场关于“谁更了解ZIP格式”的猫鼠游戏。攻击者对格式的理解比那些号称每天查杀数十亿文件的引擎更深于是就能在解析缝隙里做文章。但反过来只要防守方也愿意多花点精力去深挖这种解析差异你完全可以在自己负责的网络边界上把这个漏洞堵住不必等厂商更新库。做安全这行最怕的就是对格式和协议的理解停留在文档表面那些畸形输入的背后往往藏着真正值得你警惕的东西。