WDigest aktiviert: Warum Klartext-Anmeldeinformationen wieder in LSASS auftauchen

Was bedeutet WDigest aktiviert?

WDigest aktiviert bedeutet, dass ein System wiederverwendbares, WDigest-bezogenes Anmeldematerial erneut in LSASS speichert, obwohl Verteidiger die Menge an verwertbaren Secrets im Speicher eigentlich reduzieren sollten. Microsofts Guidance rund um Security Advisory 2871997 zielte genau darauf ab, Credential Theft auf domänenverbundenen Windows-Systemen zu erschweren. Einer der praktischsten Härtungspunkte aus dieser Guidance ist sicherzustellen, dass UseLogonCredential die Speicherung von WDigest-Geheimnissen im Speicher nicht wieder einschaltet.

Das Risiko ist relevant, weil WDigest nicht nur eine alte Protokoll-Randnotiz ist. Microsofts Protokolldokumentation beschreibt, dass supplementalCredentials den Eintrag Primary:WDigest enthalten kann, also kryptografische Ableitungen des Klartextpassworts für Digest Authentication. Wenn ein Team die WDigest-Speicherung auf Hosts wieder aktiviert, steigt die Wahrscheinlichkeit, dass eine lokale Kompromittierung wiederverwendbare Secrets offenlegt, die in LSASS gar nicht vorhanden sein sollten.

Darum sollte WDigest aktiviert gemeinsam mit Active Directory-Passwortsicherheit: Fehlkonfigurationen mit echtem Risiko, Passwörtern in AD-Beschreibungsfeldern: Erkennung und Bereinigung und Veralteten und überprivilegierten Konten in AD betrachtet werden. In allen Fällen geht es nicht nur um eine schwache Einstellung, sondern darum, dass wiederverwendbares Credential-Material leichter gestohlen und erneut genutzt werden kann als erwartet.

So funktioniert es

Microsoft dokumentiert UseLogonCredential unter dem Registry-Pfad WDigest als den Schalter, mit dem verhindert wird, dass WDigest Anmeldeinformationen im Speicher behält. Wird der Wert erneut aktiviert, steht Anmeldematerial Code zur Verfügung, der LSASS mit ausreichenden Rechten erreicht.

Die Härtungslogik ist praktisch einfach:

• wenn WDigest-Speicherung deaktiviert ist, muss ein Angreifer nach einer Host-Kompromittierung andere wiederverwendbare Secrets finden
• wenn WDigest-Speicherung aktiviert ist, bietet der Host ein unnötig attraktives Ziel für Credential Theft

Microsofts Advisory 2871997 verweist außerdem auf die Protected Users-Gruppe. Deren Mitglieder können sich nicht per NTLM, Digest Authentication oder CredSSP authentifizieren, und ihre Passwörter werden auf unterstützten Systemen anders behandelt. Das ersetzt das Deaktivieren von WDigest nicht, verfolgt aber dasselbe Ziel: weniger wiederverwendbares Credential-Material nach einer lokalen Kompromittierung.

Die Angriffskette

Schritt 1 - Lokalen Admin- oder SYSTEM-Zugriff auf einem Windows-Host erlangen

WDigest aktiviert ist meist nicht der erste Initial Access. Gefährlich wird das Thema, sobald der Angreifer bereits lokalen Admin, SYSTEM oder vergleichbare Codeausführung auf einem Host besitzt. Ab diesem Punkt entscheidet die Speicherhärtung darüber, wie viel wiederverwendbares Anmeldematerial noch in LSASS liegt.

Deshalb taucht dieses Problem häufig zusammen mit Kerberoasting: Wie Angreifer Service-Account-Passwörter knacken und AS-REP Roasting: Hashes ohne Anmeldedaten erbeuten auf. Angreifer verketten Credential-Gelegenheiten. Liefert ein Host wiederverwendbare Secrets, wird der Rest des Angriffs günstiger.

Schritt 2 - LSASS auslesen und wiederverwendbare Credentials gewinnen

Ist das Setting aktiviert, braucht der Angreifer kein vollständig kaputtes Umfeld. Ein einzelner Host reicht, auf dem die lokale Kompromittierung in Credential Access übersetzt werden kann.

# Defensiver Check der WDigest-Einstellung
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential

Für Blue Teams ist nicht das konkrete Dump-Tool entscheidend, sondern die Tatsache, dass der Host mehr verwertbares Anmeldematerial im Speicher hält als nötig.

Schritt 3 - Die erbeuteten Credentials auf benachbarten Systemen wiederverwenden

Wenn das gestohlene Geheimnis zu einem privilegierten Admin, Helpdesk-Konto oder breit berechtigten Service Account gehört, kann der Angreifer schnell auf benachbarte Systeme oder weitere Privilegpfade wechseln. Darum ist WDigest aktiviert selten ein isolierter Befund: Es vergrößert die Auswirkung anderer Zugriffsfehler.

Dieselbe Logik findet sich in Active Directory-Angriffspfaden zu Domain Admin: Jede Einstellung, die einen kompromittierten Host in eine Quelle wiederverwendbarer Credentials verwandelt, verkürzt den Weg zu kritischeren Zielen.

Erkennung

Sie brauchen keine Schätzungen, um WDigest-Exponierung zu erkennen. Microsoft liefert mit UseLogonCredential bereits den zentralen Kontrollpunkt. Eine ernsthafte Überprüfung sollte zusätzlich klären, ob sensible Admins noch außerhalb von Protected Users liegen und ob Ihre Telemetrie Registry-Änderungen oder verdächtige LSASS-Zugriffe früh genug erkennt.

# Schneller WDigest-Check auf einem Host
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

# Prüfen, ob privilegierte Konten in Protected Users sind
Get-ADGroupMember 'Protected Users'

Der Registry-Check ist der schnellste Einstieg, sollte aber nicht der einzige bleiben. In Incident Reviews sollten Sie zusätzlich prüfen, ob die Einstellung auf Admin-Workstations, Jump Hosts oder Servern mit interaktiven privilegierten Logons vorkommt. Eine einzelne Ausnahme auf dem falschen Host kann viel ansonsten solide Credential-Hardening-Arbeit zunichtemachen.

Remediation

Ein sauberer Remediationspfad ist meist kurz:

1. Inventarisieren, wo UseLogonCredential aktiviert ist. Beginnen Sie mit Admin-Workstations, Jump Hosts und sensiblen Servern.
2. Setting entfernen oder deaktivieren. Auf unterstützten Systemen setzen Sie UseLogonCredential auf 0 oder stellen den modernen Baseline-Default wieder her.
3. Legacy-Abhängigkeiten prüfen. Wenn ein Team WDigest als notwendig bezeichnet, verlangen Sie einen konkreten Applikationspfad und einen Termin zur Abschaltung.
4. Hochwertige Identitäten schützen. Nutzen Sie Protected Users für privilegierte Konten, wo es betrieblich möglich ist.
5. Drift überwachen. Alarmieren Sie auf Änderungen unter dem WDigest-Pfad und auf verdächtige LSASS-Zugriffe.

# Beispielhafte lokale Remediation auf einem Windows-Host
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential -Type DWord -Value 0

Wenn Ihre Umgebung noch alte Baseline-Skripte oder nachträgliche Hardening-Templates enthält, prüfen Sie diese sorgfältig. WDigest wird manchmal nicht absichtlich wieder eingeführt, sondern durch ein vergessenes Skript, das jemand vor Jahren kopiert hat, um ein Anwendungsproblem zu „lösen". Deshalb müssen Registry-Zustand, Build-Baseline und die tatsächliche Produktionsabhängigkeit gemeinsam geprüft werden.

Die Änderung vor dem Abschluss validieren

Die sicherste Validierungsreihenfolge ist einfach: Prüfen Sie den Registry-Zustand auf repräsentativen Systemen, bestätigen Sie, dass ein risikobehafteter Applikationspfad weiterhin funktioniert, falls eine echte geschäftliche Abhängigkeit besteht, und vergewissern Sie sich, dass Ihr Detection-Stack ein Signal auslöst, falls jemand UseLogonCredential später erneut aktiviert. Das ist genau die Art von Control, die trivial wirkt, bis ein Incident beweist, dass sie sechs Monate zuvor still rückgängig gemacht wurde.

Es lohnt sich außerdem, die Identitätsseite mitzudenken. Wenn privilegierte Admins weiter auf zu breiten Flächen arbeiten und keine stärkeren Schutzmechanismen nutzen, kann schon eine einzelne WDigest-Ausnahme deutlich gefährlicher sein als erwartet. Deshalb gehört dieser Befund in eine umfassendere Privileged-Access-Review und nicht nur in eine Workstation-Hardening-Checkliste.

Warum WDigest-Ausnahmen immer wieder zurückkehren

WDigest kommt selten zurück, weil ein Team bewusst weniger Schutz will. Häufiger passiert es durch alte Troubleshooting-Gewohnheiten: jemand kopiert einen veralteten Registry-Workaround, ein Gold Image behält einen alten Wert, oder ein Support-Skript wird weiterverwendet, ohne die ursprüngliche Applikationsabhängigkeit erneut zu validieren. Dieses Muster ist wichtig, weil es den Review verändert. Die Frage lautet nicht nur „ist der Schlüssel gesetzt?", sondern auch „welcher Build-Standard, welche Automatisierung oder welcher Owner bringt ihn immer wieder zurück?"

In reifen Umgebungen sollte diese Prüfung Admin-Workstations, Jump Hosts und jede Server-Tier umfassen, auf der privilegierte Identitäten interaktiv arbeiten. Wenn Standard-Clients sauber sind, aber die Hosts mit den wertvollsten Credentials nicht, bleibt das Restrisiko hoch. Deshalb lohnen sich auch Active-Directory-Sicherheit auditieren: Praktische Checkliste für interne Teams und AD-Sicherheitsüberwachung: Event-IDs und SIEM als ergänzende Lektüre: Sie helfen, eine lokale Registry-Schwäche mit der größeren Frage zu verknüpfen, wo privilegierte Credentials im Unternehmen tatsächlich liegen.

Wie EtcSec das erkennt

EtcSec ordnet das Thema direkt WDIGEST_ENABLED zu. Praktisch relevant ist nicht nur, ob der Registry-Wert irgendwo existiert, sondern ob die Hosts, die am meisten zählen, noch wiederverwendbares Credential-Material in LSASS halten und ob die Ausnahme einen klaren Owner hat.

Offizielle Quellen

• Microsoft Security Advisory 2871997: Update to Improve Credentials Protection and Management
• Microsoft Support article for the UseLogonCredential policy and WDigest credential storage behavior
• Microsoft protocol documentation for supplementalCredentials and Primary:WDigest

Weiterführende Themen

Betrachten Sie dieses Thema zusammen mit Active Directory-Passwortsicherheit: Fehlkonfigurationen mit echtem Risiko, Passwörtern in AD-Beschreibungsfeldern: Erkennung und Bereinigung, Veralteten und überprivilegierten Konten in AD, Active-Directory-Sicherheit auditieren: Praktische Checkliste für interne Teams und AD-Sicherheitsüberwachung: Event-IDs und SIEM. Diese angrenzenden Themen helfen, eine lokale Registry-Einstellung von der größeren Frage zu trennen, wo im Unternehmen weiterhin wiederverwendbare Credentials existieren.