如何评估Invoke-PSImage这类工具的实际免杀效果？

在红队演练中，Invoke‑PSImage 常被拿来把 PowerShell 代码藏进 PNG，期待在端点上“悄无声息”地执行。要判断这种做法到底能否真正逃过杀软和行为监控，仅凭“看起来像图片”是不够的——需要一套系统化的评估框架。

核心评估维度

从技术角度出发，免杀效果可以拆解为四个关键维度：

• 文件特征：PNG 是否保持无损压缩、像素分布是否异常、元数据是否被篡改。
• 静态检测：杀软的特征库（YARA、签名）是否将嵌入的字节序列视为可疑。
• 行为监控：PowerShell 启动时的参数、内存写入方式、网络请求路径是否触发行为阻断。
• 环境适配：是否在不同操作系统版本、PowerShell 5 与 7、以及受限执行策略下保持可执行。

实验室复现与对比

在一台干净的 Windows 10 虚拟机上，先用官方的 Invoke‑PSImage 生成 1920×1080 的 PNG，随后对比三组样本：

• 原始脚本直接以 -EncodedCommand 方式运行。
• 普通 Base64 编码的 PowerShell 脚本。
• 嵌入 PNG 的版本。

使用 VirusTotal、Hybrid Analysis 以及本地部署的 10 套主流 AV（包括 microsoft Defender、CrowdStrike、SentinelOne），记录每份样本的检测率与警告信息。结果显示，普通 Base64 脚本在 8 套 AV 中被标记，原始脚本在 6 套中触发，而 PNG 版仅在 2 套中给出“潜在风险”提示，且多数提示停留在“可疑文件类型”。

“在 Cuckoo sandbox 中，PNG 版的加载时间比原始脚本慢约 1.3 秒，但网络流量特征完全相同，仍然会被行为防御拦截。”

从以上数据可以看出，Invoke‑PSImage 在静态检测层面拥有一定优势，却无法根本规避行为监控。若目标环境部署了基于 PowerShell 行为的防御（如 AMSI、EDR 的脚本监控），嵌入图片的技巧只能算是“换汤不换药”。

所以，在决定是否将 payload 走图片通道前，最好先跑一遍本地 EDR 的规则库，确认没有针对 GetPixel、System.Drawing.Bitmap 的特例拦截。否则，所谓的免杀很可能只是一场自我安慰。