Security teams detect SMB relay attacks by monitoring for SMB authentication that is relayed to another host instead of used directly. Look for suspicious NTLM handshakes, unexpected administrative shares, and follow-on remote execution or file access from a machine that was only reachable by coercion or spoofing. Enforce SMB signing where feasible and restrict unnecessary inbound SMB exposure.
How SMB relay attacks show up in detection telemetry
Detection starts with the mismatch between who authenticated and where that authentication was actually used. In a relay, the target host accepts NTLM authentication that did not originate from a normal client session, so defenders should correlate SMB events with the source machine, the destination host, and any immediately following remote service activity. The key is to treat the authentication as suspicious when the path looks coerced, proxied, or redirected.
Reliable detection usually comes from chaining signals rather than relying on one event type. A single NTLM logon can be benign, but a relayed one often precedes admin-share access, service creation, remote file writes, or command execution on a host that had no normal reason to receive that connection. If you have endpoint telemetry, Lateral Movement Guide is the most directly useful reference for the smb relay path, because it ties relay behavior to admin shares, PsExec-style follow-on activity, and the detection patterns that surround lateral movement.
Watch for environment clues that make relay more likely: name-resolution poisoning, coerced authentication, or unexpected NTLM use where Kerberos or another stronger path would normally appear. A host that suddenly becomes a source of outbound SMB authentication, followed by access to ADMIN$ or C$, is often more informative than the login event itself. The operational question is whether the authentication was merely observed, or whether it was immediately converted into privilege-bearing access on another system.
What to verify when you think SMB relay is happening
The first verification step is to confirm whether the same account, from the same source host, is appearing across multiple destinations in a short window. That pattern can indicate relayed or repeated authentication rather than normal user-driven SMB activity. Compare the source IP, target host, share accessed, and any service-control or remote-execution events that follow.
Next, check whether the destination system accepted SMB without signing when signing should have blocked the relay. If the environment still permits unsigned SMB in places that matter, an attacker can often turn a coerced authentication into a usable network session. For a broader perspective on how relay fits into identity-driven intrusion chains and what usually comes next, Identity Threat Detection and Response (ITDR) Guide helps frame the detection problem as identity abuse plus lateral movement, not just a protocol issue.
Also verify whether the relayed session was followed by file transfer, scheduled task creation, service installation, or remote shell activity. Those follow-on actions are often what convert a suspicious SMB handshake into a confirmed incident. If you can only see one side of the flow, enrich with endpoint, network, and Windows event data before deciding whether the activity is a false positive or an active relay chain.
Hardening steps that improve SMB relay detection quality
Enforcing SMB signing where feasible reduces the attack surface and also improves your confidence in what the telemetry means. When signing is consistently required, unsigned relay attempts become easier to flag, and successful relays become less likely. Restricting inbound SMB exposure on servers and workstations also shrinks the number of places where a relayed session can land and makes anomalous access easier to notice.
Segmentation matters because relay attacks are only useful when the attacker can redirect authentication to a host that will accept it and do something valuable with it. If file servers, admin workstations, and general user endpoints all expose SMB broadly, the alert volume rises while the signal gets weaker. The strongest detections usually come from combining protocol-level anomalies with host-based evidence of administrative share use or remote execution.
Risk and Threat Considerations
SMB relay is risky because it turns ordinary authentication into a transport for unauthorized access. The danger is not just the relayed session itself, but the fact that a single successful relay can unlock administrative shares, remote service control, or file movement on a second host without a normal interactive logon.
Failure mechanism: An attacker coerces or captures NTLM authentication, relays it to a host that accepts SMB without sufficient protections, and then leverages that authenticated session for lateral movement or remote execution.
Impact: A single relay can produce unauthorized file access, service creation, command execution, or broader domain movement, especially when privileged accounts or management hosts are involved.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1021.002 — SMB/Windows Admin Shares | SMB relay commonly leads to admin-share lateral movement and remote execution. |
| T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay | This directly covers the poisoning and relay path used to hijack SMB authentication. | |
| Recommendation — Map SMB relay follow-on activity to T1021.002 and hunt for remote share abuse. Detect and block name-resolution poisoning and relay attempts mapped to T1557.001. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Restricting SMB exposure and limiting admin-share access are access-control measures. |
| Recommendation — Limit SMB reachability and administrative share exposure under CIS-6. | ||
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | SMB relay exploits remote access paths that should be constrained and monitored. |
| IA-2 — Identification and Authentication (Organizational Users) | SMB relay abuses authentication acceptance and weak session trust. | |
| Recommendation — Constrain and monitor remote access paths that can be abused for relay. Require strong authentication controls that reduce relayable SMB sessions. | ||
Practitioner Guidance
What to verify: Correlate SMB authentication with immediate post-authentication behavior. A relayed session usually becomes visible when the same account starts touching admin shares or remote services from a host that should not be initiating that pattern.
Decision rule: If you see NTLM over SMB combined with unexpected remote execution or admin-share access, treat it as a potential lateral-movement event even before you prove the relay path end to end.
What practitioners underestimate: Detection often fails when teams look only for the relay itself and not for the downstream actions it enables. The strongest evidence is usually the sequence, authentication followed by privileged access, not the handshake alone.
Practitioner takeaway: SMB relay detection is most effective when you hunt for the full chain, coerced authentication, unusual SMB acceptance, and immediate privileged follow-on activity, while hardening the hosts that would otherwise accept and operationalize the relay.