These attacks can enable unauthorized access, privileged operations, or lateral movement when services lack protections such as SMB signing, Extended Protection for Authentication (EPA), and appropriate channel-binding enforcement.

The key defensive lesson is that successful authentication does not always prove that the connection originated from the intended client or reached the intended service.

1. Introduction: When Authentication Becomes an Attack Path

Imagine an employee accessing a corporate file server using Windows integrated authentication. The employee's computer initiates an NTLM authentication exchange, and the server validates the user's identity.

Now consider a different scenario: an attacker positions themselves to receive or induce an authentication attempt and forwards that exchange to another internal service. If the target service accepts the relayed authentication without the necessary protections, the attacker may be able to act with the authenticated user's permissions.

The password might never be revealed to the attacker. The attack instead takes advantage of how authentication messages are handled and whether the target verifies that the authentication is bound to the intended connection and service.

This is the central concept behind an NTLM relay attack.

2. What Is NTLM?

NT LAN Manager (NTLM) is a Microsoft authentication protocol historically used in Windows environments. Although Kerberos is generally preferred for domain authentication, NTLM may still be used for compatibility, workgroup access, legacy applications, and certain authentication scenarios.

NTLM uses a challenge-response mechanism:

1. Negotiation: The client and server establish the authentication mechanism and relevant capabilities.

2. Challenge: The server provides a challenge value.

3. Response: The client calculates a response using secret-derived authentication material.

4. Validation: The server or a domain controller validates the response according to the authentication flow.

The challenge-response design means the user's plaintext password is not normally sent directly across the network during NTLM authentication.

However, challenge-response authentication alone does not guarantee that an exchange cannot be relayed. The security of the overall workflow depends on the target service, protocol protections, configuration, and whether authentication is properly bound to its context.

3. How an NTLM Relay Attack Works

An NTLM relay attack generally involves an attacker forwarding authentication messages between a legitimate client and a target service.

Typical attack sequence

Step 1 — Authentication is triggered

A user or system attempts to authenticate to a resource. This might occur during ordinary network activity or after being induced to connect to an attacker-controlled endpoint.

Step 2 — The authentication exchange is captured

The attacker receives the NTLM authentication messages. This does not necessarily mean that the attacker has obtained the user's plaintext password.

Step 3 — Authentication is relayed

The attacker forwards the exchange to a different service that accepts NTLM authentication.

Step 4 — The target validates the exchange

If the target lacks effective relay protections, it may accept the forwarded authentication as belonging to the legitimate user.

Step 5 — An action may be performed

Depending on the target service, the authenticated account's permissions, and the application's controls, the attacker may gain access to resources or perform unauthorized operations.

<escape> Client → NTLM authentication exchange → Attacker-controlled relay → Target service </escape>

The diagram illustrates the concept rather than a complete protocol trace. Whether the relay succeeds depends on the specific authentication flow and the protections enforced by the target.

4. Common NTLM Relay Targets

NTLM relay is not a single-service vulnerability. Its impact depends on which services accept NTLM and how they enforce authentication protections.

SMB — Server Message Block

SMB is commonly used for Windows file sharing and related network operations. An exposed SMB service may be a relay target if the relevant authentication and signing protections are insufficient.

Important control: SMB signing helps protect message integrity and can prevent common SMB relay scenarios when required and correctly enforced. Signing does not automatically protect every other protocol that uses NTLM.

LDAP and LDAPS

LDAP is used to access and manage directory information in Active Directory environments. If LDAP accepts relayed authentication without the appropriate protections, the potential impact depends on the account's directory permissions and the operations permitted by the server.

Important controls: LDAP signing and channel binding help defend against different forms of authentication abuse. Their applicability and enforcement depend on the LDAP configuration and whether TLS is used.

HTTP-based Windows authentication

Some web applications and Windows services support NTLM authentication over HTTP. If the application does not adequately bind authentication to the intended connection or service, relay risks may arise.

Important controls: Extended Protection for Authentication (EPA), including channel-binding and service-binding protections where supported, can help prevent authentication relay attacks.

Other Windows services

Additional services and application integrations may accept NTLM. Defenders should identify actual authentication paths and service configurations instead of assuming that securing SMB alone eliminates all relay risk.

5. NTLM Relay vs. Pass-the-Hash

These techniques are related to Windows authentication abuse, but they are not the same.

FeatureNTLM relayPass-the-HashPrimary mechanismForwards an authentication exchange to another serviceUses NTLM hash material to authenticate without knowing the plaintext passwordRequires a live authentication exchange?Typically, yesNot necessarilyRequires recovering the plaintext password?NoNoMain defensive focusSigning, channel binding, EPA, and reducing NTLM exposureCredential protection, reducing NTLM use, and privileged-account controlsCommon objectiveReuse authentication against a target serviceAuthenticate using stolen hash material

The distinction matters during incident response. Evidence of a relay does not, by itself, prove that password hashes were stolen or cracked.

6. Investigating a Suspected NTLM Relay Attack

A SOC analyst should correlate network, endpoint, identity, and target-service evidence. A single NTLM authentication event is not sufficient to establish that a relay occurred.

Step 1 — Identify unusual authentication patterns

Review successful and failed NTLM authentication activity. Look for unexpected source systems, unusual target services, new authentication relationships, or access that does not match the user's normal activity.

Useful Windows security events may include:

• 4624: Successful logon.

• 4625: Failed logon.

• 4648: Logon attempted using explicit credentials.

• 4776: NTLM credential validation activity on systems that generate this event.

Event availability and fields vary by system role, audit policy, and log collection configuration. These events provide context; none independently confirms an NTLM relay.

Step 2 — Correlate source and destination systems

Determine which client initiated authentication, which server received the connection, and whether the sequence is consistent with normal activity.

Investigate:

• Unexpected authentication from workstations to servers.

• Authentication involving systems that normally have no relationship.

• Repeated authentication attempts across multiple services.

• Connections from unusual hosts shortly before privileged actions.

• Network connections that do not align with the apparent user activity.

Use firewall logs, endpoint telemetry, network detection tools, and server logs to reconstruct the sequence. Avoid concluding that two events are related solely because they occur close together in time.

Step 3 — Examine the target service

Determine whether the destination service accepted NTLM and whether relevant relay protections were enabled and enforced at the time of the incident.

For SMB, review signing requirements and negotiated session properties. For LDAP, assess signing and channel-binding configuration. For HTTP-based authentication, review EPA support and configuration.

Also establish which operations the authenticated account performed and whether those operations were authorized.

Step 4 — Review identity and privilege changes

Look for suspicious activity after the authentication, including unexpected directory modifications, access to sensitive shares, changes to privileged groups, or unusual service and application operations.

For Active Directory investigations, Event ID 4728 records a member being added to a security-enabled global group, while Event ID 4732 records a member being added to a security-enabled local group. Other group-change events may be relevant depending on the group type.

These events indicate changes, not their cause. Correlate them with the affected account, initiating host, target service, and surrounding activity.

Step 5 — Determine scope and contain the activity

Identify other systems that accepted authentication from the suspected source, accounts involved in the sequence, and any downstream actions.

If malicious activity is confirmed, follow the organization's incident-response process. Potential actions include isolating affected systems, blocking malicious network paths, disabling or restricting compromised accounts, and reverting unauthorized changes. Account resets alone may not address the underlying relay exposure.

7. Indicators and Evidence to Collect

NTLM relay does not have one universal indicator of compromise. Investigation should prioritize correlated evidence.

Evidence sourceWhat to examineWhy it mattersWindows Security logsLogon events, NTLM validation, account and workstation fieldsEstablishes authentication contextSMB telemetrySigning requirements, negotiated session properties, file accessHelps assess SMB relay exposure and impactLDAP and directory logsAuthentication context and directory modificationsIdentifies potential directory abuseWeb and application logsNTLM authentication, request context, privileged actionsHelps investigate HTTP-based relay scenariosFirewall and network telemetryClient-to-server connections and unusual authentication pathsHelps reconstruct the possible relay sequenceEDR telemetrySuspicious processes, unexpected connections, and follow-on activityMay reveal the initiating host or attacker activityActive Directory audit logsGroup changes and other directory modificationsIdentifies possible privilege escalation

Investigation caution: The absence of a clear relay signature in endpoint logs does not rule out a relay. Some activity may appear as legitimate authentication at the destination, making network correlation and configuration review especially important.

8. MITRE ATT&CK Mapping

Potential ATT&CK mappings depend on the observed behavior and the evidence collected. They should not be assigned solely because NTLM authentication was involved.

• T1557 — Adversary-in-the-Middle: Relevant when evidence supports interception or manipulation of communications as part of the attack.

• T1557.001 — LLMNR/NBT-NS Poisoning and SMB Relay: Relevant when the observed activity specifically involves this technique. Not every NTLM relay uses LLMNR or NBT-NS poisoning.

• T1003.002 — Security Account Manager: Relevant only if evidence shows SAM credential dumping; it is not an inherent part of NTLM relay.

• T1098 — Account Manipulation: Potentially relevant when the attacker changes an account or its permissions as a follow-on action.

Map only the techniques supported by the investigation. A successful relay does not automatically demonstrate credential dumping, account manipulation, or any particular initial-access method.

9. Preventing NTLM Relay Attacks

Effective mitigation requires controls across authentication protocols, endpoint configuration, network exposure, and identity permissions.

Enforce SMB signing

Require SMB signing where supported and appropriate. Review both client and server policies, and verify the effective negotiated configuration rather than relying only on intended policy settings.

Signing helps prevent tampering and common SMB relay attacks, but it does not replace protections for LDAP, HTTP, or other NTLM-enabled services.

Enable LDAP signing and channel binding

Apply LDAP signing and channel-binding protections in accordance with Microsoft's guidance and application compatibility requirements. Test changes before broad enforcement to identify legacy dependencies.

These protections address different aspects of LDAP authentication security; enabling one should not be assumed to provide all the benefits of the other.

Configure Extended Protection for Authentication

Enable EPA on supported applications and services that use Windows authentication. Evaluate channel binding and service binding according to the service's architecture and vendor guidance.

Reduce unnecessary NTLM usage

Inventory NTLM dependencies and migrate compatible systems to Kerberos or other stronger, appropriately configured authentication mechanisms. Apply NTLM restrictions progressively and monitor for legacy applications that may break.

Reducing NTLM exposure limits the number of authentication paths that could be abused.

Restrict unnecessary network access

Limit which systems can reach SMB, LDAP, and other administrative services. Segment networks and restrict inbound connections to the hosts and management systems that require them.

Network restrictions do not replace protocol-level protections, but they can reduce opportunities to initiate or relay authentication.

Apply least privilege

Ensure that ordinary users and service accounts cannot perform sensitive administrative actions unnecessarily. Restrict privileged account use, review service-account permissions, and monitor high-impact operations.

Even when an authentication relay succeeds, least privilege can significantly reduce the damage an attacker can cause.

Monitor authentication behavior

Establish baselines for NTLM usage and alert on unusual source-to-target relationships, unexpected administrative access, and suspicious follow-on changes. Validate detections against normal service behavior to reduce false positives.

10. Practical SOC Detection Strategy

A useful detection strategy correlates three areas:

1. Authentication anomaly: An unexpected NTLM authentication relationship or unusual source system.

2. Target exposure: The destination service accepts NTLM without an effective, relevant relay protection.

3. Suspicious follow-on behavior: The account performs an unexpected privileged action, accesses unusual resources, or changes directory objects.

When these signals occur together, increase investigation priority. Do not treat any single signal as proof of a relay attack.

A mature detection pipeline should combine Windows event logs, network telemetry, endpoint events, Active Directory auditing, and configuration-compliance data. Configuration checks are especially important because relay protections may be absent even when there is no visible malicious activity.

Conclusion

NTLM relay attacks demonstrate that authentication security depends on more than protecting passwords. An attacker may exploit the way a legitimate authentication exchange is forwarded and accepted by a different service, potentially gaining access without recovering the user's plaintext password.

For defenders, the priorities are clear: enforce appropriate SMB signing, secure LDAP with signing and channel binding, configure EPA for supported HTTP authentication, reduce unnecessary NTLM use, and monitor suspicious authentication relationships and subsequent privileged actions.

The strongest defence is layered: make authentication difficult to relay, limit what an authenticated account can do, and collect enough telemetry to reconstruct suspicious activity.

Further Reading

• Microsoft Learn — NTLM overview

• Microsoft Learn — SMB security enhancements

• Microsoft Learn — LDAP signing requirements

• Microsoft Learn — Extended Protection for Authentication

• MITRE ATT&CK — Adversary-in-the-Middle (T1557)