Windows Credentials Protections

Reading time: 10 minutes

Credentials Protections

WDigest

Das WDigest Protokoll, das mit Windows XP eingeführt wurde, ist für die Authentifizierung über das HTTP-Protokoll konzipiert und ist standardmäßig auf Windows XP bis Windows 8.0 und Windows Server 2003 bis Windows Server 2012 aktiviert. Diese Standardeinstellung führt zu der Speicherung von Passwörtern im Klartext in LSASS (Local Security Authority Subsystem Service). Ein Angreifer kann Mimikatz verwenden, um diese Anmeldeinformationen zu extrahieren, indem er Folgendes ausführt:

sekurlsa::wdigest

Um diese Funktion ein- oder auszuschalten, müssen die UseLogonCredential und Negotiate Registrierungswerte innerhalb von HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest auf "1" gesetzt werden. Wenn diese Werte fehlen oder auf "0" gesetzt sind, ist WDigest deaktiviert:

reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential

LSA-Schutz (PP & PPL geschützte Prozesse)

Protected Process (PP) und Protected Process Light (PPL) sind Windows-Kernel-Schutzmechanismen, die entwickelt wurden, um unbefugten Zugriff auf sensible Prozesse wie LSASS zu verhindern. Eingeführt in Windows Vista, wurde das PP-Modell ursprünglich zur Durchsetzung von DRM geschaffen und erlaubte nur Binärdateien, die mit einem besonderen Medienzertifikat signiert sind, geschützt zu werden. Ein als PP markierter Prozess kann nur von anderen Prozessen, die auch PP sind und ein gleiches oder höheres Schutzniveau haben, zugegriffen werden, und selbst dann nur mit eingeschränkten Zugriffsrechten, es sei denn, dies ist ausdrücklich erlaubt.

PPL, eingeführt in Windows 8.1, ist eine flexiblere Version von PP. Es erlaubt breitere Anwendungsfälle (z. B. LSASS, Defender), indem es "Schutzniveaus" basierend auf dem EKU (Enhanced Key Usage)-Feld der digitalen Signatur einführt. Das Schutzniveau wird im EPROCESS.Protection-Feld gespeichert, das eine PS_PROTECTION-Struktur mit folgenden Inhalten ist:

• Typ (Protected oder ProtectedLight)
• Signer (z. B. WinTcb, Lsa, Antimalware usw.)

Diese Struktur wird in einem einzelnen Byte gepackt und bestimmt wer auf wen zugreifen kann:

• Höhere Signaturwerte können auf niedrigere zugreifen
• PPLs können nicht auf PPs zugreifen
• Ungeschützte Prozesse können auf keine PPL/PP zugreifen

Was Sie aus offensiver Perspektive wissen müssen

• Wenn LSASS als PPL ausgeführt wird, schlagen Versuche, es mit OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION) aus einem normalen Admin-Kontext zu öffnen, mit 0x5 (Zugriff verweigert) fehl, selbst wenn SeDebugPrivilege aktiviert ist.
• Sie können das Schutzniveau von LSASS überprüfen, indem Sie Tools wie Process Hacker verwenden oder programmgesteuert den Wert von EPROCESS.Protection lesen.
• LSASS hat typischerweise PsProtectedSignerLsa-Light (0x41), auf das nur von Prozessen zugegriffen werden kann, die mit einem höherwertigen Signierer signiert sind, wie WinTcb (0x61 oder 0x62).
• PPL ist eine nur für den Benutzerraum geltende Einschränkung; Kernel-Code kann dies vollständig umgehen.
• Dass LSASS PPL ist, verhindert nicht das Auslesen von Anmeldeinformationen, wenn Sie Kernel-Shellcode ausführen können oder einen hochprivilegierten Prozess mit entsprechendem Zugriff nutzen.
• Das Setzen oder Entfernen von PPL erfordert einen Neustart oder Secure Boot/UEFI-Einstellungen, die die PPL-Einstellung auch nach Rückgängigmachung von Registrierungänderungen beibehalten können.

Umgehungsoptionen für PPL-Schutz:

Wenn Sie LSASS trotz PPL auslesen möchten, haben Sie 3 Hauptoptionen:

1. Verwenden Sie einen signierten Kernel-Treiber (z. B. Mimikatz + mimidrv.sys), um das Schutzflag von LSASS zu entfernen:

2. Bring Your Own Vulnerable Driver (BYOVD), um benutzerdefinierten Kernel-Code auszuführen und den Schutz zu deaktivieren. Tools wie PPLKiller, gdrv-loader oder kdmapper machen dies möglich.
3. Stehlen Sie einen vorhandenen LSASS-Handle von einem anderen Prozess, der ihn geöffnet hat (z. B. ein AV-Prozess), und duplizieren Sie ihn in Ihren Prozess. Dies ist die Grundlage der Technik pypykatz live lsa --method handledup.
4. Missbrauchen Sie einen privilegierten Prozess, der es Ihnen ermöglicht, beliebigen Code in seinen Adressraum oder in einen anderen privilegierten Prozess zu laden, wodurch die PPL-Einschränkungen effektiv umgangen werden. Sie können ein Beispiel dafür in bypassing-lsa-protection-in-userland oder https://github.com/itm4n/PPLdump überprüfen.

Überprüfen Sie den aktuellen Status des LSA-Schutzes (PPL/PP) für LSASS:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL

Wenn Sie mimikatz privilege::debug sekurlsa::logonpasswords ausführen, schlägt es wahrscheinlich mit dem Fehlercode 0x00000005 fehl, aufgrund dessen.

• Für weitere Informationen dazu überprüfen Sie https://itm4n.github.io/lsass-runasppl/

Credential Guard

Credential Guard, eine Funktion, die exklusiv für Windows 10 (Enterprise- und Education-Editionen) ist, verbessert die Sicherheit von Maschinenanmeldeinformationen mithilfe von Virtual Secure Mode (VSM) und Virtualization Based Security (VBS). Es nutzt CPU-Virtualisierungserweiterungen, um wichtige Prozesse innerhalb eines geschützten Speicherbereichs zu isolieren, der vom Hauptbetriebssystem nicht erreicht werden kann. Diese Isolation stellt sicher, dass selbst der Kernel nicht auf den Speicher in VSM zugreifen kann, wodurch Anmeldeinformationen effektiv vor Angriffen wie pass-the-hash geschützt werden. Die Local Security Authority (LSA) arbeitet innerhalb dieser sicheren Umgebung als Trustlet, während der LSASS-Prozess im Hauptbetriebssystem lediglich als Kommunikator mit der LSA von VSM fungiert.

Standardmäßig ist Credential Guard nicht aktiv und erfordert eine manuelle Aktivierung innerhalb einer Organisation. Es ist entscheidend für die Verbesserung der Sicherheit gegen Tools wie Mimikatz, die in ihrer Fähigkeit, Anmeldeinformationen zu extrahieren, eingeschränkt sind. Allerdings können Schwachstellen weiterhin ausgenutzt werden, indem benutzerdefinierte Security Support Providers (SSP) hinzugefügt werden, um Anmeldeinformationen im Klartext während Anmeldeversuchen zu erfassen.

Um den Aktivierungsstatus von Credential Guard zu überprüfen, kann der Registrierungsschlüssel LsaCfgFlags unter HKLM\System\CurrentControlSet\Control\LSA inspiziert werden. Ein Wert von "1" zeigt die Aktivierung mit UEFI-Sperre an, "2" ohne Sperre, und "0" bedeutet, dass es nicht aktiviert ist. Diese Registrierungskontrolle, obwohl ein starker Indikator, ist nicht der einzige Schritt zur Aktivierung von Credential Guard. Detaillierte Anleitungen und ein PowerShell-Skript zur Aktivierung dieser Funktion sind online verfügbar.

reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags

Für ein umfassendes Verständnis und Anleitungen zur Aktivierung von Credential Guard in Windows 10 und seiner automatischen Aktivierung in kompatiblen Systemen von Windows 11 Enterprise und Education (Version 22H2), besuchen Sie Microsofts Dokumentation.

Weitere Details zur Implementierung benutzerdefinierter SSPs zur Erfassung von Anmeldeinformationen finden Sie in diesem Leitfaden.

RDP RestrictedAdmin-Modus

Windows 8.1 und Windows Server 2012 R2 führten mehrere neue Sicherheitsfunktionen ein, darunter den Restricted Admin-Modus für RDP. Dieser Modus wurde entwickelt, um die Sicherheit zu erhöhen, indem die Risiken im Zusammenhang mit pass the hash -Angriffen gemindert werden.

Traditionell werden bei der Verbindung zu einem Remote-Computer über RDP Ihre Anmeldeinformationen auf dem Zielcomputer gespeichert. Dies stellt ein erhebliches Sicherheitsrisiko dar, insbesondere bei der Verwendung von Konten mit erhöhten Rechten. Mit der Einführung des Restricted Admin-Modus wird dieses Risiko jedoch erheblich reduziert.

Beim Initiieren einer RDP-Verbindung mit dem Befehl mstsc.exe /RestrictedAdmin erfolgt die Authentifizierung zum Remote-Computer, ohne Ihre Anmeldeinformationen darauf zu speichern. Dieser Ansatz stellt sicher, dass im Falle einer Malware-Infektion oder wenn ein böswilliger Benutzer Zugriff auf den Remote-Server erhält, Ihre Anmeldeinformationen nicht kompromittiert werden, da sie nicht auf dem Server gespeichert sind.

Es ist wichtig zu beachten, dass im Restricted Admin-Modus Versuche, auf Netzwerkressourcen aus der RDP-Sitzung zuzugreifen, nicht Ihre persönlichen Anmeldeinformationen verwenden; stattdessen wird die Identität des Computers verwendet.

Dieses Feature stellt einen bedeutenden Fortschritt bei der Sicherung von Remote-Desktop-Verbindungen dar und schützt sensible Informationen vor der Offenlegung im Falle eines Sicherheitsvorfalls.

Für detailliertere Informationen besuchen Sie diese Ressource.

Zwischengespeicherte Anmeldeinformationen

Windows sichert Domänenanmeldeinformationen über die Local Security Authority (LSA) und unterstützt Anmeldeprozesse mit Sicherheitsprotokollen wie Kerberos und NTLM. Ein wichtiges Merkmal von Windows ist die Fähigkeit, die letzten zehn Domänenanmeldungen zwischenzuspeichern, um sicherzustellen, dass Benutzer weiterhin auf ihre Computer zugreifen können, selbst wenn der Domänencontroller offline ist – ein Vorteil für Laptop-Benutzer, die oft außerhalb des Netzwerks ihres Unternehmens sind.

Die Anzahl der zwischengespeicherten Anmeldungen kann über einen bestimmten Registrierungsschlüssel oder Gruppenrichtlinie angepasst werden. Um diese Einstellung anzuzeigen oder zu ändern, wird der folgende Befehl verwendet:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT

Der Zugriff auf diese zwischengespeicherten Anmeldeinformationen ist streng kontrolliert, wobei nur das SYSTEM-Konto die erforderlichen Berechtigungen hat, um sie anzuzeigen. Administratoren, die auf diese Informationen zugreifen müssen, müssen dies mit SYSTEM-Benutzerprivilegien tun. Die Anmeldeinformationen werden unter folgendem Pfad gespeichert: HKEY_LOCAL_MACHINE\SECURITY\Cache

Mimikatz kann verwendet werden, um diese zwischengespeicherten Anmeldeinformationen mit dem Befehl lsadump::cache zu extrahieren.

Für weitere Details bietet die ursprüngliche Quelle umfassende Informationen.

Geschützte Benutzer

Die Mitgliedschaft in der Gruppe der geschützten Benutzer führt zu mehreren Sicherheitsverbesserungen für Benutzer und gewährleistet höhere Schutzmaßnahmen gegen Diebstahl und Missbrauch von Anmeldeinformationen:

• Anmeldeinformationsdelegation (CredSSP): Selbst wenn die Gruppenrichtlinieneinstellung für Standardanmeldeinformationen delegieren zulassen aktiviert ist, werden die Klartextanmeldeinformationen geschützter Benutzer nicht zwischengespeichert.
• Windows Digest: Ab Windows 8.1 und Windows Server 2012 R2 wird das System die Klartextanmeldeinformationen geschützter Benutzer nicht zwischenspeichern, unabhängig vom Status von Windows Digest.
• NTLM: Das System wird die Klartextanmeldeinformationen geschützter Benutzer oder NT-Einwegfunktionen (NTOWF) nicht zwischenspeichern.
• Kerberos: Für geschützte Benutzer wird die Kerberos-Authentifizierung keine DES- oder RC4-Schlüssel generieren, noch werden Klartextanmeldeinformationen oder langfristige Schlüssel über den ursprünglichen Ticket-Granting Ticket (TGT)-Erwerb hinaus zwischengespeichert.
• Offline-Anmeldung: Geschützte Benutzer haben bei der Anmeldung oder Entsperrung keinen zwischengespeicherten Verifier, was bedeutet, dass die Offline-Anmeldung für diese Konten nicht unterstützt wird.

Diese Schutzmaßnahmen werden aktiviert, sobald ein Benutzer, der Mitglied der Gruppe der geschützten Benutzer ist, sich am Gerät anmeldet. Dies stellt sicher, dass kritische Sicherheitsmaßnahmen vorhanden sind, um gegen verschiedene Methoden des Kompromittierens von Anmeldeinformationen zu schützen.

Für detailliertere Informationen konsultieren Sie die offizielle Dokumentation.

Tabelle aus den Dokumenten.