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:
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
0 10 20 30 40 50 60 70 80 90 100
Copying registry files...
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 PowerShell (WMI):
(we covered how to create credentials in powershell here: https://isc.sans.edu/forums/diary/ 21779/)
Using PowerShell Remoting:
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.
Directory of C:\Temp\ntdsdump\Active Directory
02/25/2018 06:26 PM <DIR> .
Directory of C:\Temp\ntdsdump\registry
02/25/2018 06:26 PM <DIR> .
Total Files Listed:
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:
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:
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.
Feb 26th 2018
|Thread locked Subscribe||
Feb 26th 2018
3 years ago