16 hours or less, that’s all it takes for attackers to gain access to Microsoft Active Directory (AD) and unleash mayhem on your organization. If that attack happens on a Friday afternoon, they have all weekend to wreak havoc, escalating their privileges, deploying ransomware, exploiting your VPN, or exfiltrating your data. And once they’re in, they have access to virtually every account on every machine to do their bidding.

Worse yet, with AD’s 24% market share, that means nearly 75,0000 customers could be at risk and no business sector is immune. Couple that with AD’s broad integration with a variety of protocols attackers can further leverage, plus challenge of misconfigurations leading to excessively generous permissions, weak passwords and haphazard patching, and it’s no wonder AD attacks are on the rise.

Even the most well-funded companies like Schneider Electric, EquiLend, Capital Health, London Drugs, Hewlett-Packard—and even Microsoft itself—have recently found themselves in the AD attack crosshairs.

But you don’t have to be a victim. While Microsoft works overtime to keep up with exploits against its authentication directory service, understanding the factors that make AD a prime target and how to spot anomalies can give you an advantage in protecting your organization from losing the proverbial “keys to the kingdom.”

In our latest technical blog series, our Digital Forensics and Incident Response (DFIR) team will run through the most prominent AD threats, describing the tell-tale signs that your AD might be at risk, and give experienced insight into the best prevention and mitigation strategies to shore up your AD security and bolster your digital identity protection.

Up first, let’s break out the pitchforks and dive deep into the nefarious world of kerberoasting…

Definition:

Kerberoasting is an attack technique used to steal the hashed passwords of service accounts in Active Directory (AD) environments. These attacks target the Kerberos authentication protocol used in many organizations.

How the attack works:

Service Principal Names (SPNs): Kerberos uses Service Principal Names (SPNs) to identify service accounts running on servers (like SQL services, web services, etc.). Each SPN is tied to a specific service account and can be requested by any user in the domain.
Requesting a Ticket-Granting Service (TGS) Ticket: Attackers who have access to the domain (even with regular user privileges) can request a Ticket Granting Service (TGS) ticket for any service using its SPN. This ticket is encrypted with the password hash of the service account.
Extracting the Ticket: Once the attacker receives the encrypted TGS ticket, they can dump it from memory or the Kerberos ticket cache. Since the ticket is encrypted using the service account's password hash, the attacker does not yet have the password.
Cracking the Hash: The attacker then performs an offline brute-force or dictionary attack against the encrypted ticket to recover the clear-text password of the service account. This step relies on the strength of the service account's password and the encryption method used. Offline cracking allows the attacker to minimize the noise of failed logins attempts, making the attack difficult to detect, this can be done with some of the following tools: John-the-Ripper, Hashcat, tgsrepcrack.py, etc.
Gaining Access: Once the password is cracked, the attacker can use the service account credentials to access the network with the same privileges as that account. Since service accounts often have elevated privileges, this can allow lateral movement and further compromise within the environment.

Important considerations:

If the request for the service ticket (ST) is initiated from a domain controller hosting the Active Directory itself, there is no validation to ensure that the user has the necessary permissions to access the resource hosted by the SPN.

If attackers know the SPN they want to target, they can perform an ST request for it from a Domain Controller which returns a ST encrypted with the SPN's password hash. This action can be done requesting the ticket directly from memory (making it harder to detect) or by several tools, including: Impacket’s GetUserSPNs, Rubeus; PowerSploit (Invoke-Kerberoast), Powerview, Empire, etc.

This attack is mapped as T1558.003 on Mitre ATT&CK. Credential Access (T1558) Kerberoasting (003) https://attack.mitre.org/techniques/T1558/003/.

Detecting & Hunting for Kerberoasting

While watching for indicators of malicious activity it is important to remember that a service ticket request is a legitimate activity and none of the indicators that are going to be mentioned by itself are malicious, they need to be treated as suspicious indicators and investigated further to confirm the activity.

In Windows Security event logs (C:\Windows\System32\winevt\Logs\Security.evtx) a Kerberos service ticket request generates an event with the ID 4769 on a Domain Controller.

Event ID 4769 is typically logged many times on the domain. Following initial logon (and Kerberos TGT ticket request), a user requires a Kerberos TGS service ticket to access services on the network (file shares, SQL, SharePoint, etc).

Generally, there will be around 10 to 20 Kerberos TGS requests per user every day. The 4769 event on Domain Controllers is often noisy in respect of logging which is why it’s often not logged.

Once the events are filtered by number they can be reviewed to highlight indications of malicious activity, such as:

Ticket Encryption Type: 0x17: for legitimate requests the encryption types are 0x11 (AES128-CTS-HMAC-SHA1-96) and 0x12 (AES256-CTS-HMAC-SHA1-96), for the purpose of easing the cracking of the hash, attacking tools request the ticket with encryption type 0x17 (RC4-HMAC), which is a legacy and weaker encryption protocol.
Account name: usually the legitimate service ticket requests are from machines accounts, and every machine account ends with $. For this attack to be possible a valid AD account with credentials is required, and in most cases, these are from users (which do not have an $ on the account name). There are also legitimate requests from user accounts for service tickets, so this has to be carefully inspected, especially if the same account is requesting several service tickets for different services in a short period of time.
Number of requests by an account in a short timeframe.
Service Name: normal events typically end with a $ or are named "krbtgt".

Another event that we can look for to hunt for these attacks is Security Event ID 4768 (A Kerberos authentication ticket (TGT) was requested) this is generated on domain controllers when a ticket was requested. Most of the information contained in this event is very similar to the information on Event ID 4769. It’s fundamental to remember that Security Event IDs 4768 & 4769 are not enabled by default on Windows auditing.

Windows Security Log Event ID 4769 - A Kerberos service ticket was requested.

Example:

Event 4769 illustration

Windows Security Log Event ID 4768 - A Kerberos authentication ticket (TGT) was requested.

Example:

Event 4768 illustration.

Preventing Kerberoasting attacks

Kerberoasting relies on cracking offline user passwords, in this case the hash is not useful without being decrypted, so the most effective measure for preventing these attacks is the implementation of a strong corporate password policy. Additionally, the following recommendations would help to prevent and mitigate the effectiveness of kerberoasting:

Minimize privileges for service accounts. These accounts should only have the permissions necessary to perform their tasks. Avoid assigning them excessive privileges, such as Domain Admin or high-level permissions.
Service account passwords should be long and complex (at least 25 characters). This makes brute-forcing the password hash from a Kerberoasting attack significantly more difficult. Regularly rotate service account passwords to reduce exposure time, especially for sensitive accounts and consider where possible the use of Group-managed service accounts (gMSAs).
Review and audit service accounts for unnecessary or stale SPNs. Only accounts that require Kerberos authentication should have SPNs registered.
Configure Kerberos to enforce stronger encryption methods like AES256 instead of weaker RC4 encryption, which is more susceptible to offline cracking. Ensure that service accounts and domain controllers support and use AES encryption for Kerberos tickets. This can be configured by applying a Group Policy.
Apply the "Protected Users" Group: The Protected Users security group prevents accounts from using weak encryption for Kerberos authentication and disables NTLM authentication. Add high-value accounts to this group to mitigate the risk of Kerberoasting and other credential-based attacks.
Kerberoasting attacks are often used to escalate privileges by compromising service accounts that have delegation rights. Restrict service account delegation unless it is absolutely necessary. Use "Constrained Delegation" or "Resource-based Constrained Delegation" wherever possible instead of unconstrained delegation, which is more vulnerable to abuse.

Conclusions

Understanding how Kerberos works is key to spotting gaps that attackers can exploit with Kerberoasting.

To reduce this risk, organizations must prioritize the hardening of service accounts by enforcing strong password policies and limiting privileges. Implementing advanced threat detection and logging solutions plays a critical role in early identification of Kerberoasting activity. Additionally, the adoption of modern encryption standards for Kerberos tickets, such as AES, significantly mitigates the effectiveness of these attacks.

As adversaries continue to evolve their methods, security teams must stay proactive by applying comprehensive defense-in-depth strategies that combine prevention and detection. Regular audits, patch management, and security awareness training are vital for reducing the risks associated with Kerberoasting and maintaining robust security postures If you think you may be experiencing an attack, contact our Emergency Incident Response for immediate support by visiting our homepage for your local hotline number.

Learn more about the following services to help you proactively prepare against Active Directory attacks:

Sign up to our free Threat Intelligence for regular updates on the latest threat actors or contact NCC Group if you have any further queries.