GPO-Sicherheitseinstellungen: Vier Prüfungen für Active Directory

Was sind GPO-Sicherheitseinstellungen in Active Directory?

GPO-Sicherheitseinstellungen in Active Directory bestimmen, wie Windows-Clients lokale Namen auflösen, Update-Metadaten vertrauen, LSASS schützen und den Zugriff auf Richtlinienfreigaben authentifizieren. Vier Einstellungen verdienen eine gezielte Prüfung: LLMNR deaktivieren, HTTPS für WSUS-Metadaten verwenden, den LSA-Schutz aktivieren und gegenseitige Authentifizierung sowie Integrität für SYSVOL und NETLOGON verlangen.

Jede Einstellung betrifft eine andere Angriffsvoraussetzung. Eine sichere Update-Verbindung schützt nicht den LSASS-Arbeitsspeicher; das Deaktivieren von LLMNR deaktiviert nicht die NetBIOS-Namensauflösung. Prüfen Sie den Richtlinienwert, die Computer, die ihn erhalten, und den tatsächlich wirksamen Schutz, bevor Sie einen Befund schließen.

Unser Leitfaden zu GPO-Fehlkonfigurationen behandelt delegierte Bearbeitungsrechte, Richtlinienverknüpfungen, LAPS und die Verwaltung von Kennwortrichtlinien. Diese Anleitung behandelt vier konkrete Einstellungen, die auch dann unsicher bleiben können, wenn die administrativen Berechtigungen einer GPO korrekt sind.

Funktionsweise: Vier Richtlinien und ihre Registrierungswerte

Nutzen Sie die folgenden Einstellungen als Prüfziele. Die erwarteten Werte beschreiben eine beabsichtigte Konfiguration, keine Ergebnisse eines Audits Ihrer Umgebung.

1. LLMNR deaktivieren; NBT-NS separat behandeln

Richtlinienpfad: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution.

Registrierungsschlüssel: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient; Wert: EnableMulticast, REG_DWORD 0. Die negative Formulierung der Richtlinie ist entscheidend: Aktiviert schaltet LLMNR aus. Microsoft dokumentiert die Zuordnung der DNS-Client-Richtlinie; die Referenz zur Windows-Server-Baseline legt den Wert null fest.

LLMNR ermöglicht die lokale Namensauflösung, wenn die herkömmliche DNS-Auflösung nicht verfügbar ist. Ein Angreifer, der diesen lokalen Austausch beeinflussen kann, kann einen Client zu einem von ihm kontrollierten Ziel umleiten und eine Authentifizierung auslösen, wie im MITRE-ATT&CK-Eintrag zur Manipulation der Namensauflösung beschrieben. Abgefangene NTLMv2-Antworten sind keine Klartextkennwörter: Microsoft beschreibt NTLM als Challenge-Response-Protokoll. Ob sich eine Authentifizierung weiterleiten lässt, hängt außerdem von den Schutzmaßnahmen des Zieldienstes ab.

NBT-NS ist ein separates Risiko. Microsoft dokumentiert Win32_NetworkAdapterConfiguration.SetTcpipNetbios mit TcpipNetbiosOptions=2, um NetBIOS über TCP/IP für einen Adapter zu deaktivieren. Behandeln Sie diese Methode auf Adapterebene als eigenständige Entscheidung zur Bereitstellung mit eigenen Kompatibilitätsprüfungen. Die LLMNR-Richtlinie und die zugehörige EtcSec-Prüfung belegen keine NetBIOS-Abdeckung.

2. WSUS-Metadaten mit HTTPS schützen

Richtlinienpfad: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location. Die Richtlinienvorlagen für Windows 10/11 ordnen diese Einstellung unter Manage updates offered from Windows Server Update Service ein.

Registrierungsschlüssel: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate; Werte: WUServer und WUStatusServer, beide REG_SZ. Tragen Sie in beide Felder die HTTPS-URL des eingesetzten Servers ein. Der zugehörige Wert HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer ist für die Nutzung von WSUS REG_DWORD 1. Diese Zuordnungen sind in den Windows-Update-Einstellungen dokumentiert.

Microsofts WSUS-Konfigurationsverfahren unterscheidet zwischen HTTPS-Metadaten und der Übertragung von Nutzdaten über HTTP. Ein Angreifer im Übertragungsweg kann ungeschützte Update-Informationen manipulieren. Bewerten Sie die Clients, die diesen Server tatsächlich verwenden, und den abfangbaren Übertragungsweg; schließen Sie aus einer einzelnen URL nicht auf eine Kompromittierung jedes Computers in der Domäne.

3. LSA-Schutz mit einem unterstützten RunAsPPL-Wert aktivieren

Für Windows 11 22H2 und neuer lautet der von Microsoft dokumentierte Pfad in den administrativen Vorlagen Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process. Die dokumentierte Alternative über Gruppenrichtlinien-Einstellungen lautet Computer Configuration > Preferences > Windows Settings > Registry.

Registrierungsschlüssel: HKLM\SYSTEM\CurrentControlSet\Control\Lsa; Wert: RunAsPPL, REG_DWORD. 1 wählt den Schutz mit UEFI-Sperre, sofern unterstützt; Microsoft beschränkt die Durchsetzung von 2 ohne diese Sperre auf Windows 11 22H2 und neuer. Auf x86/x64-Geräten ohne UEFI-Unterstützung oder mit deaktiviertem Secure Boot beruht die Konfiguration auf der Registrierung statt auf einer Firmware-Sperre. Starten Sie nach der Konfiguration neu. Befolgen Sie Microsofts Verfahren zum LSA-Schutz.

Protected Process Light beschränkt das Lesen von Arbeitsspeicher und die Code-Injektion durch ungeschützte Prozesse. Fehlender Schutz kann den Diebstahl von Anmeldedaten erleichtern, nachdem ein Angreifer den erforderlichen Zugriff erlangt hat. Ein Registrierungswert allein belegt nicht den Schutz des laufenden Prozesses. Manche modernen Clients aktivieren den LSA-Schutz automatisch; ein fehlender erhobener GPO-Wert erfordert eine Untersuchung, keine pauschale Aussage, dass LSASS ungeschützt ist.

4. Gegenseitige Authentifizierung und Integrität für Richtlinienfreigaben verlangen

Richtlinienpfad: Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths.

Registrierungsschlüssel: HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths. Setzen Sie beide REG_SZ-Wertnamen, \\*\SYSVOL und \\*\NETLOGON, auf RequireMutualAuthentication=1,RequireIntegrity=1. Die Zuordnung der Connectivity-Richtlinie dokumentiert den Richtlinienpfad und den Registrierungsschlüssel; die Baseline-Referenz legt die erforderlichen Attribute fest.

Gegenseitige Authentifizierung verlangt die Validierung der Kerberos-Serveridentität; Integrität verlangt SMB-Signierung. Microsoft beschreibt UNC-Härtung und Schutz vor dem Abfangen von Verbindungen, einschließlich der standardmäßigen Härtung von SYSVOL und NETLOGON ab Windows 10 und Windows Server 2016.

Unser Leitfaden zu cPassword in SYSVOL erklärt, warum historische GPP-Geheimnisse bereinigt und die betroffenen Anmeldedaten gewechselt werden müssen, und empfiehlt bereits die UNC-Härtung. Hier liegt der Schwerpunkt auf den genauen Freigabemustern und Verbindungsanforderungen. Der Schutz der Übertragung entfernt keine gespeicherten Geheimnisse und korrigiert keine übermäßigen Schreibberechtigungen.

Die Angriffskette: Getrennte Voraussetzungen, getrennte Kontrollen

Dies sind vier unabhängige Angriffspfade, keine vier zwingenden Phasen eines einzigen Exploits. Nutzen Sie diese Unterscheidung, wenn Sie den Umfang einer Untersuchung festlegen:

Ein Konfigurationsbefund begründet Härtungsmaßnahmen. Er belegt nicht, dass ein Angreifer Anmeldedaten abgefangen, ein Update verändert, LSASS ausgelesen oder eine Richtlinie während der Übertragung geändert hat. Stützen Sie jede Schlussfolgerung zu einem Vorfall auf unabhängige Telemetrie.

Erkennung: Den Zielcomputer prüfen

Beginnen Sie mit einem Windows-Zielsystem in jedem relevanten Richtlinienbereich. Microsofts gpresult-Referenz dokumentiert die RSoP-Ausgabe für den Computerbereich:

gpresult /scope computer /r

Die Zusammenfassung hilft dabei, angewendete GPOs zu identifizieren. Nutzen Sie bei der Untersuchung widersprüchlicher Einstellungen eine detaillierte RSoP-Ausgabe und vergleichen Sie diese anschließend mit lokalen Werten und Laufzeitnachweisen. Wiederholen Sie die Prüfungen für jedes Zielsystem, dessen Richtlinienbereich Sie untersuchen.

Die folgenden Befehle verwenden Microsofts dokumentierte Syntax für reg query mit den oben durch Learn belegten Schlüsseln. Führen Sie jeden Befehl einzeln aus.

LLMNR-Konfiguration prüfen

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast

Erwarten Sie REG_DWORD 0. Wenn der Wert fehlt oder abweicht, gleichen Sie das Richtlinienergebnis des Zielsystems ab, bevor Sie die Bereitstellung als erfolgreich bewerten. Untersuchen Sie unerwartete Ziele der lokalen Namensauflösung als Hinweis für eine Untersuchung. Microsofts Referenz zu Defender-for-Identity-Warnungen erkennt die Technikfamilie LLMNR/NBT-NS-Poisoning und SMB-Relay; sie belegt keine universelle Windows-Ereignis-ID für diese Prüfung.

WSUS-Konfiguration prüfen

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

Prüfen Sie WUServer, WUStatusServer und den Eintrag AU\UseWUServer gemeinsam. Vergleichen Sie die URLs mit dem vorgesehenen FQDN und HTTPS-Port, validieren Sie das Zertifikatsvertrauen und bestätigen Sie erfolgreiche Update-Suchen auf dem Client. Eine HTTPS-Zeichenfolge allein validiert weder IIS noch die Zertifikatsbehandlung oder die tatsächliche Nutzung durch Clients. Die hier verwendeten Quellen belegen keine spezifische Ereignis-ID für einen WSUS-Angriff.

LSA-Konfiguration und Start prüfen

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL

Prüfen Sie zur Bestätigung zur Laufzeit nach dem Neustart System / WinInit / Event 12. Dieses Ereignis dokumentiert den geschützten Start von LSASS. Die wevtutil-Referenz dokumentiert Ereignisabfragen; dieses Beispiel wählt Datensätze mit Event 12 zur Prüfung aus:

wevtutil qe System /q:"*[System[(EventID=12)]]" /rd:true /f:text /c:10

Bestätigen Sie, dass der Anbieter WinInit ist und die Meldung den geschützten Start von LSASS betrifft. Der Filter wählt anhand der ID aus, daher können auch andere Anbieter erscheinen. In CodeIntegrity/Operational betrifft das Audit-Ereignis 3065 Anforderungen an gemeinsam genutzte Abschnitte und 3066 Anforderungen an die Microsoft-Signaturstufe; im Audit-Modus darf das Image weiterhin geladen werden. Unter aktiviertem Schutz kennzeichnet 3033 Fehler bei der Signaturstufe und 3063 Fehler bei gemeinsam genutzten Abschnitten. Diese Ereignisse beweisen keinen erfolgreichen Dump von Anmeldedaten. Fehlende aufbewahrte Startnachweise allein beweisen nicht, dass der Schutz deaktiviert ist.

UNC-Konfiguration prüfen

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths"

Prüfen Sie beide Freigabemuster und die erforderlichen Attribute. Berücksichtigen Sie bei fehlenden Einträgen die Standardwerte des Betriebssystems, bevor Sie die Gefährdung einstufen. Validieren Sie den Zugriff auf die tatsächlichen SYSVOL- und NETLOGON-Ziele und ihre Authentifizierungs- und Integritätsgarantien. Eine spezifische Ereignis-ID für UNC-Spoofing wird hier nicht belegt.

Behebung (Remediation): Jede Kontrolle ausrollen und überprüfen

Schritt 1: LLMNR in einem Pilotbereich deaktivieren

Aktivieren Sie die oben beschriebene DNS-Client-Richtlinie. Führen Sie die LLMNR-Registrierungsabfrage erneut aus und gleichen Sie die angewendeten Richtlinien des Computers ab. Prüfen Sie, dass Anwendungen, die lokale Namen verwenden, weiterhin ihre vorgesehenen Ziele auflösen. Falls NetBIOS weiterhin erforderlich ist, dokumentieren Sie diese Abhängigkeit separat; falls es deaktiviert werden kann, verwalten Sie die dokumentierte Adaptermethode getrennt von der DNS-Client-Einstellung.

Schritt 2: WSUS-TLS vor der Änderung der Client-URLs konfigurieren

Konfigurieren Sie das Serverzertifikat, die IIS-Bindungen und die erforderlichen virtuellen TLS-Verzeichnisse gemäß Microsofts WSUS-Verfahren. In einer Eingabeaufforderung mit erhöhten Rechten im Verzeichnis C:\Program Files\Update Services\Tools lautet der dokumentierte Befehl:

wsusutil configuressl <certificate-name>

Ersetzen Sie den Platzhalter durch den DNS-Namen des WSUS-Servers. Verlangen Sie TLS für die dokumentierten Metadatendienste, einschließlich ClientWebService; verlangen Sie TLS nicht für die gesamte WSUS-Website. Die Übertragung von Nutzdaten erfolgt weiterhin über HTTP mit Signatur- und Hashvalidierung. Aktualisieren Sie beide Client-Richtlinien-URLs auf den eingesetzten HTTPS-Endpunkt; https://wsus.contoso.com:8531 ist Microsofts Beispiel, kein ermittelter Server. Prüfen Sie das Zertifikatsvertrauen und die Update-Suche vor einer breiten Bereitstellung.

Schritt 3: LSA-Kompatibilität testen, Schutz aktivieren und neu starten

Nutzen Sie vor der Durchsetzung das Kompatibilitätsaudit des LSA-Verfahrens. Beheben Sie inkompatible Plug-ins und Treiber, wählen Sie die unterstützte RunAsPPL-Option, starten Sie neu und überprüfen Sie den geschützten Start. Audit-Ereignisse werden nicht erzeugt, wenn Smart App Control aktiviert ist oder ein Kernel-Debugger angeschlossen und aktiviert ist; das Ausbleiben von Ereignissen ist daher keine automatische Kompatibilitätsfreigabe. Prüfen Sie vor der Auswahl die Auswirkungen der UEFI-Sperre: Eine Änderung der Registrierung allein entfernt die Firmware-Variable nicht. LSA-Schutz und Credential Guard sind ergänzende Kontrollen.

Schritt 4: Beide UNC-Attribute auf beiden Freigaben verlangen

Konfigurieren Sie SYSVOL und NETLOGON explizit in der Richtlinie Hardened UNC Paths. Testen Sie den Richtlinienabruf aus jedem Zielbereich und untersuchen Sie Authentifizierungs- oder Zugriffsfehler vor der Ausweitung. Fügen Sie RequirePrivacy erst hinzu, nachdem Sie die Verschlüsselungskompatibilität geprüft haben; nicht unterstützte Endpunkte können unerreichbar werden. Prüfen Sie Schreibberechtigungen und wiederverwendbare Geheimnisse als separate Aufgaben, selbst wenn die Transportanforderungen erfüllt sind.

Führen Sie für jede Bereitstellung eine kompakte Dokumentation: Zielbetriebssystem und Geltungsbereich, angewendete GPOs, Registrierungsausgabe vor und nach der Änderung, relevante Laufzeit- oder Verbindungsnachweise und ungelöste Abhängigkeiten. Wiederholen Sie dieselben Messungen nach Richtlinienänderungen, damit spätere Prüfer eine geänderte Einstellung von einer geänderten Interpretation der Standardwerte unterscheiden können.

Wie EtcSec dies erkennt

Die vier für diesen Artikel geprüften Detect()-Implementierungen von etc-collector bewerten erhobene GPO-Registrierungsdaten:

Die Registrierungshilfsfunktionen durchsuchen zuerst die Standardrichtlinie für Domänencontroller, danach die Standarddomänenrichtlinie und anschließend eine weitere verfügbare GPO. Der Code aggregiert GPO-Werte und belegt nicht die effektive Konfiguration jeder Arbeitsstation. Er berechnet weder die Rangfolge von Verknüpfungen noch die Filterung und Vererbung für jeden Computer. Widersprüchliche GPOs oder GPOs außerhalb des Geltungsbereichs erfordern daher eine Bestätigung am Zielsystem.

Die UNC-Hilfsfunktion sucht nach den zwei erforderlichen Attributzeichenfolgen; sie ist kein Parser für effektive Richtlinien. Ein fehlender WUServer löst die HTTP-Prüfung nicht aus, doch dieses Fehlen validiert nicht die Update-Strategie. Ebenso können fehlende PPL- oder UNC-Einträge eine Untersuchung moderner Standardwerte erfordern. Nutzen Sie jeden Befund, um eine gezielte Überprüfungsaufgabe zu eröffnen, fügen Sie die Nachweise des Zielsystems bei und schließen Sie den Befund erst, wenn der beabsichtigte Schutz für den betroffenen Geltungsbereich nachgewiesen ist.