深入解析IIS Raid技术原理

在分析IIS Raid时，往往会把注意力局限在表面的DLL加载上，实际上它的“隐蔽”来自于对IIS请求管线的深度劫持——一次请求可以在不触发任何日志的情况下，被注入任意PowerShell指令。

IIS Raid的核心机制

IIS Raid并非传统的外部后门，而是利用原生的IIS native module接口，将自定义的HttpModule注册到GlobalModule列表。模块在OnBeginRequest阶段拦截HttpRequest对象，读取特定的自定义Header（如X-CT-BALA），并将Header值与硬编码密码进行比对。匹配成功后，模块直接调用system()或PowerShell.exe -EncodedCommand执行传入的payload，随后把执行结果写入自定义响应Header返回给客户端。

请求拦截与指令注入的细节

关键在于pHttpRequest->GetHeader的调用时机。IIS的请求处理是分层的：BeginRequest → AuthenticateRequest → ResolveRequestCache → ... → EndRequest。Raid选择在BeginRequest阶段介入，意味着后续的URL映射、身份验证甚至错误处理都被绕过。此时，IIS的RequestHeaders集合尚未被清洗，攻击者只需在HTTP请求中加入Header: X-CT-BALA: SIMPLEPASS和Header: X-Command: [Base64]，即可实现“零痕迹”执行。

• 模块加载：通过appcmd.exe install module向applicationHost.config写入路径。
• 密码校验：Header字段名与密码均可在源码Functions.h中自定义，降低被特征扫描捕获的概率。
• 指令执行：Payload采用Base64或URL编码，避免在明文HTTP流中暴露。
• 结果回传：执行结果被写入自定义响应Header（如X-Result），客户端脚本解析后展示。

“如果你把IIS当成普通的Web服务器来防御，Raid的存在就像是隐形的后门钥匙。”

从防御视角看，最直接的手段是禁用未签名的全局模块、审计applicationHost.config的globalModules节点，并在WAF层面拦截异常Header。事实上，有企业在部署后仅用AppCmd.exe uninstall module便清除了潜在的持久化威胁。到底还有哪些细节被忽视？这正是安全团队需要持续追踪的“灰色地带”。