« Potential Kerberos Relay Attack against a Computer Account Creation or Modification of Domain Backup DPAPI private key »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential NTLM Relay Attack against a Computer Account

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Potential NTLM Relay Attack against a Computer Account

edit

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.

Rule type: eql

Rule indices:

  • logs-system.security*
  • logs-windows.forwarded*
  • winlogbeat-*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: Active Directory
  • Use Case: Active Directory Monitoring
  • Data Source: Windows Security Event Logs
  • Resources: Investigation Guide

Version: 2

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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{"description":"","label":"NTLM authentication events from this source to this target","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AuthenticationPackageName","queryType":"phrase","value":"NTLM","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"},{"excluded":false,"field":"winlog.event_data.AuthenticationPackageName","queryType":"phrase","value":"NTLM","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"Follow-on Windows Security events from this source to this target","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"5145","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4624","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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{"description":"","label":"Alerts associated with this source IP","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: if source scope remains unclear, check related target-server alerts for the alert host.id. !{investigate{"description":"","label":"Alerts associated with this target server","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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.

Setup

edit

Setup

The following Windows audit policies must be enabled to generate the events used by this rule: - Audit Logon - Audit Detailed File Share

Rule query

edit
sequence by winlog.computer_name, source.ip with maxspan=5s

/* Filter for an event that indicates coercion against known abused named pipes using an account that is not the host */
[file where host.os.type == "windows" and event.code : "5145" and
    not startswith~(winlog.computer_name, substring(user.name, 0, -1)) and
    file.name : (
        "Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc",
        "eventlog", "winreg", "srvsvc", "dnsserver", "dhcpserver", "WinsPipe"
    )]

/* Detects a logon attempt using the NTLM protocol resulting from the coercion coming from the same IP address */
[authentication where host.os.type == "windows" and event.code in ("4624", "4625") and
    endswith~(user.name, "$") and winlog.logon.type : "network" and
    winlog.event_data.AuthenticationPackageName : "NTLM" and

    /* Filter for a machine account that matches the hostname */
    startswith~(winlog.computer_name, substring(user.name, 0, -1)) and

    /* Verify if the Source IP belongs to the host */
    not endswith(string(source.ip), string(host.ip)) and
    source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"]

Framework: MITRE ATT&CKTM

« Potential Kerberos Relay Attack against a Computer Account Creation or Modification of Domain Backup DPAPI private key »