Kerberoasting – Active Directory Attack

Active Directory services are usually used by organizations for easily configuring policies and managing permissions. Due to its widespread usage, adversaries often target misconfigured AD services using different attacks.

Kerberoasting is one of the most common attacks against domain controllers which can be effective for extracting service account credentials from Active Directory as a regular user without sending any packets to the target system. In this blog, we will focus on details of kerberoasting as well as techniques for detecting and remediating it.

Working of Kerberoasting Attack

Like most attacks against Active Directory, Kerberoasting enables privilege escalation and lateral network movement. Hence, it is used by attackers once they are established inside an enterprise network and have begun reconnaissance. Kerberoasting allows attackers, to extract password hashes for the target’s active directory user accounts through their Service Principal Name (SPN) ticket. It works by impersonating non-privileged domain users with preset SPN attributes to request service-related TGS tickets from memory in an attempt to crack the associated NTLM hashes of the plaintext passwords linked to that particular service account. Service accounts are primarily targeted because they can let an attacker add an arbitrary user to the group of administrators for that service after a successful takeover.

Kerberoasting attacks are possible because of vulnerability in the architecture of Kerberos and insecure user behavior. Several tools are currently available to enumerate the Service Principal Name (SPNs) of service accounts through crafted LDAP queries.

Stages of Kerberoasting Attack

1. Enumerate ServicePrincipalNames:
   The attacker needs to conduct internal reconnaissance to find specific service accounts with the privileges they desire. Hence, The attacker enumerates the servicePrincipalNames (SPNs) for the service accounts being targeted eg. MSSQL.
2. Request TGS tickets:
   Attacker request Ticket-Granting Service (TGS) Tickets for the successfully extracted service account Service Principal Names (SPNs) and the AD domain controller responds with a ticket for the service account with the requested services.
3. Extract the password hashes:
   The response ticket contents would be cached in memory. Subsequently, the attacker can extract and dump these hashes from the memory and later crack it offline using common password cracking tools.
4. Privilege Escalation:
   Finally, the attacker can log in to the service account using the cracked password, compromise data, and/or escalate privileges.

Detection of Kerberoasting Attacks

It is possible to detect several aspects of Kerberoasting by monitoring the Windows event log ( 4769 and 4770) for anomalous ticket-granting service (TGS) requests.

1. Monitor for Abnormal volume of TGS requests: attackers running Kerberoasting tools with default configuration options may trigger a large number of TGS requests than normally observed for a given user.
2. Monitor usage of RC4 ticket requests: As RC4 is considered a weak encryption algorithm, an adversary may attempt to explicitly request RC4 for this purpose.

Remediation of Kerberoasting Attacks

1. 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 (MITRE ID: M1041).
2. Restrict domain admin accounts from being used as service accounts (MITRE ID: M1026).
3. Adopt complex passwords and other credentials best practices that make the brute-forcing process significantly more time-consuming against the standard wordlist (MITRE ID: M1027).
4. Ensure the passwords for service accounts are changed on a regular basis.

Respond to Kerberoasting Attacks

1. Start the incident response procedure and notify the incident response team.
2. Place any implicated computers (for example, the host that requested service tickets) in quarantine for forensic investigation, eradication, and recovery activities.
3. Reset the password for the user account responsible for Kerberoasting.
4. Privilege accounts should be prioritized.