虚拟机中使GPO攻击

虚拟机中的GPO攻击：一场与系统策略的“猫鼠游戏”（附实战心得）

哎,说到虚拟机里的GPO攻击，我真是又爱又恨！爱的是它那“一击致命”的快感，恨的是配置不当就让你抓耳挠腮、怀疑人生，今天咱不整那些枯燥的理论，我就以一个“老油条”的身份，跟你唠唠我在虚拟机里折腾GPO（组策略对象）攻击时那些真实的心路历程和踩坑经验。（此段可点击跳转至我的历史文章《域渗透之GPO滥用指南》，但今天咱聊点更野的套路）

开场先泼冷水：为啥非要在虚拟机里搞？

你可能会问：“哥们儿，我直接在物理机上测试不行吗？” 我的天，那可太“刑”了！GPO攻击本质上是针对Active Directory域环境的“合法滥用”，一旦你手滑把策略推错了范围，轻则全网蓝屏（别笑，我见过因为GPO部署了错误打印机驱动导致全公司电脑卡死的惨案），重则域控直接被锁死。虚拟机就是我们最后的“安全屋”，在这里翻车了，咱顶多损失一个快照，但在生产环境翻车……那画面太美我不敢看。

而且啊,虚拟机里模拟GPO攻击有个天然优势：你可以随时“悔棋”，比如我用组策略管理编辑器给某个OU（组织单位）配置了一个“禁止运行regedit.exe”的策略，想验证攻击效果？直接对目标虚拟机执行gpupdate /force，见证奇迹的时刻到了——如果策略生效，目标机立马“瘫痪”；如果没生效，咱就回到快照点，检查是SYSVOL复制延迟了，还是Kerberos票据没刷新，这种“试错成本为零”的快感，在现实环境里可享受不到。

核心骚操作：三种GPO攻击手法，我踩过的坑都在这

经典“GPO首选项（GPP）密码提取”——别再用旧工具了！

哎呀,说起这个我就来气！网上那些老教程还在教用Get-GPPPassword.ps1脚本，但你敢信吗？在2024年的环境中，微软早在2014年就封堵了SYSVOL中明文存储密码的漏洞（MS14-025），我当初就是信了“邪”，在虚拟机里配置了一个包含cpassword的GPP条目，结果脚本运行完只回显了一堆乱码——因为域控是Server 2022，并且我启用了Pfixer补丁！

正确的玩法是啥？你得先降级域控功能级别，或者手动在GPO中创建“受限制的组”并设置密码，然后才能用Invoke-GPPStealer之类的工具从\\domain\SYSVOL\...\Groups.xml中提取加密后的密码，但这里有个致命细节：虚拟机内存恢复快照时，DNS缓存可能残留旧记录，我那次就是因为忘记刷新DNS，导致脚本解析到错误的域控IP，白白浪费了半小时，切记：操作前先ipconfig /flushdns，再nltest /dsregdns，血的教训啊！

“受害者视角”的GPO攻击：滥用“注册表策略”搞持久化

说真的,GPO攻击最狠的反而不是拿域管权限，而是制造“合法假象”，比如我在虚拟机里设置了一个注册表策略，让目标机器每次开机都自动执行一个米特尼克风格的反弹Shell脚本，具体操作是：GPO路径在“计算机配置→首选设置→Windows设置→注册表”，新建一个注册表项HKCU\Software\Microsoft\Windows\CurrentVersion\Run，键值指向我的监听程序。

这里有个大坑：当你用域管账号运行gpupdate /force时，策略立刻生效，但如果你用的是普通域用户，策略的刷新周期是90分钟±30分钟的随机偏移，我那会儿傻乎乎地以为没生效，蹲在虚拟机前面等了三小时，结果发现是我把“目标用户”的OU搞错了——策略要链接到包含用户账号的OU上，而不是计算机的OU！你说这事儿闹的，真让人血压飙升。

高级玩法：利用GPO的“安全筛选”绕过反击

呜呜呜,提到这个我就想起一次“社死”现场，我在虚拟机里搭建了一个有两个子OU的域环境，想测试“仅对Sales部门生效”的GPO攻击，结果配置完发现，Sales部门的电脑确实中招了，但IT部门的电脑也弹出了错误警告——为啥？因为我没注意“安全筛选”默认是“认证用户”组，这导致所有经过身份验证的域用户都会被策略波及。

正确的做法是：在GPO的“安全筛选”里，删除“认证用户”，只添加“Domain Computers”或者特定组，然后还要在“委托”标签里配置“读取”和“应用组策略”权限，否则策略会默默“跳过”，这个坑我连续踩了两次，第二次终于用gpresult /h report.html查看RSOP（策略结果集）才定位到问题，说实话，那一瞬间我真想砸了虚拟机，但转念一想，这不就是攻防的乐趣所在嘛！

防御视角：我用GPO攻击自己的虚拟机，反而学到了防御精髓

其实最绝的是,当你以攻击者的思路去配置GPO时，你自然就明白了怎么防守，比如我在虚拟机上对“默认域策略”动了手脚之后，我立刻用Microsoft Security Compliance Toolkit做了基线对比，发现改动点全被红色的“！”标出来了，后来我在真实渗透测试中，遇到一个可疑的GPO，我就是靠“检查SYSVOL中是否有非标准的.xml或.ini文件”来判断是否被植入后门的。

而且啊,虚拟机里的日志记录太强大了，当我的GPO攻击触发时，域控的事件查看器会留下ID为5136或5140的事件，记录谁在什么时间修改了GPO，那一刻我突然明白，最好的攻击就是“无声的攻击”——你要么想办法清除这些日志（比如先拿下域管权限，再wevtutil cl），要么用LSASS注入的方式获取权限后，用原生的dsget命令修改GPO，而不要调用额外的工具，减少痕迹。