Credential Guard und LSA-Schutz: LSASS absichern

LSASS (Local Security Authority Subsystem Service) verwahrt die Geheimnisse, die einmaliges Anmelden ermöglichen: NTLM-Hashes, Kerberos-Tickets und -Schlüssel und manchmal mehr. Jeder Prozess, der den LSASS-Speicher lesen kann, kann diese Geheimnisse abgreifen und anderswo wiederverwenden. Credential Dumping aus LSASS taucht in einem sehr großen Teil der manuell gesteuerten Angriffe auf, und deshalb bringt Windows heute zwei eigens dafür gedachte Schutzmaßnahmen mit:

• LSA-Schutz (RunAsPPL) führt LSASS als Protected Process Light aus. Nur Code, der mit der passenden Schutzstufe signiert ist, kann ihn zum Lesen des Speichers oder zum Einschleusen von Code öffnen, selbst wenn der Angreifer lokaler Administrator ist.
• Credential Guard nutzt virtualisierungsbasierte Sicherheit (VBS), um NTLM-Hashes, Kerberos-TGT-Sitzungsschlüssel und gespeicherte Domänenanmeldedaten in einen isolierten Prozess zu verlagern, LsaIso.exe, der in einer separaten virtuellen Vertrauensebene läuft. LSASS kommuniziert per RPC mit ihm und hält die rohen Geheimnisse nie selbst.

Beide ergänzen sich und sollten gemeinsam aktiviert werden.

Anforderungen

Was kaputtgeht

Beide Funktionen entfernen absichtlich Fähigkeiten. Planen Sie für:

• LSA-Plug-ins und Treiber von Drittanbietern, die nicht für geschützte Prozesse signiert sind: Smartcard-Middleware, manche Kennwortfilter, ältere Sicherheitsprodukte. Der LSA-Schutz bietet dafür einen Überwachungsmodus; nutzen Sie ihn.
• Mit Credential Guard: NTLMv1, MS-CHAPv2 und Digest funktionieren für einmaliges Anmelden mit gespeicherten Anmeldedaten nicht mehr, uneingeschränkte Kerberos-Delegierung und DES-Verschlüsselung werden blockiert, und CredSSP kann gespeicherte oder Standardanmeldedaten nicht delegieren. WLAN- und VPN-Profile mit MS-CHAPv2 (PEAP-MSCHAPv2) fragen nach oder schlagen fehl, wenn sie auf gespeicherte Windows-Anmeldedaten angewiesen sind. Stellen Sie diese vorher auf zertifikatsbasierte Authentifizierung (EAP-TLS) um.

Schritt 1: LSA-Schutz vor dem Erzwingen überwachen

Setzen Sie LSASS auf einer Pilotgruppe in den Überwachungsmodus (Windows 11 22H2 und neuer überwachen bereits standardmäßig). Dabei wird jedes Modul protokolliert, das unter dem Schutz nicht geladen werden könnte, ohne etwas zu blockieren:

Key:   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe
Value: AuditLevel  (REG_DWORD) = 8

Starten Sie neu und werten Sie Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational aus:

• Ereignis 3065: LSASS hat versucht, einen Treiber oder ein Modul zu laden, das die Sicherheitsanforderungen für gemeinsam genutzte Abschnitte nicht erfüllt.
• Ereignis 3066: LSASS hat versucht, ein Modul zu laden, das die Anforderungen an die Microsoft-Signaturstufe nicht erfüllt und daher nach Aktivierung des Schutzes blockiert würde.

Wenden Sie sich an den Hersteller jedes aufgeführten Moduls. Die meisten aktuellen Sicherheits- und Authentifizierungsprodukte liefern korrekt signierte LSA-Komponenten.

Schritt 2: LSA-Schutz aktivieren

Gruppenrichtlinie (ADMX von Windows 11 22H2 und neuer sowie Server 2025): Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process, gesetzt auf Enabled with UEFI Lock oder Enabled without UEFI Lock.

Der entsprechende Registrierungswert, der auch auf älteren Builds funktioniert:

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: RunAsPPL  (REG_DWORD)
       1 = enabled with a UEFI variable (cannot be turned off by registry alone)
       2 = enabled without UEFI lock (Windows 11 22H2 and later)

Die UEFI-Sperre ist stärker, weil ein Angreifer mit Admin-Rechten nicht einfach die Registrierung umstellen und neu starten kann. Sie bedeutet aber auch, dass ein späteres Deaktivieren ein dokumentiertes Opt-out-Tool und physische Anwesenheit erfordert; setzen Sie sie also ein, sobald Sie sich der Kompatibilität sicher sind.

Prüfen Sie nach dem Neustart im System-Protokoll: Ereignis 12 der Quelle Wininit meldet LSASS.exe was started as a protected process with level: 4.

Schritt 3: Credential Guard aktivieren

Gruppenrichtlinie: Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security:

Registrierungsentsprechungen für skriptgesteuerte oder domänenlose Bereitstellung:

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard
  EnableVirtualizationBasedSecurity   REG_DWORD 1
  RequirePlatformSecurityFeatures     REG_DWORD 1  (Secure Boot)  or 3 (Secure Boot + DMA)

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  LsaCfgFlags                         REG_DWORD 1  (with UEFI lock) or 2 (without lock)

In Intune verwenden Sie Endpoint security > Account protection oder ein Profil aus dem Einstellungskatalog für Credential Guard.

Schritt 4: Überprüfen

Auf dem Gerät zeigt msinfo32 Virtualization-based security: Running und führt Credential Guard unter Virtualization-based security Services Running auf. Per PowerShell:

$dg = Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard
$dg.VirtualizationBasedSecurityStatus   # 2 = läuft
$dg.SecurityServicesRunning             # enthält 1 = Credential Guard, 2 = HVCI (Speicherintegrität)

Microsoft empfiehlt nicht, im Task-Manager nach LsaIso.exe zu suchen; prüfen Sie stattdessen im System-Protokoll Ereignis 13 von WinInit (Credential Guard (LsaIso.exe) was started and will protect LSA credentials). Erfassen Sie diese Werte flottenweit über Ihr Verwaltungswerkzeug oder ein Compliance-Skript, denn Firmware-Updates, BIOS-Resets und Hardwaretausch können VBS stillschweigend abschalten.

Schritt 5: Die Altlasten abschalten

Credential Guard und PPL schützen, was LSASS vorhält. Reduzieren Sie, was es überhaupt vorhält:

Aktivieren Sie außerdem die ASR-Regel Block credential stealing from the Windows local security authority subsystem (9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2), die eine weitere Barriere auf Geräten bildet, auf denen Credential Guard nicht laufen kann. Siehe den Leitfaden zu ASR-Regeln.

Erkennung bleibt wichtig

Keine der beiden Funktionen schützt Anmeldedaten, die auf einem kompromittierten Computer eingetippt werden (ein Keylogger sieht sie trotzdem), Hashes lokaler Konten in der SAM oder die Datenbank NTDS.dit auf Domänencontrollern. Erkennen Sie weiterhin:

• Prozesszugriffe auf lsass.exe mit Rechten zum Lesen des Speichers (Sysmon Event 10 oder Ihr EDR).
• Änderungen an RunAsPPL, LsaCfgFlags und UseLogonCredential (Registrierungsüberwachung oder Sysmon Event 13).
• Das Anlegen von LSASS-Dumpdateien (Sysmon Event 11 für *.dmp, geschrieben von ungewöhnlichen Prozessen).

Checkliste

• LSA-Schutz überwacht (Ereignisse 3065/3066), dann mit UEFI-Sperre erzwungen
• Ereignis 12 bestätigt auf jedem Host die Schutzstufe des geschützten Prozesses
• VBS und Credential Guard laufen auf allen geeigneten Clients und Mitgliedsservern
• WLAN/VPN vor dem Credential-Guard-Rollout von MS-CHAPv2 umgestellt
• WDigest aus und überwacht; zwischengespeicherte Anmeldungen reduziert
• ASR-Regel für LSASS im Blockierungsmodus
• Flottenbericht zu SecurityServicesRunning, nach Firmware-Updates erneut geprüft

Diese beiden Einstellungen machen die zuverlässigste Post-Exploitation-Technik unter Windows unzuverlässig. Kombiniert mit Admin-Tiering gibt es schlicht weniger, was sich zu stehlen lohnt, und weniger Orte, an denen es sich stehlen lässt.