NTDS.DIT Active Directory Passwords & Decryption

Windows Server 2008 Active Directory

We know local user accounts are stored in SAM file and we have previously demonstrated on PASS THE HASH article how to dump/extract use abuse these password equivalent hashes.

In this article we demonstrate/describe some of the attack techniques to gain access to a windows domain controller the techniques to copy NTDS.dit database using built-in tools “living off the land “ the use of WMI, VSSADMIN , PowerShell. A.KA Microsoft post exploitation framework  J

Active directory data is stored in the Ntds.dit ESE database file.  Two copies of Ntds.dit present in separate location on a given domain controller  %SystmRoot%\NTDS\ Ntds.dit  &  %SystemRoot%\System32\Ntds.dit .

These are exclusive locked file meaning they cannot be copied simply using click right and copy to the destination will not work as these files have in use with set of permissions  attribute on.

This of course doesn’t mean we can’t using Build-in tools VSSADMIN or PowerShell to make a copy of the Ntds.dit file locally and infiltrate to our attacking machine for closer offline analysis and password extraction. But of course we need to gain access to the domain controller with local administrative privilege or domain admin in order be able to copy the AD server crown jewels .

Without further ado let’s get to hacking into breaking windows 2008 active directory

Our attacker IP address is set to   

Our target is windows 2008 active directory installed

We already have an administrative account (Credential theft or MS14-068 Kerberos prive escalation

Windows Built-in tools – Welcome to VSSADMIN  .

VSSADMIN is essentially shadow volume copy feature since windows Vista that allows an administrator or “hackers” to take friendly snapshot backups files even when the files are currently in use J  J J  that’s how I feel when I login to a Domain controller…

You already figured out my next move – Yes I will use VSSADMIN built-in tool to copy NTDS.dit and SYSYEM file from the domain controller save it to the disk for remote exfiltration.  You may ask why we need SYSTEM file. Great question, SYSTEM file contains what knows as Boot secret key which used at the windows boot startup for decryption

Quick Scan against domain controller identified port SMB on 445 and Port 88 kerberos authentication protocl .

server_2008_nmapFigure 1 Port scan identified number of open ports from our attacking machine

Credential theft – We use Rdesktop to login to the remote server 2008 AD.

rdesktop_02Figure 2 with administrative access we login to the remote Target windows 2008 server

vssadmin create shadow /for=c:  to creaate a light snapshot

vssadmin-create-copy-03Figure 2 vssadmin built-in windows tool to create a fast snapshot

Next we  use copy command and copy the ntds.dit file to our \windows\ntds\ntds.dit location

copy-ntds-dit-04Figure 3 snapshot of ntds.dit now successfully copied to the c:\ drive

We also need a copy of SYSTEM File to decrypt the NTDS.dit objects

copy-system-dir-04Figure 3 SYSTEM file is copied to c:\ location we need that file to decrypt the ntds file

Now that we have a copy of NTDS.dit and SYSTEM file waiting for final exfiltration to our attacking machine for offline decryption

We use Mount -t cifs to connect the target remote machine specefying the username and password and associate /mnt/

mnt-copiedFigure 4 C$ is mounted to /mnt drive to copy ntds.dit and SYSTEM file for extraction

We use esetUtil.py to look at certain table and grep particular hashes from the NTDS.dit file

bFigure 5 we use esentuil to grep datatable contains hash objects

Next we we use extract datatable from the ntds.dit and pipe it to the output.txt file

ntds-dirFigure 6 Impdump.py we point SYSTEM file and output extract and pipe it to the hashes.txt file

Password equivalent hash extracted from windows active directory server

hashes-textFigure 7 Windows NTLM password hashes

So there we are , NTLM password hashes for PTH & offline decryption





Pass The Hash …

We got hacked and yes this was sophistictaed attack


Long live pass the hash.

In cryptanalysis and computer security PASS THE HASH is security hacking technique that allows an attacker or researcher to authenticate to a windows remote service or service by using underlying LM LanMan or NTLM of the users password, instead of requiring  the associated correct plaintext password as is normally the case  .


Microsoft Windows Operating Systems store hashed user password in SAM Security Account Manager. In order to stop and deter offline password attacks against the database, Microsoft Introduced SYSKEY which will partially encrypts the SAM file. An attacker will not be able to decrypt SAM file without SYSKEY and SYSTEM File.

Microsoft based operating system up to windows 2003 store two separate authentication password hashes; LAN MANAGER (LM) which is based on DES DATA ENCRYPTION STANDARD based on symmetric block key and NTLM NT LAN MANAGER based on MD4 yes Message digest 4 hashing.

LM LAN MANAGER provide little or no security and known to be extremely weak for the following reasons:

Passwords that are longer than seven characters are split into two strings each is hashed separately .The password is converted to upper case before begin hashed. The LM/NTLM hashing system does not include salts making brute force rainbow table attacks possible.


From windows Vista on , Windows operating system by default disables LAN MANAGER LM and uses NTLM which supports all Unicode characters, and does not limit stored passwords to two 7 character but of course NTLM hashes stored in SAM database are not salted.

The SAM database cannot be copied while the operation system is running even though the windows kernel keeps an exclusive file system lock on the file, however PowerShell allow direct interactions with exclusive locked privileged files. There are many other techniques to extract windows password hashes , such as DLL injection against  LSASS Local Security Authority Subsystem Service which is core windows authentication package.

Windows Authentication

After a user logs on to windows operating system, a variety of the account credentials are generated and stored in the LSASS Local Security Authority Subsystem Service, Process in memory. This meant to allow the SSO (Single Sign On) ensuring a user isn’t prompted each time resource or services is requested. The credential data depends on the environment and configurations. This may include Kerberos TGT Ticket Granting Ticket, NTLM password hash, LM password hashes, in some instances if the user password is less than 15 characters, depending OS version and Patches level it might be possible to extract clear-text passwords (WDigest and SSP Authentications)

While it’s you can stop/prevent windows system from creating LM hash in local SAM file however this doesn’t prevent system from generating LM hash in memory. From windows vista and windows server 2008 LM is no longer generated for users unless explicitly enabled by users.

WDigest & Clear-Text Password?

Microsoft introduced Wdigest.dll in the windows XP operating system, the protocol is designed for HTTP Hypertext Transfer Protocol and Simple Authentication Security Layer (SASL) which mean passwords are not encrypted when sent to a server leaving them vulnerable to man in middle attack, at the same time windows stores the password in memory for convenience of the user when they login to their local workstation.

When Microsoft release windows 8.1 they added a security features that mitigated ability of tools like WCE , mimikatz to dump/extract clear text credentials from LSA memory .

In 2014 Microsoft backported those security fixed (http://support.microsoft.com/kb/2871997  for windows operating system prior to 8.1 however because of legacy OS and WDigest is used by many products (IIS) Microsoft left the Wdiget providers enabled which is why it’s still possible to use mimikataz module to obtain clear-text passwords prior to windows 8.1

After you install this security update, you can control how installed WDigest credentials can be saved by using a registry setting. To prevent WDigest credentials from being stored in memory, a Group Policy setting can be applied to the UseLogonCredential registry entry under the following subkey:


  • If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.

  • If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.

Windows 10 enterprise , Security Provider registry doesn’t contain UseLogonCredential entry



Figure 1 Default to windows 10 with no UserLogonCredential entry

We simply force UseLogonCredential entry set to 1 forcing registry to store clear text password in the memory  ( NT/Authority credentials required)

2Figure 2 creating UseLogonCredential in order to force user credentials stored in clear text.


UseLogonCredential entry created in SP Security Providers registry Under WDiges . The value is set to 1 stores the credentials as clear text in memeory


Figure 3 UseLogonCredential set to 1 which allows an attacker to extract clear text password direcrly from memory

Mimikatz powershell password dump with WDigest set to 1 allows clear text password


Figure 4 WDigest UseLogonCredential set to 1 allowing credential to be extracted

Mimikatz PowerShell password dump with WDigest set to 0 prevents clear-text password extraction


Figure 5 UseLogonCrdential set to 0 prevents user not to store password in memeory

WDigest Provider UserLogonCredential Registry REG_DWORD set to 0X0 mitigate against clear-text password extraction


Figure 6 corroborating UseLogonCredential is not set to  1 to fix the issue

Pass the hash (Local System)

PTH requires local administrators’ privilege that’s because local admin has Debug privilege assigned to it. Below we demonstrate PTH and open two cmd.exe consoles, one as an administrator and the other one as normal user

Cmd.exe run as Administrator has debug Privilege permission


Figure 7 Whoami /all shows administrator as part of Debug priv permission

Authenticated user with no administrator privilge


Figure 8 authenticated none privileged user with no debug privilege

There are different techniques and ways to extract password hashes from local windows operating system. We use Mimikatz for password extractions

Privilege debug is set to ok however the Lsadump::sam failed to work as mimikatz requires to have NT/Authority SYSTEM privilege to extract password hashes from the system


Figure 9 token::whoami shows Zane as normal authenticated user

How do we elevate NT/Authority SYSTEM user in order to have appropriate permissions to access windows secret hives . We  use SysInternls tools to elevate permission Local System

psexec -s -i -d cmd.exe

System internal tools to elevate local system


Figure 10  nt authority\System priv

Alternatively we can elevate within the mimikatz request nt authority/system


Figure 11 token::elevate delegation

lsadump:sam to dump NTLM password hash from SAM file


Figure 12 Mimikatz to extract the SAM hash database

sekurlsa::pth /user:Administrator /domain:locahost  /ntlm:9cf1735cff285fdcc130125cee


Figure 13 Sekurlsa obtained new cmd.exe prompt with admin token  (Mimikatz)

Dumping windows live memory

One of the tools i like to use during security pentest engagement is  ProDump a command-line utility who’s primary purpose is monitoring an application for CPU spikes and investigating crash dumps but we obviously  we interested to perform the memory dump of the core windows authentication process LSASS.exe in order to do some offline analysis using mimikatzzzz

But first we need to move ProcDump to the target victim workstation?

There are number of techniques to transfer files to the victim target workstation, but my preferred way PowerShell since the target is windows workstation

Basic PowerShell script to copy ProcDump.exe from our attacking machine and rename it on the disk hacker.exe using  System.Net.WebClient cmdlet to do clean transfer to our target destination


Figure 14 System.Net.WebClient cmdlet powershell file transfer

Next we attach the ProcDump to the lsass.exe in order to dump extract clear text password hashes.The -accepteula parameter is to accept EULA ,this its necessary to use it other wise you will get stuck in the remote console. We perform the memory dump for offline clear text and password hash extractions

hacker.exe -accepteula -ma lsass.exe


Figure 15 we use ProcDump to dump live memeory  .

Next we use mimikatz module to dump the hashes from ProcDump lssas.dmp file which contains the administrator password hashes and clear text passwords.


Figure 16  Password hash dumped from procdump .dmp file


  • Use LAPS Local Administrators Password Solutions to mitigate Lateral movements
  • Switch off Privilege debug permissions – You don’t need it
  • Upgrade to windows 10 with device guard enabled