In this post, we will cover how to perform the EternalRelay attack, an attack technique which reuses non-Admin SMB connections during an NTLM Relay attack to launch ETERNALBLUE against hosts running affected versions of the Windows operating system. This attack provides an attacker with the potential to achieve remote code execution in the privilege context of SYSTEM against vulnerable Windows hosts without the need for local Administrator privileges or credentials.
The eternalrelayx.py script is included within a modified version of impacket found within the eternalrelayx project folder. It is simply a modified version of the ntlmrelayx.py script written by dirkjanm, which can be found in the official version of impacket maintained by SecureAuthCorp on Github. The ETERNALBLUE functionality added to the eternalrelayx project relies on the MS17–010 exploit project by sleepya.
Currently, eternalrelayx.py is a proof-of-concept to demonstrate the attack method, and supports ETERNALBLUE exploitation for affected releases of Windows 7 SP1 and Windows Server 2008 R2. The actual exploit code used in the PoC is a slightly modified copy of Worawit Wang’s eternalblue_win7.py code (however, the zzz_exploit.py exploit code included within his MS17–010 project is currently being integrated into eternalrelayx to drastically increase the reliability and practical use of this tool across all affected versions of Windows).
Below, we can walk through a simple demonstration of using the eternalrelayx.py PoC against an (extremely simple) Windows 7 SP1 / Windows Server 2008 R2 Active Directory setup.
First, we’ll find hosts within our segment which do not enforce SMB signing. Below, CrackMapExec (cme) is used to scan our local subnet for available SMB servers. Using cme with the --gen-relay-list argument will generate a list of IPv4 addresses for SMB servers which do not enforce SMB signing.
The generated list of NTLM Relay targets can be used to conduct further recon/enumeration and find targets which are (most likely) vulnerable to MS17–010. The output from cme above shows a Windows 7 Professional SP1 (7601) workstation which doesn’t enforce SMB signing and supports communications over SMBv1.
Although this workstation looks like the perfect target for our attack, let’s try to get a second opinion (if possible) using a module for MS17–010 detection included in Metasploit.
Since eternalrelayx.py will utilize a single BIN payload, any raw shellcode generated from 3rd party tools should be usable (such as a Cobalt Strike Beacon), and shouldn’t exceed 2000 bytes. The following example uses demo instructions for Meterpreter included in the eternalblue_sc_merge.py script written by Worawit Wang. Generating the payload looks something like this-
A callback server / payload handler needs to be configured. For the purpose of this walk-through, we will use Metasploit to create and configure a Meterpreter handler. An RC file is included with the eternalrelayx project which can be used to automatically start our payload handler.
NOTE: The default LPORT values in the RC file will need to be changed for each payload if the Meterpreter default port values for the payload being used are different (4444 for 64-bit and 4445 for 32-bit by default).
Just like a typical NTLM relay attack, we can start poisoning the network to coerce relay targets to connect to our relay server. Responder is used for this walk-through, although there are other tools and methods of accomplishing this.
First, we need to edit the Responder configuration file (Responder.conf) for Responder to work with relay attack tools. Normally, Responder will host its own arbitrary server listeners for various protocols (SMB, HTTP, etc.) while poisoning hosts within a target network. Since we want to relay authentication to remote targets within the network (rather than just intercept and (attempt to) crack NetNTLMv1 or NetNTLMv2 hashes), we will disable SMB, HTTP,and HTTPS servers for Responder.
After saving the configuration file, we can start up Responder and begin listening for broadcast protocol traffic which can be abused to poison local network segment clients.
Once Responder successfully poisons a victim, the victim will attempt to connect and authenticate to our relay server, which will then forward the authentication to the relay target. We can demonstrate this by performing a lookup for a non-existent host within the local network.
Once poisoning is configured and running properly, eternalrelayx.py is used to wait for victim client authentication. Once a relay victim’s non-Admin privilege context is confirmed, the attack is launched against the relay target(s).
After the attack completes, our payload handler receives a callback from the victim and a Meterpreter session is created with SYSTEM privileges. Commands such as sysinfo and getuid can be used to gather basic information about the currently compromised system.
Currently, I’ve only fully tested eternalrelayx.py with Meterpreter. Other payload methods for eternalrelayx.py are currently being tested and documented for added C2 and post-exploitation framework support (Cobalt Strike, Empire, etc.).
The eternalrelayx project can be found here-
https://www.github.com/k0fin/eternalrelayx