Next Gen Kerberoasting

Theory & Background

Kerberoasting is a type of attack targeting service accounts in Active Directory. In this blog, we would be bypassing one of the common mitigations suggested ie. Enabling AES Encryption rather than RC4 Encryption Mechanism. for Kerberoasting attack.

A long and complex password for a service account along with password rotation at regular intervals is one of the best ways for mitigating Kerberoasting Attack. Enabling AES Encryption will mitigate Kerberoasting attack?

“If we enforce service account to encrypt service ticket using AES256, the resulting ticket will not be cracked”. Enabling AES encryption is also listed in the MITRE ATT&CK technique and in the OWASP document

This can be said as Partially true.

Service Ticket Encryption

The Service Ticket Encryption level is determined by the value of the AD Attribute msDS-SupportedEncryptionTypes which is set in that Service Account and this attribute has different default values set on the machine account and user account. According to Microsoft’s [MS-ADA2], “The Key Distribution Center (KDC) uses this information [msDS-SupportedEncryptionTypes] while generating a service ticket for this account.” So even if a domain supports AES encryption (i.e. domain functional 2008 and above) the value of the msDS-SupportedEncryptionTypes field on the account with the requested SPN registered is what determines the encryption level for the service ticket returned in the Kerberoasting process.

Service Tickets for the machine account mostly use the AES 256 bit Encryption mechanism as this is the highest level of encryption that is mutually supported during the Kerberos ticket exchange. This is because of the default value for msDS-SupportedEncryptionTypes in Machine Account is 0x1C (RC4_HMAC_MD5 | AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96 = 28).

However, this is set only on the machine accounts. In case of SPN registered over the user accounts, if AES Encryption is not explicitly configured, the default value set over the account is 0x7 meaning RC4 will be used to encrypt the service ticket.

By setting “This account supports Kerberos AES 128/256 bit encryption” in Active Directory Users and Computers user properties, msDS-SupportedEncryptionTypes will be changed to 0x18 (AES128_CTS_HMAC_SHA1_96 | AES256_CTS_HMAC_SHA1_96), which means this user account supports AES encryption only.

Abuse

We can retrieve the Service Tickets encrypted using RC4 Encryption for these accounts which are in turn easily crack-able.This is done by constructing SSPI/GSS-API for Kerberos authentication to get a usable TGT, then use this TGT to perform TGS-REQ and specify the encryption algorithm (RC4).

This is achieved by requesting a “fake” delegation for the CIFS service on the Domain Controller. The DC, which has unconstrained delegation enabled by default, is granted complete use of the client’s identity. Thus, a forwarded TGT will be returned by the Ticket Granting Service. With this new TGT, we can request a service ticket for the target SPN and specify RC4 as the only supported encryption method.

My Lab environment for this lab is:

  1. redwolf-dc - Domain Controller (Windows Server 2019)

  2. flab-dc.flab.redwolf.local - Domain Controller for the forest flab.redwolf.local (Windows Server 2016)

  3. svc_web@flab.redwolf.local - Service Account which as SPN value set to: (HTTP/websvr, HTTP/websvr.flab.redwolf.local)

  4. websvc@redwolf.local - Service Account which as SPN value set to : (HTTP/sqlsvr, HTTP/sqlsvr.redwolf.local)

Enumerating User Accounts that has SPN

Get-DomainUser -SPN

Retrieving ST - AES Encrypted Tickets

Retrieving the Service Tickets using Rubeus

.\Rubeus.exe kerberoast /nowrap

Cracking the captured ticket

hashcat -m 19700 hash.txt /home/kali/Wordlist/rockyou.txt

I could not crack the hash, it is still running in my VM. I will update once it is cracked along with the time taken. That's the reason why AES enabled service accounts (that only supports AES) cannot be kerberoasted.

Retrieving ST - RC4 Encrypted Tickets

Retrieving the Service Tickets using Rubeus through specifying RC4 as the only supported encryption mechanism.

.\Rubeus.exe kerberoast /usetgtdeleg /nowrap

Cracking the captured ticket

hashcat -m 13100 hash.txt /home/kali/Wordlist/rockyou.txt

Note: This method of retrieving RC4 Encrypted ST is only suitable for Domain Controllers whose version is previous to Windows Server 2019. I have highlighted this under Service Ticket Encryption section.

Things work differently on Windows Server 2019 Domain Controller. It simply returns the service ticket encrypted by the highest level encryption key supported by the service account, no matter what level of encryption key that the client claims to support or what encryption type is in client’s msDS-SupportedEncryptionTypes attribute.

Tried to retrieve the RC4 encrypted ST through the sameway as we did with DC in previous example (Windows Server 2016)

References

Last updated