5 Active Directory misconfigurations (& how they’re exploited)

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 post we cover five 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

Kerberoasting 

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. 

AS-REP Roasting

When authentication occurs within Kerberos, the first thing that happens is an authentication request to the domain controller so the identity trying to authenticate can be verified. 

That request is known as Authentication Server Request (AS-REQ.) 

This process is commonly referred to as Kerberos preauthentication.

After the client’s authentication is validated, the domain controller sends an Authentication Server Reply (AS-REP) to the client, containing a session key and a Ticket Granting Ticket (TGT).

The session key is encrypted using the user’s password hash so that only that user can decrypt and reuse it.

Now check this out! Users within the domain can be configured to skip the preauthentication process, and that means attackers can send the AS-REQ to the domain controller on behalf of any user configured that way. (Since the AS-REP contains the session keys encrypted with the user’s password hash.)

As a result, since the AS-REP contains the session keys encrypted with the user’s password hash, they can obtain the password hash of any user. 

(Tools like GetNPUsers from the Impacket tool suite can simplify this process.)

Attackers can then try to brute force passwords to decrypt the session key. If the key decrypts, that means the attacker successfully guessed it and now has the user’s password.

People in information security will often refer to this encrypted session key as a hash, but it’s really not a hash at all. Still, tools like Hashcat and John the Ripper can brute force many passwords against this “hash” in a short time to try to recover the user’s plaintext password.

By default, the AD User Account Control (UAC) setting: “Do not require Kerberos preauthentication” is disabled. This means that Kerberos preauthentication is performed for all users.

But here’s the kicker: This account option can be enabled manually and is seen from time to time during real-world engagements.

I recently supervised an internal networking penetration test where all user accounts had the “do not require Kerberos preauthentication” option enabled. The reason for this, as later stated by the client, was due to an internal application malfunction.

 

The administrators decided to enable this option “momentarily” while they fixed the issue. However, what was supposed to be temporary ended up lasting almost 2 years.

 

It’s worth noting this particular misconfiguration was only identifiable due to this particular penetration test.

Detecting AS-REP Roasting

We’ll cover how you can detect AS-REP Roasting activity using domain controller logs. 

Spotting this type of attack is easier than Kerberoasting attack detection. However, it’s still complex because you need knowledge of AD and event logs to properly filter down to malicious activity.

As we mentioned in part one of this series, regular AD operations in corporate environments make it harder to detect malicious activity because there are thousands of Kerberos events going on per minute. However, if we know what to look for, we can still find this needle in the haystack. 

Filter logs by Event ID 4768 

Event ID 4768 is an event ID recorded in Security Logs on the domain controller whenever a Kerberos Authentication ticket is requested. 

Depending on the Active directory size and assets, this can be well over thousands of tickets per minute by different accounts in the network.

Let’s view one of the many events to understand this event’s fields.

• Account Name: The user account that requested an authentication ticket from the domain controller.

• Service Name: Name of the service that handled the ticket.

• Ticket Encryption type: Depicts the Ticket encryption algorithm used (For example aes, RC4, etc). 

• Pre-Authentication Type: The status code shows whether pre-authentication was disabled or enabled for the said object (The Account Name).

We can see that the administrator user requested an authentication ticket and the service name is krbtgt. This is regular operations and whenever an account logs in to a workstation, krbtgt is a universal AD service that handles Kerberos authentication.

Now let’s discuss a few of the filters or conditions that would indicate a possible attack. 

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. 

User accounts request authentication tickets from domain controllers all the time; that’s the nature of how Active Directory Kerberos authentication works. 

To further reduce the events to investigate, we can filter out requests from all service names other than “krbtgt”. 

This is because during this attack, the attacker retrieves the authentication ticket just like a legitimate user account would, and krbtgt is a default AD Service that handles the authentication flow in Active Directory.

The major indicator that the AS-REP attack has been successful (the attacker managed to get the ticket, whether they cracked it or not is another case) is the pre-authentication type value in the resultant logs. 

Note:💡A great way to threat hunt for this attack is to just look for pre-authentication type = 0, which means it is disabled. This would already remove 90 percent of the noise in the logs, leaving more granular results to go through.

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 4768 event where:

1. Pre-Authentication Type is 0, which means it is disabled. This is a major condition to be fulfilled as without this condition, the attack can’t happen.

2. Service Name should always be krbtgt. This is also straightforward. As only krbtgt can perform authentication-related processes in AD.

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

Here’s an example of identifying an actual event that was the result of a AS-REP  attack using the detection tips above:

This event fulfills all the conditions we set which would highly indicate AS-REP Roasting activity. We can see that a domain Account “arthur.kyle” requested an authentication ticket for a user whose pre-authentication is disabled, with an encryption type of 0x17 from a workstation with IP Address 172.17.79.129.

Correlating events to detect a compromised account 

So far we found out that the user arthur.kyle got compromised due to pre-authentication being disabled. 

What we don’t know is which user account was used to perform the attack. 

It’s important to note that while the “arthur.kyle” account is the victim here, the bad actor used another account to perform the attack. 

We need to find that account, too, because it’s also been compromised! And our single AS-REP incident may expand into an incident with a wider scope as we keep more compromised assets.

We have the machine’s IP address from which the request originated. We will look for Kerberos service ticket events, as every domain user account requests those either during login/authentication or normal domain usage. 

Filter for Event ID 4769 and look for events around the time of the malicious event. 

We spotted an event about a minute later after the malicious event and it originated from User account of the “172.17.79.129” machine.

Now nothing in this event is malicious by itself. It’s purely a regular operation and is not a result of any attack or exploit. 

But since we already found AS-REP activity in the previous section, and we know it originated from this machine, this event caught our eye. 

Here we can see that happy.grunwald was the user account logged in around the time of AS-REP Roasting attack on the source machine (machine that performed the attack). 

It can be safe to assume now that this user account is compromised hence expanding the scope of the incident.

💡Note: you can AS-REP Roast with just a user list (i.e., if you gather it from an SMB NULL SESSION). But if you’re just running a tool like GetNPUsers.py or Rubeus you need a valid user account to query the user list (which all happens in the background when you run the attack).

That means this attack can be executed without any authentication if an attacker has a user list through some means (null session, an SQLi on an AD login form, successful username enumeration using Kerbrute, etc.

Detecting AS-REP roasting with Splunk

Let’s see a Splunk query for this as well

Query : Event.EventData.TicketEncryptionType=”0x17″ Event.System.EventID=”4768″ Event.EventData.PreAuthType=”0″ Event.EventData.ServiceName=”krbtgt”

| table Event.EventData.TargetUserName,Event.EventData.IpAddress

(Please note that in Splunk query, your field name might differ a little as it depends on the configurations. For example instead of  Event.System.EventID it can be “EventID” or “Windows.EventID”. It all depends on your Splunk configuration and deployment.)

In the above query, we are hunting for Event Log 4768 where the encryption type is 0x17, the authentication type is 0 (it’s disabled), and the service name is krbtgt. So this fulfills our criteria. 

Note💡: AS-REP Roasting is mapped to the sub-technique T1558.004 on the MITRE ATT&CK framework

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 “happy.grunwald” 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 AS-REP activity was noticed.

Remediation

To prevent AS-REP Roasting attacks, it is crucial to start by identifying all user accounts that do not require Kerberos pre-authentication. If not requiring pre-authentication is not necessary, ensure that pre-authentication is enabled for every account.

Always implement a robust password policy with long, complex passwords that are changed regularly. If possible, enhance security by enabling 2FA on authenticated services.