AS-REP roasting detection

Welcome to part two 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! 

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! If the preauthentication process is not in place, attackers can send the AS-REQ to the domain controller on behalf of any user in the domain. 

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 crack the hashes offline (using tools like Hashcat) or pass them around the network in what’s known as “pass-the-hash” attacks. This is an attempt to gain unauthorized access to domain resources on behalf of those users.

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 it’s really common to come across it during real-life 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 authentications.

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.

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 and NBT-NS 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. Essentially 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 made 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

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.

NTLM relay

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

As mentioned previouslyabove, 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.

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

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.

NTDS.dit file dumping

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 the users making it very desirable 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_MACHINESYSTEM 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 is exfiltrated and the HKLMSYSTEM registry hive, they can perform all  subsequent attacks offline, and do not require access to Active Directory.

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

Detection

Let’s discuss how to detect NTDS.dit dumping done via NTDSUTIL.exe Utility. Attackers love using built in utilities in Windows, because it means they don’t have to bring their own tools, which makes their operations more noisy. NTDSUTIL is a built-in utility available for management of 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 and Security Logs Domain Controller

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 system log to correlate with our application logs findings.For our final stop, we will look for event id 4799 in Security logs. Let’s start with the Application logs.

This would list down all the active directory related database operations here.

Signs of compromise:

• Application Log EventID 325: In this event we need to look for any weird file path for the newly created database (such as a dumped copy of original NTDS.dit) besides its original path of %SystemRoot%ntds. Any copy of NDTS.ditpresent 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: Let’s open up system logs from the domain controller, and filter for the event ID. When we look for the 7036 events around the timestamps that we established from our application logs findings. We see 2 services related to Volume shadow, which started running just 1 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 so far. We need to look for an event where 2 security groups (Backup Operators and Administrator) were being enumerated by 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 indeed the suspicious activity occurred. Let’s take a look at some  logs to see an example how they look

As we can see in figure below, there are lots of events in under 1 seconds

Practice detecting NTDS.dit dumping

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

The first Sherlock is focused towards detection of NTDSUTIL method, which we discussed in this blog, and the second is focused towards 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 towards beginners in the field.

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

💡Pro tip: Unlock the secrets to fortifying Active Directory with our practical checklist and best practices, tailored for real-world cybersecurity.