von Nilaa Maharjan, Security Research

Bei internen Penetrationstests müssen Sicherheitsspezialisten häufig versuchen, Passwörter aus dem Speicher infizierter Rechner zu extrahieren. Wenn die erlangten Anmeldeinformationen gehasht sind, kann der Penetration-Tester den Pass-the-Hash-Ansatz nutzen, um sich im Netzwerk zu bewegen und seine Ziele zu erreichen. Diese Technik wurde in der Vergangenheit häufig eingesetzt und ist immer noch ein existenter Bedrohungsvektor bei nicht aktualisierten Rechnern.

Angenommen, der Tester ist in der Lage, Klartext-Anmeldedaten aus dem Speicher zu extrahieren oder die gesammelten Hashes zu knacken, dann kann er sich bei den verschiedenen Netzwerk-Ressourcen und Netzwerk-Services wie Outlook, geschäftskritischen Web-Anwendungen, Device-Portalen, etc. authentifizieren.

In diesem Artikel erläutern wir, was WDigest ist, wie diese Funktion verwendet wird, um Klartext-Anmeldedaten aus dem Speicher zu extrahieren, und wie ein Analyst Logpoint nutzen kann, um einen Angriffsversuch unter Nutzung von WDigest zu erkennen, zu entschärfen und darauf zu reagieren.

Doch zunächst die Hintergründe.

Was ist WDigest?

Die WDigest-Authentifizierung ist ein Challenge/Response-Protokoll, das in erster Linie für eine LDAP– und webbasierte Authentifizierung für den Windows Server 2003 verwendet wurde. Die Funktion wurde zum ersten Mal mit Windows XP eingeführt und war standardmäßig auf Windows-Systemen aktiviert. WDigest ermöglicht es Clients, Anmeldeinformationen im Klartext an HTTP-Anwendungen (HTTP: Hypertext Transfer Protocol) sowie SASL-Anwendungen (SASL: Simple Authentication Security Layer) zu übermitteln.

Microsoft speicherte die Klartext-Anmeldedaten im Windows-RAM, wenn sich Benutzer an ihren Workstations anmeldeten, um das Authentifizierungsverfahren für Endbenutzer bequemer zu gestalten. Die Workstations nutzten diese zwischengespeicherten Anmeldeinformationen, um sich bei HTTP- und SASL-Dienste zu authentifizieren, ohne dass die Benutzer ihre Anmeldeinformationen immer wieder neu eingeben mussten. Die Klartext-Anmeldeinformationen dienen der Authentifizierung via HTTP- und SASL-Austausch.

Fordert ein Client beispielsweise einen Zugriff an, antwortet der Authentifizierungsserver dem Client, und der Client sendet seine verschlüsselte Antwort mit einem vom Passwort abgeleiteten Schlüssel. Um festzustellen, ob der Benutzer das richtige Passwort hat, wird die verschlüsselte Antwort mit einer zuvor gespeicherten Antwort auf dem Authentifizierungsserver verglichen. Und hier liegt der Kern des Problems.

Eine ausführlichere Erklärung zu WDigest, zur Funktionsweise und zu einigen Anwendungsfällen bietet Microsoft hier.

Warum ist das so wichtig?

Jedes Unternehmen sollte der Sicherheitsüberwachung von Windows hohe Priorität einräumen. Zu verstehen, wie Ihre Endpunkte eingerichtet sind und welche Türen sie unerwünschten Benutzern möglicherweise öffnen, ist für den Schutz jedes Systems von entscheidender Bedeutung. Hier kommt WDigest ins Spiel. Sie sollten sich darüber im Klaren sein, dass WDigest Passwörter im Klartext im Memory speichert. Falls sich eine böswillige Person Zugang zu einem Endpunkt verschafft und ein Programm wie Mimikatz ausführt, kann derjenige/diejenige sich nicht nur die aktuell im Speicher abgelegten Hashes, sondern auch die Klartext-Passwörter für die Benutzerkonten aneignen.

Es handelt sich dabei nicht nur um eine grundlegende Testpraxis von Red Teams, sondern auch um eine Taktik, die häufig von Angreifern wie KNOTWEED oder PHOSPHORUS für Ransomware-Kampagnen genutzt wird.

Dies ist besorgniserregend und sollte es auch sein, da Angreifer damit nicht nur einen Angriff wie Pass-the-Hash durchführen können, sondern auch über Benutzernamen und Kennwörter verfügen, um sich bei Anwendungen wie Exchange, internen Websites, etc. anzumelden.

Ein typisches Angriffsszenario

Angreifer haben Mimikatz in den vergangenen Jahren eingesetzt, um Anmeldedaten aus dem Speicher zu entwenden. Mehrere Anbieter von Antiviren-Lösungen haben Signaturen erstellt, um die Ausführung dieses Programms auf PCs zu verhindern. Es gibt jedoch mehrere Möglichkeiten, diese Antiviren-Signaturen zu umgehen, wie beispielsweise die Ausführung eines Programms im Speicher oder die Verschleierung dieses Utilitys.

Sobald ein Angreifer Zugriff auf ein internes System im Unternehmen erlangt hat, kann Mimikatz die Anmeldeinformationen aus dem Speicher abzurufen. Diese abgerufenen Anmeldedaten können in Hash-, Klartext- oder beiden Formaten vorliegen.

Wenn ein Angreifer das Glück hat, diese Anmeldedaten im Klartext zu erhalten, ist es nicht erforderlich, die Hashes zu knacken. Er hat direkten Zugriff auf interne Ressourcen und kommt damit seinem Ziel näher.

Dabei ist zu beachten, dass ein Angreifer über Administratorrechte verfügen muss, bevor er einen Befehl ausführen kann.

Hier ist ein Beispiel dafür, was ein Angreifer sehen würde, wenn er sich mit einem Tool wie Mimikatz die im Speicher vorhandenen Anmeldeinformationen anzeigen lässt. Der Benutzer „HanSolo“ hat sich über einen Remote-Desktop auf dem Rechner angemeldet. Da die spezifische Konfiguration rund um WDigest unsicher ist, sieht er nicht nur einen NTLM-Hash für das Konto, sondern auch das Klartext-Passwort „Password99!“.

Ein grundlegendes Verständnis der WDigest-Registry ist sowohl für offensive als auch defensive Analysten hilfreich.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

• Wenn der Wert für UseLogonCredential auf 0 gesetzt ist, legt WDigest keine Anmeldeinformationen im Speicher ab.
• Wenn der Wert für UseLogonCredential auf 1 gesetzt ist, legt WDigest die Anmeldeinformationen im Speicher ab.

Die Bedrohungsakteure PHOSPHOROUS beziehungsweise DEV-0270 nutzten für eine Ransomware-Kampagne LOLBINs, um die Anmeldedaten zu stehlen – nachdem sie das Gerät kompromittiert und Administratorrechte erlangt hatten. Damit werden weitere gängige Tools überflüssig, die mit größerer Wahrscheinlichkeit von Antiviren- und EDR-Lösungen (EDR: Endpoint Detection and Response) erkannt und blockiert würden. Einer dieser Prozesse beginnt mit der Aktivierung von WDigest in der Registry. Dies führt dazu, dass Passwörter im Klartext auf dem Gerät gespeichert werden und der Bedrohungsakteur Zeit einsparen kann, da er keinen Passwort-Hash knacken muss.

Wir haben festgestellt, dass zwei Varianten dieses Befehls verwendet werden, die beide den Registry-Wert von UseLogonCredential auf 1 setzen.

In Systemen, in denen die WDigest-Registry fehlt oder entfernt wurde:

"Set-ItemProperty -Force
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest'
-Name "UseLogonCredential"
-Value '1'"

In Systemen, in denen die WDigest-Registry so eingestellt ist, dass keine Klartext-Passwörter gespeichert werden:

"reg" add 
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v 
UseLogonCredential /t REG_DWORD /d 1 /f

Der Bedrohungsakteur verwendet dann rundll32.exe und comsvcs.dll mit der integrierten MiniDump-Funktion, um Passwörter von LSASS in eine Dump-Datei zu kopieren. Ein entsprechender Befehl spezifiziert häufig die Ausgabe, um die Passwörter von LSASS zu speichern. Auch die Buchstaben des Dateinamens werden vertauscht, um einer Entdeckung zu entgehen (ssasl.dmp):

powershell.exe" /c Remove-Item -Path C:\windows\temp\ssasl.pmd 
-Force -ErrorAction Ignore; 
rundll32.exe C:\windows\System32\comsvcs.dll, 
MiniDump (Get-Process lsass).id C:\windows\temp\ssasl.pmd full | out-host; 
Compress-Archive C:\windows\temp\ssasl.pmd C:\windows\temp\[name].zip

Die WDigest-Nutzung erkennen

Betrachten wir die defensive Seite, so sollten Änderungen im Registry-Pfad grundsätzlich ein verräterisches Zeichen dafür sein, dass etwas Bedrohliches im Gange ist. Auch mit Sysmon müssen Sie einen Monitoring-Pfad festlegen, damit Sie Änderungen in der Registry protokollieren können.

Die WDigest-Nutzung können Sie an zwei Stellen feststellen: in den Logdaten Ihres Domain-Controllers oder in den Server-Logdaten, wobei jeder Server überprüft werden muss.

Mit Logpoint stellen wir eine benutzerdefinierte Sysmon-Konfigurationsdatei und ein Nxlog-Beispiel zur Verfügung. Diese Zeile zielt insbesondere auf WDigest ab:

\Control\SecurityProviders\WDigest

Sobald der Pfad oder die Sysmon-Datei im System konfiguriert ist, können Sie eine sofort einsatzbereite Alert-Regel LP_Wdigest Registry Modification nutzen, um die am Registry-Pfad vorgenommenen Änderungen zu überwachen.

norm_id=WindowsSysmon event_id=13 
target_object="*WDigest\UseLogonCredential" -user IN EXCLUDED_USERS

Was den Prozess-Dump betrifft, so wird LP_Process Dump über Rundll32 und Comsvcs ausgelöst, wenn ein Angreifer oder ein Penetration-Tester versucht, die Kennwörter von LSASS in eine Dump-Datei zu übertragen.

label="Process" label=Create 
"process"="*\rundll32.exe" 
command IN ["*comsvcs.dll*#24*", "*comsvcs.dll*MiniDump*" ] -user IN EXCLUDED_USERS

Alle aktualisierten und bestehenden Regeln können Sie im Logpoint Service Desk herunterladen.

BITTE BEACHTEN SIE: In Windows 8.1 und Windows Server 2012 R2 und späteren Versionen ist die Zwischenspeicherung von Anmeldeinformationen für WDigest standardmäßig deaktiviert. Der Wert UseLogonCredential ist standardmäßig auf 0 gesetzt, wenn der Registry-Eintrag nicht vorhanden ist.

Wenn der Wert UseLogonCredential auf 0 gesetzt wird, werden Sie möglicherweise feststellen, dass häufiger Anmeldeinformationen abgefragt werden, wenn Sie WDigest verwenden.

Da dieses Problem bereits schon sehr lange besteht, hat Microsoft im Jahr 2014 einen Patch veröffentlicht, der die Speicherung von WDigest-Passwörtern im Speicher effektiv deaktiviert.

Ein Text von Microsoft, der sich mit dem Problem befasst, empfiehlt Benutzern außerdem, Klartext-Passwörter aus dem Speicher zu löschen:

Die Entfernung von Klartext-Anmeldeinformationen aus LSASS

Dieses Update verhindert, dass jeder Microsoft SSP in LSASS, außer WDigest, Klartext-Kennwörter von Benutzern speichert. WDigest speichert das Klartext-Kennwort des Benutzers nach wie vor, da es ohne das Kennwort des Benutzers nicht funktionieren kann. Microsoft möchte bestehende Kunden-Konfigurationen nicht beeinträchtigen und ein Update ausliefern, das diese Funktion deaktiviert. Microsoft empfiehlt Benutzern, ihre Logdaten für den Domain-Controller sowie die WDigest-Authentifizierungen durchzusehen. Die entsprechenden Anleitungen hierzu finden Sie unten. Falls die WDigest-Authentifizierung nicht zum Einsatz kommt, können Kunden das FixIt im KB-Artikel anwenden, um WDigest zu deaktivieren. So werden alle Klartext-Anmeldedaten aus dem LSASS-Speicher gelöscht.

Es ist wichtig zu wissen, dass zwar keine Klartext-Anmeldeinformationen mehr gespeichert werden, der NT-Hash und der Kerberos-TGT/ Session-Key jedoch weiterhin gespeichert werden und als Anmeldeinformationen gelten (ohne die im Speicher abgelegten Äquivalente der Anmeldeinformationen wäre ein Single-Sign-On unmöglich). Auch wenn die Klartext-Anmeldeinformationen nicht mehr im Speicher abgelegt sind, kann ein Angreifer andere Techniken wie Key-Logger verwenden, um Klartext-Passwörter wiederherzustellen. Die Beseitigung von Klartext-Passwörtern aus dem Speicher ist nützlich und verringert das Risiko, aber es garantiert nicht, dass Angreifer gestoppt werden.

Für Windows 7, 8, Server 2008 R2 und Server 2012 müssen Sie das oben genannte Sicherheitsupdate installieren und dann den folgenden Registry-Key auf 0 setzen.

Pfad: HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential

Am einfachsten geht dies über die Gruppen-Richtlinie, aber auch ein schnelles Skript funktioniert:

reg add
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredential /t REG_DWORD /d 0

Nachdem Sie das Sicherheitsupdate und die Aktualisierung des Registry-Schlüssels auf alle Ihre Server übertragen haben, können Sie prüfen, ob dies erfolgreich war: Fragen Sie die Registry ab, um zu sehen, ob der Schlüssel existiert und nicht auf 1 gesetzt ist.

reg query
HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v
UseLogonCredential

BITTE BEACHTEN SIE: Beide oben aufgeführten Änderungen lösen eine Warnmeldung aus, da eine Änderung am angegebenen Pfad vorgenommen wird.

Neuere Windows-Versionen (8.1+ und 2012 R2+) erfordern kein Sicherheitsupdate oder eine Festsetzung des Werts auf 0, da der Standardwert 0 ist. Sie sollten dennoch sicherstellen, dass keine manuellen Änderungen vorgenommen wurden, die den Wert auf 1 zurücksetzen.

Abhilfe mit Logpoint SOAR-Playbooks

Nach der Entdeckung der Exploit-Spuren sollten Analysten den Host, auf dem der Angriff stattfand, über ein Playbook isolieren und ein Incident-Response-Playbook starten.

Die Erkennung von Exploits ist einfach und reibungslos, da Logpoint eine einheitliche SIEM+SOAR-Lösung ist, die einen Alarm (SIEM-Event) nutzt, um automatisch ein SOAR-Playbook auszulösen. Sie können das Playbook so einstellen, dass es ausgeführt wird, wenn eine Änderung am WDigest-Registry-Pfad vorgenommen wurde. Das Playbook entfernt den Benutzer aus dem Active Directory und ändert das Benutzerkennwort mithilfe eines Zufallsgenerators.

Basierend auf den Richtlinien eines Unternehmens und den Verfahrensweisen des Incident-Response-Teams sammelt ein Investigation-Playbook so viele Daten wie möglich und erstellt einen Bericht.

Fazit

Eine Konfiguration im Zusammenhang mit WDigest könnte die Sicherheit Ihrer Umgebung, insbesondere des Endpunkts, beeinträchtigen, da diese es einem Angreifer ermöglicht, Klartext-Anmeldedaten aus dem Speicher zu entwenden. Sie können Maßnahmen ergreifen, um dieses Problem zu beheben und sicherzustellen, dass Ihre Endgeräte und Anmeldeinformationen sicherer sind. Das Sicherheitsupdate von Microsoft (KB2871997) behebt das Problem bei älteren Windows-Versionen, während neuere Versionen standardmäßig gesichert sein sollten. Überprüfen Sie die WDigest-Einstellung in der Registry für alle Windows-Endpunkte, da der Verlust von Anmeldeinformationen zum Verlust sensibler Daten führen könnte. Eine Möglichkeit, dies zu tun, sind Befehlszeilen-Abfragen für alle Ihre Hosts. Schneller geht es jedoch, wenn Sie die Überprüfung Ihrer Endpunkte automatisieren und sich die Daten in einem leicht verständlichen Bericht anzeigen lassen.

Contact us and learn why
industry-leading companies
choose Logpoint: