NTLM relay attack detection

Detecting NTLM relay attacks 

To detect NTLM relay activity in a network we need network telemetry and logon audit logs from the endpoint. 

Detecting NTLM relay attacks requires an odd approach, as we need to correlate the IP Addresses with the host names. 

This means we need to have an inventory/list of IP addresses assigned to workstations. In big corporate environments with thousands of assets in the network, keeping tabs on this is difficult. 

In such cases, network telemetry will help us determine the IP addresses of legitimate devices and make it easier to pinpoint the rogue machine.

Let's start off by opening a pcap file in Wireshark and listing the known IP addresses associated with domain-joined workstations and servers.

Viewing the endpoints included in the network traffic we can see few internal IP addresses.

The IP addresses ending with .1 and .2 are excluded because they act as gateways and are not assigned to actual workstations.

We can get host names for the IP addresses using NetBios Name service/NBNS Protocol.

Let's add a filter for this in Wireshark.

For the IP address 172.17.79.129: 

For IP Address 172.17.79.136:

For IP address 172.17.79.135 we can see there is no host name and instead some random data. 

From this, we have a short list of hostnames: 

1. Forela-Wkstn001 is assigned 172.17.79.129.

2. Forela-Wkstn002 is assigned 172.17.79.136.

3. Unknown Device is assigned 172.17.79.135.

Now, let's add a filter for smb traffic to and from the unknown device since we suspect it to be the attacker’s machine acting as a Man In The Middle (MITM).

In the above image, we can see that user “arthur.kyle” was involved in the authentication process and the unknown device is involved in this as well. 

We see the IP Address for the Wkstn002 machine as well. Seeing the traffic direction, user arthur.kyle is the user account in Wkstn002. This now screams that the credentials were stolen and relayed from the user arthur.kyle from workstation 2.

The next stream of packets now involve the same unknown device in the authentication process with the 172.17.79.129 IP address. This is another red flag as to why the same user account (arthur.kyle) is involved in authentication from two different machines (one is legitimate and the other is an unknown MITM device). 

These packets tell us that: 

1. Arthur Kyle on Wkstn002 had hashes stolen by the attacker. One way this can happen is if the user had a typo when navigating to file share and the attacker was running responder to intercept traffic in the environment. (We’ll discuss this later.)

2. The hashes stolen by the attacker were then immediately relayed to the target system, which in our case, is Wkstn001. 

3. The attacker then authenticates and logs in to the target machine(Wkstn001 using the arthur.kyle account) and then dumps the SAM Hashes from the remote machine. This is the default behavior of ntlmrelayx tool from impacket used for this purpose. After this, they can log on to the machine with the primary user account of that machine whose hash was dumped remotely.

Event log analysis

We are provided Security events logs from Wkstn001.

Let’s look at log events here, filtering for Event ID 4624.

In this specific event, we have multiple indicators that an NTLM relay attack did occur and authentication was conducted from the attacker’s machine using stolen credentials.

The first indicator we see is that Security ID Says it is NULL SID and we have no Logon ID, LogonGUID is also null.

In network information, we can see that the source workstation says WKSTN002. In IP address we see 172.17.79.135. (Suspicious!)

Workstation002 has an IP address of 172.17.79.136, but it shows .135, which was an unknown device.

Another indicator we see is that the log-on process says it’s NTLMSSP, which we confirmed from our network traffic analysis.

This confirms that the unknown device stole credentials from wkstn002 and used them to log on to wkstn001. 

Remediation

NTLM authentication should be disabled if possible. Organizations should use more robust protocols, such as Kerberos, instead.

To prevent the interception of authentication via NTLM, Server Message Block (SMB) signing must be enforced across the domain. 

SMB Message signing secures messages sent between the client and server during NTLM communications preventing the interception of NTLM authentication messages.