Insights on Kerberos Attacks
Dogs are playful so are the Kerberos. This attribution to 3 headed-dog is from Greek Mythology which was known for guarding the gates of Hades. Similarly, Kerberos protocol in other hand was built in 1980s keeping in mind to secure the resources in the networked environment.
While Kerberos is considered as secure authentication protocol over NTLM because of its way of exchanging the tickets and authorizing the subjects, yet Kerberos authentication cannot be considered as bullet proof when it is configured insecurely. However, perpetrators have somehow managed to execute successful attacks by finding it’s weakness and were able to take complete control of Crown jewels of the organization. APTs have been seen constantly exploiting this Kerberos protocol over globally in which some of the APTs include APT29, APT 32, Ke3chang are focused in Pass the Ticket attacks (T1097). Below are the few examples of generic Kerberos attacks.
- AS-REP Roasting
- Kerberoasting
- Pass The Key (PKK)
- Pass The Ticket (PTT)
- Silver Ticket (forged Kerberos TGSs)
- Golden Ticket (forged Kerberos TGTs)
- Kerberos Brute forcing
- DC Shadow attack
- PAC Attacks — MS14–068
- Skeleton Key Malware
The objective of this blog it to show the demonstration of Kerberos attacks on the simulated Domain Controllers. I came across this lab setup while solving some CTFs and noticed there are couple of DCs in the lab environment and identified it is vulnerable to above mentioned common attacks.
Before moving ahead, let us quickly brush up the basics of Kerberos authorization process. I will not explain in detail as there are already good posts here — 1, 2 and 3 but I will highlight where exactly ‘un’ethical attacker is interested to apply their offensive skills for the successful exploitation.
Background: How Kerberos Works?
Server Terminology and Brief Description:
- KDC — Key Distribution Center
- AS — Authentication Service
- TGS — Ticket Granting Service
Tickets Terminologies and Brief Description:
- AS REQ — Authentication Service Request : Purpose of this request is for user identification and hold temporary TGTs for future authentication instead of entering password every time user wants to access.
- AS REP — Authentication Service Reply: AS validates the AS-REQ and shares the TGT
- TGS REQ — Ticket Granting Server Request: User submits the TGT to TGS and request the access to target resources.
- TGS REP — Ticket Granting Server Reply: TGS verifies the TGS REQ and grants Service Tickets.
- AP REQ — Authentication Protocol Request: User shares the TGS to target resources by initiating the AP REQ and access it.
- AP REP — Authentication Protocol Reply: This is optional and used when mutual authentication is required.
Demonstration:
AS-REP Roasting
This attack works when accounts are not set with Kerberos pre-authentication feature. When this feature is disabled on accounts, attacker can easily request encrypted information from Domain Controller and crack the password offline. These attacks generally won’t work so easily because this feature will be enabled by default in modern windows environments. But still, it’s worth a shot to look around as sometimes it will be disabled due to some reasons like misconfigurations or backward compatibility etc.,
As highlighted in the above, when Pre-auth is disabled for particular users, we can request TGT from AS without any password and we can see Authentication server happily gives TGT right away!
Boom!! We got TGTs without passwords. How cool is that!
To perform AS-REP Roast, Impacket tool is preferred to get the hashes. Once the hashes are collected, it can be cracked offline using John or Hashcat.
Kerberoasting
Kerberoasting is well preferred method to extract the service account credentials from DC without sending single packet to target resources. Generally, service accounts are set with highest permissions by server administrations and set passwords not to expire. So, it is shortcut method to identify and compromise that specific service accounts to leverage higher permissions inside Active Directory environment.
Practically, Kerberoasting requires requesting Kerberos TGS service tickets with RC4 encryption with valid domain user accounts. Compromised valid domain user accounts can be used for this activity. It is possible to scan for existing Service Principal Names (SPNs) in DC and requests TGS for those target accounts. By presenting the valid TGTs to AS, TGS of the target’s accounts can be retrieved and obtained hashes can be cracked offline.
For this demonstration, I have used Impacket tool to harvest Service Principal Name (SPN) where in it is possible to request TGS of the target service and tickets can be stored locally by giving “–outputfile” arguments in the command. Then use john or hashcat for offline cracking.
Now the important question strikes in our mind is — CAN WE DETECT KERBEROASTING?
The short ANSWER is YES → But the events are too noisy, and one should be very choosy while forwarding the events to SIEM to avoid flooding since users requests TGS very often in the network for accessing the IT resources.
But the spotlight is when user initiates TGS-REQ packets with RC4 encryption - More preferably, it’s a RED FLAG unless some specific resources uses RC4.
To investigate further, SIEM should be able to collect and parse “Audit Kerberos Service Ticket Operations” logs from the Servers and looks for the below specific fields –
- Event ID: 4769 “A Kerberos service ticket was requested”
2. Ticket Options: 0x40810000
3. Ticket Encryption: 0x17 i.e → RC4-HMAC
Detailed post can be found here.
Happy Purple Teaming!
PRO-TIP: Switch to Z-Shell a.k.a ZSH from Bash. It is fun! 😀
