Blue Teaming
NTDS dumping attack detection
Learn how to detect NTDS dumping attacks in issue five of a special series on critical Active Directory (AD) attack detections & misconfigurations.
Table of Contents
Welcome to the finale of a special five-part 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:
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.
Detection
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).
💡Pro tip: Fortify AD environments with our Active Directory hardening checklist.
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.
