Dumping Windows Credentials

• Password Hashes

Get the password hashes of the local accounts, the cached domain credentials and the LSA secrets in a single run with secretsdump :

• Local SAM Hashes

Crack the LM hashes (if any) using Ophcrack .
Crack the NT hashes using JtR or hashcat .
Remember that if you can’t crack promising password hashes, you can just pass the hash against other accounts using the same password on other hosts or even the domain.

• Cached Domain Credentials

These are the password hashes of domain users that have logged on to the host previously.
Crack them using JtR or hashcat. Remember to specify the right format, which is either mscash (xp, w2k3) or mscash2 (vista, w7, w2k8 …). Note that you can’t perform “pass-the-hash” style attacks with this type of hash.

• LSA Secrets

Here, you will find account passwords for services that are set to run under actual Windows user accounts (as opposed to Local System, Network Service and Local Service), the auto-logon password and more.

If the Windows host is part of a domain, you will find the domain credentials of the machine account with which you can authenticate to the domain to list domain users and admins as well as browsing shares and so on.

Use pth on Kali Linux or wce on your own Windows system to use these credentials.

Browse shares for passwords, look on the domain controller for passwords in Group Policy Preferences (GPP) that can be decrypted:

• In-Memory Credentials

Dump clear-text passwords from memory using mimikatz and the Windows Task Manager to dump the LSASS process.

To do this, dump the lsass.exe process to a file using Windows built-in Task Manager with right-clicking “lsass.exe” then selecting “Create Dump File” (since Vista) or Procdump (pre Vista) – alternatively, use some powershell-fu (see carnal0wnage blog post):

Then dump the credentials offline using mimikatz and its minidump module:

Make sure you run mimikatz on the same major version and same architecture you pulled the process dump from (refer to this ).

Alternatively, you can upload and run wce on the host, but the binary is likely to get picked up by most Anti Virus software. Also, note that wce-v1.41beta still doesn’t seem to dump the passwords of outbound SMB sessions (that can be with “net use” on the compromised Windows system), although mimikatz will.

• Credential Manager

When a user authenticates to a network share, a proxy, or uses a piece of client software and ticks the “Remember my password” box, the password is typically stored in an encrypted vault using the Windows Data Protection API. You can see every saved credential in the Credential Manager (accessed through User Accounts in the Control Panel), and you can dump them with Network Password Recovery . Remember to run the 64-bit version on a 64-bit Windows instances, or you won’t get them all.

• Protected Storage

Dump any passwords remembered in IE, Outlook or MSN using Protected Storage PassView .

• Third-party software

NirSoft offers many tools to recover passwords stored by third-party software.

Dumping domain user hashes from the Domain Controller

These next techniques are used for dumping credentials when you already have access to a Domain Controller:

• Volume Shadow Copy

This technique consists of retrieving the Active Directory database from the Directory Service running on the Domain Controller, also known as the “ntds.dit” file. It requires the attacker to interactively logon to the Domain Controller via Remote Desktop or “psexec” – the idea is to use the Volume Shadow Copy functionality to grab a copy of the “ntds.dit” file, which would be locked & protected from read access otherwise.

First, take note of the state of the Volume Shadow Copy service before going any further. If the Volume Shadow Copy service is not already running, which isn’t by default, then using ntdsutil or vssadmin as described below will start the service for you. Remember to set the service back to its original state once finished.

Then, confirm the location of the ntds.dit file from the “DSA Database file” parameter:

At this stage, check the current size of the ntds.dit file and make sure there is at least twice as much free disk space. Once this is done, use the Windows built-in command-line tool ntdsutilto create a snapshot of the active directory database.

Now download the ntds.dit file from C:\$SNAP_201310241833_VOLUMEC$\Windows\NTDS\ and also get a copy of the SYSTEM registry hive (eg. reg.exe save HKLM\SYSTEM c:\system.save).

Cleanup when done. Delete the copy of the system hive, and remove the snapshot:

Restore the VSS service back to its original state (ie. stop the service if it wasn’t running before, disable the service if you had to enable it etc.).

Note that you could also use the Windows built-in tool vssadmin (as in this howto ), however vssadmin will not get you a “consistent” snapshot whereas ntdsutil is the correct tool to properly backup the ntds database. That said, ntdsutil on Windows 2003 can’t create snapshots so vssadmin should be used instead in this particular case.

If ntds.dit appears to be corrupted, use the built-in command-line tool esentutl to try to repair it:

Now it’s time to dump password hashes using secretsdump:

You can also dump the password history with the -history option (since r961 ).

• AD Replication (EXPERIMENTAL)

This technique is less intrusive than the Volume Shadow Copy technique as it does not require you to create a snapshot of the AD database, start the VSS service, or even to interactively logon to the DC. It is also your best bet if the server has been hardened by stripping administrators of Se* privileges, completely disabling the VSS service or others, forbidding the creation of new services etc.

This technique consists of replicating the Active Directory database locally on your own system. AD replication normally happens when a new DC is added to a domain, however adding a DC is rather intrusive as it creates new objects within the AD database and leaves permanent marks even after the DC has been removed. Therefore we need a tool that only performs the replication step, and nothing else.

To my knowledge, there are no public tools to do this yet, although this technique has been talked about before at SSTIC 2010 by Aurelien Bordes who gave the lightning talk “Fiabilisation d’outils” and did a live demo of his private tool.

Instead of writing a standalone tool from the ground up, we can just modify Samba for our own purposes as it already implements the entire procedure of adding a new DC to a domain. Our changes simply consist of disabling each step that pushes changes to the AD in order to only retain the replication step.

Here is our amazing patch for samba-4.1.0:

After applying this patch, prepare your system to perform the replication process:

Now, launch the replication:

Then, use the Samba buitlin tool pdbedit to dump the NT hashes locally:

Samba doesn’t seem to provide a tool to dump the password history, or the LM hashes (if the DC stores them), but you can use this simple python script samba-pwdump.pyto extract them directly from the LDB database:

To highlight any differences before and after the replication, I compared the LDIF exports of the Root DSE and the base DNs of the Active Directory: