SMB Relay Attack

7 min readJan 14, 2022

The SMB Relay Attack is nothing but an MITM attack that abuses/bypasses the NTLM-over-SMB authentication mechanism.

If you’re thinking, “such jargon, much wow”, then buddy, you’re in safe hands here. We shall not cower from topics we don’t understand — we shall prevail!

Let’s get on with it🙂

Setting the stage…

SMB, or Service Message Block, is a communication protocol used for file-sharing across a network. It follows the client-server model, and is also used for supporting NTLM authentication.

NTLM, on the other hand, is a single-sign-on (SSO) tool used in Windows Active Directory environments. It implements a challenge-response mechanism via the NEGOTIATION, CHALLENGE and AUTHENTICATION messages to authenticate a user.

In the NTLM- or NTLMv2-over-SMB scenario, the negotiation, challenge and authentication messages are embedded in the SMB messages that the client sends to/receives from the server.

Before delving into why MITM works here, we need to know how it works.

MITM stands for Man-In-The-Middle and quite literally means just that. An attacker / pentester would position herself somewhere between the target and another system it connects to (a server, usually). She could then sniff the traffic, intercept it, or relay it as a means to an end, which is usually compromising the target machine or the target network.

In the SMB Relay Attack, the MITM strategy is used for relaying captured credentials to bypass authentication and impersonate the legitimate user. And this is made possible by 2 key shortcomings on the victim’s side:

Unsalted password hashes ( a major pitfall of NTLM authentication), and
Disabled SMB Signing (when enabled, it ensures the integrity of a message as well as confirms the legitimacy of its origin).

Thus, without enforcing integrity and authenticity checks, the service in question becomes vulnerable to an MITM relay attack.

Environment / Pre-requisites

The SMB Relay attack is used in Active Directory environments to gain foothold in the network.

A typical AD environment has at least 1 Domain Controller (DC) and some client PCs that connect to it.
The DC handles DNS, authentication-authorization, and administration of the network.
A client machine could be a Win10 PC that a user may log into with her domain account.

An AD account is a user or admin account that is linked to an AD domain. One can use the same account on multiple computers (if the computers are on the same network as the DC), and network access is handled via sessions.

Active Directory users fall into the following two categories:

A Domain User Account is a set of credentials (username and password) that is registered with the Domain Controller and assigned to a user.
A Domain Admin Account is similar to a User Account but it is assigned to an administrator. It has higher privileges than a user account.

In this article, the User_A and User_B (domain user accounts), along with the DC, belong to the domain COMPANY.

On a Windows client machine, there are two types of accounts:

a system account, or the machine account that is not part of the AD domain, is completely local to the machine and has local administrative privileges on the machine, and
an AD account, that a user can log on to the machine with.

In this article, the Machine_A and Machine_B accounts are system accounts.

An AD domain user account can be assigned administrative privileges on any machine in the AD network.

In the AD network used for this demo, User_A is admin on Machine_A, User_B is admin on Machine_B and User_A is also admin on Machine_A.

The above information may not be required to understand how the SMB relay attack works, but I’m just leaving it here to provide more clarity around AD components.

In the relay attack described in this article, we will be sniffing > capturing > relaying credentials of User_A to a vulnerable target in the network (Machine_B). For this to work, we need

…. a few assurances/pre-requisites, if you will:

SMB signing must be disabled on the target
the captured credentials must belong to a user who is an administrator on the target

…. and a couple of tools:

responder
ntlmrelayx from Imapcket

3, 2, 1 .. ACTION!

For the demo, I’ve set up my lab as follows:

A Windows Server 2019 as the Domain Controller
Two Windows 10 client machines (for User_A and User_B)
User_A is an administrator on Machine_B
A Kali attacker’s machine

Note All these computers must be part of the same subnet. Here, 10.0.2.0/24.

As we are assuming the role of the attacker, the tools and commands used in this demo will be run from the Kali machine.

Step 1 — Scan

Run an NMAP scan to identify potentially vulnerable machines in the target network.

sudo nmap — script smb2-security-mode -p445 10.0.2.0/24

Here, we are specifically looking at port 445 which is used by SMB, and script-scanning SMBv2. (Running a regular NMAP port scan with -sC and -sV flags without scripts will tell if there are machines on the target network running SMBv1 — which is, to put it lightly, a very vulnerable version of the service and is now deprecated.)

Server (or the Domain Controller) is at 10.0.2.7
Machine_A (where User_A is logged in) is at 10.0.2.5
Machine_B (where User_B is logged in) is at 10.0.2.6

Notice that communications to and from Machines A and B do not require SMB signing.

Step 2 — Responder

Responder is a tool used for Link Local Multicast Name Resolution (LLMNR) poisoning.

LLMNR is a protocol based on DNS that is used for finding resources on a small network, as an alternative to DNS.

When a user queries the LLMNR server for the location of a resource on the network, the server first requests for the user’s credentials to check if the user is authenticated to access the resource. The user provides credentials (NTLM hash) to the server, the server validates it and then allows access.

In LLMNR poisoning, an attacker can use tools like Responder to pose as a legitimate Name Server and capture the credentials of the querying user.

However, in an SMB Relay Attack, we don’t want the Responder to “respond” to the queries. We simply want to “relay” the credentials (the NTLM hash) of a user who is an Administrator on the target machine, to the target machine. (Remember, in our lab, User_A is an admin on Machine_B.)

So the role of Responder in this scenario is to just pretend to be the LLMNR server on the target network and handle faulty DNS lookups. For example, when a user requests access to a non-existent SMB share (an “event” occurs), responder requests for the NTLM hash from the user ( pretending that the share exists — it doesn’t), thus compromising the user account.

Before running the responder, disable the SMB and HTTP servers. This can be done from the tool’s config file.

sudo responder –I eth0 –rdw

Step 3 — Relay

To relay the captured credentials, we need to use a relay server. Impacket provides a tool for this called ntlmrelayx.

sudo impacket-ntlmrelayx -t 10.0.2.6 -smb2support

Target is Machine_B at 10.0.2.6

When responder captures the credentials, the relay will use it to authenticate as the Administrator on Machine_B.

Step 4 — Wait for an Event

An “event” here, as mentioned earlier, could be a DNS lookup for a non-existent resource. This is something we need to wait for to happen.

On a user’s computer (say, Machine_A), where User_A is logged in, an attempt to connect to the \\10.0.2.99 share would look like …

… because it doesn’t exist.

Any such “event” that raises a need for name resolution will be captured by responder.

Step 5 — Pwn!

The result of an “event” looks like this on responder:

And the relay captures the hash.

Since User_A is an Administrator on Machine_B, the relay is also able to dump out the SAM file. (That’s where the password hashes are stored, like /etc/shadow in Linux OSes.)

… OWNED!

Attack Summary

NMAP results → see which targets have SMB signing disabled.
Fire up responder.
Fire up NTLM Relay X to relay to target.
Wait for an admin user to cause an “event”.
NTLM hash is captured and relayed to the target machine.
SAM dumped.