Definition

The NTLM protocol is an old authentication protocol used by Windows machines to authenticate at domain or network level. It’s a Challenge / Response protocol, so it lets you authenticate to a server without the password ever passing over the network.

This protocol is widely used by companies in conjunction with the Kereberos protocol. Only companies with a good cyber maturity no longer use it, as it’s not easy to do without.

How it works

When a client wants to authenticate to a server using this protocol, the server will send a challenge to the client, who will try to solve it using the hash of his password. Once the challenge has been solved, the client will send the response to the challenge, and the server will perform the same operation, comparing the client’s result with its own. If the result is the same, this means that the client possesses the secret with which he had to solve the challenge, and is therefore who he claims to be.

The NTLM protocol is encapsulated by several other protocols, such as SMB, LDAP or HTTP. These protocols can use NTLM to authenticate a client. This is made possible by SSIP (Security Support Provider Interface), an interface provided by Microsoft that enables the NTLM protocol to be reused without having to be rebuilt from scratch.

The NTLM Relay attack

The NTLM Relay attack is a Man-in-The-Middle attack, i.e. the attacker will position himself between the client and the server, pretending to be the client to the server and vice versa.

There are several possible methods for doing this, and the one we’re going to look at here is a method using multi-cast resolution protocols.

Multicast/broadcast resolution protocol

Windows devices use various protocols for domain name resolution. The most commonly used are :

  • DNS (Domain Name System)
  • LLMNR (Link Local Multicast Name Resolution)
  • NBT-NS (Netbios Name Service)
  • mDNS (Multicast DNS)

The first to be used is DNS, but if that fails to resolve the domain name you’re looking for, the other 3 are used if they’re enabled. The problem is that these protocols are broadcast, i.e. they send their resolution request to the whole local network, hoping that someone will respond. Thus, an attacker can illegitimately respond to these requests and demand authentication from the client.

Once this authentication request has been retrieved, the attacker can relay it to a server to impersonate the client. This process is clearly explained in the diagram below:


For this attack to work, it is important to specify that the signature must not be forced on the protocols for the target serverus. Indeed, if the signature is forced, the attacker will not be able to relay the requests.

In practice

To carry out this attack, you need to use 4 tools: responder, nxc, ntlmrelayx and proxychains.

We start by launching responder, which will allow us to listen to LLMNR, NBT-NS and mDNS requests:

1
responder -dvw -I eth0

-d to launch a dhcp server

  • v for verbose
    -w to launch a wpad server
    PS: Don’t forget to disable the SMB, HTTP and LDAP severs in the configuration in: /etc/responder/responder.conf

Next, use this command to retrieve the list of servers that do not require SMB protocol signatures:

1
nxc smb --gen-relay-list smb_targets.txt 10.10.10.0/24

Then we use ntlmrelayx to relay requests from clients and servers on the network with this command :

1
impacket-ntlmrelayx -socks -smb2support -tf smb_targets.txt

-socks : to store sessions in socks
-smb2support : support for SMB version 2
-tf list of machines not requiring signature

By default, ntlmrelayx opens a sock on port 1080, so you need to modify the proxychains configuration in /etc/proxychains4.conf.


Subsequently, when authentication attempts are relayed, we can retrieve :

You can interact with them using the command :

1
proxychains4 nxc smb 192.168.1.161 -u TESTADMIN -d TEST