WDigest aktiviert: Warum Klartext-Anmeldeinformationen wieder in LSASS auftauchen

What Is 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.

How WDigest aktiviert Works

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.

The Attack Chain

Schritt 1 - Lokale Admin- oder SYSTEM-Rechte 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.

Schritt 2 - LSASS auslesen und verwertbare 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 - Gestohlene Secrets auf Nachbarsystemen 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.

Detection

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.

Warum die Einstellung immer wieder zurückkehrt

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, welches Skript 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.

Remediation

💡 Quick Win: Wenn ein Host keine belastbare geschäftliche Abhängigkeit zur WDigest-Speicherung hat, deaktivieren Sie das Setting und prüfen Sie, dass es nicht durch alte Baselines, Images oder Support-Skripte wieder eingeführt wird.

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

Validate Before You Close the Finding

Die Maßnahme ist nicht abgeschlossen, nur weil der Wert einmal auf 0 gesetzt wurde. Prüfen Sie den Registry-Zustand auf repräsentativen Systemen, bestätigen Sie, dass ein vermeintlich kritischer Applikationspfad weiterhin funktioniert, falls eine legitime Abhängigkeit existiert, und vergewissern Sie sich, dass Ihre Detection-Stack eine spätere Reaktivierung erkennen würde. Genau diese Art von Control wirkt banal, bis ein Incident zeigt, dass sie vor Monaten still zurückgekommen ist.

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.

Wo Sie Legacy-Defaults und Drift getrennt prüfen sollten

Eine belastbare WDigest-Review sollte mit den Systemen beginnen, auf denen sich besonders wertvolle Identitäten tatsächlich anmelden. Microsofts Support-Guidance zur Credential-Härtung macht deutlich, dass sich das Standardverhalten je nach Windows-Generation unterscheidet. Auf Windows 7, Windows Server 2008 R2, Windows 8 und Windows Server 2012 bleibt UseLogonCredential nach dem Sicherheitsupdate standardmäßig auf 1, solange die Organisation den Wert nicht aktiv auf 0 setzt. Auf Windows 8.1, Windows Server 2012 R2 und neueren Versionen ist WDigest-Credential-Caching dagegen standardmäßig deaktiviert, wenn der Registry-Eintrag nicht existiert. Genau diese Differenz erklärt, warum alte Gold Images, Troubleshooting-Skripte oder Baselines aus Legacy-Betrieb den Befund noch Jahre später zurückbringen können.

Praktisch heißt das: Prüfen Sie Admin-Workstations, Jump Hosts und Server mit interaktiven privilegierten Logons getrennt vom allgemeinen Client-Bestand. Wenn moderne Standard-Clients sauber sind, ein älteres Admin-Image aber UseLogonCredential wieder setzt, konzentriert sich das reale Risiko weiterhin auf die Hosts mit den interessantesten Credentials. Eine pauschale Stichprobe im Büro-Client-Bestand reicht deshalb oft nicht aus.

Ein weiterer sinnvoller Kontrollschritt ist der Vergleich zwischen dokumentierter Baseline, Image-Pipeline und aktuellem lokalen Zustand produktiver Hosts. Sobald diese drei Quellen nicht denselben Registry-Zustand beschreiben, ist das Problem meistens organisatorisch und nicht technisch. Dann muss geklärt werden, welches Skript, welche GPO, welches Build-Artefakt oder welche manuelle Ausnahme den Wert immer wieder zurückbringt. Ohne diesen Owner-Nachweis taucht WDigest nach dem nächsten Rebuild häufig einfach erneut auf.

Prüfen Sie dabei ausdrücklich auch, ob auf einem Gerät mehr als ein lokales Administratorkonto existiert und welches Konto von Windows LAPS oder anderen lokalen Standards überhaupt verwaltet wird. Sonst bleibt trotz sauberer Registry-Härtung möglicherweise ein alter Admin-Pfad mit denselben privilegierten Nutzern operativ relevant.

Die Prüfung sollte außerdem zu Microsofts Guidance für Protected Users passen. Die Gruppe behebt WDigest nicht allein, aber Microsoft nennt klar, dass ihre Mitglieder NTLM, Digest Authentication und CredSSP nicht verwenden können. Wer WDigest isoliert prüft, ohne gleichzeitig zu bewerten, wo privilegierte Konten interaktiv arbeiten und ob sie bereits durch Protected Users oder ähnliche Standards eingegrenzt werden, übersieht oft den eigentlichen Risikoschwerpunkt.

How EtcSec Detects This

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.

ℹ️ Note: EtcSec erkennt WDigest-Credential-Storage automatisch in Active-Directory-Reviews und hilft so, die Systeme zu priorisieren, auf denen eine lokale Kompromittierung die wertvollsten Identitäten offenlegen würde.

Official References

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

Related Reading

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-Sicherheitsaudit-Checkliste für interne Teams und AD-Sicherheitsüberwachung: relevante Event IDs und SIEM. Diese Themen helfen, einen lokalen Registry-Befund mit der größeren Frage nach wiederverwendbaren Secrets im gesamten Umfeld zu verbinden.