LSASS-Schutz
Schutzmechanismen für den LSASS-Prozess unter Windows, insbesondere RunAsPPL (Protected Process Light), die das Auslesen von Zugangsdaten aus dem Arbeitsspeicher verhindern.
Der Local Security Authority Subsystem Service (LSASS) ist ein zentraler Windows-Prozess (lsass.exe), der Authentifizierungen verarbeitet und dabei NTLM-Hashes, Kerberos-Tickets und weitere Zugangsdaten im Arbeitsspeicher vorhält. Genau das macht ihn zum primären Ziel für Credential-Dumping-Tools wie Mimikatz: Wer den LSASS-Speicher auslesen kann, erhält Zugriff auf alle dort zwischengespeicherten Credentials — und damit die Grundlage für Pass-the-Hash-Angriffe und laterale Bewegung im Netzwerk.
RunAsPPL — Protected Process Light
RunAsPPL ist der wichtigste Schutzmechanismus für den LSASS-Prozess. Wird LSASS als Protected Process Light (PPL) ausgeführt, kann nur noch Microsoft-signierter Code auf den Prozessspeicher zugreifen. Unsignierte Tools — einschließlich Mimikatz — werden vom Betriebssystem blockiert, bevor sie den Speicher überhaupt adressieren können. Die Schutzebene (Protection Level) sorgt dafür, dass selbst Prozesse mit Administratorrechten keinen Lesezugriff auf LSASS erhalten, solange sie nicht die korrekte Signatur tragen.
Aktivierung
Die Aktivierung erfolgt über den Registrierungsschlüssel HKLM\SYSTEM\CurrentControlSet\Control\Lsa mit dem DWORD-Wert RunAsPPL = 1. In Domänenumgebungen lässt sich diese Einstellung per Gruppenrichtlinie zentral auf alle Systeme verteilen. Ab Windows 11 22H2 ist RunAsPPL bei Neuinstallationen auf Enterprise-verwalteten Geräten (domänenverbunden oder Entra-ID-registriert) mit HVCI-Unterstützung standardmäßig aktiviert. Unverwaltete Geräte und bestehende Systeme, die per Upgrade migriert werden, übernehmen die Einstellung nicht automatisch und müssen manuell oder per GPO konfiguriert werden.
Zusammenspiel mit Credential Guard
RunAsPPL und Credential Guard verfolgen komplementäre Ansätze. RunAsPPL schützt den LSASS-Prozess selbst vor unbefugtem Zugriff, während Credential Guard die sensiblen Geheimnisse (NTLM-Hashes, Kerberos-TGTs) in eine virtualisierungsbasierte Sicherheitsumgebung (VBS) auslagert, die selbst ein kompromittiertes Betriebssystem nicht erreichen kann. Beide Maßnahmen sollten gemeinsam aktiviert werden: Credential Guard entzieht LSASS die Credentials, RunAsPPL verhindert den Zugriff auf die verbleibenden Daten im Prozessspeicher.
Einschränkungen
RunAsPPL ist kein absoluter Schutz. Kernel-Mode-Treiber können die PPL-Schutzstufe umgehen, da sie auf derselben Privilegierungsebene wie der Kernel selbst operieren. Angriffe über verwundbare signierte Treiber (Bring Your Own Vulnerable Driver, BYOVD) sind dokumentiert und werden in der Praxis eingesetzt. Microsoft begegnet diesem Risiko mit der Kernel-Mode-Blocklist und HVCI (Hypervisor-Protected Code Integrity), die das Laden bekannter verwundbarer Treiber unterbinden können.
Auf der operativen Seite können legitime Sicherheitstools, die auf LSASS-Speicherzugriff angewiesen sind — etwa bestimmte EDR-Lösungen oder Backup-Agenten —, nach der Aktivierung von RunAsPPL nicht mehr korrekt funktionieren. Ein Test in einer Staging-Umgebung vor dem produktiven Rollout ist daher unerlässlich.
Relevanz für KMUs
LSASS-Schutz per RunAsPPL ist eine der wirksamsten Härtungsmaßnahmen mit minimalem Aufwand: Ein einzelner Registrierungswert oder eine GPO, ausgerollt auf alle domänenverbundenen Systeme, entzieht Credential-Dumping-Tools die Grundlage.
In Kombination mit LAPS für lokale Admin-Passwörter und einem Tiering-Modell für die Trennung privilegierter Konten entsteht eine mehrschichtige Verteidigung, die den häufigsten Angriffspfad in Active-Directory-Umgebungen erheblich erschwert. Wer zusätzlich Credential Guard aktiviert und administrative Tätigkeiten auf eine PAW beschränkt, erreicht ein Schutzniveau, das die meisten opportunistischen Angreifer effektiv stoppt.