— Non-Admin NTLM Relaying & ETERNALBLUE Exploitation

Kory Findley (k0fin)
Jul 2 · 7 min read


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.

Attack Scenario

  • Connected to a local internal network segment.
  • Can send broadcast protocol traffic to hosts within our local internal network segment.
  • No credentials for local or domain accounts.
  • Attacker machine is not joined to Active Directory.
  • Targets affected by ETERNALBLUE are accessible within our network segment.


  • No credentials or hash cracking required.
  • No socks proxy or proxychains required.
  • No need to be joined to domain.
  • Non-Admin credentials can still be abused to obtain RCE in SYSTEM privilege context against affected hosts.
  • Easy to use any type of payload we want for 3rd-party post-exploitation/C2.
  • Exploitation capabilities can be extended to support all variations of ETERNALBLUE for additional Windows version affected by the MS17–010 SMBv1 vulnerability.

How It Works

  1. Arbitrarily relay poisoned client’s credentials to ETERNALBLUE target(s).
  2. If the relay victim is a non-Admin (if the relay target returns an rpc_access_denied message for the relayed credentials), the authenticated SMB connection for the relayed user is used to perform a TreeConnectAndX setup to the target’s IPC$ share and create a Tree ID (TID).
  3. The TID is used to perform ETERNALBLUE exploitation against the target. After this portion of the exploit is sent, a packet is evaluated for a specific retStatus.
  4. If the retStatus condition is met, we should be able to continue the rest of the exploit and achieve RCE.
  5. Our shellcode is sent to the target before being triggered and executed.
  6. Disconnect the TID, logoff, and close the reused SMB connection.
  7. The SMB thread is completed.

How It’s Made

The script is included within a modified version of impacket found within the eternalrelayx project folder. It is simply a modified version of the 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.

Supported Targets

Currently, 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 code (however, the 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).

Attack Demo

Below, we can walk through a simple demonstration of using the PoC against an (extremely simple) Windows 7 SP1 / Windows Server 2008 R2 Active Directory setup.

Finding Relay Targets

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.

CME is used to discover an applicable Windows target which support SMBv1 and does not enforce SMB signing.

Finding ETERNALBLUE Targets

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.

Generating a Payload

Since 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 script written by Worawit Wang. Generating the payload looks something like this-

  • Compile 32-bit and 64-bit Windows kernel shellcode with NASM.
  • Concatenate user-mode and kernel-mode payloads into a single payload for each processor architecture.
  • Merge concatenated 32-bit and 64-bit payloads into a final payload.
A simple Python script included in the eternalrelayx project is used to generate a Meterpreter payload for the EternalRelay attack.

Configuring a Payload Handler

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.

The RC file included with is loaded into Metasploit (msfconsole) to configure and launch our payload handler.

Poisoning the Network

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.

Responder is configured to run without its SMB, HTTP, and HTTPS servers enabled. This allows Responder to be used for poisoning attacks without handling server connections or authentication attempts.
Responder is started in poisoning mode (-wrf) and listens for broadcast protocol traffic which can be poisoned to coerce clients into connecting to our relay server.
An attempted connection to a host name which does not exist in the local network triggers an NBNS lookup.


Once poisoning is configured and running properly, 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).

A non-Admin user is relayed using, which successfully launches the attack against our relay target.

Meterpreter Callback and Code Execution

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.

The Meterpreter payload handler receives a callback from the payload on port 4444.

Additional Payloads

Currently, I’ve only fully tested with Meterpreter. Other payload methods for 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-

Features in Progress

  • Integrating for more reliable and practical exploitation across all affected Windows versions
  • Ability to use custom 1-liner payloads (PowerShell, etc.) for EternalRelay RCE
  • Using NTLM relay victims to simply scan / detect the presence of the MS17–010 SMBv1 vulnerability affecting Windows relay targets.


  • Skip Duckwall (passingthehash) for the original idea!
  • Tyler Robinson for passing the idea along and encouraging me to try it out!
  • Worawit Wang (sleepya) for his work around MS17–010 and ETERNALBLUE!
  • Dirk-jan Mollema (dirkjanm) and Alberto Solino (agsolino) for their work around impacket and!

Special Thanks & Shout-Outs

  • LETHAL Security — West Coast Hackers
  • illMob
  • pr3c0re
  • Tyler Robinson
  • 0ray
  • illwill
  • cheetz
  • Skip Duckwall
  • Vijay Bolina
  • Devin Ertel
  • 3nc0d3r
  • tactical_intel
  • dc0de
  • Robert CurtinSeufert
  • johnhsawyer
  • p00r0ne
  • jaybeale
  • haxorthematrix
  • TheBlindHacker
  • PermaNull