„Keine Pass-the-Hash-Angriffe mehr“ – Die Grenzen von Remote Credential Guard

Remote Credential Guard wurde kürzlich von Microsoft eingeführt, um den Diebstahl von Anmeldedaten von Systemen zu erschweren, auf die über RDP zugegriffen wird. Im Wesentlichen ermöglicht diese Funktion RDP-Verbindungen, ohne Anmeldedaten auf Zielservern zu hinterlassen. Stattdessen bleiben die Anmeldedaten auf dem Quellsystem und das Ziel fordert bei Bedarf Diensttickets von der Quelle an.

Obwohl dies eine hilfreiche Kontrolle darstellt, kann ein Angreifer auf dem Zielsystem verbleiben, auf eine eingehende Verbindung warten und, anstatt die Anmeldedaten zu stehlen, einfach die gewünschten Tickets von der Quelle anfordern. Auf diese Weise kann der Angreifer auch ohne im Besitz der Anmeldedaten zu sein, den privilegierten Benutzer für die Dauer der Sitzung imitieren (z. B. indem er sich die generierten Diensttickets oder das Zugriffstoken des Opfers einverleibt).

In diesem Blog werden einige der Möglichkeiten zur Ausführung dieses Angriffsvektors erläutert.

Remote Credential Guard

Im vergangenen Jahr hat Microsoft Credential Guard eingeführt – eine Sicherheitsfunktion in Windows 10 Enterprise und Windows Server 2016. Credential Guard nutzt Virtualisierungstechnologie, um die Gefahr des Diebstahls abgeleiteter Anmeldedaten auf Domänenebene nach einer Kompromittierung zu senken und damit die Wirksamkeit von Kerberos-Angriffen wie Overpass-the-Hash und Pass-the-Ticket zu verringern. Vor kurzem veröffentlichte Microsoft sein Jubiläums-Update und damit Remote Credential Guard, eine Sicherheitsfunktion mit dem Ziel, Anmeldedaten bei Remote-Desktop-Verbindungen (RDP) zu schützen, indem die erforderlichen Diensttickets vom Quellsystem generiert werden, anstatt die Anmeldedaten (Hashes und TGTs) auf das Zielsystem zu kopieren.

Diese Funktion soll Administratoren die sichere Verbindung mit nicht vertrauenswürdigen Remoteservern ermöglichen („Angriffsannahme“), ohne privilegierte Anmeldedaten auf diesen Servern zu hinterlassen. Sie scheint den eingeschränkten Administratormodus, eine in Windows 8.1  / 2012 R2 eingeführte und dann auf Windows 7 / 8 / 2008 R2 / 2012 zurückportierte Funktion, zu ersetzen. Im eingeschränkten Administratormodus wurden privilegierte Anmeldedaten geschützt, indem die RDP-Sitzung in eine lokale Administratorsitzung „umgewandelt“ wurde, was den Diebstahl von privilegierten Anmeldedaten auf Domänenebene verhindern sollte. Der entscheidende Vorteil von Remote Credential Guard gegenüber dem eingeschränkten Administratormodus ist, dass die RDP-Verbindung vollständig interaktiv (statt Netzwerkanmeldung) ist und somit den Zugriff auf Remotedienste aus der „anmeldedatenfreien“ RDP-Sitzung ermöglicht.

Wenn sich ein Benutzer über RDP an einem System mit Remote Credential Guard anmeldet, speichert keiner der Security Support Provider (SSP) im Speicher das Klartextpasswort oder den Passwort-Hash des Benutzers. Wenn ein Angreifer das Zielsystem kompromittiert hat und versucht, die Hashes auszulesen, findet er dort keine auszulesenden Hashes.

Dadurch wird dem Angreifer die Möglichkeit genommen, Pass-the-Hash- oder Overpass-the-Hash-Angriffe (auch als Pass-the-Key bekannt) auszuführen, um den Remote-Benutzer zu imitieren. Ist dies also das Ende von Angriffen zum Diebstahl von Anmeldedaten?

Diensttickets bleiben erhalten

Es sollte beachtet werden, dass Kerberos-Tickets im Speicher verbleiben, um interaktive (und SSO-)Sitzungen vom Zielserver (über RDP) zu ermöglichen.  Beim Auslesen der zwischengespeicherten Kerberos-Tickets aus dem Speicher zeigt sich, dass der Sitzungsschlüssel des Ticket Granting Ticket (TGT), das vom Credential Guard des Clientsystems delegiert wurde, verschlüsselt wird und somit unbrauchbar für einen Pass-the-Ticket-Angriff ist.

Da Diensttickets (Ticket Granting Service) aber nicht verschlüsselt sind, können sie immer noch übergeben werden, um Zugriff auf bestimmte Dienste zu erhalten (SPN). Das Ausmaß des Zugriffs und die Möglichkeiten zur Eskalation hängen hierbei von den Diensttickets ab, die extrahiert werden können.

Der Zielserver zieht alle vom Benutzer über das Quellsystem (mit RDP-Verbindung) angeforderten Diensttickets zurück. Wenn die RDP-Sitzung die Ausführung administrativer Aufgaben oder Zugriffe auf sensible Ressourcen beinhaltet, werden attraktive Diensttickets, die für eine Remote-Ausführung und Daten-Exfiltration missbraucht werden könnten, wahrscheinlich zwischengespeichert. Demnach stimmt es zwar, dass Passwort-Hashes und TGTs eine größere Angriffsfläche haben und damit stärker gefährdet sind als Diensttickets, jedoch können Diensttickets auf eigene Weise wertvoll sein.

Dennoch bieten Diensttickets nur begrenzten Nutzen. Was ist, wenn ein Angreifer mit seiner Beute unzufrieden ist und auf andere, lukrativere Ziele zugreifen will? Schließlich kann sich ein Angreifer nicht immer darauf verlassen, dass das Konto des Opfers über ausreichende Berechtigungen zur Eskalation verfügt und der Benutzer zufällig die Diensttickets anfordert, die eine wirksame Erweiterung ermöglichen.

Auslesen des Zugriffstokens

Obwohl die Anmeldedaten des Opfers durch Credential Guard auf dem Quellsystem isoliert sind, verbleibt das Zugriffstoken des Opferkontos für die Dauer der RDP-Sitzung auf dem kompromittierten Server. Durch Auslesen dieses Zugriffstokens kann ein Angreifer auf einem kompromittierten Server einen Code im Zusammenhang mit dem Konto des Opfers ausführen. Auch wenn das TGT des Opfers geschützt ist, leitet Remote Credential Guard alle Kerberos-Anfragen zurück an das Quellsystem, wodurch dieses überlistet werden kann, um Diensttickets auszustellen.

Sowohl für das Token des RDP-Clients als auch für das bösartige duplizierte Token werden auf der Grundlage der Berechtigungen des authentifizierten Kontos Diensttickets generiert und Berechtigungen erteilt. Auch wenn das Angriffsfenster schmal ist, können im Namen des Opfers schnell willkürlich Tickets angefordert werden, um diese später auf einem anderen System zu verwenden. Standardmäßig beträgt die Lebensdauer von Diensttickets zehn Stunden, was dem Angreifer genug Zeit für seinen nächsten Schritt gibt.

Richtiges Timing oder Skills

Der genannte Angriffsvektor setzt zwei Dinge voraus: ein System mit administrativem Zugriff und einen Benutzer, der am kompromittierten Server angemeldet ist (oder vor kurzem noch war). Ersteres könnte durch den Missbrauch einer Sicherheitslücke oder einer Fehlkonfiguration erreicht werden, während Letzteres ein gewisses Social Engineering oder aber etwas Glück erfordert. Nach der Kompromittierung eines Servers muss der Angreifer zunächst prüfen, ob eine aktive Terminalsitzung oder zwischengespeicherte Kerberos-Tickets vorhanden sind. Wenn keine Anmeldedaten vorhanden sind und die Zeit nicht drängt, kann der Angreifer im System verbleiben und auf eingehende Verbindungen warten. Er kann es aber auch auf die altmodische Art versuchen und eine solche Verbindung provozieren, indem er einen Administrator durch Verursachen eines Problems, für dessen Lösung höhere Privilegien erforderlich sind, dazu bringt, sich über RDP mit dem System zu verbinden.

Zusammenfassung

Remote Credential Guard soll privilegierte Anmeldedaten auf Domänenebene bei der Verbindung mit einem Remoteserver über RDP vor Diebstahl schützen, doch abgeleitete Anmeldedaten beschränken sich nicht auf NTLM-Hashes und Kerberos-TGTs. Aus Sicht des Angreifers ist die Anzahl der Ableitungen von kompromittierten Anmeldedaten irrelevant, sofern eine von ihnen die gewünschte Zugriffsebene ermöglicht. Obwohl die mögliche Gefährdung von Anmeldedaten zu einem gewissen Grad begrenzt wird, kann Remote Credential Guard das Risiko eines Diebstahls von Anmeldedaten durch einen entschlossenen Angreifer, der bereits das Zielsystem kompromittiert hat und nur noch darauf wartet, dass ihm eine privilegierte Sitzung in Netz geht, nicht vollständig beseitigen.

Empfehlungen

Angesichts der Grenzen von Remote Credential Guard stellt sich die Frage, wie abgeleitete Anmeldedaten weiter vor Diebstahl geschützt werden können. Die folgenden Maßnahmen und Richtlinien können helfen, einige der Lücken, die Remote Credential Guard offen lässt, zu schließen:

  • Stellen Sie Remote-Verbindungen nach Möglichkeit durch Netzwerkanmeldung statt durch interaktive Anmeldung her.
  • Definieren und begrenzen Sie den administrativen Zugriff stufenweise (Tier-Modell), d. h. das Administratorkonto auf Gesamtsystem-/Domänenebene wird nur zum Verwalten des Active Directory verwendet.
  • Reduzieren Sie die Angriffsfläche von Anmeldedaten auf das für die jeweilige Aufgabe geringstmögliche Privileg.
  • Erzwingen Sie die Entfernung von Anmeldedaten nach dem Abmelden.