Loading

KRBTGT Delegation Backdoor

Identifies the modification of the msDS-AllowedToDelegateTo attribute to KRBTGT. Attackers can use this technique to maintain persistence to the domain by having the ability to request tickets for the KRBTGT service.

Rule type: eql
Rule indices:

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

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

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

Version: 214
Rule authors:

  • Elastic

Rule license: Elastic License v2

Audit User Account Management must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-user-account-management

  • What account was changed, and what krbtgt delegation value did the alert preserve?

    • Focus: alert 4738 evidence in winlog.event_data.TargetSid, winlog.event_data.TargetUserName, winlog.event_data.TargetDomainName, winlog.event_data.AllowedToDelegateTo, and winlog.computer_name.
    • Implication: Escalate when the target now lists a krbtgt service target such as "krbtgt/DOMAIN"; lower suspicion only when the target, value, and controller match a time-boxed security validation or emergency delegation repair explicitly naming krbtgt, which is not routine delegation.

  • Who initiated the account change?

    • Focus: winlog.event_data.SubjectUserSid, winlog.event_data.SubjectUserName, winlog.event_data.SubjectDomainName, and winlog.event_data.SubjectLogonId.
    • Implication: Escalate when a human admin, newly introduced service identity, or unexpected controller-local context made the change; lower suspicion only when the same stable tier-0 identity owns this exact delegation-maintenance path.

  • What source and authentication method created the modifying session?

    • Focus: authentication events on the same host.id where winlog.event_data.TargetLogonId equals alert winlog.event_data.SubjectLogonId; review source.ip, winlog.logon.type, and winlog.event_data.AuthenticationPackageName. $investigate_0
    • Hint: missing authentication telemetry, or absent source.ip on local/service sessions, is unresolved, not benign; review same-session 4648 records when credential-source context matters. $investigate_1
    • Implication: Escalate for an unusual source, remote-interactive access, unexpected NTLM, or explicit credentials; lower suspicion when the session maps to the expected tier-0 admin path for this controller.

  • Did surrounding directory changes prepare, repeat, or roll back the krbtgt delegation?

    • Focus: surrounding 4738 records for the same winlog.event_data.TargetSid, plus 5136 records on the same winlog.computer_name and modifying subject/session; use winlog.event_data.ObjectDN, winlog.event_data.AttributeLDAPDisplayName, and winlog.event_data.AttributeValue to identify the affected object and value.
    • Hint: reconstruct the burst from same-target 4738 and same-controller directory-service changes; if 5136 grouping is thin, use winlog.record_id order on the same controller plus subject/session and object DN. Absent 5136 evidence leaves prerequisite and rollback context unresolved, not benign.
      • $investigate_2
      • $investigate_3
    • Implication: Escalate when winlog.event_data.AttributeLDAPDisplayName and winlog.event_data.AttributeValue show delegation-enabling changes, repeated msDS-AllowedToDelegateTo writes, or no rollback; prompt removal narrows the persistence window but does not clear actor or session intent.

  • Does the same actor or target touch other delegation-relevant accounts in the case window?

    • Focus: run this only if earlier answers are suspicious or unresolved; search 4738 and 5136 records for the same modifying subject/session or winlog.event_data.TargetSid, then compare winlog.event_data.TargetUserName, winlog.event_data.ObjectDN, winlog.event_data.AttributeLDAPDisplayName, and winlog.event_data.AttributeValue.
    • Implication: Broaden scope when the same actor or target appears in additional delegation writes across objects or controllers; keep it narrow when changes stay confined to one exact target and resolved maintenance path. $investigate_4

  • Escalate when a non-routine actor/session adds krbtgt delegation, supporting directory changes show setup, the value remains, or same-actor/target scope expands; close only when the modified account, krbtgt value, actor/session, source/authentication context, surrounding changes, rollback, and scope all align with one tightly controlled authorized workflow; preserve raw 4738, authentication, and directory-change evidence and escalate when findings stay mixed or incomplete.

  • Authorized security validation or emergency delegation repair can trigger this rule only when krbtgt delegation is the explicit planned action. Confirm the target (winlog.event_data.TargetSid plus winlog.event_data.AllowedToDelegateTo), actor/session (winlog.event_data.SubjectUserSid, winlog.event_data.SubjectLogonId, and recovered authentication context), controller, and surrounding attribute evidence all align. If change records are unavailable, telemetry-only closure must still bind one exact workflow with no contradictions; prior benign recurrence strengthens confidence but is not required.
  • Do not close generic service onboarding, migration, or constrained-delegation cutover as benign unless outside confirmation explicitly names krbtgt delegation and telemetry matches that exact target, actor, session, and controller path. A normal service-delegation explanation that does not account for the krbtgt value is incomplete.
  • Before creating an exception, validate that the same winlog.event_data.SubjectUserSid, winlog.event_data.TargetSid, exact winlog.event_data.AllowedToDelegateTo, winlog.computer_name, and recovered session pattern identify the authorized workflow across prior benign cases or a tightly controlled test plan. Build the exception from that minimum confirmed pattern, and avoid exceptions on "krbtgt", event 4738, or "msDS-AllowedToDelegateTo" alone.
  • If confirmed benign, document the actor, target account, krbtgt value, controller, recovered session context, and surrounding delegation-change pattern before reversing temporary containment. Create an exception only if that same pattern is stable across prior benign cases.
  • If suspicious but unconfirmed, first export the alert, raw 4738 record, matching authentication events, and surrounding 4738 or 5136 records. Preserve the modified account, krbtgt value, actor/session, source/auth context, and rollback evidence before reversible containment such as heightened monitoring or temporary delegation-administration restrictions.
  • If confirmed malicious, preserve the same identity, session, and directory-change evidence first, then restrict or disable the modifying account. Restrict the modified target only when it was intentionally backdoored or used for follow-on Kerberos abuse. Contain the recovered source host when session evidence identifies one, or hand off the preserved evidence set to Active Directory or incident response.
  • After containment, review recent 4738 and 5136 records for the same actor, target, and controller before cleanup. Remove the unauthorized krbtgt value from the msDS-AllowedToDelegateTo attribute, roll back related delegation-prerequisite changes identified in the same change set, and verify clean replication across domain controllers.
  • If ticket abuse or broader Active Directory compromise is confirmed, activate the domain-compromise plan, including the required double reset of krbtgt after scoping and coordination with directory owners.
  • Post-incident hardening: restrict delegation administration and SeEnableDelegationPrivilege to dedicated tier-0 identities, keep Audit User Account Management plus supporting 5136, 4624, and 4648 visibility on domain controllers, and document any recurring benign validation pattern for future triage.
iam where host.os.type == "windows" and event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*"

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK