Kerberoasting attack detection

Welcome to part one of a special series on detecting Active Directory attacks & misconfigurations. Each blog post dives deep into identifying, detecting, and mitigating a dangerous AD vulnerability. 

And the best part? 

You’ll get a free AD-focused Sherlock to practice the defensive techniques you learn!

The attack methods and misconfigurations we cover will include:

• Kerberoasting (part one)

• AS-REP Roasting (part two)

• LLMNR poisoning (part three)

• NTLM relay (part four)

• NTDS dumping (part five) 

Let’s get started! 

Why you should prioritize Active Directory misconfigurations 

There is no "one-size-fits-all" solution for configuring Active Directory out of the box because no organization has the same structure. 

Due to extensive configurations that depend on the complexity of a corporate environment, administrators often struggle to securely configure Microsoft Active Directory.

Unauthorized access to the AD environment enables attackers to steal sensitive data, disrupt crucial services, and ultimately gain full control over the organization's network, essentially obtaining the "keys to the kingdom." 

So cybersecurity professionals and administrators need to become familiar with how AD operates. Blue team members must be able to identify misconfigurations and attacks, and red team members must understand them to effectively audit these environments.

In this series, we will go over five common misconfigurations (and attacks) that can be found when auditing AD environments; each one can lead to severe consequences when exploited by malicious actors:

1. Kerberoasting

2. AS-REP Roasting

3. LLMNR and NBT-NS poisoning

4. NTLM Relay

5. NTDS.dit dumping

Kerberos & Active Directory 

Active Directory uses the Kerberos protocol to allow users to authenticate on the network and then access services.

With Kerberos, when a user accesses a resource hosted by a Service Principal Name (SPN), a service ticket (ST) is generated by the domain controller and encrypted with that SPN password hash. The application server then decrypts and validates the ST.

When the request for the service ticket is initiated from the domain controller itself, there is no validation to ensure that the user has the necessary permissions to access the resource hosted by the SPN.

Here is where things get interesting: If attackers know the service, as in the SPN they want to target, they can perform an ST request for it from the Domain Controller getting back an ST encrypted with the SPN's password hash.

The attacker may use Impacket’s GetUserSPNs tool, which is often used to perform Kerberoasting attacks.

With that hash, they can go on and try to brute-force it offline to obtain the cleartext password of that service account. 

Bam! There you go, this is Kerberoasting.

💡Note: Keberoasting is mapped to the sub-technique T1558.003 on the MITRE ATT&CK framework. Read our detailed (and visual) Kerberos authentication guide for a friendly intro to the world of Kerberos. 

Kerberos attack detection & forensic analysis 🔍

In this section, we will talk about how to detect Kerberoasting activity using domain controller logs. 

As previously mentioned, Kerberoasting activity is not anything out of the ordinary, it's just regular Kerberos operations in a domain environment, except these exploit a vulnerability. 

This makes it harder to detect as in corporate environments there are thousands of Kerberos events going on per minute. However, we can still find the needle in the haystack if we know what to look for.

 

Sniffing Security Logs & events 🔍

We will go over Security Logs from a domain controller to go through detection and what kind of telemetry we get as an aftermath of a Kerberoasting attack.

As we’ve already learned, Security Logs record Event ID 4769 on a domain controller whenever a Kerberos service ticket is requested. Depending on the Active directory size and assets, this may be thousands of tickets per minute, and it is normal behavior. 

For example, if a user accessed a file share, a service ticket would be requested by that user from the domain controller to access the service. 

Since there are thousands and thousands of events occurring at a time, detecting this attack gets more difficult because it “blends in” with normal activity.

Let's open up Security Logs in Event Viewer.

We see lots of different Events, some related to Kerberos as well. To detect potential Kerberoasting activity, let’s filter down for event ID 4769.

There are still many events. Let's view one to understand its fields.

Here we can see that Account Name “DC01$” requested a service ticket for service named DC01$. In Windows names ending with $ are typically service accounts and machine accounts. Similarly, the DC01$ service is related to that service account.

This all belongs to normal Active Directory operations. Below that we can see an option named “Ticket Encryption type” with the value of 0x12 which equals to “AES256-CTS-HMAC-SHA1-96 ”. 

In legitimate use cases for Kerberos ticket operations, the encryption type would be 0x12 or 0x11. 

But if we see an encryption type “0x17”  which is RC4 encryption, that would be a clue to look into this further, as an attacker may request a ticket in this encryption type because it allows them to crack the password. 

Note💡: All major open-source tools, like Impacket and Rubeus, request tickets in RC4 encryption type. 

To further reduce the chances of false positives, we can filter out requests from other service accounts and machine accounts. 

Service accounts request service tickets from domain controllers all the time; that’s the nature of how service accounts work. To further reduce the events to investigate, we can filter out requests from service names starting with “$”—they are computer accounts. 

SOC analysts can query the logs in SIEMs to create a filter for all the things mentioned.

With the filters discussed above we’re snooping for a 4769 event where:

1. Account name that is NOT a service or machine account (ending with $), so any normal domain user account (this would be the account which is compromised and from which the attacker performed this attack.)

2. Service Names that do NOT end with $.

3. Ticket encryption type will be 0x17 which is RC4 encryption, allowing attackers to easily crack the hash.

Now, let's use those criteria to spot the actual event that was the result of a Kerberoasting attack:

This event fulfills all the conditions we set that indicate Kerberoasting attack activity. 

We can see that a domain Account “alonzo.spire” requested a ticket for a service name “MSSQLService” with an encryption type of 0x17 from a workstation with IP Address 172.17.79.129.

Notice that both the account name and service name do not end with $. 

The follow-up to this detection would be to:

1. Create a timeline of when this event was generated.

2. Do a forensic analysis of the machine with IP Address 172.17.79.129, and find out how the “alonzo.spire” user account got compromised. 

3. We can use artifacts like Process Logs from Sysmon if available, prefetch, lnk files, Managed File Transfer (MFT), or registry to gain insights on what occurred around the time when Kerberoasting activity was noticed.

Analyzing endpoint artifacts 🔍

Let's expand a little bit more and explore the source endpoint artifacts from where the attack was conducted (172.17.79.129 workstation). We will analyze prefetch files and PowerShell logs.

PowerShell 

Starting with PowerShell logs, we can see executed commands/scripts by filtering for event ID 4104.

Timestamps show 08:16, which is in my local time. Converting this in UTC, the time is 03:16 which is just two minutes before our Kerberoasting activity. Looking at the first event we see a PowerShell script execution bypass being performed.

This enables scripts to be executed in a PowerShell session. The follow-up events occurred all at the same time, which could be part of a single script, as the PowerShell script block records the full script being executed.

We find evidence that this is PowerView.ps1 script, which is an offensive PowerShell script used for AD enumeration and is used in post-exploitation activities. 

Attackers can use this to find any Kerberoastable accounts.

Prefetch files

Now let's pivot to prefetch files. We will use PECmd by Eric Zimmerman to parse the prefetch files and event viewer to go through the event logs.

We used PECmd to parse the provided prefetch files and save them in the current directory with the name analysis.csv:

PECmd.exe -d "path-to-prefetch-files" --csv . --csvf outputfilename.csv

Analyzing the CSV file with Timeline Explorer, we’ll need to look for any exe execution around the timeline we have established. First, filter for the date of the incident:

Looking at the last run timestamps, we find an exe was executed just a second before our malicious events were logged on the Domain Controller.

We see that this is a Kerberos abuse tool. One that's common in Active Directory pentesting or offensive operations. 

Kerberoasting detection in Splunk

Let's see an example of this in Splunk SIEM.

Query: 

Event.EventData.TicketEncryptionType="0x17" Event.System.EventID="4769" Event.EventData.ServiceName!="*$" | table Event.EventData.ServiceName,Event.EventData.TargetUserName,Event.EventData.IpAddress

Remediation

To prevent these attacks, it's imperative to use long passwords and complex passwords with at least 25 characters for service accounts. This will significantly slow down when trying to crack the hashes.

For privileged services, consider using Group Managed Service Accounts (GMSA) to ensure that passwords are long, complex, and changed frequently.

Implementing Privileged Access Management (PAM) may also help limit the exposure of privileged credentials and reduce the attack surface for Kerberoasting while enabling monitoring for all changes to security group permissions.