Credentials in Windows, and how to dump them remotely!
When it comes to trying to break into and owning machines on a target network, the first and most evident step to take is to hunt for any form of credential.
Unfortunately, (or fortunately !) When it comes to Windows systems, credentials don’t only revolve around a clear text password and a username, it gets to a whole new level and it can be a little bit overwhelming to grasp all the different forms and concepts at once! But still, through this post, we will try to get over the different types of credentials used, where and how they are stored, and most importantly, how to dump them remotely!
LM? NTLM? Net-NTLM? So confusing..or not :D
Before diving into it, it’s essential to take a look at the different types of hashes and protocols that are used in AD/Windows environments and grasp their concepts! The only annoying part is that they have quite similar names! but don’t worry we’ll work things out.
1- The LM hash :
LM hash, LanMan hash, or LAN Manager hash is an old, weak algorithm that was used in legacy windows systems to store passwords. It was disabled by default starting from Windows Vista, but can be found if it’s enabled by a GPO, or, on an older Windows version.
If you are curious about the algorithm used, I invite you to read this, it’s quite simple, thus easy to crack!
Example of an LM hash : aad3b435b51404eeaad3b435b51404ee
PS : “aad3b435b51404eeaad3b435b51404ee” is the Null hash.
2- The NT hash :
It’s the format currently used to store hashes in Windows environments. It’s based on the MD4 algorithm. Sometimes it’s referred to as the NTLM hash, which can cause some confusion!
Example of an NT hash : e19ccf75ee54e06b06a5907af13cef42
The NT and LM hashes are found together when dumping passwords from a Windows machine, in this format :
aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42
LM : NT3- The NTLMv1/v2 hashes :
NTLMv1/v2 are part of the NTLM (New Technology LAN Manager) suite of Windows protocols, for authentication. They are challenge-response protocols that use the LM hash. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN).
In a nutshell, when a user wants to authenticate to a certain resource, the server hosting that resource sends a challenge, which is a random string that is unique on each session and asks the user’s machine to encrypt it with the user’s LM hash. Once the response is sent, the server hosting the resource sends the encrypted challenge, the challenge, and the username to the domain controller (which knows all the passwords of the users), the DC will then encrypt the received challenge with the user’s password hash, if the value is the same as the response received, access is permitted!
NTLMv2 is the newer version of NTLMv1, which is intended as a cryptographically strengthened replacement for NTLMv1. It is supported by default starting from Windows 2000.
In fact, NTLM was replaced by Kerberos as the default authentication protocol. But it is still maintained and enabled in all Windows systems, for compatibility purposes between older clients and servers. Also, it is still the protocol used by default when it comes to interacting with certain services like SMB.
Example of NTLMv1 hash :
u4-netntlm::kNS:338d08f8e26de93300000000000000000000000000000000:9526fb8c23a90751cdd619b6cea564742e1e4bf33006ba41:cb8086049ec4736c
Example of NTLMv2 hash :
admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030
NTLMv1/2 hashes are also referred to as Net-NTLM hashes.
Where to find hashes?
The NTLMv1/v2 hashes are the types of hashes that can be captured by attacks like Man in the middle, where the attacker inserts himself in the middle of the network in order to listen and interact with the challenge-response traffic and eventually capture these hashes.
More explications about an example of this attack can be found here :
Other types of hashes are evidently stored in machines. They can be found in different places, like the SAM database, LSA secrets, or the NTDS.dit file.
1-The Security Account Manager (SAM) :
The Security Account Manager is a database that stores information about the local users of the machine and their hashed passwords.
SAM is part of the registry. It’s stored in the HKEY_LOCAL_MACHINE\SECURITY\SAM subkey and duplicated to the HKEY_LOCAL_MACHINE\SAM key. At the file-system level, the SAM registry files are stored together with the rest of the registry files under C:\Windows\System32\config.
2-The Local Security Authority :
The Local Security Authority (LSA) is a protected system process that authenticates and logs users onto the local computer, it maintains information about all aspects of local security on a computer.
LSASS.exe is the Local Security Authority Server process. It is an executable file located in the C:\Windows\System32\ folder and used to enforce security policies, meaning that it’s involved with things like password changes and login verifications. Upon authentication, It queries the SAM database in order to check for the validity of the credentials submitted. LSASS stores credentials of users with active Windows sessions in memory. The stored credentials let users seamlessly access network resources without re-entering their credentials each time. The credentials stored in the LSASS memory aren’t only of local users, but it also includes domain accounts credentials.
Another place where we find credentials is LSA Secrets. It is a registry location that contains important data that are used by the Local Security Authority like authentication, logging users on to the host, local security policy etc. LSA secrets are encrypted and stored in HKEY_LOCAL_MACHINE/Security/Policy/Secrets, the key to decrypt them is stored in HKEY_LOCAL_MACHINE/Security/Policy.
One last thing to add, in the legacy Windows version, passwords were stored in clear texts in the LSASS memory, to support WDigest authentication (an old authentication protocol). In the newer Windows version (from Windows 8.1 and Windows Server 2012), LSASS is prevented from storing credentials in clear text, but this restriction can be easily bypassed by a simple registry modification (when high privilege access is granted on the machine).
3-The NTDS.dit :
NTDS (New Technologies Directory Services).DIT (Directory Information Tree). It is a database that stores different pieces of information about the Active directory, including the credentials of domain members. Obviously, this file is only found on Windows Server machines that are Domain controllers. You can find the NTDS file at “C:\Windows\NTDS”.
How to remotely dump these hashes!
In order to dump the credentials on a certain machine, you must compromise a user who is a local administrator on that machine. Once a user is compromised, one of the first steps is to attempt to authenticate to the different machines on the network and identify on which machines that user is a local administrator. Then, you can proceed to dump credentials on those machines. In addition to compromising more users and moving laterally across the network, this can even lead to obtaining the credentials of a domain admin...It all depends on the hygiene of the sys admins and how poorly privileges are managed across the network.
1-Credential Dumping with Secretsdump.py :
First, I’d like to cover the secretsdump python script that comes in the impacket toolkit. It’s like the swiss army knife of credential dumping, as it allows you to dump credentials present in the SAM database, LSA Secrets, and NTDS.dit file with a one-liner. This will allow us to analyze the different forms of hashes retrieved and better understand them.
To run secretsdump, all you have to do is download the impacket toolkit from here. As options, it takes the domain name, username, the password or hash of the user to authenticate as, and the IP address of the target machine.
Example :
secretsdump.py domain_name/username:password@ip_machine
secretsdump.py domain_name/username@ip_machine -hashes LM:NT
In my small lab environment, I set up a Domain controller with the domain name ssi.dz, and user1 and user2 as domain users. I also joined to it a machine named COMPUTER2.
I run secretsdump on COMPUTER2 (which lives at 192.168.1.20) with user1 credentials. (PS : user1 is a local administrator on the machine COMPUTER2).
Let’s analyse this :
[*] Target system bootKey:
This is the machine’s bootKey, which is used to decrypt the SAM, LSA secrets, and cached domain credentials among others.
The SAM database :
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash) :
secretsdump is dumping the SAM database in that format (rid 500 is for administrators, 501 is for guests, rid>1000 is for users that were not created by the system).
If you get ‘aad3b435b51404eeaad3b435b51404ee’ in the LM hash, it means you’re dealing with a version of Windows where LM hashes aren’t supported by default (new Windows versions).
Example of the output : Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[*] Dumping cached domain logon information (domain/username:hash) :
These are the pieces of information about credentials (domain users credentials) stored in the registry for verification and validation when a domain-joined computer cannot connect to Active directory during a logon. Cached logon information cannot be used to access resources (they can’t be presented for authentication), they are only used for local verification.
The only hopeful method is to try and crack them, to extract plain text credentials.
Example of the output : SSI.DZ/Administrator:$DCC2$10240#Administrator#afc9966b706760909a899ee9dbf4c563
SSI.DZ/user1:$DCC2$10240#user1#6771fd35b76ef6eff18cff42f5363de4
SSI.DZ/user2:$DCC2$10240#user2#ca08b288d8fd2908cfc8d443f617ef83
As we can see, this machine has cached the credentials of the Domain admin, user1, and user2, because these three domain accounts have previously logged on on this machine.
LSA SECRETS :
[*] Dumping LSA Secrets :
This part reveals the Machine accounts passwords, I found this great article about leveraging a Pass the hash attack with a machine account hash.
DPAPI (Data Protection Application Programming Interface) is used to encrypt/decrypt some credentials saved on Windows systems. Like cookies and saved passwords on browsers.
while NL$KM is the key used to encrypt cached domain passwords.
NTD.dit :
Secretsdump can also dump the NTD.DIT file, where the target is a Domain controller. Here is the output when I ran it on the DC.
Oh damn…that was an awful LOT of hashes…Now that we understand a little better the hashes that can be dumped from different sources, we can explore some more tools that are usually used to get the hashes.
2-Retrieving credentials directly from the registry :
HKEY_LOCAL_MACHINE (HKLM) is a registry hive (A hive in the Windows Registry is the name given to a major section of the registry that contains registry keys, registry subkeys, and registry values), it includes three keys that we are interested in: SAM, SYSTEM, and SECURITY.
The SAM database information is extracted from SAM & System key, while cached credentials and LSA secrets are extracted from System & Security.
The first step is to get a copy of the SYSTEM, SECURITY, and SAM hives and download them back to your machine. We will place the copies in a temp folder, I did this over psexec :
reg save HKLM\sam %temp%\sam
reg save HKLM\system %temp%\system
reg save HKLM\security %temp%\security
To upload the files to your machine, use the get command.
Don’t forget to clean up and delete the dump files :
To read the extracted files, we can use secretsdump :
secretsdump.py -sam sam -security security -system system LOCAL
You can even use creddump, which includes the three tools lsadump, cachedump, and pwdump.
3-From the Security Account Manager (SAM) :
Using Metasploit : Metasploit is an extremely famous and useful hacking framework, it contains a collection of exploits that can be used directly on targets. After having a meterpreter session (a metasploit shell) on the target’s machine, you can use the hashdump command to dump the content of the SAM database.
Using mimikatz from metasploit : Mimikatz is the swiss army knife when it comes to credentials on Windows. It’s a post-exploitation tool that dumps passwords from memory, and hashes among others.
You can load mimikatz on a meterpreter session (with the command load kiwi) and then dump the SAM database (with the command lsa_dump_sam)
mimikatz can also be load within Empire (which is a post-exploitation framwork similiar to metasploit).
Using crackmapexec : (a.k.a CME) is a post-exploitation tool from which you can leverage a bunch of cool attacks, one of them is dumping credentials!
crackmapexec smb 192.168.1.20 -u ‘user1’ -p ‘PasswordUser1’ — sam
4-From the Local Security Authority :
Dumping LSASS memory Using Procdump: ProcDump is a free command-line tool published by Sysinternals whose primary purpose is monitoring an application and generating memory dumps of the chosen process. You can download it from here.
To run Procdump remotely, I established an SMB session with the target machine, then I used the “put” command to upload the Procdump executable to the target machine.
The command to execute in order to generate the memory dump goes as follow :
procdump.exe -accepteula -ma lsass.exe mem.dmp
- accepteula: automatically accept the Sysinternals license agreement
- -ma: write a dump file with all process memory (lsass.exe) in a .dmp format.
To upload the dmp file to your machine: get mem.dmp
Ps: don’t forget to clean up the mess.
The next step is to read the dmp file, for that we can use mimikatz with the following command :
privilege::debug
sekurlsa::minidump mem.dmp
sekurlsa::logonpasswords
Mimikatz is a tool developed for Windows, but if you want to keep working on Linux, I’ve found this brilliant tool called pypykatz, which is a Mimikatz implementation written in Python and can be run on Linux.
To read the dmp file using pypykatz, the command goes as follow :
pypykatz minidump mem.dmp
I found this awesome python script called lsassy, it’s a tool that automates this whole process, and allows you to launch this attack with a one-liner. It also uses different methods (5 methods in total), here is a nice explanation :
lsassy has been integrated as a module in Crackmapexec, I tried it on a machine where both the domain Admin and the user user1 have been authenticated, here is the result :
Dumping LSA secrets Using mimikatz from metasploit : We’ve seen previously how to load mimikatz from a meterpreter session to dump the SAM database, the same can be done to dump LSA Secrets.
load kiwi
lsa_dump_secrets
Dumping LSA secrets Using Crackmapexec: LSA secrets can also be dumped using crackmapexec.
crackmapexec smb 192.168.1.20 -u ‘User1’ -p ‘PasswordUser1’ — lsa
What’s the next step?
One obvious reflection upon obtaining any sorts of hashes is to try and crack them, hopefully, to get clear text passwords and move easily across the network. However, if a strong password policy is present, and cracking doesn’t give a result, other choices are always possible. If you have obtained some NTLMv1/2 hashes by a MITM attack, you can directly relay them to the next target. You can find an example of a relaying attack explained here.
If you have obtained some NT/LM hashes, you can also pass them around the network in order to authenticate without having to crack the hashes. This attack is called “Pass the hash”, and it will be covered in the next blog.
Thank you for reading, and stay tuned for more :)
