Unerlaubter Zugriff auf Anmeldeinformationen ist ein Schritt, der sich in fast jedem erfolgreichen Cyberangriff feststellen lässt. Angreifer sind dabei besonders an Techniken interessiert, die ihnen Zugangsdaten mit weitreichenden Berechtigungen liefern, ohne dass in den Überwachungssystemen gleich die Alarmglocken schrillen. Und manchmal ergeben sich solche Techniken aus der Funktionalität von Windows und des Active Directory.

Kerberoasting ist eine Angriffstechnik, die darauf beruht, dass in Kerberos grundsätzlich jeder Benutzer oder Computer für jeden Dienst ein Serviceticket vom Domaincontroller (DC) anfordern kann. Erst beim tatsächlichen Zugriff auf den Dienst unter Verwendung dieses Tickets wird überprüft, ob das anfragende Konto hierzu das Recht besitzt. Somit kann, wenn ein Sicherheitsprinzipal im AD über einen Service Principal Name (SPN) verfügt, jeder User – also auch ein vom Angreifer gekaperter Standardbenutzer oder Arbeitsplatzrechner – ein Serviceticket für diesen Sicherheitsprinzipal von einem DC erhalten.

Das vom Domaincontroller ausgestellte Serviceticket beinhaltet einen Teil, der ausschließlich für den angefragten Dienstprinzipal bestimmt ist und ihm gleichzeitig versichern soll, dass das Ticket tatsächlich vom DC der angegebenen Domäne erzeugt wurde. Hierzu ist das Ticket mit dem Kerberos-Hash des Service-Accounts verschlüsselt, der idealerweise nur dem DC und dem Konto selbst bekannt ist. Allerdings beinhaltet das Ticket Klartextinformationen, die von vornherein bekannt sind, wie beispielsweise den Namen des anfragenden Benutzers. Damit lässt sich der Erfolg eines Entschlüsselungsversuchs schnell und zuverlässig verifizieren. Dennoch sind die gesuchten Informationen nicht im Payload enthalten, sondern kommen lediglich als Verschlüsselungsschlüssel zum Einsatz.

Kerberoasting läuft daher auf Brute Force hinaus. In der Regel wird der Angreifer das komplette Serviceticket zunächst aus der kompromittierten Umgebung exfiltrieren und Tools wie HashCat oder John The Ripper in seiner eigenen Umgebung verwenden, um das Klartextkennwort zu rekonstruieren (Offline-Cracking). Da die führenden Ransomware-Banden bereits vor einiger Zeit das "as-a-Service"-Geschäftsmodell für sich erschlossen haben, passt es natürlich aus kaufmännischer Sicht sehr gut ins Konzept, dass die für das Cracken von Hashes und Tickets notwendige GPU-Leistung stundenweise in den Hyperscaler-Clouds wie Azure oder AWS gemietet werden kann. Das macht gleichzeitig auch die Standortbestimmung der "Crackstations" anhand der typischen Muster im Stromverbrauch unmöglich.

Die beiden Phasen des Kerberoasting sind also mit einem diametral unterschiedlichen Aufwand verbunden. So leicht die Erzeugung und die Exfiltration des Servicetickets in den allermeisten Active-Directory-Umgebungen ist, so aufwendig kann das Knacken des Kennworts ausfallen, wenn es lang und komplex ist. Einen großen Unterschied in der fürs Cracken benötigten Rechenleistung macht auch der verwendete Hash-Algorithmus – das herkömmliche und mit NTHash identische RC4 wird zunehmend von AES abgelöst. Die Windows-Versionen ab Server 2019 werden von sich aus nur mit dem AES-Hash verschlüsselte Tickets anfordern und ausstellen. Ist jedoch RC4 grundsätzlich in der AD-Umgebung möglich, kann der Angreifer den Domain Controller zum Protocol Downgrade zwingen und explizit ein Ticket anfordern, bei dem der Serviceteil mit dem RC4-Hash verschlüsselt ist.

Wie immer, wenn es um das Erraten von Kennwörtern geht, spielt die Zeichenanzahl und Komplexität eine sehr große Rolle. Wenn wir uns bei der Generierung von Kennwörtern auf die 109 Zeichen beschränken, die auf einer deutschen Tastatur direkt eingegeben werden können, gibt es mehr verschiedene Kennwörter bis zu einer Länge von 19 Zeichen als verschiedene RC4-Hashes insgesamt. Daher sind Computerkonten und Group Managed Service Accounts (gMSA) in der Regel nicht als Kerberoasting-Ziele geeignet, denn deren Kennwörter sind rein zufällige Strings, die sich regelmäßig ändern. Bei Computern ist es durch eine Gruppenrichtlinie gesteuert, bei gMSA bei der Erstellung des Accounts festgelegt. Standardmäßig liegt der Wert in beiden Fällen bei 30 Tagen, was das Cracken endgültig unwirtschaftlich macht.

Es hält sich unter vielen Administratoren das Gerücht, dass Domänen-Mitglieder die Vertrauensstellung zum AD verlieren, wenn sie zu lange keine Verbindung zu einem Domaincontroller aufnehmen können. Dies war beim alten Windows NT-Domänenmodell und bei Windows 2000 manchmal der Fall, moderne Windows-Versionen hingegen können damit problemlos umgehen. Dennoch hat es in der Pandemie dazu geführt, dass manche Organisationen für Home-Office-Notebooks die Änderung der Maschinenkennwörter per Gruppenrichtlinie deaktiviert haben. Und in einigen Fällen wurde diese Richtlinie falsch verknüpft, sodass sie auch auf Server wirkt, von denen einige über explizite Privilegien verfügen. Stellt ein Angreifer eine solche Fehlkonfiguration fest und hat er Zugriff auf preiswerte GPU-Ressourcen, kann sich selbst das Cracken eines 128 Zeichen langen Kennworts als wirtschaftlich erweisen, wenn die Belohnung dafür groß genug ist.

Das ideale Ziel für Kerberoasting ist somit ein "Legacy Service Account", ein Benutzerkonto also, das über

- ein nicht ablaufendes Kennwort, möglichst händisch vergeben und mit RC4 verschlüsselt,

- einen expliziten SPN sowie

- weitreichende Berechtigungen entweder im AD selbst oder in anderen Systemen verfügt.

Eine etwas seltener gewordene Abwandlung von Kerberoasting liefert statt des Klartext-Kennworts nur den Hash, der dann für Pass-the-Hash (NTLM), Overpass-the-Hash (Kerberos-Ticket mit RC4-Verschlüsselung) oder Pass-the-Key (Kerberos-Ticket mit AES-Verschlüsselung) verwendet werden kann. Der benötigte Rechenaufwand ist jedoch identisch, da in beiden Fällen die Hashes nicht unmittelbar durchprobiert, sondern jeweils aus Klartext gebildet werden.

Das Auffinden von lohnenden Kerbe­roasting-Zielen ist einfach: Angreifer verwenden dafür Tools wie Python-Skripte (ein beliebtes Beispiel ist "GetUserSPN.py" aus Impacket [2], das auf einer Linux-Maschine läuft), um die Chancen der Entdeckung bei Verwendung von PowerShell oder anderer Standardwerkzeuge zu verringern. Als Verteidiger müssen Sie keine Angst haben, bereits bei der Erkundung aufzufliegen, und können sich einfach des bordeigenen AD-Moduls für PowerShell bedienen. Wir suchen nach Accounts, die

- nicht deaktiviert sind,

- normale User sind,

- ein nicht-ablaufendes Kennwort und

- mindestens einen explizit gesetzten Service Principal Name besitzen.

Hierfür können Sie den folgenden LDAP-Filter verwenden:

Der Wert "2" für "userAccountControl" bedeutet dabei "Account deaktiviert", der Wert "66048" ist die Summe aus 65536 (Kennwort läuft nicht ab) und 512 (normales Benutzerkonto). Möchten Sie die besonders lohnenswerten Ziele finden, die gleichzeitig noch Mitglied in einer der privilegierten Gruppen sind, fügen Sie nach "(servicePrincipalName=*)" noch "(adminCount=1)" in den Filter ein. Den so entstandenen LDAP-Filter können Sie mit

oder mit

verwenden. Sie können ihn auch mit dem LDAP-Browser Ihrer Wahl oder mit Kommandozeilen-Suchwerkzeugen wie adfind [3] oder dsquery [4] einsetzen.

Die prinzipielle Anwendung von Kerberoasting liegt in der Funktionsweise von Kerberos selbst, daher wird es Ihnen nicht gelingen, durch irgendwelche Konfigurationseinstellungen Ihr Active Directory so zu härten, dass Kerberoasting nicht mehr möglich ist. Doch sind Sie keineswegs machtlos. Ihre Verteidigung sollte sich allerdings nicht ausschließlich auf das Erschweren der Angriffe konzentrieren, sondern auch deren mögliche Folgeschäden beschränken. So machen Sie die Kerberoasting-Technik für den Angreifer nicht nur teuer in der Durchführung, sondern auch unattraktiv im Ergebnis.

War es dem Angreifer möglich, ein TGS für ein Service-Account vom Domain Controller zu erhalten, so können Sie die Attraktivität dieser Ausbeute auf drei Arten verringern:

1. Verwenden Sie für Dienstkonten möglichst lange Kennwörter, um das Cracken des Hashs so aufwendig wie möglich zu machen. Da das Kennwort für Service-Accounts in der Regel nicht Zeichen für Zeichen eingetippt werden muss, sondern per Copy & Paste übertragen wird, kann es gern lang und komplex ausfallen.

2. Wechseln Sie die Kennwörter der Dienstkonten regelmäßig, um die Zeitspanne, in der das erbeutete Hash-Material überhaupt nutzbar ist, zu verkürzen. Ist die Lebensdauer der Kennwörter kürzer als die geschätzte Zeit, die für das Cracken der Hashes notwendig ist, so ist das Klartextkennwort theoretisch sicher. Für Dienste, die nicht zu 100 Prozent verfügbar sein müssen und einen gelegentlichen Neustart vertragen, können Sie das Kennwort mit einem Skript recht häufig neu setzen. Falls es von der jeweiligen Anwendung unterstützt wird, sollten Sie am besten zu gMSA greifen [5], die ihr Passwort automatisch ändern. Standardmäßig geschieht es alle 30 Tage, Sie können jedoch bei der Anlage eines gMSA – und nur zu diesem Zeitpunkt – die Dauerhaftigkeit des Kennworts auf einen anderen Wert festlegen.

3. Schränken Sie die Anmeldemöglichkeiten und die Berechtigungen der SPN-bewehrten Service-Accounts rigoros ein. Dienstkonten der SQL-Server sind oft mit Administratorrechten auf den jeweiligen Maschinen versehen, was für den Betrieb des SQL-Servers nicht erforderlich ist. Sehr oft sind Service-Accounts sogar Mitglied in hochprivilegierten Gruppen wie Domänen-Admins. Halten Sie sich bei der Rechtevergabe an das Least-Privilege-Prinzip.

Falls Sie am Perimeter Ihres Netzwerks Systeme einsetzen, die das Exfiltrieren von Daten erkennen und unterbinden, sollten Sie prüfen, ob dort Regeln möglich sind, die auf Servicetickets als Payload reagieren. Diese Möglichkeit ist allerdings nur als zusätzliche Sicherheitsmaßnahme zu verstehen. Gehen Sie davon aus, dass die Exfiltration vermutlich gelingen wird, denn die Tickets sind verhältnismäßig klein, sie lassen sich also in die meisten Exfiltrationsverfahren integrieren – DNS, OCSP, aber auch HTTP, FTP oder E-Mail.

Um die Anmeldefähigkeit eines Service-Accounts zu beschränken, haben Sie mehrere Möglichkeiten. Sie können ganz altmodisch zum "Anmelden an…"-Button in der AD-Benutzerverwaltung greifen, der dem "logonWorkstation"-Attribut entspricht. Sie können aber auch das Anmelden eines Dienstkontos mittels Gruppenrichtlinien verweigern. Die für reguläre User-Accounts so wirkungsvolle Multifaktor-Authentifizierung lässt sich bei Service-Accounts aus offensichtlichen Gründen nicht einsetzen. Die Anmeldebeschränkungen helfen auch gegen Overpass-the-Hash und Pass-the-Key, nicht jedoch gegen den klassischen Pass-the-Hash-Angriff, sollte das erbeutete Dienstkonto über Berechtigungen an Ressourcen verfügen, die noch NTLM akzeptieren.

In vielen Einsatzszenarien besteht außerdem eine sehr wirkungsvolle, in der Praxis jedoch nur sehr selten genutzte Möglichkeit, Kerberoasting gleich an der Quelle stark einzuschränken. Mithilfe von Authentifizierungsrichtlinien, die mit Windows Server 2012 R2 eingeführt wurden, können Sie vorgeben, welche Accounts grundsätzlich ein Serviceticket für einen bestimmten Service-Prinzipal anfordern dürfen und von welchen Computern aus dies zulässig ist. Wenn also beispielsweise in einer 3-Tier-Anwendung die Datenbank mit dem Account SVCSQL und die Anwendungsschicht mit dem Account SVCAPP ausgeführt wird, könnte das "Maximalprogramm gegen Kerberoasting" wie folgt aussehen:

- SVCSQL wird als gMSA erstellt, mit der Einschränkung, dass nur die tatsächlichen SQL-Server das Kennwort lesen dürfen.

- Dem Account SVCSQL wird eine Authentifizierungsrichtlinie zugewiesen, die das Anfordern von Servicetickets ausschließlich einer Gruppe namens "SQL Access" erlaubt, die das reguläre Dienstkonto SVCAPP und die Datenbankadministratoren beinhaltet. Die Ausstellung von Servicetickets wird außerdem nur für Anfragen erlaubt, die entweder von den Applikationsservern oder von den Admin-Workstations kommen.

- SVCAPP erhält Anmeldeeinschränkungen, sodass die Anmeldung mit diesem Konto ausschließlich von den Applikationsservern aus möglich ist.

- Beide Service-Accounts erhalten nur so viele Rechte, wie für die Ausführung von SQL beziehungsweise der Anwendungsschicht unbedingt erforderlich ist.

- Muss das Frontend der Anwendung nicht für jedermann in der Organisation, sondern nur für ganz bestimmte Benutzer und Clients verfügbar sein, lässt sich eine entsprechende Authentifizierungsrichtlinie auch auf das Konto SVCAPP anwenden.

Damit sind die Möglichkeiten, ein Serviceticket zum Kerberoasten zu erhalten, massiv eingeschränkt, und der Nutzen eines solchen Tickets aus Angreifersicht allenfalls fraglich. Achten Sie außerdem stets darauf, dass in Ihrer Umgebung nur Benutzer und Gruppen das Recht besitzen, das "servicePrincipalName"-Attribut zu beschreiben, die dieses auch tatsächlich benötigen, also im Zweifel nur die Tier-0-Administratoren. Andernfalls könnte ein Angreifer ein privilegiertes Konto, auf das er es abgesehen hat, für Kerberoasting verwundbar machen, indem er ihm einen SPN zuweist.

Sowohl das Beantragen des Servicetickets als auch die spätere Verwendung des – wenn auch gecrackten – Kennworts sind ganz normale Vorgänge im Active Directory, was das Aufdecken von Kerberoasting sehr schwierig macht. Die initiale Erkundung können Sie nur erkennen, indem Sie entweder ein sehr fortgeschrittenes AD-Monitoring verwenden, das die LDAP-Abfragen analysiert, oder die AD-Protokollierung so weit hochdrehen, dass jede LDAP-Abfrage mitgeschnitten wird, und die so entstehenden Ereignisprotokolle anschließend durchforsten. Der letztere Ansatz erfordert allerdings das Anheben der Protokollierung über "Debug" hinaus auf das "Field Engineering"-Niveau, was Unmengen an Logeinträgen verursacht und sich negativ auf die Performance Ihrer Domaincontroller auswirkt.

Viel interessanter für die Überwachung ist der Vorgang der Ticketanforderung. Bei aktivierter Überwachungsrichtlinie "Ticketvorgänge des Kerberos-Diensts überwachen: Erfolg" wird im Ereignisprotokoll "Sicherheit" des angesprochenen Domaincontrollers ein Event mit der ID 4769 generiert. Durch Auswertung dieser Ereignisse können Sie erkennen, dass beispielsweise ein User, der nichts mit dem angesprochenen Dienst zu tun haben sollte, ein Ticket für diesen Dienst angefordert und erhalten hat oder dass eine Verschlüsselung mit dem RC4-Hash zum Einsatz kam, obwohl alle Komponenten normalerweise auch AES unterstützen sollten. Auch eine überdurchschnittliche Häufigkeit von Serviceticket-Beantragungen durch ein und denselben Nutzer kann ein Hinweis auf Kerberoasting sein. Die Kodierung der im Ticket verwendeten Verschlüsselungstypen ist übrigens unter [6] dokumentiert. Sie unterscheidet sich von der im AD-Attribut "msDS-SupportedEncryptionTypes" benutzten Konvention.

Auch das Verwenden der erbeuteten Anmeldedaten lässt sich möglicherweise anhand der Audit-Ereignisse nachvollziehen. Genau wie bei der Beantragung des Tickets müssen Sie hier nach Anomalien suchen – Service-Accounts, die sich von Clientcomputern aus anmelden, Verwendung von RC4, Zugriff durch Dienstkonten auf Ressourcen, die nichts mit dem jeweiligen Dienst zu tun haben und Ähnliches. Ohne ein umfassendes "Security Information and Event Management" (SIEM) und Security-Administratoren, die mit der Such- und Filter-Engine der verwendeten SIEM-Umgebung sehr gut umgehen können, ist es ein nahezu aussichtsloses Unterfangen.

Eine weitere Möglichkeit, Kerberoasting frühzeitig aufzuspüren, ist ein Service-Account-Honeypot. Da der Angreifer ein echtes produktives Konto nicht auf den ersten Blick von einem extra angelegten Account ohne eine produktive Verwendung unterscheiden kann, wird er es bei seiner Erkundung entdecken und versuchen, es zu kerberoasten. Sie sollten allerdings mindestens einmal das Kennwort dieses Kontos ändern und danach eine Anmeldung damit durchführen, um es so aussehen zu lassen, als wäre es in der Vergangenheit benutzt worden. Halten Sie sich bei der Anlage des Honeypots an die in Ihrem AD geltenden Namenskonventionen. Setzen Sie bei diesem Konto ruhig auch adminCount=1, ohne es tatsächlich einer privilegierten Gruppe hinzuzufügen. Der Honeypot-Account kann auf zwei Arten auf Kerberoasting aufmerksam machen:

1. Event 4769 kennzeichnet die Ausstellung eines Servicetickets zum Kerberoasten – um dies festzustellen, müssen Sie allerdings den Security-Eventlog ständig überwachen.

2. Wenn Sie dem Honeypot-Account ein recht einfaches und kurzes Kennwort geben, wird das Kerberoasting gelingen, und der Angreifer wird das Konto zum Anmelden verwenden. Überwachen Sie also die auf die Anmeldung bezogenen Attribute des AD-Objektes ("lastLogon", "lastLogonTimestamp", "badPwdTime"), um die Verwendung dieses Kontos zu entdecken. Diese Überprüfung erfordert zwar deutlich weniger Aufwand als die logbasierte Überwachung, dennoch müssen Sie sie auf sämtlichen Domaincontrollern durchführen.

Im Fall von Kerberoasting ist es für Sie als Verteidiger einfacher, den Angriff unwirtschaftlich zu machen, als ihn durch Konfigurationen zu verhindern oder seine erfolgreiche Durchführung im Nachhinein zu entdecken. Daher sollten Sie die Verwendung herkömmlicher Service-Accounts einschränken und deren Rechte begrenzen, inklusive der Anmelderechte. Das Erzwingen der AES-Verschlüsselung und die Verwendung langer Kennwörter, die regelmäßig und am besten maschinell geändert werden, macht Kerberoasting für den Angreifer unattraktiv.