Zwischengespeicherte Anmeldungen, WDigest und Co.

Credential Guard und LSA-Schutz härten, wie Windows die vorgehaltenen Geheimnisse schützt. Dieser Leitfaden befasst sich damit, wie viel es überhaupt vorhält. Eine Handvoll Einstellungen entscheidet darüber, ob ein kompromittierter Computer ein Klartextkennwort preisgibt, einen knackbaren Hash jedes kürzlich angemeldeten Domänenbenutzers oder gespeicherte Kennwörter für Dateifreigaben und Webanwendungen. Die meisten lassen sich kostenlos ändern und brechen sehr wenig, wenn man weiß, worauf zu achten ist.

Alles hier gilt auch für Geräte, auf denen Credential Guard nicht laufen kann: ältere Hardware, VMs ohne geschachtelte Virtualisierung und Domänencontroller. Es ist die Grundlage der Reihe Schutz von Anmeldedaten.

Was Windows vorhält, und wo

Schritt 1: Zwischengespeicherte Anmeldungen reduzieren

Wenn sich ein Domänenbenutzer interaktiv anmeldet, speichert Windows einen Verifier, damit sich derselbe Benutzer später ohne Domänencontroller anmelden kann. Standardmäßig werden die letzten 10 Benutzer vorgehalten. Auf einem gemeinsam genutzten Arbeitsplatz oder einem Server ist das eine Liste aller kürzlich tätigen Helpdesk-Techniker und Admins, jeder davon ein Hash, der offline geknackt werden kann.

Die Einstellung lautet Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive logon: Number of previous logons to cache (in case domain controller is not available). Sie schreibt CachedLogonsCount (ein REG_SZ, kein DWORD) unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

Die Microsoft-Sicherheitsbaselines konfigurieren diese Einstellung nicht; Microsofts eigene Empfehlung nennt 0 als Gegenmaßnahme und schlägt 2 für Endbenutzer- und Mobilgeräte vor, und die CIS Benchmarks empfehlen 4 oder weniger. Wählen Sie den niedrigsten Wert, mit dem Ihre Benutzer leben können, und testen Sie einen Laptop, indem Sie ihn von allen Netzwerken trennen und sich anmelden.

Zwei zugehörige Punkte:

• Mitglieder von Protected Users hinterlassen nie einen zwischengespeicherten Verifier; ein weiterer Grund, menschliche Admins in diese Gruppe aufzunehmen (siehe Admin-Tiering und Protected Users).
• Das Senken des Werts löscht vorhandene Verifier nicht sofort. Einträge werden überschrieben, wenn sich neue Benutzer anmelden. Auf Servern, auf denen bereits Admin-Verifier liegen, stoppt der Wert 0 neues Zwischenspeichern; planen Sie, die Kennwörter privilegierter Konten zu rotieren, die zuvor auf wenig vertrauenswürdigen Computern zwischengespeichert wurden.

Schritt 2: WDigest dauerhaft abschalten

WDigest ist ein altes HTTP/SASL-Authentifizierungspaket, das das Klartextkennwort des Benutzers im Speicher benötigte. Seit Windows 8.1 und Windows Server 2012 R2 speichert es standardmäßig keinen Klartext mehr, doch das Verhalten wird weiterhin über einen einzigen Registrierungswert gesteuert, den ein Angreifer mit Admin-Rechten umstellen kann:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
Value: UseLogonCredential  (REG_DWORD) = 0

Steht er auf 1, legt jede folgende interaktive Anmeldung das Klartextkennwort im LSASS-Speicher ab, wo Werkzeuge wie Mimikatz es lesen können. Das ist ein bekannter Persistenzschritt bei Angriffen: Wert umstellen, Bildschirm sperren, warten, bis der Benutzer entsperrt.

Setzen Sie den Wert ausdrücklich auf 0, statt sich auf den Standard zu verlassen. Die SecGuide.admx des Security Compliance Toolkit stellt ihn als WDigest Authentication (disabling may require KB2871997) unter Computer Configuration > Policies > Administrative Templates > MS Security Guide bereit; setzen Sie ihn auf Disabled. Der KB-Verweis ist nur für Windows 7 und Server 2008 R2 relevant. Microsoft hat diese Einstellung aus der Sicherheitsbaseline für Windows 11 24H2 gestrichen, weil die Richtlinie mit diesem Release als veraltet gilt; auf aktuellen Builds können Sie den Registrierungswert also auch direkt per Gruppenrichtlinieneinstellungen oder Intune erzwingen. Überwachen Sie ihn in jedem Fall weiter.

Credential Guard hindert Digest ebenfalls daran, gespeicherte Anmeldedaten zu verwenden, doch ein per Richtlinie erzwungenes 0 schützt die Computer, auf denen es nicht läuft.

Schritt 3: Anmeldedaten nach der Abmeldung löschen

Nachdem sich ein Benutzer abgemeldet hat, kann LSASS seine Anmeldedaten noch eine Weile im Speicher halten, wenn Handles auf die Anmeldesitzung offen bleiben. Windows 8.1 und neuer löschen sie nach 30 Sekunden. Der Wert lautet:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: TokenLeakDetectDelaySecs  (REG_DWORD) = 30

Unter aktuellen Windows-Versionen ist das das integrierte Verhalten; das Setzen schützt also vor allem davor, dass jemand den Wert erhöht. Die Microsoft-Sicherheitsbaseline verlangt es nicht; setzen Sie ihn dort, wo Ihr Härtungsstandard oder Ihr Audit es fordert, und belassen Sie ihn bei 30 Sekunden.

Beachten Sie, dass dies nur abgemeldete Sitzungen betrifft. Ein privilegiertes Konto, das per RDP an einem Server angemeldet bleibt, verbleibt so lange im Speicher, wie die Sitzung besteht. Setzen Sie Zeitlimits für RDP-Sitzungen und melden Sie getrennte Sitzungen ab, wie unter RDP-Härtung beschrieben.

Schritt 4: Keine Netzwerkkennwörter mehr speichern

Die Anmeldeinformationsverwaltung speichert Kennwörter, die Benutzer (oder Anwendungen) speichern lassen: zugeordnete Laufwerke mit „Anmeldedaten speichern“, RDP-Verbindungen, Outlook, manche Fachanwendungen. Sie sind per DPAPI mit dem Schlüssel des Benutzers geschützt; jeder Code, der als dieser Benutzer läuft, kann sie also entschlüsseln.

Prüfen Sie, was auf einem Gerät für den aktuellen Benutzer gespeichert ist:

cmdkey /list
vaultcmd /listcreds:"Windows Credentials" /all

Die Richtlinie Network access: Do not allow storage of passwords and credentials for network authentication (Security Options) setzt DisableDomainCreds = 1 unter HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Ist sie aktiviert, speichert Windows keine Domänenanmeldedaten für die Netzwerkauthentifizierung mehr in der Anmeldeinformationsverwaltung.

Diese Einstellung muss getestet werden, weshalb viele Baselines sie den Hochsicherheitsstufen überlassen:

• Geplante Aufgaben, die mit Run whether user is logged on or not und gespeichertem Kennwort konfiguriert sind, funktionieren nicht mehr. Stellen Sie sie auf SYSTEM, ein gMSA oder ein anderweitig verwaltetes Dienstkonto um.
• Gespeicherte Anmeldedaten für RDP und zugeordnete Laufwerke bleiben nicht mehr erhalten. Benutzer werden erneut gefragt, was in der Regel genau beabsichtigt ist.

Aktivieren Sie die Richtlinie zuerst auf Servern und Privileged Access Workstations, wo gespeicherte Domänenanmeldedaten am gefährlichsten sind und sich geplante Aufgaben am leichtesten erfassen lassen. Speziell für RDP aktivieren Sie zusätzlich Do not allow passwords to be saved unter Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client.

Schritt 5: Per Skript anwenden und prüfen

Für eine schnelle Bestandsaufnahme auf einem einzelnen Computer oder über ein Wartungsskript:

$lsa = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
[pscustomobject]@{
  CachedLogonsCount        = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon").CachedLogonsCount
  UseLogonCredential       = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -ErrorAction SilentlyContinue).UseLogonCredential
  TokenLeakDetectDelaySecs = (Get-ItemProperty $lsa).TokenLeakDetectDelaySecs
  DisableDomainCreds       = (Get-ItemProperty $lsa).DisableDomainCreds
  NoLMHash                 = (Get-ItemProperty $lsa).NoLMHash
}

Erzwingen Sie die Werte per Gruppenrichtlinie oder Intune statt per Skript, damit sie erneut angewendet werden, falls etwas sie ändert. In Intune finden Sie die Security Options im Einstellungskatalog unter Local Policies Security Options; für Werte ohne native Einstellung funktioniert ein benutzerdefinierter OMA-URI mit einer eingelesenen ADMX oder ein Wartungsskript.

Was kaputtgeht

• Offline-Anmeldung auf Laptops, wenn zwischengespeicherte Anmeldungen auf 0 stehen.
• Geplante Aufgaben mit gespeicherten Kennwörtern und gespeicherte Anmeldedaten, sobald DisableDomainCreds aktiviert ist.
• Sehr alte Anwendungen mit HTTP-Digest-Authentifizierung und Windows-SSO. Sie sind selten und fragen dann nach einem Kennwort.

Überprüfen

1. Genutzte zwischengespeicherte Anmeldungen. Das Sicherheitsereignis 4624 mit Logon Type 11 (CachedInteractive) zeigt, dass sich ein Benutzer über einen zwischengespeicherten Verifier angemeldet hat. Auf Servern sollte es nach Setzen des Werts 0 nie auftreten.
2. Manipulation von WDigest. Alarmieren Sie bei Schreibzugriffen auf UseLogonCredential über Sysmon Event 13 oder die Registrierungsüberwachung (Sicherheitsereignis 4657, das eine SACL auf dem Schlüssel erfordert). Jede Änderung auf 1 ist ein sehr verlässlicher Kompromittierungsindikator.
3. Inhalt der Anmeldeinformationsverwaltung. Führen Sie nach dem Aktivieren von DisableDomainCreds die Prüfung mit cmdkey /list auf einer Stichprobe von Servern und Admin-Arbeitsplätzen aus; gespeicherte Domäneneinträge sollten verschwunden sein, sobald sich die Benutzer erneut authentifiziert haben.
4. Flottenbericht. Sammeln Sie die Ausgabe des Skripts aus Schritt 5 zentral und verfolgen Sie Geräte, die von Ihrem Standard abweichen.

Checkliste

• Zwischengespeicherte Anmeldungen: 0 auf Servern und Kiosken, 1 bis 2 auf Laptops
• Admin-Konten von Personen in Protected Users, damit sie nie zwischengespeichert werden
• UseLogonCredential per Richtlinie ausdrücklich 0, Alarmierung bei Änderungen
• TokenLeakDetectDelaySecs auf 30, wo Ihr Standard es verlangt
• DisableDomainCreds auf Servern und PAWs aktiviert, geplante Aufgaben umgestellt
• RDP-Client darf keine Kennwörter speichern
• Ereignis 4624 mit Anmeldetyp 11 auf Servern geprüft

Keine dieser Einstellungen ist spektakulär, doch zusammen verringern sie die Menge an wiederverwendbarem Material auf jedem Computer. Kombiniert mit der Überwachung von WDigest und Credential Guard bleibt einem Angreifer weit weniger zu holen.