Local Relay

How local relay works

Local relay is not about stealing a password and then logging in later. It is a real-time forwarding technique: the attacker positions a nearby or intermediate system so that authentication traffic can be relayed between the client and the target service, often without ever needing to know the secret itself. The security boundary that matters is the protocol handshake, not just the credential value.

This makes local relay especially relevant in environments where the service accepts the forwarded authentication as if it came directly from the victim. The attack succeeds because the target trusts the authentication flow, so the defensive question is whether the protocol is resistant to relay, not whether the attacker can crack a password offline.

Why local relay is dangerous

Relay attacks are dangerous because they turn legitimate authentication into an access path for an attacker. If the protocol lacks message signing, mutual authentication, or other protections against replay and forwarding, the attacker can reuse the victim’s live authentication exchange to reach a service with the victim’s own privileges.

That means the compromise often looks like valid access rather than obvious credential theft. In practice, local relay can bypass assumptions built into network authentication and can be used to reach resources, sessions, or administrative functions that would otherwise require stronger proof of origin.

How organisations assess exposure

Exposure depends on where relaying is possible and which services still trust unauthenticated or weakly protected handshakes. Organisations should identify systems that accept network authentication on local segments, intermediate hosts, shared subnets, or exposed service paths, then review which protocols are protected by signing, channel binding, or equivalent anti-relay controls.

It is also important to map which assets are reachable from untrusted or semi-trusted networks, because relay techniques often exploit gaps between network location and authentication trust. A service may be correctly configured in isolation, yet still be relayable if an intermediate host can forward the handshake intact.

Authoritative control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls, NIST SP 800-207 Zero Trust Architecture, and NIST SP 800-63 Digital Identity Guidelines help frame the trust, authentication, and access-control expectations that relay attacks try to undermine.

Prevention, detection, and recovery

Preventing local relay usually means reducing trust in unauthenticated network proximity and hardening the authentication protocol so forwarded handshakes are not sufficient. Message signing, strong channel binding, protected authentication paths, and segmentation all reduce the chance that an attacker can interpose a relay point.

Detection is harder because the attacker may not need to modify credentials or create obviously malicious traffic. Defenders should look for unexpected authentication flows, suspicious intermediary hosts, abnormal login sources, and signs that a service accepted authentication from an unexpected network location. After suspected exploitation, review whether any sessions, tickets, keys, or other authentication material were used to obtain follow-on access.

For adversary technique mapping and detection engineering, the attack pattern fits well with MITRE ATT&CK Enterprise Matrix, especially when relayed authentication leads to credential access, lateral movement, or privilege escalation. Where the relay path involves system or service account trust, the OWASP Non-Human Identity Top 10 is also useful for thinking about overprivileged or reusable authentication material.

Risk and Threat Considerations

Local relay is risky because it weaponises legitimate trust relationships. The attacker does not need to crack the target account, only to preserve enough of the original handshake that the service accepts it as authentic, which can make the compromise look like routine access.

Failure mechanism: The authentication protocol accepts forwarded or replayed handshake material without strong protections such as signing, binding, or origin checks, allowing an intermediate system to impersonate the client in real time.

Impact: An attacker can gain access with the victim’s privileges, pivot to adjacent systems, or abuse the resulting session to reach higher-value resources while blending into normal authentication activity.

Practitioner Guidance

Why practitioners should care: Local relay is a configuration and protocol-design problem as much as it is an attacker technique. If a service still trusts a relayed handshake, stronger passwords alone will not remove the exposure.

What to watch for: Treat relay-resistant authentication as a property to verify, not assume. The practical test is whether the service rejects forwarded authentication from an intermediate host and whether the logging can distinguish a legitimate client path from a relayed one.

Practitioner takeaway: Focus on protocol hardening, trust-boundary reduction, and exposure review together, because any one of them alone can leave a relay path intact.

Related resources from NHI Mgmt Group

• What breaks when a local AI CLI is remotely steered through a relay package?
• What breaks when local AI tools are linked to a remote operator relay?
• Why are local .env files and config notes risky in Microsoft 365?
• How should teams respond to a local Linux privilege escalation flaw in shared environments?