Teams should watch for unusual NTLM traffic patterns, signs of ARP poisoning or spoofing, and authentication requests that do not match normal user or host behavior. Correlate those signals with lateral movement, unexpected session creation, and privilege changes. Detection works best when network telemetry, identity logs, and threat analytics are reviewed together as one control picture.
Why This Matters for Security Teams
ntlm relay is dangerous because it turns a legitimate authentication exchange into a path for unauthorized access without needing to crack the password itself. That makes it especially hard to spot if teams only look for failed logons or obvious credential theft. The practical problem is not just the relay event, but what the attacker does next, often using the relayed identity to reach higher-value systems or privileged sessions. NHI Mgmt Group’s Ultimate Guide to NHIs – Key Challenges and Risks notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that identity abuse often begins before defenders notice any lateral movement.
Security teams should treat relay detection as a correlation problem, not a single alert problem. Signals from SMB authentication, name resolution abuse, and host-to-host trust shifts matter more than any one event. The most useful detections tend to focus on anomalies in where authentication originates, whether the target should accept that traffic, and whether the resulting session matches normal administrative behavior. In practice, many teams find relay activity only after privilege escalation has already created a new persistence path, rather than through intentional early warning.
How It Works in Practice
Effective detection starts with understanding the relay chain. Attackers typically coerce a system into authenticating to them, then forward that NTLM exchange to a different service that will accept it. That means defenders need telemetry from the network layer, identity provider, endpoint, and directory services together. The MITRE ATT&CK Enterprise Matrix helps map the follow-on behaviour, especially lateral movement and privilege escalation patterns that appear after the relay succeeds.
High-signal checks include:
- NTLM authentication from a source host that does not normally initiate admin or service traffic.
- ARP spoofing, LLMNR/NBT-NS poisoning, or other local name-resolution abuse on flat networks.
- Unexpected authentication to LDAP, SMB, HTTP, or AD CS endpoints from a workstation rather than a known management host.
- Session creation or token use that does not fit the user’s normal access path or timing.
- Privilege changes shortly after a suspicious authentication exchange.
Current guidance suggests that detections should be tied to policy and asset context, not only signatures. The NIST Cybersecurity Framework 2.0 supports this kind of coordinated visibility, while NHI lifecycle controls in the NHI Lifecycle Management Guide reinforce why identity behavior must be monitored across its full operational life, not just at issuance. Teams that normalize expected service-to-service authentication can flag outliers faster, especially when a user workstation suddenly behaves like an authentication intermediary. These controls tend to break down in legacy Windows environments with broad NTLM reliance because normal and malicious relay traffic can look nearly identical at the packet level.
Common Variations and Edge Cases
Tighter NTLM controls often increase operational overhead, requiring organisations to balance faster detection against the risk of breaking older applications and administrative workflows. That tradeoff is real in mixed Windows estates, where NTLM may still exist alongside Kerberos, legacy print services, or third-party tools that were never designed for modern identity hardening.
There is no universal standard for every relay-detection rule set yet, but best practice is evolving toward layered controls. In some environments, the better signal is not the relay itself but the post-relay outcome, such as a privileged group membership change, new remote service creation, or a directory write from an unexpected source. Teams should also watch for false negatives where attackers relay through internal infrastructure that already looks trusted, including jump hosts or management subnets. NHI Mgmt Group’s Top 10 NHI Issues and the State of Non-Human Identity Security both point to a wider visibility gap that affects identity monitoring overall, not just non-human accounts. In those cases, the most reliable path is to reduce NTLM exposure while improving telemetry around directory changes and privileged sessions. Alerting also becomes less reliable when endpoint logging is sparse or when network security tools cannot inspect east-west traffic in real time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers identity abuse and tool misuse patterns that resemble relay-enabled escalation. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Relay attacks exploit weak identity visibility and over-privileged machine accounts. |
| CSA MAESTRO | Supports runtime governance for autonomous access and anomaly-driven escalation paths. | |
| NIST AI RMF | Risk management depends on monitoring, context, and continuous detection across systems. | |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring is essential for spotting relay precursors and privilege changes. |
Instrument identities and tool access so anomalous post-auth actions are detected and contained quickly.
Related resources from NHI Mgmt Group
- How do security teams detect abuse of workload identity and certificate issuance paths before privilege escalation occurs?
- How do developers and security teams detect stealthy privilege escalation in malware chains?
- How should security teams detect fast flux activity in DNS traffic before it supports a broader intrusion?
- How should security teams validate their exposure to a Linux kernel privilege escalation flaw before attackers use it in production?