« LSASS Process Access via Windows API Mimikatz Memssp Log File Detected »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential Machine Account Relay Attack via SMB

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

Potential Machine Account Relay Attack via SMB

edit

Identifies potential relay attacks against a machine account by identifying network share access events coming from a remote source.ip but using the target server computer account. This may indicate an SMB relay attack.

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: 4

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Machine Account Relay Attack via SMB

Possible investigation steps

  • What does the alert-local 5145 event show about the remote source, target server, machine account, and exact share or pipe path?
  • Focus: source.ip, winlog.computer_name, user.name, winlog.event_data.ShareName, and winlog.event_data.RelativeTargetName, noting "IPC$", "ADMIN$", and coercion-related named pipes in the relative target path.
  • Implication: escalate when a remote source reaches relayable pipes or admin shares while user.name matches the target server machine account; lower suspicion only when the same source, target, and path are already tied to a known relay-safe infrastructure tier.
  • Does the apparent machine-account access really resolve to one target-server identity and one stable infrastructure path?
  • Focus: user.name, winlog.computer_name, host.name, host.ip, and source.ip.
  • Implication: relay remains likely when the target server account appears from a source.ip that is not one of the target server’s host.ip values; if hostname aliases or clustering explain the address mismatch, keep validating the share path and auth evidence before closure.
  • Do surrounding authentication events show the same source creating machine-account network logons or NTLM fallback on the target?
  • Why: 5145 proves share access; 4624 and 4625 show whether the source authenticated with the target machine account and which protocol path was used, while 4648 only adds explicit-credential context.
  • Focus: Windows Security events on the target server from the alert source: winlog.event_data.TargetUserName, winlog.logon.type, winlog.event_data.AuthenticationPackageName, and winlog.event_data.LmPackageName.
  • Hint: pivot on 4624 and 4625 for the alert source.ip, target server, and user.name to winlog.event_data.TargetUserName match; use 4648 only for explicit-credential context. Missing authentication telemetry is unresolved, not benign. !{investigate{"description":"","label":"Authentication events from this source to the target machine account","providers":[[{"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":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{user.name}}","valueType":"string"}],[{"excluded":false,"field":"event.code","queryType":"phrase","value":"4625","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":"winlog.event_data.TargetUserName","queryType":"phrase","value":"{{user.name}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the same source produces machine-account type 3 logons, failures followed by success, NTLM where Kerberos is expected, or weak LM details; lower suspicion only when auth fields match the same stable infrastructure path seen in the 5145 evidence.
  • Do surrounding 5145 events show the source revisiting relayable pipes, alternate shares, or more servers with the same machine-account pattern?
  • Focus: 5145 events for the same source.ip and user.name, comparing winlog.event_data.ShareName, winlog.event_data.RelativeTargetName, and winlog.event_data.AccessMask across target servers.
  • Hint: start with 5145 events for the same source.ip and user.name in the alert window, then expand only if the first events show relayable pipe access, admin-share access, or repeated machine-account use. !{investigate{"description":"","label":"Detailed file-share events from this source and machine account","providers":[[{"excluded":false,"field":"event.code","queryType":"phrase","value":"5145","valueType":"string"},{"excluded":false,"field":"source.ip","queryType":"phrase","value":"{{source.ip}}","valueType":"string"},{"excluded":false,"field":"user.name","queryType":"phrase","value":"{{user.name}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: broader pipe, admin-share, or multi-server coverage supports active relay; a bounded single-path pattern lowers urgency only when it stays inside the same recognized infrastructure cohort.
  • If local evidence stays suspicious or unresolved, do related alerts expand the source or target scope?
  • Focus: related alerts for source.ip covering coercion, relay, lateral movement, remote execution, or credential access from the same origin. !{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: compare target-server alerts for suspicious authentication, service creation, persistence, or credential access on 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 containment when the same source targets other servers or the target shows follow-on execution or persistence; keep scope local only when related alerts stay confined to the same recognized infrastructure cohort.
  • Based on the evidence gathered, what disposition is supported?
  • Focus: 5145 share or pipe path, machine-account and target fit, source role, surrounding auth, repeated 5145 scope, and related-alert scope.
  • Implication: escalate when relayable access aligns with the target machine account plus NTLM/auth corroboration, repeated 5145 activity, or related alerts; close only when all evidence tightly binds one stable infrastructure workflow with no contradictory auth or scope; preserve and escalate when evidence is mixed or incomplete.

False positive analysis

  • Load balancers, cluster nodes, proxies, management gateways, backup, or orchestration tooling can make a machine account appear to access a share from a different source. Confirm only when the source-target-account tuple, share or pipe path, access mask, and auth method all align with the same stable infrastructure role, with no broader relayable paths or extra machine-account auth. Use topology records only to corroborate that exact telemetry pattern; if unavailable, require the same field pattern across prior alerts.
  • Build exceptions from the minimum confirmed workflow: source.ip, winlog.computer_name, user.name, winlog.event_data.ShareName, and winlog.event_data.RelativeTargetName, plus the stable auth pattern when available. Avoid exceptions on user.name, winlog.event_data.ShareName, or source.ip alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the recognized source, target server, machine account, share or pipe path, access mask, and auth pattern. Create an exception only after the same workflow recurs across prior alerts or is corroborated by topology records.
  • If suspicious but unconfirmed, preserve the alert, surrounding 5145 and authentication records, case timeline, source and target identities, share or pipe path, access mask, and NTLM/auth details before containment. Apply reversible containment first, such as restricting SMB from the source to the target or tightening access to the exposed relay path; use host isolation only if the source continues suspicious machine-account access and the server role can tolerate interruption.
  • If confirmed malicious, contain the source host or block the relay path using the preserved 5145/auth evidence. Record the evidence before terminating processes, blocking access, or rotating secrets.
  • After scoping affected source and target systems, rotate the affected computer-account secret when evidence shows credential material was exposed, replayed, or relayed to privileged services; otherwise coordinate identity review before disruptive rotation. Review adjacent systems or delegated credentials exposed through the same relay path.
  • Post-incident hardening: enforce SMB signing or Extended Protection, reduce NTLM exposure, restrict relayable services, and audit other servers contacted from the same source.ip.

Setup

edit

Setup

Audit Detailed File Share must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-detailed-file-share

Rule query

edit
file where host.os.type == "windows" and event.code == "5145" and endswith(user.name, "$") and

 /* compare computername with user.name and make sure they match (dot-boundary prevents prefix-only matches) */
 startswith~(concat(winlog.computer_name, "."), concat(substring(user.name, 0, -1), ".")) and

 /* exclude local access */
 not endswith(string(source.ip), string(host.ip)) and
 source.ip != "::" and source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1"

Framework: MITRE ATT&CKTM

« LSASS Process Access via Windows API Mimikatz Memssp Log File Detected »