
Ein PowerShell-Skript, das hilft, anfällige Einstellungen in AD-Gruppenrichtlinien zu finden. (veraltet, stattdessen Grouper2 verwenden!)
VERWENDE GROUPER NICHT MEHR. VERWENDE GROUPER2! https://github.com/l0ss/Grouper2
Ein PowerShell-Skript, das dabei hilft, anfällige Einstellungen in der AD-Gruppenrichtlinie zu finden.

Grouper ist ein PowerShell-Modul, das für Pentester und Redteam-Mitglieder (aber wahrscheinlich auch für Systemadministratoren nützlich) entwickelt wurde. Es durchforstet die (normalerweise sehr lauten) XML-Ausgaben des Get-GPOReport-Cmdlets (Teil des Microsoft Group Policy-Moduls) und identifiziert alle in Gruppenrichtlinienobjekten (GPOs) definierten Einstellungen, die für jemanden nützlich sein könnten, der etwas Lustiges/Böses tun möchte.
Beispiele für die Arten von Dingen, die es in GPOs findet:
Ja, es ist ziemlich grob, aber es spart mir enorm viel Zeit beim Durchlesen dieser schrecklichen 150 MB großen HTML-GPO-Berichte, und wenn es für mich funktioniert, könnte es auch für Sie funktionieren.
Hinweis: Obwohl einige Funktionsnamen das Wort 'Audit' enthalten könnten, ist Grouper ausdrücklich NICHT als erschöpfendes Audit für Best-Practice-Konfigurationen gedacht. Wenn Sie das wollen, sollten Sie Microsoft SCT und LGPO.exe oder ähnliches verwenden.
Generieren Sie einen GPO-Bericht auf einem Windows-Rechner mit den installierten Gruppenrichtlinien-Cmdlets. Diese sind standardmäßig auf Domänencontrollern installiert, können auf Windows-Clients mit RSAT installiert werden oder über den Assistenten 'Rolle hinzufügen' auf Windows-Servern aktiviert werden.
Get-GPOReport -All -ReportType xml -Path C:\temp\gporeport.xml
Importieren Sie das Grouper-Modul.
Import-Module .\grouper.psm1
Führen Sie Grouper aus.
Invoke-AuditGPOReport -Path C:\temp\gporeport.xml
Es gibt auch ein paar Parameter, mit denen Sie herumspielen können, die beeinflussen, welche Richtlinieneinstellungen Grouper Ihnen anzeigt:
-showDisabled
Standardmäßig zeigt Grouper Ihnen nur GPOs, die derzeit aktiviert und mit einer OU in AD verknüpft sind. Dies schaltet dieses Verhalten um.
-Online
Standardmäßig arbeitet Grouper nur mit der tatsächlichen XML-Ausgabe von Get-GPOReport und führt überhaupt keine Netzwerkkommunikation durch, was es recht 'opsec-sicher' macht, obwohl ich diesen Begriff hasse.
Wenn Sie es mit -Online aufrufen, aktiviert Grouper Überprüfungen, die eine Kommunikation mit (mindestens) der AD-Domäne erfordern, aus der der Bericht generiert wurde, aber wahrscheinlich auch mit Dateiservern usw. Dies ermöglicht Grouper nützliche Dinge wie das Melden der ACLs auf Dateien, die von GPOs anvisiert werden, und die Überprüfung, ob z.B. der aktuelle Benutzer in die betreffende Datei schreiben kann.
-Level
Grouper hat 3 Filterstufen, die Sie auf seine Ausgabe anwenden können.
Die Verwendung ist unkompliziert. -Level 3, -Level 2, etc.
Get-GPOReport funktioniert auch auf nicht der Domäne beigetretenen Maschinen über runas /netonly einwandfrei. Sie benötigen einige Low-Priv-Anmeldeinformationen, aber das ist zu erwarten.
Machen Sie es so:
runas /netonly /user:domain\user powershell.exe
auf einer nicht der Domäne beigetretenen Maschine, die mit einem Domänencontroller kommunizieren kann.
Führen Sie dann in der resultierenden PowerShell-Sitzung Folgendes aus:
Get-GpoReport -Domain example.com -All -ReportType xml -Path C:\temp\gporeport.xml
Einfach.
Alles, was Grouper zum Funktionieren braucht, ist PowerShell 2.0 und die XML-Datei aus der Get-GPOReport-Ausgabe. Sie können es auf einer VM ohne Netzwerkkarte ausführen, wenn Sie besorgt sind, und es wird trotzdem einwandfrei funktionieren.
Abgesehen davon ist der Code recht einfach, sodass es nicht schwer sein sollte zu erkennen, dass er nichts im Entferntesten Verdächtiges tut.
Kurze Antwort: Ja.
Lange Antwort: Ja, eine dieser Lösungen wäre besser, aber es gibt ein paar Dinge, die mich bisher daran gehindert haben.
Idealerweise würde ich die Richtliniendateien direkt aus SYSVOL parsen, aber sie sind in einer Reihe verschiedener Dateiformate gespeichert, einige sind proprietär, sie sind sehr mühsam zu lesen, und ich habe weder die Zeit noch die Neigung, eine Reihe von Parsern dafür von Grund auf zu schreiben, wenn Microsoft bereits Cmdlets bereitstellt, die die Arbeit sehr gut erledigen.
In naher Zukunft möchte ich Microsofts Get-GPOReport in Grouper einbauen, sodass Sie überhaupt kein RSAT mehr benötigen, aber ich muss herausfinden, ob das eine Art Urheberrechtsverletzung darstellt. Ich muss auch herausfinden, wie ich das, was ich gerade gesagt habe, tatsächlich umsetzen kann.
Grouper ist kein Schwachstellenscanner. Grouper filtert lediglich die enorme Menge an überflüssigem Inhalt und Rauschen in Gruppenrichtlinienberichten, um Ihnen nur die Richtlinieneinstellungen zu zeigen, die auf ausnutzbare Weise konfiguriert sein KÖNNTEN.
Soweit möglich arbeite ich jede der Kategorien von Prüfungen durch, um zusätzliche Filterung hinzuzufügen, um offensichtlich nicht anfällige Konfigurationen zu entfernen und das Rauschen weiter zu reduzieren, aber Gruppenrichtlinien sind extrem flexibel und es ist ziemlich schwierig, jeden möglichen Fehler vorherzusehen, den ein Admin machen könnte.
Cool, du hast gerade einen Weg gefunden, Grouper besser zu machen! Blättere nach unten und du wirst sehen, wo ich eine kleine Anleitung zum Hinzufügen neuer Prüfungen zu Grouper bereitgestellt habe.
Ich hab deinen Rücken, Kumpel. Es gibt eine test_report.xml im Repo, mit der du es ausprobieren kannst. Sie enthält eine Reihe schlechter Einstellungen, sodass du sehen kannst, wie das aussieht.
Du musst es mit dem Flag -showDisabled ausführen, weil es so voll mit wirklich schrecklichen Konfigurationen ist, dass ich das GPO nicht einmal in einer Laborumgebung aktivieren wollte.
OK.

Kurze Antwort: PowerView wird das ganz gut machen.
Längere Antwort: Ich werde versuchen, diese Funktionalität irgendwann hinzuzufügen, aber in der Zwischenzeit halt die Klappe und benutze PowerView.
Cool, leicht zu beheben.
Öffne grouper.ps1, suche das '$polchecks'-Array und kommentiere einfach die Zeile aus, in der diese Prüfung zum Array hinzugefügt wird.
Fertig.
Klar, klingt gut.
Hole eine GPOReport-XML-Ausgabe, die die Art der Richtlinie/Einstellung enthält, die Grouper finden können soll. Dies kann das Erstellen einer geeigneten Richtlinie in einer Laborumgebung erfordern.
Finde das <GPO> XML-Objekt, das zu deiner Zielrichtlinie passt.
Finde den Unterabschnitt des XML, der die Informationen enthält, die du aus der Richtlinie extrahieren möchtest. Richtlinieneinstellungen sind entweder in Benutzer- oder Computerrichtlinien unterteilt, daher befindet sich dies normalerweise entweder in:
GPO.Computer.ExtensionData.Extension
oder
GPO.User.ExtensionData.Extension
Jetzt kommt der lästige Teil – der Grund, warum dieser Code so ein Durcheinander ist, ist, dass jeder Richtlinieneinstellungsabschnitt unterschiedlich strukturiert ist und sie sehr unterschiedliche Namenskonventionen verwenden, also musst du herausfinden, wie deine Zielrichtlinie strukturiert ist. Viel Glück?
Hier ist ein Grundgerüst einer Prüffunktion, die du als Einstieg verwenden kannst. Stelle sicher, dass sie entweder gar nichts zurückgibt oder $null zurückgibt, wenn nichts Interessantes gefunden wird.
Function Get-GPOThing {
[cmdletbinding()]
Param (
[Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [System.Xml.XmlElement]$polXML,
[Parameter(Mandatory=$true)][ValidateSet(1,2,3)][int]$level
)
######
# Description: Checks for Things.
# Vulnerable: Description of what it shows if Level -eq 3
# Interesting: Description of what it shows if Level -eq 2
# Boring: All Things.
######
$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
""
}
}
}
}
Vielen Dank an:
Apropos beschissener Code, ja, ich weiß, dass dies ein kleines Durcheinander ist. Ich habe versucht, es so modular wie möglich zu gestalten, damit andere ohne allzu große Mühe zusätzliche Prüfungen hinzufügen können, aber es braucht noch viel Liebe. Wenn du einen Fehler siehst, den ich gemacht habe und der dringend behoben werden muss, lass es mich bitte wissen.
Navigiere mit Strg-f zu '$polchecks' und füge es zusammen mit den anderen zum Array der Prüfungen hinzu.
Teste es.
Wenn es funktioniert, reiche einen Pull-Request ein!
Wenn du nicht weiterkommst, melde dich. Ich werde versuchen zu helfen, wenn ich ein paar Minuten zusammenkratzen kann.