« Potential Computer Account NTLM Relay Activity Potential NTLM Relay Attack against a Computer Account »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Potential Kerberos 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 Kerberos 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 Kerberos authentication material for the server’s computer account 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: 3

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Potential Kerberos Relay Attack against a Computer Account

Possible investigation steps

  • What do the recovered source events prove about the relay sequence?
  • Why: Kerberos relay can reuse a coerced machine-account ticket when SPN selection or service protections allow it; reflective variants keep the same triage anchors: recovered pipe, source.ip, target dollar account, and Kerberos network auth.
  • Hint: Open Investigate in Timeline before interpreting the grouped alert; filter the alert window to event.code 5145 and 4624/4625 with the same winlog.computer_name and source.ip. In this step, read file.name from the recovered 5145 source event. If endpoint file telemetry is available for this host and time window, recover the matching file.* evidence before using it for interpretation or remediation. Treat it as optional corroboration, not the alert source.
  • Focus: recovered 5145 and 4624/4625 source events scoped by winlog.computer_name, source.ip, and @timestamp; in the 5145 event read file.name as the named-pipe value, then in the auth event read winlog.event_data.AuthenticationPackageName, winlog.logon.type, and host.ip.
  • Implication: escalate when a known coercion pipe such as Spoolss, netdfs, lsarpc, efsrpc, netlogon, srvsvc, or winreg is followed within seconds by a Kerberos network logon from the same non-target source.ip; lower suspicion only when the recovered pipe/auth outcome recurs for the same source, server, and machine account and outside topology or owner evidence verifies that exact infrastructure role.
  • Does the authenticated machine account belong to the target server?
  • Focus: winlog.event_data.TargetUserName dollar-account prefix and winlog.event_data.TargetDomainName from the auth source event compared with winlog.computer_name.
  • Implication: escalate when the target account is the target server’s dollar account and the source is not the server itself; if the account does not map to the target server, resolve whether the sequence paired unrelated events before using the alert for closure or escalation.
  • Did the Kerberos authentication create a usable session or only a failed attempt?
  • Focus: auth source-event event.code, winlog.event_data.Status, winlog.event_data.SubStatus, winlog.event_data.TargetLogonId, and source.ip.
  • Implication: prioritize confirmed compromise review when a 4624 produces a winlog.event_data.TargetLogonId; keep failed-only 4625 sequences suspicious when the source or pipe is unexplained, but lower urgency when the status pattern is a recurring, bounded failure from recognized infrastructure.
  • Does the source IP fit recognized infrastructure or relay-characteristic behavior?
  • Focus: surrounding Windows Security authentication events for source.ip and winlog.computer_name, reading winlog.event_data.TargetUserName, winlog.event_data.AuthenticationPackageName, winlog.logon.type, winlog.event_data.Status, and winlog.event_data.SubStatus.
  • Hint: use same-source authentication events to see whether the source targets multiple machine accounts or alternates Kerberos successes and failures around the alert. !{investigate{"description":"","label":"Authentication events from this source to this target","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","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":"Kerberos","valueType":"string"}],[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","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":"Kerberos","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the source is rare for this server, targets multiple machine accounts, or alternates Kerberos successes and failures outside a verified infrastructure role; missing surrounding authentication telemetry is unresolved, not benign. Lower suspicion only when the same bounded source/server/account/outcome pattern recurs and outside topology or owner evidence verifies the exact role.
  • If local evidence is suspicious or unresolved, is this part of broader relay activity?
  • Focus: related alerts for source.ip that show additional coercion or machine-account Kerberos relay. !{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: pivot target-server related alerts for service creation, persistence, or remote execution only when the source pivot is suspicious; missing related alerts narrows existing-alert scope only, not host activity. !{investigate{"description":"","label":"Alerts associated with this target server","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: for raw Windows Security scoping after a 4624, review follow-on Windows Security events on the same winlog.computer_name where winlog.event_data.SubjectLogonId matches the recovered winlog.event_data.TargetLogonId; filter within results for service creation, task creation, share access, or persistence if the result set is large. Missing follow-on events is unresolved unless that event coverage is confirmed. !{investigate{"description":"","label":"Follow-on Windows Security events for the Kerberos logon session","providers":[[{"excluded":false,"field":"winlog.computer_name","queryType":"phrase","value":"{{winlog.computer_name}}","valueType":"string"},{"excluded":false,"field":"winlog.event_data.SubjectLogonId","queryType":"phrase","value":"{{winlog.event_data.TargetLogonId}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: expand scope when source history shows other coercion or machine-account Kerberos relay, or when target history shows follow-on service, persistence, or remote-execution alerts; keep containment local only when related alerts stay limited to the same explained infrastructure tuple.
  • Based on the recovered evidence, what disposition is supported?
  • Focus: sequence integrity, target dollar-account identity, Kerberos outcome, source-fit tuple, and related-alert results.
  • Implication: escalate when the sequence is intact and unexplained, when successful machine-account Kerberos comes from an unrecognized source, or when related-alert evidence shows follow-on abuse; close only when recovered source events and supported recovery bind one exact recognized infrastructure workflow with no contradictory evidence; preserve and escalate when evidence conflicts or visibility is missing.

False positive analysis

  • Validated infrastructure peers or authorized relay/coercion testing are the narrow benign paths. Confirm by verifying the recovered source events align on the same source.ip, winlog.computer_name, target machine account in winlog.event_data.TargetUserName, Kerberos winlog.event_data.AuthenticationPackageName, network winlog.logon.type, bounded winlog.event_data.Status/winlog.event_data.SubStatus, and recovered pipe evidence for the same server/account/pipe/outcome tuple. If telemetry cannot explain the specific pipe, account, and outcome, do not close as benign.
  • Use topology, owner, or test-plan confirmation only to verify the exact recovered tuple after source-event recovery. Before creating an exception, validate recurrence across prior alerts from this rule for the same source/server/account/pipe/outcome pattern. If this is the first confirmed benign occurrence, document it as a candidate exception and monitor before suppressing. Build exceptions from the full confirmed workflow pattern; avoid exceptions on source.ip, winlog.computer_name, or machine-account name alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the evidence that proved the workflow: source.ip, winlog.computer_name, target machine account, Kerberos network auth, bounded winlog.event_data.Status/winlog.event_data.SubStatus, and recovered pipe evidence. Create an exception only after the same full pattern recurs across prior alerts from this rule.
  • If suspicious but unconfirmed, preserve the alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before containment. Use reversible containment first: temporarily restrict SMB/RPC between source.ip and the affected server, or isolate the source host when its role tolerates isolation. Escalate to broader host or account action only if follow-on service, persistence, execution, or wider relay evidence appears.
  • If confirmed malicious, preserve the same alert export, Timeline source events, recovered pipe evidence, target machine-account identity, auth outcome, session identifier when present, and related-alert results before action. Then contain the source host and restrict access to the affected winlog.computer_name; if direct containment is unavailable, hand off the preserved evidence set to the team that can act. Remove the coercion route, block the offending source path, and eradicate only services, scheduled tasks, dropped tools, or configuration changes confirmed during response.
  • Rotate the affected computer-account secret and review adjacent delegated, service, or administrative credentials that could have been exposed through the relay path. Coordinate disruptive credential or host actions with identity and infrastructure owners when the target is a domain controller, cluster node, or other critical service.
  • After containment, audit other servers reached from the same source.ip and retain Windows Security source events needed to reconstruct each source/server/account/pipe sequence.
  • Post-incident hardening: before releasing containment for a reflective Kerberos relay path, validate the relevant CVE-2025-33073 fixes and SMB signing or service-specific signing/sealing/channel binding on the affected service tier. Restrict coercion-prone RPC and named-pipe exposure, then document the confirmed source/server/account/pipe pattern for future analysts and control owners.

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 Kerberos 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 : "Kerberos" 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 Computer Account NTLM Relay Activity Potential NTLM Relay Attack against a Computer Account »