SMB/NTLM Relay
Last updated
Last updated
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.
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 client sends the Type 1 message, which contains the
user name (in plaintext)
The server generates the challenge and sends it back to the
client
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.
The algorithm used to compute the LM Hash is DES and here are the steps used by Windows to do so:
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.
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.
Force the client (target) to start a connection to us (fake server)
Use Man-in-the-Middle techniques in order to sniff the client response
first go to responder config file and disable smb and http:
we can also use crackmapexec to generate a list of all hosts in a network with SMB signing disabled:
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:
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:
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.
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:
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
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.
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.
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.
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.
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.