Jenseits des Tresors: Zero Standing Privilege schützt vor mehr als nur Passwortangriffen

Teil 2 von 3 unserer Reihe Rethinking Privileged Access. Beginnen Sie mit Teil 1: Das Passwort war nie das einzige Problem.

In Teil 1 haben wir die Grenze zwischen dem Tresor-und-Checkout-Modell des klassischen PAM und dem Sitzungs-und-Activities-Modell des modernen PAM mit Netwrix Privilege Secure (NPS) gezogen. Das eine schützt das Passwort, das andere beseitigt die dauerhaften Privilegien dahinter. Diese Betrachtung ist ein guter Ausgangspunkt, greift aber zu kurz. In Windows und Active Directory ist das Passwort nur der Samen. Alles, was ein Angreifer für die laterale Bewegung nutzt, wird daraus abgeleitet oder aufgrund davon ausgestellt: ein NTLM-Hash, ein Kerberos-Ticket, eine zwischengespeicherte Anmeldung, ein Zertifikat, ein DPAPI-Blob. Ein PAM-Tool, das nur das Passwort schützt, schützt ein Glied einer viel längeren Kette.

Hier zeigt sich der eigentliche Unterschied zwischen klassischem und modernem PAM. Ein Tresor verbirgt das Passwort, berührt aber nichts, was daraus folgt. NPS beseitigt dauerhafte Privilegien, indem es Konten in dem Moment rotiert, deaktiviert oder löscht, in dem eine Sitzung endet. Das unterbricht mehrere dieser nachgelagerten Angriffspfade, denn die meisten davon setzen voraus, dass ein privilegiertes Konto in nutzbarem Zustand länger existiert, als nötig wäre. NPS verhindert AD-Bedrohungen wie Kerberoasting jedoch nicht vollständig. Andere Netwrix-Produkte wie Netwrix Threat Prevention können helfen, indem sie verdächtige Authentifizierungsaktivitäten erkennen.

Die Angriffsfläche bei Anmeldedaten, die niemand im Tresor ablegt

Das lässt sich in einer Windows/AD-Umgebung über das Klartextpasswort hinaus angreifen:

• NTLM-Hashes: direkt per Pass-the-Hash nutzbar, ohne dass sie geknackt werden müssen.
• Kerberos-Tickets (TGT/TGS): per Pass-the-Ticket stehl- und wiederverwendbar sowie per Golden und Silver Tickets fälschbar, wenn der krbtgt-Schlüssel oder der Schlüssel eines Dienstkontos kompromittiert ist.
• Kerberoasting-/AS-REP-Roasting-fähiges Material: jeder Domänenbenutzer kann ein Diensticket für ein Konto mit SPN oder ein AS-REP für ein Konto ohne Vorauthentifizierung anfordern und es offline knacken.
• Zwischengespeicherte Domänenanmeldedaten (MSCACHEv2): liegen im lokalen SECURITY-Hive jedes Rechners, an dem sich ein Benutzer angemeldet hat.
• Zertifikate und msDS-KeyCredentialLinkExpand-Einträge: missbrauchbar durch Fehlkonfigurationen von AD-CS-Vorlagen oder Shadow-Credential-Angriffe, um sich als Benutzer zu authentifizieren, ohne je dessen Passwort anzufassen.
• LAPS-/gMSA-verwaltete Passwörter: nur durch die ACL des Attributs geschützt, in dem sie gespeichert sind.
• DPAPI-geschützte Geheimnisse: entschlüsselbar, wenn ein Angreifer den Master-Key des Benutzers ableitet oder den DPAPI-Backup-Schlüssel der Domäne stiehlt.

Keines dieser Elemente erfordert das Klartextpasswort, und alle gewähren etwas, das dem sehr nahekommt.

Warum dauerhafte Privilegien der gemeinsame Nenner sind

Fast jedes Element dieser Liste ist nur deshalb mächtig, weil das Konto dahinter gerade jetzt echte Privilegien besitzt und sie unbegrenzt behält. Ein klassisches PAM-Setup mit einem im Tresor abgelegten, rotierten und injizierten Passwort auf einer dauerhaften Domain-Admins-Mitgliedschaft hinterlässt zwischen zwei Checkouts trotzdem einen NTLM-Hash, der sich zu stehlen lohnt, ein TGS, das sich zu rösten lohnt, und eine zwischengespeicherte Anmeldung, die sich zu knacken lohnt.

Die Kontomodelle von NPS (Anforderer-, verwaltete und ephemere Konten, ausführlich in Teil 1 behandelt) packen diese gemeinsame Ursache direkt an. Verwaltete Konten werden in dem Moment deaktiviert und erneut rotiert, in dem eine Sitzung endet, ephemere Konten werden vollständig gelöscht, und selbst Anforderer-Konten besitzen erhöhte Gruppenmitgliedschaften nur für die Dauer der Sitzung.

Weil Privilegien einen Anfang und ein Ende haben, statt ewig zu bestehen, verlieren die meisten der oben genannten Angriffe ihr Ziel in dem Augenblick, in dem die Sitzung schließt. NPS muss den Angriff nicht erkennen, denn es bleibt nichts mehr übrig, was sich anzugreifen lohnt.

Was NPS bei den einzelnen Angriffen verändert

Mit NPS verfügt ein kompromittiertes Konto nur über begrenzte Privilegien, was den möglichen Schaden begrenzt.

Zwei Funktionen, die die Wirkung weiter ausdehnen

Zwei der kontounabhängigen Activities in NPS, beide in Teil 1 vorgestellt, verdienen hier erneut Erwähnung, weil sie dieselbe Logik über Anmeldedaten hinaus erweitern:

• RDP aktivieren/deaktivieren. Die meisten Server lassen RDP dauerhaft lauschen. NPS kann es nur für die Dauer einer Sitzung einschalten und unmittelbar danach wieder ausschalten. Das beseitigt eine große, ständig verfügbare Angriffsfläche, die nichts damit zu tun hat, welche Anmeldedaten ein Angreifer besitzt.
• Schutzmodus. Das Scannen von Windows- und Linux-Ressourcen nach nicht genehmigten lokalen Konten erfasst eine andere Fehlerart: einen Insider (oder einen Angreifer, der bereits eingedrungen ist), der unbemerkt ein dauerhaftes Konto für spätere Zwecke anlegt. Es wendet dieselbe Philosophie, „unverwaltete Privilegien nicht ansammeln zu lassen“, auf Konten an, die NPS gar nicht erstellt hat.

Was dies nicht ersetzt

Es lohnt sich, die Grenze genau zu benennen, denn Übertreibung nützt niemandem. NPS wirkt gegen Angriffe, die davon abhängen, dass ein privilegiertes Konto in nutzbarem Zustand bestehen bleibt, und das deckt erstaunlich viel des Windows-Katalogs für Angriffe auf Anmeldedaten ab. Es greift nicht bei Angriffen, die unabhängig vom Echtzeitstatus eines einzelnen Kontos funktionieren: ein aus einem gestohlenen krbtgt-Schlüssel gefälschtes Golden Ticket, der Missbrauch von AD-CS-Vorlagen, eine in ein Attribut geschriebene Shadow Credential oder der Diebstahl des domänenweiten DPAPI-Backup-Schlüssels. Dafür braucht es jeweils eigene Hygienemaßnahmen (konsequente krbtgt-Rotation, Prüfung der Zertifikatsvorlagen, Überwachung von Attributschreibzugriffen, Schutz des Backup-Schlüssels), unabhängig davon, wie konsequent das Sitzungs- und Activities-Modell umgesetzt ist.

Das Fazit

Klassisches PAM legt ein Passwort in einen Tresor und schützt damit ein einziges Artefakt. Das Beseitigen dauerhafter Privilegien mindert den Wert fast aller Elemente, die aus diesem Passwort folgen: Hashes, Tickets, zwischengespeicherte Anmeldungen und Attribute verwalteter Konten. Diese Artefakte sind nur dann stehlenswert, wenn das Privileg dahinter noch besteht, sobald der Angreifer sie nutzen will. NPS stoppt nicht jeden auf Anmeldedaten gerichteten Angriff in Active Directory, schließt aber weit mehr dieser Angriffsfläche, als „das Passwort schützen“ es je könnte.

Als Nächstes in dieser Reihe

Alles oben Gesagte setzt voraus, dass Konten vollständig mit den NPS-Kontomodellen betrieben werden. Teil 3 behandelt Bring Your Own Vault (BYOV): wie NPS denselben sitzungsbasierten Schutz über einem Tresor ergänzt, den Sie bereits betreiben (ein klassischer PAM-Tresor, CyberArk, BeyondTrust, HashiCorp Vault oder LAPS), damit Sie diese Exposition verringern können, ohne alles auf einmal zu migrieren.