详解Venom中的PowerShell绕过技术

谈到红队行动中的Payload投递，PowerShell脚本的免杀是个老生常谈却又不断演进的话题。业内流传的Venom框架提供了一种颇有启发性的加载方式，它巧妙地绕过了基于静态签名的硬盘查杀。今天我们不谈那些泛泛的“混淆”概念，直接切入其核心的绕过逻辑，看看它是如何将脚本“藏”起来的。

核心：从Base64到Gzip的“套娃”艺术

早期PowerShell免杀极度依赖Base64编码，-enc参数几乎成了标配。但如今，任何像样的EDR（终端检测与响应）或AV（杀毒软件）都会将FromBase64String这类函数调用视为高可疑行为，甚至直接解码并扫描其中的内容。Venom的方法聪明之处在于，它没有在Base64这一层死磕，而是将其降级为一种“运输格式”。

真正的Payload被Gzip算法压缩后，再转换成Base64字符串。当脚本执行时，流程是这样的：先解码Base64得到原始的Gzip字节流，然后通过System.IO.Compression.GzipStream在内存中实时解压，最后用[scriptblock]::create将解压出的纯文本代码转换为可执行的脚本块。这个过程，Payload在硬盘上从未以可读的PowerShell代码形式存在过，它始终是一串“无害”的、经过压缩和编码的数据。

为何GzipStream是更好的选择？

GzipStream在这里扮演了双重角色：压缩器和混淆器。首先，压缩大幅减少了Payload的体积，降低了网络传输和磁盘写入的痕迹。更重要的是，经过Gzip压缩后的字节流，其统计特征与随机数据更接近，缺乏可识别的PowerShell语法结构（如function、if、$变量等），这使得基于正则表达式或语法树分析的静态引擎难以直接定位恶意意图。

你可以把它想象成不是把一封信（恶意代码）加密，而是把信先粉碎成纸屑，再把纸屑压成一个紧密的纸团。检查者（AV）看到的只是一个纸团，既看不到信的内容，也认不出这是信被粉碎后的样子。

执行链的隐蔽性设计

Venom的加载器在进程创建上也花了不少心思。它没有简单地调用powershell -enc ...，而是通过.NET的System.Diagnostics.ProcessStartInfo对象精细地配置一个新进程：

• 自动判断系统架构，选择32位（powershell.exe）或64位（syswow64...powershell.exe）的解释器路径，确保兼容性。
• 设置WindowStyle='Hidden'和CreateNoWindow=$true，实现无窗口启动。
• 将UseShellExecute设为$false并重定向标准输出，使进程脱离资源管理器启动，行为更低调。

这些参数组合起来，产生的PowerShell子进程在命令行参数中仅包含一个极长的、看似随机的字符串（即Gzip的Base64），而真正的恶意指令是在子进程内部，通过脚本块动态创建并执行的。这有效割裂了父进程（可能是合法的安装程序或文档）与最终恶意行为之间的直接关联。

实践延伸与局限思考

这种方法的精髓在于“内存加载”。理论上，它不仅可以加载PowerShell脚本，任何能转化为字节流并在内存中还原执行的东西都可以尝试，比如.NET程序集（DLL）甚至经过处理的PE文件。有测试者曾尝试将Mimikatz的EXE编码后注入，虽然实现了硬盘免杀，但在执行阶段却失败了。这暴露了它的一个局限：它本质上是PowerShell的脚本执行环境，直接执行原生Win32 PE文件需要更复杂的进程注入或组装技术，并非简单解码就能运行。

防守方应对这种技术，视线必须从硬盘转移到内存和行为上。监控GzipStream与ScriptBlock.Create的连续调用，特别是当解压的数据源自非信任的进程内存或网络时，应当视为高风险事件。同时，对PowerShell进程的参数长度、是否包含大量编码字符进行基线分析，也能发现异常。

攻击在进化，防守的视角也必须随之流动。Venom展示的这条绕过路径，与其说是一个永久的漏洞，不如说是一次精彩的战术演示，提醒我们静态的“特征”是多么不可靠，真正的对抗永远发生在动态的执行瞬间。