AD-Passwortsicherheit: Fehlkonfigurationen die Angreifer Lieben

Was ist Active-Directory-Passwortsicherheit?

Die Active-Directory-Passwortsicherheit umfasst die Richtlinien, Kontenflags und Legacy-Authentifizierungseinstellungen, die festlegen, wie Anmeldeinformationen in der Domäne erstellt, gespeichert und wiederverwendet werden. Sind diese Kontrollen schwach, brauchen Angreifer keine Exploit-Kette, um Fuß zu fassen. Ein schwaches Passwort, ein nie ablaufendes Admin-Konto oder ein in ein Attribut kopiertes Passwort können bereits ausreichen.

Diese Probleme sind im Tagesgeschäft oft unauffällig. Konten mit PasswordNeverExpires oder PasswordNotRequired können monatelang produktiv bleiben, in Beschreibungsfeldern kopierte Passwörter werden leicht übersehen, und Legacy-Einstellungen wie WDigest oder NTLMv1 machen erbeutete Anmeldeinformationen deutlich leichter wiederverwendbar.

Dieser Artikel behandelt sechs besonders wirkungsvolle passwortbezogene Fehlkonfigurationen in Active Directory und zeigt, wie sich validieren lässt, dass eine Behebung die Exposition tatsächlich beseitigt hat.

Funktionsweise

Active Directory erzwingt Passwortkontrollen über zwei zentrale Mechanismen:

• Die Standard-Domänen-Passwortrichtlinie, die per Gruppenrichtlinie domänenweit angewendet wird
• Fine-Grained Password Policies (FGPP), die über Password Settings Objects auf bestimmte Benutzer oder Gruppen angewendet werden

Fine-Grained Password Policies werden als Password Settings Objects (PSOs) implementiert; ihre Rangfolge wird über das Attribut msDS-PasswordSettingsPrecedence festgelegt: Ein niedrigerer Wert bedeutet eine höher priorisierte PSO. Eine direkt mit einem Benutzer verknüpfte PSO hat immer Vorrang; gelten mehrere PSOs über Gruppenmitgliedschaften, wird die mit dem niedrigsten Precedence-Wert zur wirksamen Richtlinie, und die Standard-Domänen-Passwortrichtlinie greift nur, wenn überhaupt keine PSO zutrifft. In der Praxis sollten Tier-0- und Dienstkonten unter einer PSO mit niedrigem Precedence-Wert und einer deutlich strengeren Baseline als der Domänen-Standard liegen.

Wird keines von beiden regelmäßig überprüft, ist das Ergebnis vorhersehbar: schwache oder langlebige Passwörter, von normalen Kontrollen ausgenommene Konten und Legacy-Authentifizierungseinstellungen, die den Missbrauch von Anmeldeinformationen erleichtern, sobald ein Angreifer Fuß gefasst hat.

Die Angriffskette

Schritt 1 – Schwache Konten aufzählen

Jeder authentifizierte Domänenbenutzer kann AD nach Konten mit schwachen Passworteinstellungen abfragen:

# Konten mit Passwörtern, die nie ablaufen
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet | Sort-Object PasswordLastSet

# Konten, bei denen kein Passwort erforderlich ist
Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

# Konten mit Passwort im Beschreibungsfeld
Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp|kennwort|passwort"} |
    Select-Object SamAccountName, Description

Schritt 2 – Legacy-Protokoll-Exposition prüfen

# Prüfen, ob WDigest aktiviert ist
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential

# NTLM-Kompatibilitätsstufe prüfen
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# Werte 0-2 erlauben NTLMv1; Wert 5 erzwingt ausschließlich NTLMv2

Schritt 3 – Erbeuten und Knacken

Ist WDigest aktiviert, kann eine lokale Kompromittierung, die LSASS erreicht, Klartext-Anmeldeinformationen direkt offenlegen:

# Mimikatz-Beispiel bei aktiviertem WDigest
sekurlsa::wdigest

Bei schwachen oder langlebigen Passwörtern können Angreifer NTLM-Material nach einem Hash-Dump auch offline knacken:

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

Schritt 4 – Persistenz durch schwache Passworthygiene

Konten mit PasswordNeverExpires sind langlebige Persistenzziele. Ist das Konto sensibel und wird das Passwort nie rotiert, behält der Angreifer einen gültigen Authentifizierungsweg, bis ein Administrator es explizit zurücksetzt.

Erkennung

Windows Event-IDs

Verhaltensindikatoren

• Konten mit Passwörtern, die älter sind als das genehmigte Rotationsfenster
• Aktivierte Konten mit PasswordNeverExpires oder PasswordNotRequired
• Beschreibungsfelder mit credential-ähnlichen Zeichenfolgen
• WDigest aktiviert auf Endpunkten oder Servern, wo es nicht ausdrücklich benötigt wird
• NTLMv1 wird weiterhin ausgehandelt in Umgebungen, die eigentlich nur NTLMv2 zulassen sollten

SIEM-Erkennungsabfrage (Elastic KQL)

event.code: "4624" AND
winlog.event_data.LmPackageName: "NTLM V1"

Behebung

1. Starke Domänen-Passwortrichtlinie erzwingen

Set-ADDefaultDomainPasswordPolicy -Identity corp.local `
    -MinPasswordLength 14 `
    -ComplexityEnabled $true `
    -MaxPasswordAge (New-TimeSpan -Days 90) `
    -MinPasswordAge (New-TimeSpan -Days 1) `
    -PasswordHistoryCount 24

2. Nie ablaufende Passwörter korrigieren

Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} |
    Set-ADUser -PasswordNeverExpires $false

3. Konten ohne erforderliches Passwort korrigieren

Get-ADUser -Filter {PasswordNotRequired -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -PasswordNotRequired $false
}

4. Passwörter aus Beschreibungsfeldern entfernen

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp"} | ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
        Write-Host "Beschreibung geleert für: $($_.SamAccountName)"
    }

5. WDigest deaktivieren

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" `
    -Name UseLogonCredential -Value 0

Wo möglich per GPO ausrollen: Computer Configuration > Administrative Templates > MS Security Guide > WDigest Authentication = Disabled

6. Ausschließlich NTLMv2 erzwingen

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name LmCompatibilityLevel -Value 5

Oder per Richtlinie: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM

7. Microsoft Entra Password Protection bereitstellen (Hybrid-Umgebungen)

Für mit Microsoft Entra ID synchronisierte Domänen blockiert die lokale Microsoft Entra Password Protection schwache Passwörter bereits auf dem Domain Controller bei Passwortänderungen und -resets — und schließt damit eine Lücke, die die integrierte Komplexitätsrichtlinie nicht abdeckt: Wörterbuchbegriffe, Tastaturmuster und organisationsspezifische Begriffe, die formal komplex genug sind, aber trivial zu erraten bleiben.

Die Bereitstellung besteht aus zwei Komponenten: einem Password Protection Proxy-Dienst, der die globalen und benutzerdefinierten Sperrlisten aus Microsoft Entra ID abruft, und einem DC-Agent, der auf jedem Domain Controller installiert wird und die zwischengespeicherte Richtlinie lokal bei Passwortänderungen und -resets durchsetzt. Der DC-Agent setzt die Durchsetzung anhand seiner zwischengespeicherten Kopie auch dann fort, wenn die Verbindung zum Proxy vorübergehend unterbrochen ist.

# Prüfen, ob der DC-Agent installiert ist und Durchsetzungsereignisse protokolliert
Get-EventLog -LogName "Microsoft-AADPasswordProtection-DCAgent/Admin" -Newest 20

Starten Sie im Audit-Modus, um zunächst zu ermitteln, wie viele bestehende Passwörter abgelehnt würden, bevor Sie in den erzwungenen Modus wechseln, und ergänzen Sie die benutzerdefinierte Sperrliste um organisationsspezifische Begriffe — Markennamen, Produktnamen, interne Projekt-Codenamen —, denn die globale Liste allein erfasst diese nicht.

Wie EtcSec dies erkennt

EtcSec prüft passwortbezogene Identitätskontrollen bei jedem AD-Scan.

PASSWORD_NEVER_EXPIRES kennzeichnet aktivierte Konten mit nie ablaufenden Passwörtern und hilft, die risikoreichsten Identitäten zuerst sichtbar zu machen.

PASSWORD_POLICY_WEAK bewertet die Standard-Domänen-Passwortrichtlinie anhand der gewählten Baseline für Länge, Komplexität, Verlauf und Alter.

PASSWORD_NOT_REQUIRED identifiziert Konten, bei denen das Flag PASSWD_NOTREQD noch gesetzt ist.

PASSWORD_IN_DESCRIPTION durchsucht Verzeichnisbeschreibungen nach credential-ähnlichen Zeichenfolgen.

WDIGEST_ENABLED prüft auf zwischengespeichertes Klartext-WDigest.

NTLMV1_ALLOWED hebt Umgebungen hervor, die weiterhin NTLMv1-Aushandlung zulassen.

Konten, die eine Sonderbehandlung brauchen

Wenden Sie nicht dieselbe Behebung blind auf jede Kontenklasse an.

• Dienstkonten brechen häufig, wenn ein Passwort zurückgesetzt wird, ohne den Dienst, die geplante Aufgabe oder den Application Pool zu aktualisieren, der davon abhängt.
• Tier-0- oder Break-Glass-Konten sollten nicht allein deshalb schwache oder geteilte Anmeldeinformationen behalten, weil sie selten genutzt werden; sie brauchen stärkere Handhabung, stärkere Speicherung und explizites Monitoring.
• Geteilte Admin-Identitäten sollten entfernt statt nur rotiert werden. Rotation löst das Accountability-Problem nicht.
• Legacy-Anwendungen, die weiterhin von NTLMv1 oder schwacher Passwort-Handhabung abhängen, brauchen eine zeitlich befristete Ausnahme und einen Migrationsplan, keine dauerhafte Freistellung.

Wie gute Belege aussehen

Eine Überprüfung der Passworthärtung lässt sich deutlich leichter belegen, wenn das Team genau die Nachweise aufbewahrt, die den Erfolg der Bereinigung zeigen. Nützliche Artefakte sind der Vorher-Nachher-Export der Konten mit PasswordNeverExpires, die Liste der Konten, die zuvor PasswordNotRequired hatten, die Bestätigung, dass WDigest auf repräsentativen Systemen deaktiviert ist, sowie der Owner- oder Migrationsvermerk für jedes Dienstkonto, das noch eine temporäre Ausnahme benötigt. Diese Nachweise sind wichtig, weil Passworthygiene dazu neigt, über dringende Ausnahmen und Anwendungs-Workarounds wieder abzudriften.

Validierung nach der Behebung

Schließen Sie den Befund erst ab, nachdem Sie dieselben Erkennungsschritte erneut ausgeführt haben, die auch ein Angreifer nutzen würde:

• die Berichte zu PasswordNeverExpires und PasswordNotRequired erneut ausführen und bestätigen, dass verbleibende Ausnahmen beabsichtigt sind
• verifizieren, dass Ausnahmen für Dienstkonten dokumentiert, einem Owner zugeordnet und an einen Migrationsplan wie die Einführung von gMSA gebunden sind
• repräsentative Systeme stichprobenartig prüfen, um zu bestätigen, dass UseLogonCredential dort 0 ist, wo WDigest deaktiviert sein soll
• validieren, dass LmCompatibilityLevel zum geplanten NTLMv2-only-Rollout passt und Legacy-Systeme explizit behandelt wurden
• die Suche im Beschreibungsfeld erneut ausführen und bestätigen, dass Anmeldeinformationen entfernt und nicht lediglich in ein anderes Attribut verschoben wurden

Verwandte Kontrollen

Passworthygiene wird deutlich gefährlicher, wenn sie mit Kerberoasting: Wie Angreifer Dienstkonto-Passwörter knacken, Veralteten privilegierten Konten: verstecktes Risiko in Active Directory, Active Directory Monitoring: Die Security-Event-IDs, die zählen oder NTLM-Relay-Angriffen: Authentifizierung in AD kapern kombiniert wird. Überprüfen Sie diese Kontrollen im selben Behebungsfenster, damit Sie den Angriffspfad entfernen statt nur ein Symptom.