Blog Post

Kerberoasting – Threat Hunting for Active Directory Attacks

Organizations rely on Active Directory (AD) services to make policy configurations, user management, and permissions easy to manage. However, this also makes AD a primary target for adversaries, given it is often the key to the kingdom. Kerberoasting is one of the most common attacks against domain controllers. It is used to crack a Kerberos (encrypted password) hash using brute force techniques. If successful, it can crack NTLM hashes in a few hours and provide the adversary with a clear-text password which can then be used to progress further with attacks like Silver Tickets, etc. In this blog post, we discuss the details of Kerberoasting as well as techniques to perform threat hunting for attackers using this technique on your network.

Technical Details

During Kerberoasting, the adversary attempts to extract password hashes for the target’s active directory user accounts through their Service Principal Name (SPN) ticket. Adversaries primarily target service accounts, since a successful takeover of such an account can let an adversary add an arbitrary user to the group of administrators for that service e.g. MSSQL DB.

 

During this attack, an adversary attempts to enumerate the Service Principal Name (SPNs) of service accounts through crafted LDAP queries using several red teaming utilities such as GetUserSPNs.ps1, Invoke-Kerberoast.ps1, etc. Such tools make the Kerberoasting process easier, as they take care of subsequent attack phases in an automated fashion.

Kerberoasting Attack Stages

Kerberoasting is a well-documented attack technique (MITRE ATT&CK T1558.003) and there are many existing articles mentioned in the reference section that explains each attack step in more detail. At a high level, this attack can be broken down into the following steps:

  1. Enumerate Service Principal Names (SPNs) of AD service accounts e.g. MSSQL, IIS web services, etc. Figure 1 shows the LDAP request sent to the domain controller to pull out the SPN names.

Figure 1. Service AccountSPN Enumeration via LDAP
  1. Request Ticket-Granting Service (TGS) Tickets for the extracted service account Service Principal Names (SPNs). The credential hashes are now stored in memory. A TGS validates the use of a ticket for a specified purpose, such as network service access. More information on TGS and tickets can be found here. Figure 2 shows how the TGS-REQ is sent to the domain controller to retrieve the ticket for the user-extracted SPN value.

Figure 2: Client sending TGS request to request for service tickets
  1. As a result of the above Kerberos TGS request, the AD domain controller responds back with a ticket for the service account with the requested services. Figure 3 shows the TGS-REP response received from the domain controller.

Figure 3: TGS-REP from the domain controller
  1. The above-demonstrated ticket contents would be cached in memory. Subsequently, the adversary can extract and dump these hashes from memory using tools like Mimikatz or others as a flat kirbi document.
  2. To decrypt these hashes, the adversary can use several offline passwords cracking utilities such as hashcat, john, tgsrepcrack.py that will brute force passwords using wordlists. This process can be done outside the victim’s environment using powerful Graphics Processing Unit (GPU) resources or a cloud-environment to lower the time required for the overall password decryption process.
  3. Finally, the adversary tries to log in to the service account using the brute-forced password, compromise data, and/or escalate privileges.

Threat Hunting and Detecting Kerberoasting with Awake

Kerberoasting attacks can be very difficult to detect on the network since most of the activities described above involve only local command executions. However, there are a few network-based heuristics that help detect the pre-exploitation phase of this attack:

  • In general, common kerberoasting tools request the weak RC4 encryption type (Figure 2) to initiate the TGS-REQ requests. Algorithms such as RC4 are inherently weak and easy to crack through available password cracking utilities. This is especially true when compared to other encryption algorithms such as AES-128 or AES-256.
  • The Active Directory domain controller server will respond to the above requests by using weak encryption algorithms such as RC4 (Figure 3) when responding with a TGS-REP.
  • Unlike normal AD traffic, when Kerberoasting is active in an environment, threat hunters will observe an abnormal number of TGS-REQ and TGS-REP requests/responses.

To detect these pre-exploitation techniques, the Awake Security Platform provides an abstraction layer to parse LDAP searchRequest messages and Kerberos protocol data. This helps an analyst identify the Kerberos TGS-REQ and TGS-REP communications, correlate the LDAP and Kerberos based protocol data individually between the two endpoints, conduct frequency analysis to identify suspicious behaviors. The Awake Security Platform co-relates the set of events based on the observed sequences of SPNs enumeration and usage of the weak encryption algorithms during the TGS-REQ and TGS-REP negotiation.

And when the Awake platform identifies such suspicious behavior on the network (similar to MITRE ATT&CK ID: T1558.003), it creates a graphical representation of the attack as shown in Figure 4, demonstrating that a Windows device attempted to access the organization’s domain controller in an attempt to perform Kerberoasting.

Figure 4: Awake Situation for Kerberoasting Attack

Remediation

It is highly recommended to:

  • Restrict the usage of insecure algorithms like RC4 in Kerberos and especially for service accounts. Instead, configure service accounts to negotiate using AES-128 and AES-256 encryption algorithms only.
  • Restrict domain admin accounts from being used as service accounts.
  • Adopt complex passwords and other credentials best practices that make the brute-forcing process significantly more time-consuming against the standard wordlist.
  • Ensure the passwords for service accounts are changed on a regular basis.

References

 

Sujit Ghosal
Sujit Ghosal

Sr. Threat Researcher