动态对抗杀软总结

想第一时间看到我们的大图推送吗？赶紧把我们设为星标吧！这样您就不会错过任何精彩内容啦！感谢您的支持！🌟

免责声明

      文章所涉及内容，仅供安全研究教学使用，由于传播、利用本文所提供的信息而造成的任何直接或间接的后果及损失，均由使用者本人负责，作者不为此承担任何责任。

前言：基于目前主流的r3层动态对抗技巧且针对360核晶，卡巴斯基edr以及bitdefender进行思路讲解，不包含钓鱼，不包含内核，以及流量对抗。

木马（cs4.5二开或者以上版本以及havoc）

360核晶：

由于本人日常并不对抗360，也没有深入了解过，简单测试了一下核晶在动态层面基本上是必杀shell指令的，针对这一点我们可以采用bof的形式去执行一些 cmd命令同样可以实现，并且鉴于360对白加黑进行大面积的封禁，上线方式也改为分离式上线（未测试单文件），维权方式可推荐计划任务或者服务的形式当然这里，需要通过win api的形式实现。

卡巴斯基edr：

基于大量的测试，卡巴斯基对于cs的上线并不像其它杀软非常敏感，更多的查杀重心是放在内存的扫描之上，cs4.9.1执行shell指令并不会被查杀，但当运行一段时间之后内存会被查杀，所以对抗方式其实可以使用二开的cs或者换用其它的c2，当然长时间的sleep规避(可以hook sleep自己实现sleep加密)也是存在一定效果的，这里即使我们进行注入依旧会被查杀。

bitdefender：

个人测试中属于对连网和行为检测非常严格的杀软，其也是目前市面上为数不多会在r3层进行hook的杀软，卡巴已经取消了r3 hook，基于此类对抗，我们可以基于两个方面进行bypass，第一个spoofcall堆栈欺骗这个技术同样适用于卡巴斯基的对抗，两个杀软都存在栈回溯技术能通过返回地址定位你的函数调用链，第二个对抗方式就是unhook对抗，通过取消api的挂钩也是可以bypass bit的基于以上两种方式，bitdefender的bypass方式同样也适用于eset。

动态检测：

个人总结r3层的动态检测大部分基于你的函数调用链，以及是否存在一些危险行为。

各种注入：

很多人比较喜欢在loader层面实现注入的操作，比如最近比较火的 poolparty，dllcallback，threadless，apc注入等，个人经验来讲，注入属于后渗透的操作了，并不应该去作为loader的一部分，获取目标句柄本身就是一个很存在风险的操作，360在不开核晶的情况下对目前主流的注入方式都是直接秒杀，我甚至只用syscall的方式调用通用内存申请方式就能上线，同时在注入的过程中我们需要注意一个很多人不太关注的点那就是cfg，cfg是什么简单通俗来讲就是进程保护的一种机制，很有可能在你注入的过程中就会触发该机制从而导致目标进程自动崩溃（注崩），所以并不建议一开始就进行注入。

傀儡进程：

为什么不要使用傀儡进程，我个人的理解是在对抗国外某些大型杀软时起一个进程并不是一个很好的选择，这会被杀软通过内核事件进行记录，对于国内的360或者火绒或许并没有这么严格的检测机制，所这里我仅仅只是对于国外的杀软，尽量不要使用傀儡进程，测试中defender和卡巴包括eset是没有查杀的所有这里可以作为一个动态对抗的一种手段，但其实我个人更喜欢使用模块镂空来实现，这种技术不在需要依赖于传统的内存申请调用链来实现shellcode的加载。

ppid欺骗：

个人认为在shellcode加载层面完全是一个没有用的技术，先不说其技术特点，光获取目标句柄以及创建进程就不是一个特别明智的行为，个人感觉逃避基于父/子进程关系的检测已经不算是一个杀软检测的核心点了，其实在r3层的ppid欺骗对于内核层检测并没有什么意义，通过白加黑的形式去加载已经是一个较为合理的加载方式。

syscall：

现代loader中或者是c2开发中基本上是一个必要存在的技术点，市面上很多syscall方案，veh，各种gate，以及syswhispers3等，市面上存在大量成熟的syscal的方案，个人比较推荐的就是veh或者peb+hash的方式，说到peb，我们可以通过peb去自实现一套GetModuleHandle/GetProcAddress，这其实就是动态调用的进阶玩法，当然动态调用依旧是一个不错的选择，当然我们需要注意的就是syscall存在一个缺陷就是调用链不够完整，举个列子run shellcode VirtualAlloc kernel32 kernelbase ntdll->NtAllocateVirtualMemory这是一个VirtualAlloc的调用链，可以看到kernel32到ntdll这个是一个完整的调用链，但很多syscall的常规玩法从调用链看上去就是直接ntdll，这可能会成为一个不太好的点虽然杀软并会作为查撒和点但是我个人习惯是构造完整链，当然这里也是有方法解决的那就是寻找一个非ntdll的跳板函数去构建假的调用链，这里存在弊端就是跳板函数容易成为特征，这种方式有好有坏吧。

白加黑：

目前来说除开360个人认为是针对cs这种被厂商研究透彻的c2payload加载的最佳方式，在操作系统上其实存在不少可劫持的dll，但是注意如果杀软会对system32/wow64下的dll进行校验，那么劫持系统本身的dll则不太适合，更多的其实应该挖掘第三方的软件，挖掘工具https github.com/Accenture/Spartacus  该工具可同时挖掘com劫持。

内存加载：

这个技术其实更多的是给自己的c2使用的，对于cs的shellcode并不会作为常规的payload加载方式，更多的还是去读取内容然后使用win32api进行加载。

反沙箱和反调试：

此技术是必要的，即便能正常上线，依旧存在样本被云上传之后继续行为分析，如果分析出存在恶意操作，将不利于shellcode的长期运行。

加壳：

个人的建议书有能力自己可以实现一个压缩壳，使用llvm，se，或者vmp不一定会是一个好的静态或者动态对抗策略。

总结

个人总结动态对抗，核心应该是少做花里胡哨的操作，在进行syscall时构造完整的调用链，让你的程序看上去越正常越好，如果开发自己的c2也应该遵循该原则，在后渗透的过程中尽量不要去使用shell命令特别是cs自己的，更多依赖于bof 进行操作。

原文始发于微信公众号（泾弦安全）：动态对抗杀软总结