不要再使用Grouper了。请使用Grouper2! https://github.com/l0ss/Grouper2
一个用于帮助发现Active Directory组策略中易受攻击设置的PowerShell脚本。

Grouper是一个为渗透测试人员和红队设计的PowerShell模块(虽然对系统管理员也可能有用),它筛选来自Get-GPOReport cmdlet(属于Microsoft的组策略模块)的(通常非常嘈杂的)XML输出,并识别组策略对象(GPO)中定义的所有可能对试图进行有趣/邪恶操作的人有用的设置。
以下是它在GPO中发现的一些东西的例子:
没错,它相当粗糙,但它为我节省了大量阅读那些糟糕的150MB HTML GPO报告的时间,如果它对我有用,那么可能对您也有用。
注意:虽然某些函数名称可能包含“audit”一词,但Grouper明确不旨在对最佳实践配置等进行详尽审计。如果您需要那种功能,应该使用Microsoft SCT和LGPO.exe之类的工具。
在安装了组策略cmdlet的Windows机器上生成GPO报告。 域控制器上默认安装了这些cmdlet,可以在Windows客户端上通过RSAT安装,或者通过Windows服务器上的“添加功能”向导启用。
Get-GPOReport -All -ReportType xml -Path C:\temp\gporeport.xml
导入Grouper模块。
Import-Module .\grouper.psm1
运行Grouper。
Invoke-AuditGPOReport -Path C:\temp\gporeport.xml
您还可以调整一些参数,用于更改Grouper将显示哪些策略设置:
-showDisabled
默认情况下,Grouper只显示当前已启用且链接到AD中某个OU的GPO。此参数切换该行为。
-Online
默认情况下,Grouper仅处理Get-GPOReport的实际XML输出,不进行任何网络通信,因此相当“opsec安全”,尽管我讨厌这个词。
如果您使用-Online参数调用,Grouper将启用需要(至少)与生成报告所在的AD域通信的检查,但也可能涉及与文件服务器等通信。这将允许Grouper执行诸如报告GPO目标文件的ACL,以及检查当前用户是否可写入该文件等便捷操作。
-Level
Grouper有3个级别的过滤,您可以应用于其输出。
使用方法很简单。-Level 3, -Level 2等。
Get-GPOReport 通过 runas /netonly 在非域加入的机器上完全正常工作。您需要一些低权限凭据,但这是预料之中的。
像这样操作:
runas /netonly /user:domain\user powershell.exe
在一台能与域控制器通信的非域加入机器上。
然后在生成的 PowerShell 会话中,像这样操作:
Get-GpoReport -Domain example.com -All -ReportType xml -Path C:\temp\gporeport.xml
非常简单。
Grouper 运行所需的一切只是 PowerShell 2.0 和 Get-GPOReport 输出的 xml 文件。如果您担心,可以在没有网卡的虚拟机中运行它,它仍然可以正常工作。
再说了,代码基本很简单,所以不难看出它并没有做任何可疑的事情。
简短回答:是的。
详细回答:是的,做这些事情之一会更好,但有一些原因阻止我目前去做。
理想情况下,我希望直接从 SYSVOL 解析策略文件,但它们以多种不同的文件格式存储,有些是专有格式,阅读起来非常痛苦,而且我没有时间也没有兴趣从头编写一堆解析器,而微软已经提供了很好的 cmdlet 来完成这项任务。
在不久的将来,我想把微软的 Get-GPOReport 烘焙到 Grouper 中,这样您就不需要 RSAT 了,但我需要弄清楚这是否会构成某种版权侵犯。我还需要弄清楚如何实现我刚才说的那个功能。
Grouper 不是漏洞扫描器。Grouper 只是筛选组策略报告中大量的无用信息和噪音,向您展示可能以可利用方式配置的策略设置。
在可能的范围内,我正在逐步为每个检查类别添加额外的过滤,以剔除明显不脆弱的配置,并进一步降低噪音水平,但组策略非常灵活,很难预料管理员可能犯的所有错误。
太好了,您刚刚找到了一种改进 Grouper 的方法!往下翻,您会看到我提供了一个关于如何向 Grouper 添加新检查的小指南。
我支持您,兄弟。仓库里有一个 test_report.xml,您可以用来试试。里面包含许多糟糕的设置,这样您就能看到效果。
您需要使用 -showDisabled 标志来运行它,因为它充满了非常糟糕的配置,我甚至不想在实验室环境中启用那个 GPO。
好的。

简短回答:PowerView 可以很好地完成这项工作。
详细回答:我会尝试在某个时候添加这个功能,但在此期间,闭嘴,用 PowerView 吧。
没问题,很容易解决。
打开 grouper.ps1,找到 "$polchecks" 数组,然后注释掉添加该检查的那一行。
搞定。
当然,没问题。
获取包含您希望 Grouper 能找到的策略/设置类型的 GPOReport xml 输出。这可能需要在实验室环境中创建一个合适的策略。
找到与目标策略匹配的 <GPO> xml 对象。
找到包含您想从策略中提取的信息的 xml 子部分。策略设置分为用户策略或计算机策略,因此通常位于以下位置之一:
GPO.Computer.ExtensionData.Extension
或
GPO.User.ExtensionData.Extension
现在是令人讨厌的部分——这段代码之所以如此混乱,是因为每个策略设置部分的结构都不同,并且它们使用截然不同的命名约定,因此您需要弄清楚目标策略的结构。祝您好运?
这是一个检查函数的骨架,您可以用它来开始。确保如果没有发现有趣的内容,它要么不返回任何内容,要么返回 $null。
Function Get-GPOThing {
[cmdletbinding()]
Param (
[Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [System.Xml.XmlElement]$polXML,
[Parameter(Mandatory=$true)][ValidateSet(1,2,3)][int]$level
)
######
# Description: 检查某些东西。
# Vulnerable: 如果 Level -eq 3 时显示的内容描述
# Interesting: 如果 Level -eq 2 时显示的内容描述
# Boring: 所有东西。
######
$settingsThings = ($polXml.Thing.ExtensionData.Extension.Thing | Sort-Object GPOSettingOrder)
if ($settingsThings) {
foreach ($setting in $settingsThings) {
if ($level -eq 1) {
$output = @{}
$output.Add("Name", $setting.Name)
if ($setting.SettingBoolean) {
$output.Add("SettingBoolean", $setting.SettingBoolean)
}
if ($setting.SettingNumber) {
$output.Add("SettingNumber", $setting.SettingNumber)
}
$output.Add("Type", $setting.Type.InnerText)
Write-Output $output
""
}
}
}
}
非常感谢:
说到糟糕的代码,是的,我知道这有点乱。我已经尽量使其模块化,以便其他人能够相对轻松地添加额外的检查,但它仍然需要很多改进。如果您发现我犯了一个迫切需要修复的错误,请告诉我。
使用 Ctrl+F 找到 "$polchecks",然后将其添加到检查数组中,与其他检查一起。
测试它。
如果有效,提交一个拉取请求!
如果遇到问题,联系我。如果我能挤出几分钟时间,我会尽力帮忙。