Got Privs? Crack Those Hashes!

Joff Thyer //

Black Hills Information Security loves performing both internal penetration tests, as well as command and control testing for our customers. Thanks to the efforts of many great researchers in the industry, we are lucky enough to escalate privileges in many environments, laterally move, and demonstrate access to sensitive data.

As a penetration tester, we must always have the mindset of demonstrating business risk as the number one goal. Thus I find myself often saying things like “Domain Admin” in the Windows Active Directory world are not everything. In fact, in support of this idea, there have been many occasions whereby I have managed to move laterally within an environment because of enumerated/discovered local administrative privileges and even used token impersonation exclusively to mimic a normal business user with the goal of demonstrating access to data. Did I need to grab that domain admin privilege for this? Well not at all. Do these sorts of actions scare the daylights out of business executives that are trying to guard the crown jewels? You bet it does!!

Gaining local privilege escalation is something we often achieve through any number of methods including:

• Mis-configured service accounts
• Unquoted service path names
• Unattended installation XML files
• Group policy preferences XML files
• DLL hijacking
• The “always elevate” registry key for MSI installations
• Kerberoasting – thank you, Tim Medin!!!
• Password spraying

In recent tests, I have found that Kerberoasting remains very fruitful but in unusual ways. One attack path I have found interesting is to spray for passwords that you first discover through Kerberoasting or other local machine escalation. It is amazing how many times that Systems Admins will reuse passwords and not be cognizant that password reuse across different privileged accounts is a really bad idea.

All that said, let’s just face it, there is nothing better than the thrill of finally getting full domain administrative access. While it does not demonstrate business risk directly, it sure makes you feel a little tingle followed by your happy little “got root” dance. (Yes, admit it… you all have a “got root” dance). My lovely wife always knows when I hit the jackpot because my office is next to the kitchen, and I cackle loudly when it happens.

Ok, so after you get that Domain Admin account through whatever means, there are so many things you can do. Among these is performing the “value-added service” of grabbing the full domain account hashes, and letting your “hashcat” flag fly in all its glory. Yes, crack those hashes and see just what percentage of all the creds you can actually obtain. In the process of doing so, you will turn your rockin’ video GPU water-cooled cracking masterpiece into a small space heater while using about 3,000 watts of electricity over a couple of days… but oh the wonderful beauty of the result! Of course, when you are finished you should use Carrie’s Domain Password Audit Tool to produce a beautifully formatted HTML report. It is not unusual to obtain figures such as over 70% of hashes cracked in any one organization.

Now I will get to the point… extracting the hashes can be dangerous!!! Why do you ask? Well, many of us in the bad old days are accustomed to using either “hashdump”, or “smart_hashdump” (thanks Carlos… https://www.darkoperator.com/blog/2011/5/19/metasploit-post-module-smart_hashdump.html) in the Metasploit project. While these are lovely, well-written pieces of software, both approaches on a Domain Controller will try to extract hashes from the LSASS.EXE process. Within a small environment, you will probably be just fine. However, there are times when you are operating within an environment of 20,000 – 100,000 credentials or more. If you muck around with LSASS.EXE in this sized environment, you will likely crash a domain controller, and that is sub-optimal.

How do we handle this situation? It would be really nice if we could gain access to the NTDS.DIT, SAM, and SYSTEM files directly and just copy the data down. This works well because the folks at Core Security have a Python script called “secretsdump.py” within the Impacket repository giving us the ability to grab the hashes directly from the database, and registry files.

Next question is… how on earth do we gain access to these files? On a running domain controller, they are locked files, so you can’t just romp on into the “%SYSTEMROOT%\SYSTEM32” directory and copy the files. Well, not technically true, you can find backups of SAM, and SYSTEM in the “%SYSTEMROOT%\SYSTEM32\CONFIG” directory, and it might well be possible to locate the files in a Volume Shadow Copy. Alas, even if you do locate these files, they will be old by perhaps a day or a week.

There happens to be a fantastic tool located on a Windows domain controller called “NTDSUTIL.EXE”. The NTDSUTIL tool is used for accessing and managing a Windows active directory database. The tool should typically only be used by experienced system administrators, but also has this wonderful penetration testing use case.

WARNING: This tool is POWERFUL. Do not experiment ad-hoc with NTDSUTIL unless using your own lab system. It will directly interact with Active Directory databases, and you might well destroy the domain.

The nice part about NTDSUTIL from a penetration testing perspective is that you can create a full active directory backup in “IFM” media mode in a completely safe manner. Once you do this, all that is left is to copy the files to where you need them for hash extraction and cracking purposes. The upside of this method is a safe, and relatively stealthy method of grabbing the data for your “value-added service” of cracking the hashes. The downside of this method is that some Active Directory Databases are sizeable, often several hundreds of megabytes or gigabytes in size. In general, I have found that ex-filtration works fairly well if you created an encrypted ZIP, base64 encode and then download the result.

Specifically, when using NTDSUTIL we are doing the following:

• Setting the active instance to “NTDS”
• Entering “IFM” media creation mode
• Creating a full backup to a specified directory path
• Quitting out of IFM, and then quitting from NTDSUTIL

NTDSUTIL is normally a text menu-driven process, however, it is possible to specify each of the commands directly on the command line from CMD.EXE as follows:

C:\> ntdsutil “ac in ntds” “ifm” “cr fu c:\TEMP\AD” q q

The most important thing to realize is that the “C:\TEMP\AD” directory specified above must exist, must be an empty directory, and must have enough free disk space to hold the full database. The other important thing is that you must have an administrative account in order to perform this operation.

In general, I prefer to not use Remote Desktop Protocol but rather use WMIC to launch the required NTDSUTIL command. One of the challenges with this is you end up with the age-old quotation escaping challenge in crafting your command.

Let’s assume your target domain controller is 10.10.10.10. What you can do is map a drive to the domain controller, create your directory to store the results, and invoke WMIC to run your NTDSUTIL command.

A command sequence as follows should do the trick assuming you are resident on a regular workstation within the environment.

C:\> NET USE Z: \\10.10.10.10\C$ /USER:DOMAIN\Administrator C:\> MKDIR Z:\TEMP\AD C:\> WMIC /NODE:10.10.10.10 /USER:DOMAIN\Administrator /PASSWORD:XXXXX process call create "cmd.exe /c \"ntdsutil \"ac in ntds\" \"ifm\" \"cr fu c:\TEMP\AD\" q q\”" 

You can check on the progress using the command while NTDSUTIL completes. It may take a while especially if the active directory environment is large.

C:\> DIR /S Z:\TEMP\AD 

After this completes, your job is to compress the resulting files (SYSTEM, SAM, and NTDS.DIT) using ZIP with encryption, optionally base64 encode, and download the results to a Linux system you control.

The IMPACKET secretsdump script can then be used to extract all hashes in a format suitable for cracking with “hashcat” as follows:

$ python secretsdump.py -system SYSTEM -security SECURITY -ntds NTDS.DIT -outputfile outputfilename LOCAL 

After you have successfully exfiltrated the data, please ensure that you clean up your mess on the domain controller itself. I would suggest doing the following:

C:\> Z: Z:\> CD \TEMP\AD Z:\TEMP\AD> RD /S /Q “Active Directory” Z:\TEMP\AD> RD /S /Q “Registry” Z:\> C: C:\> NET USE Z: /DELETE 

If you have sufficient drive space on the local workstation you are working with, another option is to create a share from your system, and mount that share on the domain controller. Subsequently, you would create an empty directory on this share, and use a similar NTDSUTIL command to create the backup of the database with this path.

The greatest advantage of following this sort of methodology when extracting hashes is that you are NOT endangering the LSASS.EXE process via any DLL injection, and thus not risking a domain controller crash.

Another potential method to use is to abuse domain controller replication functionality with “DCSYNC”. If you would like to read about this, please refer to Harm Joy’s blog at http://www.harmj0y.net/blog/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/.

Happy hunting folks.