Potential NTLM Relay Attack against a Computer Account

Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target server's computer account, originating from a different host. This may indicate that an attacker has captured and relayed the server's computer account hash to execute code on behalf of the compromised system.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/06/18"
  3integration = ["system", "windows"]
  4maturity = "production"
  5updated_date = "2026/04/22"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects potential relay attacks by identifying coercion attempts followed by authentication events using a target
 11server's computer account, originating from a different host. This may indicate that an attacker has captured and
 12relayed the server's computer account hash to execute code on behalf of the compromised system.
 13"""
 14from = "now-9m"
 15index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
 16language = "eql"
 17license = "Elastic License v2"
 18name = "Potential NTLM Relay Attack against a Computer Account"
 19references = [
 20    "https://github.com/p0dalirius/windows-coerced-authentication-methods",
 21    "https://www.thehacker.recipes/a-d/movement/mitm-and-coerced-authentications",
 22    "https://www.synacktiv.com/publications/ntlm-reflection-is-dead-long-live-ntlm-reflection-an-in-depth-analysis-of-cve-2025",
 23    "https://github.com/Orange-Cyberdefense/ocd-mindmaps/blob/main/excalimap/mindmap/ad/authenticated.md",
 24]
 25risk_score = 73
 26rule_id = "23e5407a-b696-4433-9297-087645f2726c"
 27severity = "high"
 28tags = [
 29    "Domain: Endpoint",
 30    "OS: Windows",
 31    "Use Case: Threat Detection",
 32    "Tactic: Credential Access",
 33    "Data Source: Active Directory",
 34    "Use Case: Active Directory Monitoring",
 35    "Data Source: Windows Security Event Logs",
 36    "Resources: Investigation Guide",
 37]
 38timestamp_override = "event.ingested"
 39type = "eql"
 40
 41query = '''
 42sequence by winlog.computer_name, source.ip with maxspan=5s
 43
 44/* Filter for an event that indicates coercion against known abused named pipes using an account that is not the host */
 45[file where host.os.type == "windows" and event.code : "5145" and 
 46    not startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
 47    file.name : (
 48        "Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc",
 49        "eventlog", "winreg", "srvsvc", "dnsserver", "dhcpserver", "WinsPipe"
 50    )]
 51
 52/* Detects a logon attempt using the NTLM protocol resulting from the coercion coming from the same IP address */
 53[authentication where host.os.type == "windows" and event.code in ("4624", "4625") and
 54    endswith~(user.name, "$") and winlog.logon.type : "network" and
 55    winlog.event_data.AuthenticationPackageName : "NTLM" and
 56
 57    /* Filter for a machine account that matches the hostname */
 58    startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
 59
 60    /* Verify if the Source IP belongs to the host */
 61    not endswith(string(source.ip), string(host.ip)) and
 62    source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"]
 63'''
 64
 65note = """## Triage and analysis
 66
 67### Investigating Potential NTLM Relay Attack against a Computer Account
 68
 69#### Possible investigation steps
 70
 71- What source events make up the sequence, and do they support a coercion-to-NTLM path?
 72  - Focus: open Timeline from the sequence alert and recover member events for the alert `host.id` or `host.name` plus `source.ip`; compare source-event `winlog.computer_name`, 5145 `file.name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, and `winlog.logon.type`.
 73  - Hint: use the recovered 5145 Windows Security source event as the primary pipe evidence. If endpoint file telemetry is available for this host and time window, recover the matching `file.*` evidence before using it for interpretation or remediation.
 74  - Implication: escalate when a coercion-style pipe such as Spoolss, netdfs, efsrpc, FssagentRpc, lsarpc, netlogon, samr, srvsvc, winreg, dnsserver, or WinsPipe is followed within seconds by a type 3 NTLM machine-account logon from the same source; lower concern when the recovered pair matches a recurring proxy, cluster, backup, or management path with the same pipe and auth pattern; close as a non-hit only when source events break the sequence or do not share the same source and target.
 75
 76- Did the authentication stage succeed, fail, or show weak NTLM handling?
 77  - Focus: auth-stage `event.code`, `winlog.event_data.Status`, `winlog.event_data.SubStatus`, `winlog.event_data.LmPackageName`, and `winlog.event_data.AuthenticationPackageName`.
 78  - Implication: urgent escalation is warranted for a 4624 success, success-after-failure pattern, or NTLMv1/weak `winlog.event_data.LmPackageName`; failure-only 4625 activity still supports attempted coercion when the recovered pipe event and source path hold.
 79
 80- Does the authenticated machine account belong to the target server?
 81  - Focus: auth-stage `winlog.event_data.TargetUserName` and `winlog.event_data.TargetDomainName` compared with `winlog.computer_name`, `host.name`, and `host.id`.
 82  - Implication: target-name alignment plus a dollar-suffixed machine account supports relayed or reflected computer-account use; a different host, alias, or cluster identity is an identity mismatch to resolve before disposition, not a benign conclusion by itself.
 83
 84- Does the source fit a recognized SMB/RPC infrastructure path for this server?
 85  - Focus: surrounding Windows Security events for the same target, source, and machine account, checking `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`.
 86  - Hint: use same-source NTLM authentication events to review repeated machine-account logons, success-after-failure patterns, and weak `LmPackageName` values around the alert. $investigate_2
 87  - Implication: escalate when the source is rare for this server, targets multiple machine accounts, or drives burst failures followed by success; lower concern only when the same source/server/account/auth pattern recurs as a recognized proxy, load-balancer, cluster, backup, or management path. Missing Windows Security history leaves source fit unresolved, not benign.
 88
 89- Did the same source perform follow-on Windows Security activity after the relay pair?
 90  - Focus: post-sequence Windows Security events on the same target and source, especially `event.code` 5145, 4624, or 4625 plus `winlog.event_data.TargetUserName`, `winlog.event_data.Status`, and `winlog.event_data.SubStatus`.
 91  - Hint: review same-source follow-on Windows Security events for repeated share or pipe access and repeated machine-account logons after the sequence. $investigate_3
 92  - Implication: escalate when the source keeps accessing shares or pipes or repeats machine-account logons after the relay window; absence of follow-on Windows Security events reduces observed scope but does not prove benign execution did not occur.
 93
 94- If local evidence is suspicious or unresolved, does related alert scope change urgency?
 95  - Focus: related source-IP alerts for `source.ip`, especially other coercion, machine-account NTLM, service creation, or remote-execution signals. $investigate_0
 96  - Hint: if source scope remains unclear, check related target-server alerts for the alert `host.id`. $investigate_1
 97  - Implication: broaden response when the same source or target shows related relay or execution alerts; keep the case locally scoped when related alerts add no new source, target, or follow-on evidence.
 98
 99- Based on sequence integrity, auth result, identity, source fit, follow-through, and scope, what disposition is supported?
100  - Focus: recovered source events, machine-account identity, NTLM handling, recognized infrastructure fit, follow-on Windows Security events, and related-alert scope.
101  - Implication: escalate when the recovered sequence holds and the source is unrecognized, successful, weakly protected, or followed by further access; close only when recovered evidence and supported context bind one exact workflow on this host, with outside confirmation when telemetry cannot prove legitimacy; preserve evidence and escalate when results are mixed or visibility is limited.
102
103### False positive analysis
104
105- Clustered file services, SMB/RPC proxies, backup controllers, or management tiers can legitimately front machine-account NTLM traffic through bounded SMB/RPC paths. Confirm by verifying the same `source.ip`, `winlog.computer_name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, status pattern, 5145 named-pipe/share object, and lack of suspicious follow-on `event.code` activity all converge on the same workflow. If workflow records are unavailable, require historical recurrence of that exact telemetry pattern before closing.
106- Before creating an exception, validate recurrence across prior alerts from this rule for the same `source.ip`, `winlog.computer_name`, machine account, NTLM package/version, and 5145 object family. Build the exception from the minimum confirmed workflow pattern; avoid exceptions on source IP alone, target server alone, or dollar-suffixed machine-account names alone.
107
108### Response and remediation
109
110- If confirmed benign, reverse temporary containment and document the exact `source.ip`, `winlog.computer_name`, `winlog.event_data.TargetUserName`, `winlog.event_data.AuthenticationPackageName`, `winlog.event_data.LmPackageName`, `winlog.event_data.Status` or `winlog.event_data.SubStatus`, and 5145 object pattern that proved the workflow. Create a narrow exception only after recurrence proves the same telemetry pattern.
111- If suspicious but unconfirmed, preserve the alert document, Timeline member events, recovered 5145 object, authentication result, NTLM package/version, source and target identifiers, status values, and any follow-on Windows Security records before containment. Use reversible containment first, such as temporarily blocking the recovered source from SMB/RPC access to the affected server or isolating the unexpected source host when its role tolerates isolation.
112- If confirmed malicious, keep the preserved evidence set attached to the case, then isolate or block the source host and restrict its SMB/RPC access to the affected `winlog.computer_name`. Eradicate only confirmed follow-on services, tasks, shares, or relay tooling identified during investigation; coordinate disruptive actions on domain controllers, cluster nodes, and production servers with identity and infrastructure owners.
113- Rotate the affected computer-account secret only after evidence preservation and service-impact review, then review delegated or administrative credentials that could have been exposed or reused through the relayed session. Reduce NTLM exposure, enforce SMB signing and Extended Protection for Authentication where applicable, and disable unneeded coercion-prone RPC services on the affected tier.
114- After containment, audit other servers reached from the same `source.ip` and retain the Windows Security telemetry needed to reconstruct the 5145-to-4624/4625 sequence. Document any reflection-style or marshaled-target variant indicators for future case comparison.
115"""
116
117setup = """## Setup
118
119The following Windows audit policies must be enabled to generate the events used by this rule:
120- [Audit Logon](https://ela.st/audit-logon)
121- [Audit Detailed File Share](https://ela.st/audit-detailed-file-share)
122"""
123
124[rule.investigation_fields]
125field_names = [
126    "@timestamp",
127    "event.code",
128    "host.id",
129    "host.name",
130    "host.ip",
131    "source.ip",
132    "winlog.computer_name",
133    "file.name",
134    "winlog.event_data.TargetUserName",
135    "winlog.event_data.TargetDomainName",
136    "winlog.event_data.AuthenticationPackageName",
137    "winlog.event_data.LmPackageName",
138    "winlog.logon.type",
139    "winlog.event_data.Status",
140    "winlog.event_data.SubStatus",
141]
142
143[[transform.investigate]]
144label = "Alerts associated with this source IP"
145description = ""
146providers = [
147  [
148    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
149    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" }
150  ]
151]
152relativeFrom = "now-48h/h"
153relativeTo = "now"
154
155[[transform.investigate]]
156label = "Alerts associated with this target server"
157description = ""
158providers = [
159  [
160    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
161    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
162  ]
163]
164relativeFrom = "now-48h/h"
165relativeTo = "now"
166
167[[transform.investigate]]
168label = "NTLM authentication events from this source to this target"
169description = ""
170providers = [
171  [
172    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
173    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
174    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" },
175    { excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "NTLM", valueType = "string" }
176  ],
177  [
178    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
179    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
180    { excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" },
181    { excluded = false, field = "winlog.event_data.AuthenticationPackageName", queryType = "phrase", value = "NTLM", valueType = "string" }
182  ]
183]
184relativeFrom = "now-1h"
185relativeTo = "now"
186
187[[transform.investigate]]
188label = "Follow-on Windows Security events from this source to this target"
189description = ""
190providers = [
191  [
192    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
193    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
194    { excluded = false, field = "event.code", queryType = "phrase", value = "5145", valueType = "string" }
195  ],
196  [
197    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
198    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
199    { excluded = false, field = "event.code", queryType = "phrase", value = "4624", valueType = "string" }
200  ],
201  [
202    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
203    { excluded = false, field = "source.ip", queryType = "phrase", value = "{{source.ip}}", valueType = "string" },
204    { excluded = false, field = "event.code", queryType = "phrase", value = "4625", valueType = "string" }
205  ]
206]
207relativeFrom = "now-1h"
208relativeTo = "now"
209
210[[rule.threat]]
211framework = "MITRE ATT&CK"
212[[rule.threat.technique]]
213id = "T1187"
214name = "Forced Authentication"
215reference = "https://attack.mitre.org/techniques/T1187/"
216
217[[rule.threat.technique]]
218id = "T1557"
219name = "Adversary-in-the-Middle"
220reference = "https://attack.mitre.org/techniques/T1557/"
221[[rule.threat.technique.subtechnique]]
222id = "T1557.001"
223name = "LLMNR/NBT-NS Poisoning and SMB Relay"
224reference = "https://attack.mitre.org/techniques/T1557/001/"
225
226[rule.threat.tactic]
227id = "TA0006"
228name = "Credential Access"
229reference = "https://attack.mitre.org/tactics/TA0006/"

Triage and analysis

Investigating Potential NTLM Relay Attack against a Computer Account

Possible investigation steps

  • What source events make up the sequence, and do they support a coercion-to-NTLM path?

    • Focus: open Timeline from the sequence alert and recover member events for the alert host.id or host.name plus source.ip; compare source-event winlog.computer_name, 5145 file.name, winlog.event_data.TargetUserName, winlog.event_data.AuthenticationPackageName, and winlog.logon.type.
    • Hint: use the recovered 5145 Windows Security source event as the primary pipe evidence. If endpoint file telemetry is available for this host and time window, recover the matching file.* evidence before using it for interpretation or remediation.
    • Implication: escalate when a coercion-style pipe such as Spoolss, netdfs, efsrpc, FssagentRpc, lsarpc, netlogon, samr, srvsvc, winreg, dnsserver, or WinsPipe is followed within seconds by a type 3 NTLM machine-account logon from the same source; lower concern when the recovered pair matches a recurring proxy, cluster, backup, or management path with the same pipe and auth pattern; close as a non-hit only when source events break the sequence or do not share the same source and target.
  • Did the authentication stage succeed, fail, or show weak NTLM handling?

    • Focus: auth-stage event.code, winlog.event_data.Status, winlog.event_data.SubStatus, winlog.event_data.LmPackageName, and winlog.event_data.AuthenticationPackageName.
    • Implication: urgent escalation is warranted for a 4624 success, success-after-failure pattern, or NTLMv1/weak winlog.event_data.LmPackageName; failure-only 4625 activity still supports attempted coercion when the recovered pipe event and source path hold.
  • Does the authenticated machine account belong to the target server?

    • Focus: auth-stage winlog.event_data.TargetUserName and winlog.event_data.TargetDomainName compared with winlog.computer_name, host.name, and host.id.
    • Implication: target-name alignment plus a dollar-suffixed machine account supports relayed or reflected computer-account use; a different host, alias, or cluster identity is an identity mismatch to resolve before disposition, not a benign conclusion by itself.
  • Does the source fit a recognized SMB/RPC infrastructure path for this server?

    • Focus: surrounding Windows Security events for the same target, source, and machine account, checking winlog.event_data.TargetUserName, winlog.event_data.AuthenticationPackageName, winlog.event_data.LmPackageName, winlog.event_data.Status, and winlog.event_data.SubStatus.
    • Hint: use same-source NTLM authentication events to review repeated machine-account logons, success-after-failure patterns, and weak LmPackageName values around the alert. $investigate_2
    • Implication: escalate when the source is rare for this server, targets multiple machine accounts, or drives burst failures followed by success; lower concern only when the same source/server/account/auth pattern recurs as a recognized proxy, load-balancer, cluster, backup, or management path. Missing Windows Security history leaves source fit unresolved, not benign.
  • Did the same source perform follow-on Windows Security activity after the relay pair?

    • Focus: post-sequence Windows Security events on the same target and source, especially event.code 5145, 4624, or 4625 plus winlog.event_data.TargetUserName, winlog.event_data.Status, and winlog.event_data.SubStatus.
    • Hint: review same-source follow-on Windows Security events for repeated share or pipe access and repeated machine-account logons after the sequence. $investigate_3
    • Implication: escalate when the source keeps accessing shares or pipes or repeats machine-account logons after the relay window; absence of follow-on Windows Security events reduces observed scope but does not prove benign execution did not occur.
  • If local evidence is suspicious or unresolved, does related alert scope change urgency?

    • Focus: related source-IP alerts for source.ip, especially other coercion, machine-account NTLM, service creation, or remote-execution signals. $investigate_0
    • Hint: if source scope remains unclear, check related target-server alerts for the alert host.id. $investigate_1
    • Implication: broaden response when the same source or target shows related relay or execution alerts; keep the case locally scoped when related alerts add no new source, target, or follow-on evidence.
  • Based on sequence integrity, auth result, identity, source fit, follow-through, and scope, what disposition is supported?

    • Focus: recovered source events, machine-account identity, NTLM handling, recognized infrastructure fit, follow-on Windows Security events, and related-alert scope.
    • Implication: escalate when the recovered sequence holds and the source is unrecognized, successful, weakly protected, or followed by further access; close only when recovered evidence and supported context bind one exact workflow on this host, with outside confirmation when telemetry cannot prove legitimacy; preserve evidence and escalate when results are mixed or visibility is limited.

False positive analysis

  • Clustered file services, SMB/RPC proxies, backup controllers, or management tiers can legitimately front machine-account NTLM traffic through bounded SMB/RPC paths. Confirm by verifying the same source.ip, winlog.computer_name, winlog.event_data.TargetUserName, winlog.event_data.AuthenticationPackageName, winlog.event_data.LmPackageName, status pattern, 5145 named-pipe/share object, and lack of suspicious follow-on event.code activity all converge on the same workflow. If workflow records are unavailable, require historical recurrence of that exact telemetry pattern before closing.
  • Before creating an exception, validate recurrence across prior alerts from this rule for the same source.ip, winlog.computer_name, machine account, NTLM package/version, and 5145 object family. Build the exception from the minimum confirmed workflow pattern; avoid exceptions on source IP alone, target server alone, or dollar-suffixed machine-account names alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the exact source.ip, winlog.computer_name, winlog.event_data.TargetUserName, winlog.event_data.AuthenticationPackageName, winlog.event_data.LmPackageName, winlog.event_data.Status or winlog.event_data.SubStatus, and 5145 object pattern that proved the workflow. Create a narrow exception only after recurrence proves the same telemetry pattern.
  • If suspicious but unconfirmed, preserve the alert document, Timeline member events, recovered 5145 object, authentication result, NTLM package/version, source and target identifiers, status values, and any follow-on Windows Security records before containment. Use reversible containment first, such as temporarily blocking the recovered source from SMB/RPC access to the affected server or isolating the unexpected source host when its role tolerates isolation.
  • If confirmed malicious, keep the preserved evidence set attached to the case, then isolate or block the source host and restrict its SMB/RPC access to the affected winlog.computer_name. Eradicate only confirmed follow-on services, tasks, shares, or relay tooling identified during investigation; coordinate disruptive actions on domain controllers, cluster nodes, and production servers with identity and infrastructure owners.
  • Rotate the affected computer-account secret only after evidence preservation and service-impact review, then review delegated or administrative credentials that could have been exposed or reused through the relayed session. Reduce NTLM exposure, enforce SMB signing and Extended Protection for Authentication where applicable, and disable unneeded coercion-prone RPC services on the affected tier.
  • After containment, audit other servers reached from the same source.ip and retain the Windows Security telemetry needed to reconstruct the 5145-to-4624/4625 sequence. Document any reflection-style or marshaled-target variant indicators for future case comparison.

References

Related rules

to-top