安全策略被修改与防护绕过取证分析

安全策略被修改与防护绕过取证分析

很多蓝队现场会把注意力放在“恶意程序是什么”，但在真实入侵中，攻击者往往在样本运行之前就先做了一件更关键的事：让安全产品别管它。

最常见的手法不是高深的内核驱动，而是非常朴素的策略削弱：

• 关闭实时防护
• 添加目录排除项
• 添加进程排除项
• 关掉云保护、样本提交、脚本扫描
• 修改本地策略或注册表

这些动作本身就具有强攻击语义，因为它们通常不是业务行为，而是为后续木马、矿工、窃密、横向和清痕让路。

0x01 这类取证要回答什么

建议优先回答四个问题：

1. 防护被改了什么？ 是关闭功能、加排除项，还是改审计策略和本地安全策略。
2. 是谁改的？ 是管理员、恶意脚本、服务账号，还是远程会话中的攻击者。
3. 是什么时间改的？ 是否紧贴在样本执行、WebShell 落地、横向移动之前。
4. 改完之后发生了什么？ 有没有出现木马、隧道、压缩外传、凭据抓取等后续行为。

0x02 公开案例一：WhisperGate 使用 PowerShell 添加 Defender 排除项

Unit 42 在 2022 年有关乌克兰网络攻击的通报里提到：

• WhisperGate 相关攻击链中
• wscript.exe 执行 VBS
• VBS 再调用 PowerShell
• 使用 Set-MpPreference -ExclusionPath 'C:\'
• 将整盘加入 Windows Defender 排除范围

这类行为的危险不在于“某个恶意文件被放行”，而在于它一次性给整个系统腾出了执行空间。

公开来源：

• Unit 42: Threat Brief: Ongoing Russia and Ukraine Cyber Activity

0x03 公开案例二：Silent Skimmer 使用 Add-MpPreference 放行目录

Unit 42 在 2024 年 Silent Skimmer 事件中披露：

• 攻击者利用 Telerik 漏洞进入环境
• 随后调用 powershell -ExecutionPolicy Bypass Add-MpPreference -ExclusionPath D:\
• 把指定盘符加入排除列表

这说明很多攻击者的思路很实际：

• 不求关掉整个安全产品
• 只要把后门和载荷活动目录放进排除项就够了

公开来源：

• Unit 42: Silent Skimmer Gets Loud (Again)

0x04 公开案例三：Fake Installers to Monero 广泛添加 Defender 排除项

Elastic Security Labs 在 2026 年假安装包投放矿工的研究中提到：

• Loader 会隐藏运行 PowerShell
• 调用 Add-MpPreference -ExclusionPath
• 调用 Add-MpPreference -ExclusionProcess
• 把自身、%TEMP%、%LocalAppData%、%AppData% 以及后续用到的 LOLBin 一并放进行为白名单

这非常适合写进实战文档，因为它说明：

• 排除项不是“偶尔一个目录”
• 真正恶意事件里，经常是整套 staging 目录和进程链一起被放行

公开来源：

• Elastic Security Labs: Fake Installers to Monero: A Multi-Tool Mining Operation

0x05 Windows 现场排查命令

1. 直接看 Defender 当前配置

Get-MpPreference | Select-Object `
  DisableRealtimeMonitoring,
  DisableBehaviorMonitoring,
  DisableScriptScanning,
  MAPSReporting,
  SubmitSamplesConsent,
  ExclusionPath,
  ExclusionProcess,
  ExclusionExtension

2. 查 Defender 状态

Get-MpComputerStatus | Select-Object `
  AMRunningMode,
  AntivirusEnabled,
  RealTimeProtectionEnabled,
  IoavProtectionEnabled,
  NISEnabled,
  AntispywareEnabled

3. 查最近是否有人执行过策略修改命令

$start=(Get-Date).AddDays(-3)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=$start} |
  Where-Object {
    $_.Message -match 'Add-MpPreference|Set-MpPreference|powershell\.exe|pwsh\.exe'
  } |
  Select-Object TimeCreated, Message

4. 查注册表策略位

reg query "HKLM\SOFTWARE\Microsoft\Windows Defender" /s
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /s
reg query "HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions" /s
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Exclusions" /s

5. 查是否用脚本批量改策略

Get-ChildItem C:\ -Recurse -Force -ErrorAction SilentlyContinue |
  Where-Object {$_.Extension -in '.ps1','.vbs','.bat','.cmd'} |
  Select-String -Pattern 'Add-MpPreference|Set-MpPreference|DisableRealtimeMonitoring|ExclusionPath|ExclusionProcess' -ErrorAction SilentlyContinue

0x06 审计策略与本地安全策略的取证点

防护绕过不只发生在 Defender，也可能发生在本地安全策略层。

1. 常见风险点

• 审计策略被关闭或缩窄
• 本地安全策略被放松
• 防火墙规则被调整
• SmartScreen 或脚本限制被削弱
• WDAC/AppLocker 规则被改

2. 重点排查命令

auditpol /get /category:*
netsh advfirewall show allprofiles
Get-AppLockerPolicy -Effective -Xml

如果条件允许，也建议导出：

secedit /export /cfg C:\Temp\secpol_export.inf

这样后续可以和基线比对。

0x07 一条现场可执行的排查流程

如果你怀疑主机已经被做了防护绕过，建议按下面顺序执行：

1. 先用 Get-MpPreference 看排除项和关键开关
2. 再用 Get-MpComputerStatus 看防护是否还在运行
3. 再查 4688 / Sysmon 是否有 Add-MpPreference、Set-MpPreference
4. 再看策略修改之后是否紧跟样本落地、外联、隧道或压缩外传
5. 最后导出策略状态，和基线对比后恢复

0x08 处置前的证据固定建议

不要一上来就急着把排除项删光，建议先固定：

Get-MpPreference | Out-File C:\Temp\mpreference.txt
Get-MpComputerStatus | Out-File C:\Temp\mpstatus.txt
auditpol /get /category:* > C:\Temp\auditpol.txt
reg export "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" C:\Temp\defender_policy.reg /y

固定完再恢复，会更利于后续复盘和写报告。

0x09 恢复命令示例

1. 删除恶意排除项

Remove-MpPreference -ExclusionPath "C:\"
Remove-MpPreference -ExclusionPath "D:\"
Remove-MpPreference -ExclusionProcess "C:\Users\Public\loader.exe"

2. 恢复关键防护项

Set-MpPreference -DisableRealtimeMonitoring $false
Set-MpPreference -DisableBehaviorMonitoring $false
Set-MpPreference -DisableScriptScanning $false

3. 再次确认状态

Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled

0x0A 三个常见误区

1. 只查恶意文件，不查防护是否被削弱

很多现场之所以“什么都没拦住”，不是样本太强，而是防护早就被动过了。

2. 只看当前状态，不看修改时间窗

当前看到一个排除项，并不能说明是谁加的；只有把时间和后续行为串起来，才能说明它是攻击链一部分。

3. 恢复了设置就结束

如果加排除项的脚本、任务或后门还在，防护状态很可能会再次被改回去。

0x0B 建议的交付结构

这类事件适合整理为如下表格：

0x0C 总结

安全策略检测 在 0x03 阶段，真正要做的不是简单说“看看 Defender 开没开”，而是要明确回答：

• 哪些防护能力被削弱
• 这些变化是谁造成的
• 它和后续恶意执行是否构成闭环
• 是否还存在会把策略改回去的持续机制

当你把 Add-MpPreference/Set-MpPreference、注册表策略、审计状态和后续木马活动连成同一条时间线时，防护绕过就不再只是一个“配置问题”，而会成为攻击链里非常关键的一环。