So überprüfen Sie den LSA-Schutz in Windows 11

Der Prozess LSASS (Local Security Authority Subsystem Service) ist eine zentrale Windows-Komponente. Er ist für die Benutzerauthentifizierung, die Durchsetzung von Sicherheitsrichtlinien und die Erstellung von Zugriffstoken zuständig, die den Zugriff auf Systemressourcen steuern. Da LSASS sensibles Anmeldematerial verarbeitet und speichert (z. B. Passwort-Hashes, Kerberos-Tickets), ist der Prozess ein äußerst lohnendes Ziel für Angreifer:innen. Bei einer Kompromittierung lassen sich Anmeldeinformationen aus dem Arbeitsspeicher auslesen, Rechte ausweiten und Systeme seitlich durchqueren.

Der Schutz der Local Security Authority (LSA) ist ein zentrales Sicherheitsfeature in Windows 11, das genau dieses Risiko verringern soll. Es schützt den LSASS-Prozess, indem es ihn als geschützten Prozess ausführt und den Zugriff ausschließlich auf vertrauenswürdige, signierte Komponenten beschränkt. So lassen sich unbefugte Speicherzugriffe, Code-Injection und gängige Techniken zum Diebstahl von Anmeldeinformationen verhindern. Um zu überprüfen, ob der LSA-Schutz aktiviert ist, reicht allerdings ein einzelner Schalter in der Benutzeroberfläche nicht aus: Sie müssen mehrere Systemindikatoren kontrollieren.

Lesen Sie weiter und erfahren Sie, mit welchem praxisnahen Workflow Administrator:innen und Managed Service Provider (MSPs) den LSA-Schutz in Windows 11 überprüfen können.

So prüfen Sie, ob der Schutz der Local Security Authority aktiv ist

Gerade in verwalteten Umgebungen ist es wichtig, den LSA-Schutz aus mehreren Blickwinkeln zu validieren. Die folgenden Schritte führen Sie durch Prüfungen in der Benutzeroberfläche, Registrierungswerte, Nachweise aus dem Ereignisprotokoll, den Richtlinienkontext und ergänzende Sicherheitsfunktionen, damit sichergestellt ist, dass LSASS als geschützter Prozess läuft.

📌 Voraussetzungen:

• Lokale Administratorrechte auf dem Endpunkt
• Zugriff auf Windows-Sicherheit, Ereignisanzeige und eine Shell mit erhöhten Rechten (z. B. PowerShell, Eingabeaufforderung)
• Formaler Änderungsnachweis für jede Behebungsmaßnahme

Schritt 1: Windows-Sicherheit prüfen

Überprüfen Sie zunächst den Status in Windows-Sicherheit, um zu sehen, wie das System den LSA-Schutz aktuell meldet. In diesem Schritt erkennen Sie außerdem, ob Warnungen oder Empfehlungen vorliegen, die sofortige Aufmerksamkeit erfordern.

1. Navigieren Sie zu Einstellungen > Datenschutz & Sicherheit > Windows-Sicherheit > Gerätesicherheit > Details zur Kernisolierung.
2. Suchen Sie den Schalter für den Schutz der Local Security Authority und vergewissern Sie sich, dass er auf Ein steht.
3. Sehen Sie sich alle angezeigten Empfehlungen oder Warnungen an.
4. Erstellen Sie einen Screenshot, falls Nachweise für Audits oder das Ticketing benötigt werden.

Schritt 2: Über die Registrierung bestätigen

Prüfen Sie anschließend die Registrierung, um festzustellen, ob der LSA-Schutz auch auf Systemebene konfiguriert ist. So können Sie zwischen Anzeigeproblemen in der Benutzeroberfläche und der tatsächlich beabsichtigten Schutzkonfiguration unterscheiden.

1. Öffnen Sie den Registrierungs-Editor mit Administratorrechten.
2. Navigieren Sie zu HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Prüfen Sie RunAsPPL und stellen Sie sicher, dass der Wert auf 1 oder 2 gesetzt ist. Damit wird der LSA-Schutz aktiviert (mit oder ohne UEFI-Lock), sodass LSASS nach einem Neustart als geschützter Prozess läuft.
4. Prüfen Sie RunAsPPLBoot und stellen Sie sicher, dass der Wert auf 1 oder 2 gesetzt ist. Damit greift der LSA-Schutz bereits früher im Startvorgang, wobei 2 auf unterstützten Systemen eine stärkere Durchsetzung bietet, weil die Einstellung gegen Manipulation gesperrt wird.
5. Ziehen Sie diese Werte im nächsten Schritt zusammen mit den Ereignisprotokollen heran, um das Laufzeitverhalten zu bestätigen.

Schritt 3: Mit Ereignisprotokollen validieren

Ereignisprotokolle liefern zudem einen verlässlichen Nachweis darüber, ob LSASS tatsächlich als geschützter Prozess gestartet ist, und zeigen Plug-ins, die unter den Schutzanforderungen nicht geladen werden konnten.

1. Öffnen Sie die Ereignisanzeige.
2. Wechseln Sie zu Anwendungs- und Dienstprotokolle > Microsoft > Windows > CodeIntegrity > Operational.
3. Halten Sie nach Code Integrity-Ereignissen Ausschau (z. B. Ereignis-ID 3065 oder 3089), die anzeigen, dass LSASS als geschützter Prozess gestartet ist, und die LSA-Plug-ins markieren, die blockiert wurden oder nicht geladen werden konnten.
4. Folgen Sie den Audit-Hinweisen von Microsoft für die weitere Analyse.

Schritt 4: Mit PowerShell und Richtlinienkontext überprüfen

Ergänzend helfen PowerShell und eine Richtlinienprüfung dabei, zu bestätigen, dass der LSA-Schutz durch Management-Tools aktiviert und durchgesetzt wird. So bleibt die Einstellung auch nach Betriebssystem-Updates erhalten und kann von Endbenutzer:innen nicht geändert werden.

1. Verwenden Sie eine PowerShell-Sitzung mit erhöhten Rechten, um die LSA-bezogenen Registrierungswerte zu bestätigen und den konfigurierten Status mit diesem Befehl zu überprüfen:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "RunAsPPL","RunAsPPLBoot" -ErrorAction SilentlyContinue

2. Stellen Sie sicher, dass Gruppenrichtlinien oder MDM den LSA-Schutz durchsetzen, damit er Updates übersteht und lokale Einstellungen in der Benutzeroberfläche überschreibt.

Schritt 5: LSASS- und Credential Guard-Status gegenprüfen

Sie sollten außerdem prüfen, wie der LSA-Schutz mit Credential Guard zusammenwirkt, denn beide Funktionen setzen auf ein geschütztes LSASS-Verhalten und auf virtualisierungsbasierte Sicherheit. Es handelt sich jedoch um zwei getrennte Hardening-Funktionen. Wer ihre Abstimmung bestätigt, vermeidet Fehlkonfigurationen, die die Isolierung schwächen oder unerwartete Warnungen auslösen können.

1. Bestätigen Sie, dass Credential Guard aktiviert ist.
2. Bestätigen Sie, dass LSASS als geschützter Prozess läuft, indem Sie die RunAsPPL-Registrierungswerte und die in den vorherigen Schritten ermittelten Startereignisse für geschützte Prozesse prüfen.
3. Prüfen Sie die Code Integrity- und LSA-Überwachungsprotokolle auf Fehler, die auf blockierte Komponenten oder Konflikte zwischen Credential Guard und dem LSA-Schutz hinweisen.
4. Dokumentieren Sie alle Abweichungen zwischen erwartetem und tatsächlichem Status, damit sie vor der weiteren Validierung behoben werden können.

Schritt 6: Nachweise für das Audit dokumentieren

Sammeln Sie immer eindeutige und überprüfbare Nachweise, damit Sie die Ergebnisse später nachvollziehen können und die Fehlersuche deutlich leichter fällt.

1. Erstellen Sie Screenshots des LSA-Schutzstatus in Windows-Sicherheit.
2. Exportieren Sie die relevanten Registrierungsschlüssel aus HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
3. Notieren Sie die Ereignis-IDs, die einen geschützten LSASS-Start belegen oder Plug-in-Probleme aufzeigen.
4. Halten Sie Gerätename, Windows-Build und den zutreffenden Richtlinienbereich fest und legen Sie die Nachweise in Ihrem RMM- oder Ticketing-System ab.

Schritt 7: Inkonsistente Statusmeldungen beheben

Werden Sie abschließend aktiv, wenn die Signale zum LSA-Schutz in Benutzeroberfläche, Registrierung und Ereignisprotokollen nicht übereinstimmen. Beheben Sie diese Widersprüche, damit das Gerät tatsächlich geschützt ist und der gemeldete Status stimmt.

• Wenden Sie die entsprechende Richtlinie erneut an, wenn die Benutzeroberfläche den LSA-Schutz als deaktiviert anzeigt, Registrierung und Richtlinienwerte ihn aber als aktiviert ausweisen.
• Starten Sie das Gerät neu und wiederholen Sie den Vorgang bei Bedarf, bis Windows-Sicherheit, Registrierungswerte und Code Integrity-Ereignisse übereinstimmend zeigen, dass LSASS als geschützter Prozess startet.
• Gehen Sie Warnzuständen oder Meldungen zu nicht signierten LSA-Paketen in Windows-Sicherheit nach.
• Nutzen Sie Ihren vorhandenen Artikel zur Fehlerbehebung, um nicht konforme Plug-ins oder Treiber zu bereinigen.
• Validieren Sie die Konfiguration nach der Behebung erneut, um zu bestätigen, dass der Status über alle Quellen hinweg einheitlich ist.

Best Practices im Überblick

Nachfolgend finden Sie einige Best Practices, mit denen sich der LSA-Schutz konsistent validieren und zuverlässig durchsetzen lässt. Sie reduzieren Unklarheiten und beschleunigen Untersuchungen.

Das steckt hinter dem LSA-Schutz, und darum lohnt sich die Überprüfung

Der LSA-Schutz ist eine Windows-Sicherheitsfunktion, die LSASS als geschützten Prozess ausführt. Damit wird verhindert, dass nicht vertrauenswürdiger Code in den Prozess injiziert wird, und Versuche werden blockiert, im Arbeitsspeicher gespeicherte Anmeldeinformationen zu stehlen. Die Funktion härtet eine der sensibelsten Komponenten des Betriebssystems ab und bildet die Grundlage moderner Schutzmechanismen für Anmeldeinformationen wie Credential Guard.

Die Überprüfung ist aus mehreren Gründen entscheidend:

• Sie stellt sicher, dass LSASS nicht nur konfiguriert ist, sondern tatsächlich als geschützter Prozess läuft.
• Sie deckt Abweichungen zwischen Benutzeroberfläche, Registrierung und Richtliniendurchsetzung auf.
• Sie stellt sicher, dass der Schutz nach Upgrades oder Richtlinienänderungen bestehen bleibt.
• Sie identifiziert ungeschützte oder inkompatible LSA-Plug-ins, die die Sicherheit schwächen.
• Sie liefert Nachweise für Audits, Compliance-Prüfungen und Sicherheitsuntersuchungen.

Fehlerbehebung

Beim Überprüfen des LSA-Schutzes können einige typische Probleme auftreten. Die folgenden Schritte zur Fehlerbehebung helfen dabei, dass das Gerät seinen Sicherheitsstatus korrekt meldet.

LSA wird nach einem Upgrade als deaktiviert angezeigt

Stellen Sie sicher, dass die Unternehmensrichtlinie weiterhin angewendet wird und die RunAsPPL-Werte weiterhin konfiguriert sind. Manche Windows-Upgrades setzen Sicherheitseinstellungen zurück, daher kann ein Neustart erforderlich sein. Bleibt die Einstellung nicht erhalten, wenden Sie die Richtlinie erneut an und prüfen Sie noch einmal.

Der Schalter in der Benutzeroberfläche fehlt oder ist ausgegraut

Das bedeutet in der Regel, dass die Einstellung über eine Unternehmensrichtlinie und nicht lokal gesteuert wird. Prüfen Sie die Rangfolge der Richtlinien und vergewissern Sie sich, dass die Registrierung den durchgesetzten Status widerspiegelt. Auch nicht unterstützte oder veraltete Konfigurationen können dazu führen, dass der Schalter nicht verfügbar ist.

Warnungen zu ungeschützten Plug-ins

Sehen Sie sich die Audit-Hinweise von Microsoft an, um zu ermitteln, welche Plug-ins oder Treiber nicht als geschützt geladen werden konnten. Aktualisieren, entfernen oder ersetzen Sie die nicht konformen Komponenten, um das korrekte LSA-Verhalten wiederherzustellen. Prüfen Sie anschließend die Ereignisprotokolle erneut, um sicherzugehen, dass keine weiteren Plug-ins betroffen sind.

Analyst:innen verwechseln LSA und LSASS

Machen Sie deutlich, dass LSA das Subsystem ist, das für die Authentifizierungsrichtlinie zuständig ist, während LSASS der Prozess ist, der sie umsetzt. Eine kurze interne Erläuterung hilft, wiederkehrende Verwechslungen zu reduzieren.

LSA-Schutz validieren und langfristig absichern

Die Überprüfung des LSA-Schutzes sollte strukturiert erfolgen, damit sichergestellt ist, dass LSASS wirklich als geschützter Prozess läuft. Mit dem beschriebenen Workflow, von der Prüfung der Registrierungswerte bis zur Behebung von Widersprüchen, können MSPs und Administrator:innen langfristig für Stabilität sorgen.

Verwandte Themen:

• So aktivieren Sie Credential Guard und den LSA-Schutz auf allen Client-Geräten
• So aktivieren oder deaktivieren Sie den Schutz der Local Security Authority in Windows 11
• So beheben Sie die Warnung „LSA-Paket ist nicht wie erwartet signiert“ in Windows 11
• So setzen Sie alle lokalen Sicherheitsrichtlinien in Windows auf die Standardwerte zurück