Kerberoasting detected in Microsoft Defender for Identity (v2.131)
Basic authentication makes use of a (cleartext) username and password pair.
NTLM authentication is an encrypted challenge/response scheme including the hash of the password.
Kerberos (most secure) is a network authentication protocol using tickets to prove the identity to communicate over the (non-secure) network.
TGT = Ticket Granting Ticket
KDC = Key Distribution Center
AS = Authentication Server
TGS = Ticket Granting Service
Setup
The requirement(s) for the Kerberoasting lab is an Active Directory (Kerberos KDC = AS + TGS) and a computer or (service) account. A service account (user) will be used in the attack example. Create a user account in Active Directory (password never expires) and set the servicePrincipalName attribute (Adsiedit.msc or ‘dsa.msc -> advanced features -> attribute editor’) value to MSSQLService/DB1.domain.local (example).
Search all Service Principal Name(s) in Active Directory via
Setspn -Q */*
And create a ticket in memory for the user we created.
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList “MSSQLService/DB1.vuln.local”
Verify the cached Kerberos ticket via klist
Kerberoasting
The ticket is encrypted with the Service Principal Name password hash. Kerberoasting is an attack method to access the ticket from memory and decrypt the ticket using brute force password cracking techniques. Although there are many methods. I will use 2 methods (the goal is not the Kerberoasting attack but to verify the detection via Microsoft Defender for Identity).
Method 1 — Rubeus
Rubeus is a C# tool for raw Kerberos interaction and abuses.
Rubeus.exe kerberoast /outfile:hash.txt
stores the hash value to file (for later cracking)
Method 2 — Invoke-kerberoast.ps1
Invoke-kerberoast.ps1 is a PowerShell cmdlet for kerberoast-able accounts and returns the extracted hash.
Method 3 — MimiKatz & Tgsrepcrack.py
An other method that can be used is MimiKatz (kerberos::list /export), save to .kirbi file which can be used with tgsrepcrack.py or kirbi2john.py.
Crack the hash
Now that we have the hash, we can brute force (Kali Linux) the hash via ‘john the ripper’ or hashcat for example.
hashcat -m 13100 --force -a 0 hash.txt password.lst
We found the password 😊 of the service account.
Pro-tip: use least-privilege and change the password on a regular basis. Often service accounts are domain admin (that always works 😊) and the password is never changed.
Microsoft Defender for Identity
Microsoft Defender for Identity (previously called Azure ATP) is a Security detection tool to detect anomalies (attacks) on the Active Directory.
The attack kill chain phases
- Reconnaissance (scanning the domain)
- Compromised credentials
- Lateral movement (https://medium.com/@derkvanderwoude/microsoft-defender-for-identity-lateral-movement-b55046c09870)
- Domain Dominance (game over)
Version 2.131 (verify via the Sensors) can detect Kerberoasting.
Defender for Identity’s Suspected Kerberos SPN exposure (external ID 2410) security alert is available in version 2.131. In this detection, a Defender for Identity security alert is triggered when an attacker enumerates service accounts and their respective SPNs, and then requests Kerberos TGS tickets for the services. The attackers intent may be to extract the hashes from the tickets and save them for later use in offline brute force attacks. For more information, see Kerberos SPN exposure
All three Kerberoasting methods are detected by Microsoft Defender for Identity.
Microsoft 365 Defender
Microsoft 365 Defender, the XDR (eXtended Detection and Respond) solution from Microsoft detected the cross-source incident and correlated the alerts (Microsoft Defender for Identity and Microsoft Defender for Endpoint) relating to the Kerberoasting attack for an easy RCA (root cause analysis).
I hope this blogs helps in basic understanding of Kerberoasting and how to protect (detect) via Microsoft Defender for Identity and Microsoft 365 Defender.
