Härtungsmaßnahme Protected Process Light

Eine der meistverwendeten Techniken in Hacker-Angriffen oder eben auch in einem Red Team Assessment ist das Auslesen von Zugangsdaten (Passwörter, Hashes, Tickets, Sessions Keys, etc.) aus dem Arbeitsspeicher. Zentraler Angriffspunkt für diese Technik ist die Local Security Authority (LSA) bzw. der zugehörige Windows-Prozess Local Security Authority Server Service (LSASS). Dieser Prozess ist dafür verantwortlich, entfernte und lokale Login-Prozesse durchzuführen und eventuelle Einschränkungen zu erzwingen. Entsprechend befinden sich im Arbeitsspeicher des Prozesses eine Vielzahl an sensiblen Informationen, die für diese Abläufe notwendig sind. Da unter Windows jeder Administrator standardmäßig über das Debug-Privileg (SeDebugPrivilege) verfügt und daher den Arbeitsspeicher jedes Prozesses einsehen kann, sind diese Daten dort vor einem Hacker mit administrativen Rechten nicht wirklich sicher. Tools wie mimikatz oder WCE sind in der Lage, den Speicherbereich von LSA systematisch nach Zugangsdaten zu untersuchen und diese an den Benutzer auszugeben.

Da es sich hierbei um ein konzeptionelles Problem handelt (vor dem übrigens auch Linux-Systeme nicht sicher sind, s. z.B. mimipenguin), sucht Microsoft schon lange nach einer Lösung, um das Auslesen von Zugangsdaten als Administrator zu unterbinden. Hierbei entstanden organisatorische Empfehlungen (wie das Administrative Tier-Modell oder ESAE/Red Forest), Härtungsmaßnahmen (um die Art und Zahl von Zugangsdaten im Arbeitsspeicher zu reduzieren, z.B. die Sicherheitsgruppe „Geschützte Benutzer“) und technische Gegenmaßnahmen (wie Credential Guard oder Protected Process Light).

Mit Windows 8.1 führte Microsoft besagte Schutzfunktion Protected Process Light ein. Wird ein Prozess als solcher ausgeführt, genießt er zusätzlichen Schutz durch den Kernel z.B. vor Auslesen oder Verändern des Speicherbereichs. Um das Feature nicht einfach ausschalten zu können, wird außerdem Secure Boot genutzt, um die entsprechende Registry-Einstellung vor Manipulation zu schützen. Die einzige Einschränkung für die reguläre Nutzung durch diese Maßnahme ist, dass nun nur noch durch Microsoft signierte LSA plug-ins (für z.B. externe Fingerabdrucksensoren) akzeptiert werden, und das Debuggen von LSA-Plugins nicht möglich ist. Da ein Plugin ohne gültige Signatur generell vermieden und das Debuggen von LSA-Plugins nur in extremen Ausnahmefällen nötig sein sollte, spricht zunächst nichts gegen die Einführung des Features.

Doch wie effektiv ist der Schutz? Ein kurzer Versuch vermittelt zunächst einen guten Eindruck:

 

 

Allerdings liefert mimikatz einen Kerneltreiber mit, der – einmal geladen – im Kernelspace von Windows aktiv ist und somit Einschränkungen auf Kernelebene angreifen kann: mimidrv.sys.
Lädt man diesen, kann der Schutz des LSASS-Prozesses einfach entfernt werden und auf den zugehörigen Speicherbereich wieder zugegriffen werden:

 

Ist der Schutz also wirkungslos? Nein, ist er definitiv nicht. Zunächst einmal ist das Laden des Treibers mit einigen Problemen für uns Red Teamer verbunden: der Treiber muss als Datei mit dem festen Namen „mimidrv.sys“ im aktuellen Arbeitsverzeichnis liegen. Das mit dem festen Namen könnte man allerdings noch mit einer angepassten und selbst kompilierten Variante von Mimikatz ändern. Das Laden von der Platte ist jedoch schon nicht mehr so einfach zu beseitigen. Außerdem muss der verwendete Treiber signiert sein, um von Windows geladen zu werden. Der Autor von mimikatz, Benjamin Delpy, veröffentlicht eine signierte Variante, allerdings eignet sich diese natürlich hervorragend für signaturbasierte Erkennung durch Antivirensysteme. virustotal.com zeigt eine Erkennungsrate von 54/70:

Natürlich kann der Treiber, wie ganz mimikatz, selbstständig obfuskiert, neu kompiliert und signiert werden, um eine signaturbasierte Erkennung durch Antiviren-Systeme zu vermeiden. Doch dieser Schritt ist sehr aufwendig und mit Kosten für das Code-Signing-Zertifikat verbunden. Deshalb scheuen ihn bereits viele Angreifer, auch weil es in der Regel einfachere Lösungen gibt und andere Erkennungstechniken sich nicht so leicht täuschen lassen. Außerdem generiert das Laden eines Treibers weitere Indizien (Indicators of Compromise, IoC), die zur Entdeckung des Angriffs durch ein SIEM führen können:

 

Zusammengefasst ist das Aktivieren von RunAsPPL für LSA eine sinnvolle Schutzmaßnahme. Sie kann zwar umgangen werden, allerdings ist dies mit aktivem Antiviren-System nicht trivial. Dagegen sprechen nur minimale Einschränkungen im regulären Betrieb, weshalb NSIDE klar eine Empfehlung zur Aktivierung des Schutzes auf sämtlichen Windows-Systemen ausspricht.