Ausgangslage: LSASS ist ein lohnendes Ziel – auch ohne „Malware-Drama“

In AD-Umgebungen landen Anmeldeinformationen und abgeleitete Secrets an Stellen, die im Alltag normal wirken: Admin-Logons auf Servern, geplante Tasks, Service-Konten, Remote-Management, Helpdesk-Sessions, Break-Glass-Accounts. Für Angreifer ist das attraktiv, weil ein erfolgreicher Zugriff auf LSASS oft direkt zu lateral movement oder Privilegienausweitung führt.

Das Problem: Viele Gegenmaßnahmen (z. B. „Admin darf nicht auf Clients arbeiten“) sind organisatorisch richtig, aber in der Praxis nicht sofort perfekt. RunAsPPL ist hier ein technischer Hardening-Baustein, der den Aufwand für Credential-Theft auf Windows-Systemen spürbar erhöht – vorausgesetzt, du rollst ihn kontrolliert aus.

Zielbild: LSASS läuft als Protected Process Light, kompatibel und messbar

Ein sauberes Zielbild ist nicht „ein Registry-Wert überall“, sondern:

  1. Tier-0 / Admin-Endpunkte zuerst (DCs, Admin-Workstations, Management-Server).
  2. Kompatibilität ist vorab geklärt (AV/EDR, Credential Provider, Smartcard/SSO-Add-ons, Monitoring).
  3. Erzwingung und Drift-Kontrolle über GPO/Endpoint-Management inkl. Nachweis.
  4. Rollback ist geplant (für einzelne OUs/Device-Gruppen), ohne das Projekt zu stoppen.

RunAsPPL ist keine „Magie“: Es ist ein sinnvoller Schutzmechanismus – aber nur ein Teil einer Tier-0-Story.

Umsetzung: kontrollierter Rollout statt „Flag Day“

1) Scope sauber schneiden (wo bringt es den größten Nutzen?)

Pragmatische Priorisierung:

  • Tier 0: Domain Controllers, PAWs/SAWs, Jump Hosts, Management-Server.
  • Tier 1: Server mit Admin-Logons (z. B. File/SQL/App), Citrix/RDS Hosts.
  • Tier 2: Standard-Clients (oft später, abhängig von Tooling-Kompatibilität).

Wichtig: RunAsPPL wirkt besonders dort, wo privilegierte Anmeldungen stattfinden. Genau dort willst du es zuerst.

2) Enablen per Policy (bevorzugt) oder Registry (gezielt)

Bevorzugter Weg ist eine zentrale Policy (so bekommst du Drift-Kontrolle und nachvollziehbaren Scope). Je nach Windows-Version/ADMX ist das typischerweise ein Setting unter den LSA-/Security-Optionen (sinngemäß „LSASS als geschützter Prozess“).

Wenn du es technisch verifizieren willst, ist der Registry-Status relevant:

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

Praktisch:

  • Änderungen erfordern üblicherweise einen Reboot.
  • Plane die Umsetzung als Pilot → Welle 1 → Welle 2, nicht als Einmal-Change.

3) Kompatibilität testen (das ist der eigentliche Projektanteil)

RunAsPPL scheitert selten am Windows-Kern, sondern an „Rand-Integrationen“:

  • AV/EDR: braucht ggf. kompatible Treiber/Signaturen; sonst fehlende Telemetrie oder Schutzfunktionen.
  • Credential Provider / SSO-Add-ons: Drittanbieter-Login-Komponenten können unerwartet betroffen sein.
  • Legacy Admin-Tools: einzelne Debug-/Dump-Workflows (auch legitime) funktionieren anders oder gar nicht.
  • RDS/Citrix: viele Logons, viele Profile, viel Drittanbieter-Integration → guter Pilot-Kandidat.

Empfehlung: Pilot-OU mit repräsentativen Systemen und „typischen Admin-Usern“ (inkl. Smartcard/Hello, falls im Einsatz).

4) Nachweis im Betrieb: messen, nicht glauben

Für die Projektsteuerung zählt, dass du den Zustand pro Systemklasse belegen kannst:

  • Policy-Status (GPO/MDM-Compliance)
  • Registry-Status (RunAsPPL*)
  • Change-Events/Incidents nach Rollout (Helpdesk-Tickets, EDR-Health, Auth-Issues)

Zusätzlich: Stelle sicher, dass „Tier-0-Endpoints“ nicht aus dem Scope fallen (Stichwort: OU-Drift, neue Jump Hosts, neu aufgesetzte DCs).

Vorteile (explizit)

  • Höhere Hürde für Credential-Theft: direkter Zugriff auf LSASS wird deutlich erschwert.
  • Gute Ergänzung zu NTLM-/Kerberos-Hardening: selbst wenn Protokolle sauberer werden, bleiben Logons ein Ziel.
  • Tier-0-Impact: besonders wirksam auf Admin-Endpunkten und DCs (wo Credentials am wertvollsten sind).
  • Drift-resistent bei sauberem Policy-Rollout: klarer, überprüfbarer Zustand.

Nachteile und Grenzen (explizit)

  • Kompatibilitätsrisiko: EDR/AV und Drittanbieter-Login-Komponenten sind häufig die Engstelle.
  • Reboot-Planung: erfordert koordinierte Wartungsfenster, insbesondere auf Servern/DCs.
  • Nicht gleich „Credential Guard“: RunAsPPL schützt LSASS-Prozesszugriffe, ersetzt aber keine isolierte Secret-Verarbeitung.
  • Kein Ersatz für Tiering/Logon-Controls: wenn Admins überall interaktiv arbeiten, bleiben Risiken hoch – nur schwerer auszunutzen.

Typische Stolperfallen in Projekten

  • „Wir schalten es einfach überall an“: ohne Pilot brichst du dir schnell EDR/SSO oder Sonderfälle.
  • Nur Clients betrachtet: Server- und Admin-Endpunkte sind meist wichtiger.
  • Bundling mit anderen Changes: RunAsPPL + große Auth-Änderungen + EDR-Agent-Wechsel in einer Welle = schlechte Fehlersuche.
  • Kein Rollback-Pfad: dann wird beim ersten Incident alles pausiert, statt gezielt zu reagieren.
  • Drift über neue Systeme: ohne Baseline/Compliance gehen Neuinstallationen am Zielbild vorbei.

Projekt-Checkliste (für Umsetzung und Betrieb)

  • [ ] Ziel-Scope tierbasiert definiert (Tier 0/1/2) inkl. OU-Design.
  • [ ] Kompatibilitätsmatrix erstellt (EDR/AV, Credential Provider, Smartcard/Hello, RDS/Citrix, Monitoring).
  • [ ] Pilot-OU ausgerollt inkl. Reboot-Plan und klarer Erfolgskriterien.
  • [ ] Rollout-Wellen geplant (Tier 0 zuerst), inkl. Rollback pro OU/Gruppe.
  • [ ] Betriebsnachweis definiert (Policy/Registry-Status + EDR-Health + Ticket-Signale).
  • [ ] Neuinstallationen/Golden Images in Baseline integriert (keine Drift durch Templates).