Despite being a veteran protocol, New Technology Lan Manager (NTLM) remains one of the most common authentication protocols used in Windows environments. Even though Kerberos offers enhanced security features over NTLM, many systems and functions still depend on NTLM, making it impossible for most organizations to move away from it entirely.
Unfortunately, there are a number of known attack techniques that exploit the way NTLM operates in order to gain a foothold in a target environment. Additionally, these attacks leverage misconfigurations and related protocols (such as SMB, IPv6, LLMNR, NBT-NS) that are also quite common in internal networks. Moreover, tools to find and exploit such misconfigurations are readily available, meaning that novice attackers can leverage these techniques.
That’s why the NTLM relay attack has been a mainstay for attackers for many years. In fact, NTLM relay attacks were leveraged in 33% of the compromises we could achieve from 2019-2021 (see our Attack Vectors Report for a full analysis of our most common attack vectors). The impact of the attack can range from compromising an account to full domain takeover, allowing an attacker to access to virtually all areas of your network and steal sensitive data. In any case, the NTLM relay attack remains one of the most common means of achieving a foothold in a target environment.
Attacker techniques have evolved, and new NTLM exposures have been identified, resulting in various iterations of the NTLM relay attack. At a basic level, the attacker uses man-in-the-middle techniques to listen in on network traffic, ideally listening for some form of authentication challenge being exchanged between the client and server. Authentication challenges are critical to this form of attack. Throughout the remainder of this post, we examine different forms of the attack, as well as ways to protect your network.
How To Perform NTLM Relay Attacks
1. Pre-requisites
To perform any basic NTLM relay attack, some prerequisites will need to be met:
- LLMNR or NBT-NS is enabled: There must be broadcast traffic in the environment such as Link Local Multicast Name Resolution (LLMNR) and NetBIOS Name Resolution (NBT-NS)
- SMB signing is not required: There must be a Server Message Block (SMB) server(s) that does not require signing
For more detailed information on LLMNR and NBT-NS spoofing please refer to our Back to Basics: LLMNR and NBT-NS Spoofing blog
1a. To identify if SMB signing is required, we can use CrackMapExec with the –gen-relay-list flag to compile a list of all SMB servers with signing disabled. Download CrackMapExec, follow the installation guide, and run CrackMapExec using the following syntax: crackmapexec smb <CIDR> –gen-relay-list relaytargets.txt
In our example above, the results show SMB signing on the domain controller, but the other two clients in the domain have signing disabled, which makes them perfect relay targets. The list generated by CME will be used in future attacks.
1b. To identify if LLMNR or NBT-NS is enabled on the network, we can run Responder to capture LLMNR, NetBIOS, and multicast DNS (mDNS) broadcast traffic. Download Responder, follow the setup guide, and reconfigure the Responder.conf file to the following configurations: SMB = Off, HTTP = Off. This will ensure Responder only listens for SMB and HTTP traffic and does not respond.
1c. Run Responder.py with the following syntax: sudo python Responder.py -I wlan0 -dwv. The -dwv flags will enable the Responder to poison LLMNR, NBT-NS, and mDNS traffic. Alternatively, Responder can be run with -A flag to analyze broadcast traffic and not respond. If LLMNR, NBT-NS, or mDNS traffic is enabled, then we should see broadcast traffic in the console.
We see Responder poisoning LLMNR, NBT-NS, and mDNS traffic. This means that we have verified LLMNR and NBT-NS are enabled on the network, which verifies that we have everything we need to attempt an NTLM relay attack.
1d. After setting up Responder to poison LLMNR and NBT-NS traffic, we wait for a user to access an SMB share with signing disabled. Below is an example of one of the domain users accessing an SMB server without signing required.
1e. After a user attempted to access SMB server “Share2”, we were able to successfully capture NetNTLMv2 hashes using Responder. The next steps would be to either use these captured hashes in a relay attack or crack them using Hashcat.
NetNTLM vs NTLM Hashes
It is important to note that NetNTLMv1/v2 hashes are not NTLM hashes that can be used in pass-the-hash attacks. NetNTLM hashes like the ones we captured in Responder can only be used in relay attacks or cracked using Hashcat but CANNOT be used in pass-the-hash attacks. These hashes can be captured using Responder and are used for network authentication, which is the result of the challenge and response protocol. On the other hand, NTLM hashes CAN be used in pass-the-hash type attacks. NTLM hashes are stored in the SAM database in the domain controller, which can be acquired by dumping the SAM database using a combination of tools (NTLMRelayX, mitm6, PetitPotam, Printerbug, Responder, secretsdump.py). In the following sections, these different methods of capturing NTLM hashes will be explored.
2. Classic SAM Dump Using NTLM Relay and Responder
This NTLM relay attack is one of the most common methods, which requires the use of ntlmrelayx.py and Responder. This attack is very similar to the previous attack we conducted; however, in this scenario, we are using both Responder and ntlmrelayx.py. Like the previous attack, this method relies on LLMNR or NBT-NS being enabled.
2a. Download Impacket, follow the setup guide and run ntlmrelayx.py using the following syntax: python ntlmrelayx.py -of <SAMhashdump> -tf <relaytargets> -smb2support. For the -tf flag, you will need to supply ntlmrelayx with a file that contains the list of SMB shares with signing disabled.
2b. Run Responder.py with the following syntax: sudo python Responder.py -I wlan0 -dwv. NTLM relay will be our SMB and HTTP server for this attack, so ensure Responder.py is configured with SMB = Off and HTTP = Off.
2c. After starting Responder and ntlmrelayx.py, we need to wait for a user to access one of the SMB shares with signing disabled.
2d. After a user attempts to access the SMB server “Share”, we can successfully capture the local SAM hashes using NTLM Relay and Responder. The first attempts to authenticate failed because we were attempting to relay a computer towards itself, which isn’t possible due to patches. The third relay attempt succeeded because we accessed the SMB server “Share” from a remote client. As a result, we were able to dump the SAM hashes from the remote host.
These NTLM hashes we were able to gather from this SAM dump can be further used in a pass-the-hash attack to further exploit the target.
3. Proxy Chaining SMB Connections
In this scenario, we will replicate the same relay we produced previously, but with the addition of using SOCKS and proxy chains. Using this method will give us the ability to perform other attacks with different tools by using the other scripts found within Impacket. Another benefit of this approach is that it gives you a better overview of your successful relayed attempts. This approach requires the use of ntlmrelayx, proxy chains, and secretsdump.py.
3a. Run ntlmrelayx.py using the following syntax: python ntlmrelayx.py -tf <relaytargets> -smb2support -socks
3b. After setting up ntlmrelayx.py with SOCKS, we needed to wait for a user to access one of the SMB shares with signing disabled.
3c. After the user attempted to access SMB server “Share2” and another user attempted to access “Share”, we were able to successfully create SMB connections using the SOCKS proxy. We used the SOCKS command to view the active relay sessions available in NTLM Relay and got an overview of all the SMB connections to see which ones were successful. Based on the SOCKS output, we saw we had two active sessions we could use. From there we could use proxy chains to run secretsdump.py to dump the SAM database.
3d. Download ProxyChains and reconfigure proxychains4.conf to set proxy chains to the NTLM relay SOCKS proxy. In our example, this was achieved by modifying the proxychains4.conf file with the following configuration:
3e. Using ProxyChains, we used the secretsdump.py script from Impacket to dump the SAM hashes (NTLM hashes) from one of the active SMB relay sessions. Run proxy chains with the following syntax: sudo proxychains secretdump.py -no-pass <domain>/<user>@<host_ip>. This method enabled us to use any tool we want and ignore any passwords required by using the relay credentials. For example, instead of running secretsdump.py, we could use other scripts such as getST.py, addcomputer.py, rpcdump.py, getUserSPNs.py, getADUser.py, etc.
4. Coercing Authentication
There are multiple methods that can be used to coerce authentication. The most popular approaches typically use Printerbug and PetitPotam. For the purposes of this walkthrough, PetitPotam and NTLM Relay were used to attempt coercion.
4a. The following syntax was used to run PetitPotam: sudo python PetitPotam.py -u ‘user’ -d <domain> -p ‘password’ <user>@<hostname>/<directory> <target_ip>.
4b. The following syntax was used to run ntlmrelayx.py: sudo python ntlmrelayx.py -t ldaps://<domaincontroller_ip> -wh attacker-wpad –delegate-access. The –delegate-access flag attempts to create an account, which can be used to impersonate any domain user including the administrator account. After running ntlmrelayx.py, we were able to successfully enumerate the domain information and add a user to the domain. The domain information can be accessed via the lootdir directory as shown in the screenshot.
5. MITM6—IPv6 Spoofing & Delegation Relay
In many Windows operating systems, IPv6 is enabled by default. In many corporate environments, IPv6 is largely underutilized due to the slow adoption of the newer protocol. Threat actors can leverage this by spoofing IPv6 addresses and taking over DHCP requests using mitm6. As a result, attackers can force authentication between the attacker’s host and the victim’s host. This NTLM relay attack will involve the use of ntlmrelayx.py and mitm6.
NOTE: LDAPS and Kerberos must be set up within the target environment prior to attempting this specific approach
5a. Download MITM6. We spoofed any requests and hijacked DHCP sessions within our test environment using the mitm6 tool. The following syntax was used to start mitm6: sudo python mitm6.py -d <domain> –ignore-nofqdn
5b. Run ntlmrelayx with the following syntax: sudo python ntlmrelayx.py -t ldaps://<domaincontroller_ip> -wh attacker-wpad –delegate-access. The -wh flag was used to set the proxy host and enable serving a WPAD file for proxy authentication attacks. For this demo, the WPAD_HOST was attacker-wpad.
5c. Restart the target hosts in your test environment or wait for a user to attempt to log in to an internal resource. The best time to run this type of attack would be early in the morning or after lunchtime. This is because we need to capture DHCP requests, which occur after a host is restarted and when logins occur the most.
5d. After restarting one of the target hosts, we successfully relayed to LDAPS from an unauthenticated source. Our NTLM relay was able to successfully add a new domain machine account and a computer for the relayed victim. This allowed us to impersonate any user within the domain.
5e. Utilizing getST.py, we attempted to get a service ticket for the CIFS service for the vulnerable host while impersonating a domain user. This would enable us to use the service ticket with secretsdump.py to dump the SAM hashes. The following commands were used to impersonate one of the user accounts using the machine account created by the NTLM relay in the previous step. The syntax for the commands is provided below:
- sudo python getST.py -spn cifs/<relayed_host>.<domain> ‘<domain>/MWPSDJLO$:DuuA$Te>pmbk2^@’ -dc-ip <domaincontroller_ip> -impersonate <domain user>
- export KRB5CCNAME=<user>.ccache
- sudo python secretsdump.py -k -no-pass <host>.<domain>
We were able to successfully compromise the target and dump the SAM hashes using secretsdump.py.
How to Mitigate NTLM Relay Attacks
As noted earlier, most organizations are not able to disable NTLM entirely because other technology in their environments are still dependent on it. Instead, organizations need to learn how to manage the risk NTLM presents. While the risk cannot be completely eliminated, you can help mitigate NTLM relay attacks through the following recommendations.
- Enforce SMB signing.
- Disable NTLM authentication on HTTP endpoints to mitigate against ESC8.
- Disable LLMNR/NBT-NS and IPv6.
- This prevents an attacker from poisoning LLMNR/NBT-NS and IPv6.
- Turn on Extended Protection for Authentication (EPA)
- EPA needs to be required if Active Directory Certificate Services (AD CS) are being used with Certificate Authority Web Enrollment and/or Certificate Enrollment Web Service.
- For services that permit NTLM authentication, ensure that EPA is enabled and SMB signing is required.
This article was written by Erica Cummings, with assistance from Nick Woodman.
Sources:
- https://www.trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022/
- https://www.thehacker.recipes/ad/movement/ntlm/relay
- https://www.secureauth.com/blog/what-is-old-is-new-again-the-relay-attack/
- https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html
- https://aas-s3curity.gitbook.io/cheatsheet/internalpentest/active-directory/exploitation/exploit-without-account/smb-relay
- https://adam-toscher.medium.com/top-five-ways-i-got-domain-admin-on-your-internal-network-before-lunch-2018-edition-82259ab73aaa
