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:

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. 

Kerberosting 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.

💡Pro tip: Fortify AD environments with our Active Directory hardening checklist.

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.

LLMNR poisoning ⚔️

In earlier versions of Windows networks, the Network Basic Input/Output System (NetBIOS) protocol was used to perform operations across the network. A crucial component of this protocol was NetBIOS Name Service (NBT-NS), which was responsible for name registration and resolution.

Link-Local Multicast Name Resolution (LLMNR) is the successor of NBT-NS. It performs the same task as its predecessor, name resolution for hosts on the same local network.

LLMNR allows for the resolution of both IPv4 and IPv6 addresses into hostnames without the need for a DNS server on the local network. If a request to a DNS server fails (e.g., if a DNS server is not available), an LLMNR query is made across the local network to attempt to resolve that request.

So, how can this be a bad thing?

LLMNR does not require authentication to perform those name resolutions. That means that any computer on a local network can perform a LLMNR query.

If an attacker is listening on the local network, they can respond to those queries. This can lead to potential harmful behavior and attacks, such as LLMNR poisoning.

During an LLMNR poisoning attack, the attacker is listening for LLMNR requests. When a request is made across the local network, their device responds with its own IP address redirecting network traffic.

Responder is a popular tool to perform LLMNR poisoning attacks.

If an LLMNR event occurs on the network and the attacker is listening, Responder can obtain sensitive information regarding the victim such as the IP address, username, and password hash.

With the hash in their possession, attackers can attempt to crack it and obtain the password in clear text. Or they can try to relay that hash to authenticate as the victim in a particular service.

Note💡:LLMNR/NBT-NS Poisoning and SMB Relay is mapped to the sub-technique T1557.001 on The MITRE ATT&CK framework. 

Detecting LLMNR poisoning 🔍

Let’s dive into how we can find evidence of an LLMNR poisoning attack on network traffic.

Since network traffic contains so much extra noise (all regular web traffic for example), performing network forensics to pinpoint anomalies becomes difficult due to the sheer amount of traffic in corporate environments. 

So we need to know exactly where we should focus our efforts to find any evidence of malicious activity.

Just like in previous blogs, we’ll include a few conditions/traces that need to be present for us to conclude that indeed the attack mentioned above did occur. 

Analyze LLMNR traffic to find the rogue device

Let's start by opening the packet capture in Wireshark.

LLMNR runs on UDP port 5355 by default so we’ll filter for that. Now we can only see LLMNR traffic. 

Looking at source and destination IPs, we see that the IP address 172.17.79.136 performed a DNS query “DCC01” and another IP 172.17.79.135 that responds to that query. 

We notice that the query in question is “DCC01” which seems like a typo for a hostname (the actual hostname is DC01 but the user wrote a typo and instead the queried hostname was DCC01). 

From this, we can paint a picture that the user wanted to navigate to a file share on DC01 but instead wrote a typo “DCC01” which caused the DNS Server to fail and use LLMNR protocol for hostname resolution—from where the attacker’s rogue server acted as DC and grabbed the credentials. 

In legitimate cases, the IP address responding to the queries should belong to the Domain Controller. In our case, the DC IP is 172.17.79.4 and the machine responding to the queries is different, thus prompting us to look further into it. 

We will confirm this theory once we analyze SMB traffic. 

For now, we need to confirm that the “.135” IP address is a rogue device as we currently suspect that machine to be controlled by attackers. Remove the Wireshark filter and add a filter for DHCP.

We see the DHCP request between the suspected IP and the DHCP server. We can see the hostname for the machine that leased the “.135” IP address.

The hostname is Kali, an offensive Linux distribution used by hackers and pentesters. This confirms that this machine is not any domain-joined machine and needs further investigation.

Evidence of credential stealing in SMB traffic

Now we’ll analyze SMB traffic to find credentials being stolen and sent over to the attacker’s Kali Linux machine. 

Let's start over by adding an smb2 filter in Wireshark.

We can see multiple NTLM Authentication Negotiations. To only see negotiation packets and not other SMB packets, add a filter for “ntlmssp”. We will apply this filter first and then go back to viewing full SMB traffic.

• We can see that authentication is taking place for the domain-joined user called “john.deacon.”

• One other pattern we can spot is that multiple occurrences of NTLM authentications can be seen occurring within seconds of each other. 

By default we cannot see the IPs, so to view that go to View > Name resolution and enable Resolve Network Addresses. This will now display hostnames.

One thing to note is that DCC01 is not an actual host in the network, Wireshark decoded the Attacker’s Kali hostname as DCC01 in smb traffic because the victim machine (Forela-Wkstn002.local) thinks the Kali machine is the DCC01 host (the typo the victim made).

This confirms our findings so far that the credentials got stolen by the attacker from Wkstn002. 

Let’s again filter for smb2 traffic and see the file share the victim wanted to navigate to.

In smb traffic we see that the user from wkstn2 navigated to a file share on DC01. Now the whole scenario makes more sense. Let’s go over again to what happened.

1. The victim wanted to visit \\DC01\DC-Confidential but instead made a typo (\\DCC01\DC-Confidential) which failed the hostname resolution.

2. When the DNS server was not able to resolve DCC01 (as it does not exist), Windows tried using LLMNR to resolve this.

3. Our crafty attacker was running a tool called Responder in the network which acts as an LLMNR server and it responded to the LLMNR query by the victim machine.

4. The victim's machine sent the hash to authenticate thinking it was a domain controller, but in reality, it was an attacker-controlled server.

5. On the victim’s side, nothing seems out of the ordinary. When file share does not open, victim realises they made a typo and they type in the correct path and carry on as usual. In our case victim fixed the typo and navigated to DC01 share after realizing their typo.

We can see all above activity occured in under a minute.

Recovering & cracking the user hash 

This step is important because it allows us to determine if the attacker cracked the compromised user hash. 

If the password policy is strict in your environment, there’s a high chance the attacker failed to crack the password. The real impact of this attack is therefore reduced thanks to the complex password policy. 

Go to NTLM authentication traffic (ntlmssp filter). The NTLM authentication and negotiation occur in sets of three (3) packets. Each negotiation includes an: 

1. NTLMSSP_NEGOTIATE packet.

2. NTLMSSP_CHALLENGE packet.

3. NTLMSSP_AUTH packet.

To recover the hash, we need to dissect 1 set. Let’s do this on the first set. We need different values from the negotiations and to plug in the values in this format.

Format :

User::Domain:ServerChallenge:NTProofStr:NTLMv2Response(without first 16 bytes/32 characters).

To find each value:

User: In details of NTLMSSP_NEGOTIATE packet expand SMB2 (Server Message Block Protocol Version 2) ->SMB2 Header -> Session ID->Account.

Domain: In details of NTLMSSP_NEGOTIATE packet expand SMB2 (Server Message Block Protocol Version 2) ->SMB2 Header -> Session ID->Domain.

ServerChallenge: In details of the NTLMSSP_CHALLENGE PACKET  expand SMB2 (Server Message Block Protocol Version 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic  -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> NTLM Server Challenge.

NtProofStr:  In details of the NTLMSSP_AUTH Packet expand SMB2 (Server Message Block Protocol Version 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic **** -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> -> NTLM Response -> NTLMv2 Response ->NTProofStr.

NTLMV2Response: In details of the NTLMSSP_AUTH Packet expand SMB2 (Server Message Block Protocol Version 2) -> Session Setup Response (0x1) -> Security Blob -> GSS-API Generic **** -> Simple Protected Negotiation -> negTokenTarg -> NTLM Secure Service Provider -> -> NTLM Response -> NTLMv2 Response. 

💡Note: You have to remove the first 32 characters from the value of this field because the first 32 characters are the same as NTProofStr, which we already have acquired and is ready to be plugged in the hash format for cracking.

Now let's plug in the values in the format. 

This is the final format we get and we save this a txt file. 

Now let's get cracking. We will use Hashcat to crack this.

Hashcat Format: Hashcat.exe -a0 -m5600 hash.txt passwords.txt. 

In this format, hash.txt contains our hash format which we plugged in and passwords.txt is our wordlist.

To summarise what we’ve discussed so far: 

1. In LLMNR traffic, look for any machine responding to queries that is not a domain controller.

2. Look for NTLM authentication packets going towards the unidentified/unknown machine discovered from point 1.

3. Look for typos in LLMNR traffic, DNS Traffic, and SMB traffic. 

4. Try cracking the hash to see how resilient the password of the compromised user is.

5. As a follow up, look for authentications for the compromised user in the environment, especially after the time of LLMNR poisoning, and search for logon types three (3) (network logon) and 10 (RDP Logon).

Remediation

If LLMNR and NBT-NS are not required in the environment, you should disable both of them entirely as a mitigation measure.

If a particular organization is unable to disable the LLMNR and NBT-NS protocols, they can consider implementing Network Access Control (NAC) and requiring long and complex passwords to reduce the chances of attackers cracking them offline.

Practice detecting LLMNR poisoning with HTB Sherlocks

Take on the Very Easy “Noxious” Sherlock focused on forensics and detection of Kerberoasting attacks.

The Sherlock has a guided mode that’s perfect for beginner cybersecurity analysts or DFIR professionals looking to develop real-world defensive skills.

Boost your defensive skills in Active Directory

NTLM relay attacks ⚔️

Windows New Technology LAN Manager (NTLM) is the name of a set of Active Directory protocols that provide authentication in the network. To ensure backward compatibility, NTLM is used mainly on systems that do not support Kerberos authentication.

When an attacker intercepts network traffic with an LLMNR poisoning attack, they can further attempt to relay the intercepted event to authenticate themselves to a particular service on behalf of the victim.

This is known as an NTLM relay attack. NTLM relay attacks are possible because the NTLM itself does not provide session security.

Impacket's ntlmrelayx is one of the most commonly used tools that can be leveraged to perform this attack.

Play the Reaper Sherlock

• Learn NTLM authentication protocol and the session security SSPI provides for NTLM sessions.

• Deep dive into the NTLM Relay attack using the techniques and tools attackers use.

• Delve into advanced cross-protocol relay attacks and mounting attacks.

Play the Reaper Sherlock 

 

Detecting NTLM relay attacks 🔍

To detect NTLM relay activity in a network we need network telemetry and logon audit logs from the endpoint. 

Detecting NTLM relay attacks requires an odd approach, as we need to correlate the IP Addresses with the host names. 

This means we need to have an inventory/list of IP addresses assigned to workstations. In big corporate environments with thousands of assets in the network, keeping tabs on this is difficult. 

In such cases, network telemetry will help us determine the IP addresses of legitimate devices and make it easier to pinpoint the rogue machine.

Let's start off by opening a pcap file in Wireshark and listing the known IP addresses associated with domain-joined workstations and servers.

Viewing the endpoints included in the network traffic we can see few internal IP addresses.

The IP addresses ending with .1 and .2 are excluded because they act as gateways and are not assigned to actual workstations.

We can get host names for the IP addresses using NetBios Name service/NBNS Protocol.

Let's add a filter for this in Wireshark.

For the IP address 172.17.79.129: 

For IP Address 172.17.79.136:

For IP address 172.17.79.135 we can see there is no host name and instead some random data. 

From this, we have a short list of hostnames: 

1. Forela-Wkstn001 is assigned 172.17.79.129.

2. Forela-Wkstn002 is assigned 172.17.79.136.

3. Unknown Device is assigned 172.17.79.135.

Now, let's add a filter for smb traffic to and from the unknown device since we suspect it to be the attacker’s machine acting as a Man In The Middle (MITM).

In the above image, we can see that user “arthur.kyle” was involved in the authentication process and the unknown device is involved in this as well. 

We see the IP Address for the Wkstn002 machine as well. Seeing the traffic direction, user arthur.kyle is the user account in Wkstn002. This now screams that the credentials were stolen and relayed from the user arthur.kyle from workstation 2.

The next stream of packets now involve the same unknown device in the authentication process with the 172.17.79.129 IP address. This is another red flag as to why the same user account (arthur.kyle) is involved in authentication from two different machines (one is legitimate and the other is an unknown MITM device). 

These packets tell us that: 

1. Arthur Kyle on Wkstn002 had hashes stolen by the attacker. One way this can happen is if the user had a typo when navigating to file share and the attacker was running responder to intercept traffic in the environment. (We’ll discuss this later.)

2. The hashes stolen by the attacker were then immediately relayed to the target system, which in our case, is Wkstn001. 

3. The attacker then authenticates and logs in to the target machine(Wkstn001 using the arthur.kyle account) and then dumps the SAM Hashes from the remote machine. This is the default behavior of ntlmrelayx tool from impacket used for this purpose. After this, they can log on to the machine with the primary user account of that machine whose hash was dumped remotely.

Event log analysis

We are provided Security events logs from Wkstn001.

Let’s look at log events here, filtering for Event ID 4624.

In this specific event, we have multiple indicators that an NTLM relay attack did occur and authentication was conducted from the attacker’s machine using stolen credentials.

The first indicator we see is that Security ID Says it is NULL SID and we have no Logon ID, LogonGUID is also null.

In network information, we can see that the source workstation says WKSTN002. In IP address we see 172.17.79.135. (Suspicious!)

Workstation002 has an IP address of 172.17.79.136, but it shows .135, which was an unknown device.

Another indicator we see is that the log-on process says it’s NTLMSSP, which we confirmed from our network traffic analysis.

This confirms that the unknown device stole credentials from wkstn002 and used them to log on to wkstn001. 

Remediation

NTLM authentication should be disabled if possible. Organizations should use more robust protocols, such as Kerberos, instead.

To prevent the interception of authentication via NTLM, Server Message Block (SMB) signing must be enforced across the domain. 

SMB Message signing secures messages sent between the client and server during NTLM communications preventing the interception of NTLM authentication messages.

NTLM Relay Attacks

• Learn NTLM authentication protocol and the session security SSPI provides for NTLM sessions.

• Deep dive into the NTLM Relay attack using the techniques and tools attackers use.

• Delve into advanced cross-protocol relay attacks and mounting attacks.

Learn NTLM Relay Attacks

NTDS password extraction ⚔️

Active Directory stores domain information in the NTDS.dit file, which is located by default in %SystemRoot%\ntds\ on the domain controller. 

This file contains crucial domain information, including password hashes for users, making it a very desirable target for attackers.

To gain access to the NTDS.dit file the attacker must already have administrator access in the environment. If the attacker has access to the domain controller, they can exfiltrate the NTDS.dit file alongside the HKEY_LOCAL_MACHINE\SYSTEM registry hive, which contains all the information needed to decrypt the NTDS.dit data. 

Although Active Directory locks this file while running (disallowing any copy activities), an attacker can use the Volume Shadow Copy Service (VSS) to copy the volume and extract the NTDS.dit file from the snapshot. 

They could also make a copy using a diagnostic tool available as part of Active Directory, NTDSUTIL.exe. 

Furthermore, if an attacker has a set of valid credentials, they could leverage tools like crackmapexec to dump the NTDS.dit file remotely and parse it.

After an attacker exfiltrates the NTDS.dit file and the HKLM\SYSTEM registry hive, they can perform subsequent attacks offline, and do not require access to AD.

After obtaining the password hashes from the NTDS.dit file, attackers can attempt to crack them offline to obtain the plaintext passwords. If they are unable to crack the hashes offline, they could also try using the password hashes in pass-the-hash attacks to further exploit the environment.

The process of parsing the domain information from those files can be done with tools like secretsdump, which is part of the Impacket tool suite.

Note💡: OS Credential Dumping NTDS.dit is mapped to the sub-technique T1003.003 on the MITRE ATT&CK framework. 

Detecting NTDS password extraction 🔍

Let’s discuss how to detect NTDS.dit dumping done via NTDSUTIL.exe Utility. 

NTDSUTIL is a built-in utility available for the management of the NTDS database in Windows servers, but an attacker can exploit it to gain access to this database. 

However, doing this leaves few indicators of the attack that we can use to establish that NTDS.dit was dumped by a malicious entity.

Application, system & security logs 

To examine this, we will use application and system logs from the Domain Controller. 

We need to monitor for Event ID 325 and 327 and the event source “ESENT” in application logs. These events are logged when a new database is created and when a database is detached respectively. 

We will also look for event ID 7036 in the system log to correlate with our application logs findings. For our final stop, we will look for event ID 4799 in the Security logs. Let’s start with the application logs.

This would list down all the AD-related database operations.

Signs of compromise include: 

Application Log EventID 325: 

We need to look for any weird file path for the newly created database (such as a dumped copy of the original NTDS.dit) besides its original path of %SystemRoot%\ntds\. Any copy of NDTS.dit present in another location strongly indicates malicious behavior. 

We can see an example of a suspicious log below:

Application Log EventID 327: 

Immediately after the previous event, we would see event 327, with the same NTDS.dit path and a message saying that the database was detached by the engine. 

From these two logs, we can create a timeline of the events.

System Log EventID 7036: 

When we look for the 7036 events around the timestamps that we established from our application logs findings, we see two services related to Volume shadow, which started running just a second before the creation of the NTDS.dit database. 

This activity would further confirm our findings so far.

Security Log EventID 4799: 

Next, filter for the event ID and look for the events in the established timeline. 

We need to look for an event where two security groups (Backup Operators and Administrator) were being enumerated by the ntdsutil.exe process multiple times (around 50+ times in 1-2 seconds). 

This is a strong indicator and can be used to validate our findings and establish that suspicious activity occurred. Let’s take a look at some logs to see how they appear. 

As we can see in the figure below, there are lots of events in under a second. 

Remediation

Organizations should take steps to secure administrative access for the domain controller, and monitor Administrative accounts for suspicious activity. Consider implementing a Local Administrator Password Solution (LAPS) 

Also, implement methods to prevent code injection attacks that can compromise credentials by configuring added Local Security Authority (LSA).

Practice detecting NTDS.dit dumping

We have prepared 2 Very Easy Sherlocks focused on forensics and detection of NTDS.dit dumping.

The first Sherlock is focused on the detection of the NTDSUTIL method, which we discussed in this blog, and the second is focused on the vssadmin detection method, in which threat actors attack the vssadmin utility. The Sherlocks are available for free and have a guided mode, fully focused on beginners in the field.

Level up your defence with HTB Sherlocks

Take on the Crown Jewel 1 + Crown Jewel 2 Sherlocks focused on forensics and detection of NTDS dumping attacks. The free Sherlocks feature a guided mode perfect for beginner cybersecurity analysts or DFIR professionals looking to develop real-world defensive skills.

Boost your defensive AD skills