Bypassing EDR NTDS.dit protection using BlueTeam tools.

bilal al-qurneh
4 min readJun 9, 2024

During an internal penetration test, Cortex EDR was installed in the domain controller. After obtaining Domain Admin privileges on the network, the EDR blocked all known attempts to extract the NTDS hashes. Consequently, I had to think of an alternative methods to retrieve the hashes.


To Extract the hashes we need:
- SYSTEM hive, I dumped the entire server memory using Magnet DumpIt and extracted the hives with Volatility.
- NTDS.dit, protected by the OS and monitored by EDR, I used FTK Imager to read the C:\ drive in its raw state without triggering the normal system calls.
- Then using impacket-secretdump locally to decrypt the file.

The Long version :

Previously i wrote an article about a similar method to dump the Lsass, this article uses the same technique for the initial step and expands on it.

All the tools used are signed and have legitimate uses by the blue team, which give the advantage to the attacker to use them without getting blocked.
To manually extract the hashes, we need two things: the SYSTEM hive and the ntds.dit file from the system.

For the SYSTEM hive:
I extracted it by dumping the entire server memory, which took about 30 minutes using Magnet DumpIt (

Next, we can extract the hives from the raw memory dump using Volatility. I’ll use a combination of Volatility2 and Volatility3, as some modules perform better in one version than the other.

Start by listing all the hives and their locations using Volatility3 (

vol -f test.raw windows.registry.printkey.PrintKey

To dump the hive, we’ll use Volatility2: ( )

/opt/volatility_2.6_lin64_standalone/volatility_2.6_lin64_standalone --profile=Win10x64_14393 dumpregistry -o 0xaf0287e41000 -D output_vol -f test.raw

For the NTDS.dit file:
This file is protected by the operating system, making it difficult to copy directly. That’s why attacks like Shadow Copy exist, but the EDR was blocking these attempts and likely monitoring any system calls involving this file. To bypass this, I used FTK Imager. Typically used in forensics to create and analyze hard drive dumps, FTK Imager also has a feature that allows reading and analyzing attached drives.

This method allows us to read the `C:\` drive in its raw state and access any file on it without triggering normal system calls. Using this approach, we can not only read `ntds.dit` but also any file on the system that is protected, monitored, or locked by a running process.

FTK Imager is not inherently portable, and while there is a portable version called FTK Imager Lite, it is paid. Therefore, we need to create our own portable version (since no one likes the idea of installing software on the domain controller during an assessment).

Here are the steps to create the portable version:
1. Download and install FTK Imager on your Windows machine: (
2. Copy the contents of `C:\Program Files\AccessData\FTK Imager` into a new folder.
3. Copy the following DLLs from `C:\Windows\System32` into the new folder:
— mfc100*
— mfc110*
— mfc120*
— mfc140*
— mfc140u.dll
— msvcp140.dll
— vcruntime140.dll

You can now share this folder and access it from the domain controller.

To open the current drive:
1. Go to File -> Add Evidence Item -> Physical Drive -> Select the C drive.
2. Export C:\Windows\NTDS\ntds.dit.

Now we can decrypt the NTDS.dit file using impacket-secretdump. LOCAL -system output_vol/registry.0xaf0287e41000.SYSTEM.reg -ntds ntds.dit

You can find me on: