Your guide to NTLM relay, Part 2: Delivering relay attacks

For better understanding of the topic, I strongly recommend reviewing this article. First of all, let’s agree on terms.

Imagine a situation: a client attempts to authenticate from a host called Work1 to SMB; while an attacker hijacks the client’s session and authenticates to LDAP. Hereinafter, this case is called Relay from SMB to LDAP.

Another example: a client attempts to authenticate from Work1 to HTTP; while an attacker hijacks this session and authenticates to SMB. Further in the article, this case is called Relay from HTTP to SMB.

Clients

To implement a relay attack, you need both a client and a server, and this model is implemented in ntlmrelayx. RelayServers were discussed in the previous article; while this one examines RelayClients.

SMB (445/TCP)

Authentication can be relayed to SMB from any other protocol. The main prerequisite for a successful relay attack is as follows: SMB signing must be disabled on the target host. To check this, use the following command:

In the screenshot below, SMB signing is enabled; accordingly, you cannot deliver an SMB relay attack on this host.

By contrast, in the next example, the SMB signing requirement is disabled, and the target host is susceptible to relay attacks.

To automate the process, use the following command:

SMB relay attacks can be delivered in multiple ways. The simplest variant is to relay an account that has local admin rights on the target host to an SMB workstation. In the course of this operation, SAM hashes will be dumped, and you’ll get NT hash of the local admin and gain a foothold on the target host.

But if the relayed account has no rights, you’ll get a failure message, and that’s it.

If SMBv2 is used, the -smb2support flag must be added. As a target, you can specify the file where your targets are listed in order of priority and protocols to be attacked are specified. Its approximate format is shown below:

To input such a file containing the list of targets, use the -tf flag:

It must be noted that usually you receive not a single authentication, but several at once; accordingly, you can try to relay them to several targets. In addition, ntlmrelayx supports the multirelay mechanism that can turn one authentication into ten. Sometimes this works, but the result isn’t guaranteed. After the first error or access denial, the process will stop. To disable this mechanism when you attack multiple targets, add the --no-multirelay parameter to the command:

Don’t forget to add the required flags for each of the protocols that are on the list of targets. This applies to all other clients as well.

The interactive mode can be used to interact with network folders on the target host on behalf of the relayed account:

After that, a shell will be deployed on the local interface; use the following command to connect to it:

After the connection, you’ll get access to a regular smbclient from Impacket that uses the same syntax.

The interactive mode can be useful when you don’t know whether you have privileged rights on the target host or not. If there are no rights, and you use the standard mode, nothing will happen. If the relayed account has privileged rights, you will at least gain access to the entire file system and may find something interesting there. But there is an even more universal technique.

You can encounter a situation when you don’t have local admin rights, but still can gain a foothold on the target host on behalf of the relayed account using the -socks flag:

The interactive mode can be used to implemented the following scheme:

After a successful relay attack, you get an SMB session that can be used repeatedly with proxychains4. All you have to do is edit the config file /etc/proxychains4.conf. The following string should be added at the end:

To use an already established connection after editing the proxychains config, use the following syntax:

Note that you can authenticate this way only on the host you’ve relayed authentication to. You run ntlmrelayx with the socks flag and specify workstations where SMB signing is disabled as targets.

After editing the proxychains config, you can use proxychains to run smbclient without the password.

This method enables even an unprivileged user to gain a foothold on the target host, which can be useful in certain situations. But if the hijacked session is privileged, you can run secretsdump and get NT hashes.

This way you can run all Impacket tools, as well as respective scripts. In fact, this method enables you to perform truly amazing tricks (to be addressed later), but for now, let’s proceed to the next protocol.

LDAP (389/TCP, 636/TCP)

You can perform LDAP relay attacks only if the LDAP signing requirement is disabled on the server. To check this, use the script LdapRelayScan.py.

LDAP relay attacks can be extremely fruitful for the attacker; accordingly, Microsoft tries to prevent them in every possible way. NTLM authentication can be relayed to LDAP only if certain key conditions have been met:

1. Authentication from HTTP can always be relayed to LDAP;
2. Authentication from SMB can be relayed to LDAP in the following cases:
   • client uses NetNTLMv1 hash; or 
   • vulnerabilities CVE-2019-1040 and CVE-2019-1166 are present on domain controllers; and 
3. Exploitation of RemotePotato0.

No flags are required when you relay credentials from HTTP to LDAP:

As can be seen from the above screenshot, ntlmrelayx checks user’s privileges on the domain, adds a new user (if possible), assigns privileges to it using DCSync, and dumps domain info. If the user doesn’t have any privileges, then domain info is dumped, and that’s it.

You can dump ntds.dit using the account created as a result of your relay attack.

The screenshot below shows a domain dump obtained as a result of a successful LDAP relay attack.

A few words about Relay from SMB to LDAP. I am not going to discuss in detail the structure of each hash (this is beyond the scope of this article), but you must be aware of the difference between them in the context of this attack:

• NetNTLMv1 hash is a nice surprise to an attacker since it has a design flaw and doesn’t contain message integrity code (MIC), thus, making it possible to perform Relay from SMB to LDAP; and 
• NetNTLMv2 fixes this flaw, but is still marred by vulnerabilities (CVE-2019-1040 and CVE-2019-1166) that enable you to remove MIC and perform Relay from SMB to LDAP.

In all above-described situations, use the --remove-mic flag in ntlmrelayx:

If you attempt to authenticate to a patched controller using an NetNTLMv2 hash, your attack would fail.

But if the controller you authenticate to with a NetNTLMv2 hash isn’t patched, you’ll gain profit.

In a similar way, if you deliver a relay attack on a patched controller using an NetNTLMv1 hash, you’ll gain profit.

The interactive mode can also be useful:

After that, you can connect to the interactive shell and start interacting with LDAP. Built-in functions enable you to dump the domain, add a user to a group, remove it from there, exploit RBCD, create a new user, etc. Not much, but still…

Below is a cool example showing how you can use a RAW server (see the previous article for more detail).

Authentication has been relayed to LDAP, and an account was created as a result; even though it’s not an admin account, it still has the DCsync privilege.

RPC (135/TCP)

NTLM authentication can be relayed to DCE/RPC. This topic is usually discussed in the context of Potato attacks. But some vulnerabilities make it possible to execute commands on a host regardless of SMB signing requirements – because SMB isn’t used there at all.

First studies in this field were published in the Compass Security Blog. For three years already, these guys have been discovering new exploitation vectors for relay attacks on RPC. The first identified vulnerability was CVE-2020-1113; the next one, CVE-2021-26414; and in 2022, they demonstrated to the world an attack on AD CS ESC11.

To exploit CVE-2020-1113 (included in Impacket 0.10.0), use the following command:

As an example, let’s try to execute arbitrary code on a domain controller with SMB signing enabled.

Even if the domain is configured to require SMB signing, it’s still worth trying to deliver an RPC relay attack since a single missing patch can give you an advantage.

To exploit ESC11, you have to add to your Impacket some code that is available on GitHub.

To exploit ESC11, use the following command:

As a result of exploitation, you get a certificate on behalf of the account whose authentication was hijacked. For instance, you can coerce a domain controller to authenticate on your host, exploit ESC11, obtain a certificate on behalf of the controller, and compromise the domain!

HTTP (80/TCP)

Authentication can be relayed to HTTP from any other protocol; the main exploitation vector is AD CS ESC8.

If you are searching for AD CS without an account, check all controllers and all detected Windows servers for an URL in the http://<CA IP>/certsrv format. If you have an account, everything is much simpler: you can use a handy tool called Certipy.

To deliver a relay attack, use the following command:

The screenshot below shows Relay from RPC to HTTP.

In the next screenshot, you can see how authentication is relayed from RAW to HTTP and an ESC8 attack is delivered.

Conclusions

When it comes to brute-forcing, everything is clear: you find out the hash type and run hashcat; however, when you are dealing with relay attacks, the situation is more complicated. Due to various factors, it’s not always clear where to relay the hijacked authentication.

Below is a table presenting results of my experiments with relay attacks. All experiments were conducted using ntlmrelayx v0.10.0.

Under certain conditions, authentication from SMB can be relayed to any other protocol.

Authentication from DCE RPC can be relayed to HTTP, SMB, and RPC. Using RemotePotato0 techniques, it’s possible to get HTTP authentication on behalf of a privileged user and deliver a LDAP relay attack.

Authentication from HTTP can be relayed anywhere without restrictions.

Authentication from WCF can be relayed to HTTP, SMB, and RPC. LDAP requires separate research; I was unable to deliver such an attack without special preparations.

Bonus

In the course of an internal pentesting audit, you may encounter a situation when access is available via a VPN that prohibits reverse connections are (i.e. coerced authentication won’t be able to reach the attacker).

Imagine that the domain is small and fairly new; accordingly, it has no vulnerabilities or misconfigurations yet. But what immediately catches your eye is that SMB signing is disabled on almost all hosts, including Exchange servers that often possess high privileges on the domain.

During the reconnaissance stage, you were able to find local accounts from several domain hosts, but none of them have local admin rights. Using a local account, you can deliver a coerce attack. As a result, you get the domain account of a host, thus, gaining access to some network folders and more.

To access network folders, you perform a coerce attack so that SMB authentication comes to your Linux PC, and then you deliver an SMB relay attack to any domain node where SMB signing is disabled (see the diagram below).

In other words, even if you have only a local account, it’s quite possible to gain access to some domain resources. But you can get more out of it. Using this cunning trick, you can coerce another host after a successful relay attack. The scheme is as follows: Coerce + Relay + Coerce + Relay = Admin.

This attack chain becomes possible if SMB signing is disabled on Exchange servers, and Exchange servers act as admins for each other (as often happens). Using a local account, you get the domain account of a host and deliver an SMB relay attack to Exchange1; after that, you coerce it to authenticate on the attacker’s machine. After receiving its authentication, you deliver an SMB relay attack to Exchange2 on behalf of Exchange1 (see the diagram below).

As you can see, you don’t need a domain account or even a local admin account on some host to perform amazing tricks.

Protection

As can be seen from the table above, to protect your domain, you have to close endpoints where a relay attack can be delivered. The following measures can be recommended:

1. Enable SMB signing;
2. Enable LDAP signing;
3. Disable WebEnroll in AD CS;
4. Set the IF_ENFORCEENCRYPTICERTREQUEST flag in AD CS to True; and 
5. Install security updates on a regular basis.

In most cases, relay attacks become possible due to slight misconfigurations in infrastructure settings; therefore, simple security steps can be sufficient to protect your domain.

Epilogue

Relay attacks significantly expand attacker’s capabilities. If you conduct proper reconnaissance, assess the situation correctly, use all possible vectors to hijack authentications, and relay them to various endpoints, your prospects of success increase dramatically.

Good luck!