红队攻防之基础免杀( 二 )


红队攻防之基础免杀

文章插图
 
遍历内存进行搜索:
红队攻防之基础免杀

文章插图
 
二、 将DLL及其相应的节写入内存中:
红队攻防之基础免杀

文章插图
 
三、 建立DLL导入表,以便DLL可以调用ntdll.dll和kernel32.dll WINAPI
红队攻防之基础免杀

文章插图
 
四、 修复重定位表:
红队攻防之基础免杀

文章插图
 
五、 调用DLL的入口点:
红队攻防之基础免杀

文章插图
 
最终我们的恶意代码位于dllmain中,项目还是采用加载shellcode的方式上线cs 。
柔性加载
限制使用具有RWX标记的内存,cs在4+可以直接进行相关配置 。
红队攻防之基础免杀

文章插图
 
推荐配置:
set startrwx "false"; set userwx "false"; set cleanup "true"; set stomppe "true"; set obfuscate "true"; set sleep_mask "true"; set smartinject "true"; 牛刀小试 360
使用base64+xor混淆shellcode:
红队攻防之基础免杀

文章插图
 
成功bypass:
红队攻防之基础免杀

文章插图
 
红队攻防之基础免杀

文章插图
 
火绒
和上述方法相同:
红队攻防之基础免杀

文章插图
 
红队攻防之基础免杀

文章插图
 
definder
加强shellcode的混淆:
std::string rest2_reference = "xxx", "==");
依旧报毒,但是类型发生改变了,说明静态的混淆有效果:
红队攻防之基础免杀

文章插图
 
异或的操作,比较可疑,经过测试发现是cs的shellcode出现在数组里就报毒,应该是对内存进行的扫描 。
所以我们可以使用《文章二》中提及的技术“规避常见的恶意API调用模式”,将shellcode分片直接写入连续内存 。
在测试的过程中发现莫名其妙的过了查杀:
红队攻防之基础免杀

文章插图
 
很神奇,这段并没有实现内存的切片写入,因为shellcode的大小没有达到4096,实际上相当于直接分配了个大小为4096的数组,写入了shellcode 。
而且把这段代码相同的格式放外面就不行,个人感觉definder还是没有去检查内存 。


推荐阅读