KRBTGT Delegation Backdoor
Description
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.
Query · eql
iam where host.os.type == "windows" and event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*"
Investigation fields
Pivot points the source recommends for triage.
@timestampuser.nameuser.idwinlog.event_data.SubjectUserNamewinlog.event_data.SubjectUserSidwinlog.event_data.SubjectDomainNamewinlog.event_data.SubjectLogonIdwinlog.logon.idwinlog.event_data.TargetUserNamewinlog.event_data.TargetSidwinlog.event_data.TargetDomainNamewinlog.event_data.AllowedToDelegateTohost.namehost.idwinlog.computer_name
Implementation guide
Audit User Account Management must be enabled to generate the events used by this rule. Setup instructions: https://ela.st/audit-user-account-management
Analyst notes
Investigating KRBTGT Delegation Backdoor
Possible investigation steps
- 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, andwinlog.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, andwinlog.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.idwherewinlog.event_data.TargetLogonIdequals alertwinlog.event_data.SubjectLogonId; reviewsource.ip,winlog.logon.type, andwinlog.event_data.AuthenticationPackageName. $investigate_0 - Hint: missing authentication telemetry, or absent
source.ipon 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 samewinlog.computer_nameand modifying subject/session; usewinlog.event_data.ObjectDN,winlog.event_data.AttributeLDAPDisplayName, andwinlog.event_data.AttributeValueto 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_idorder 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.AttributeLDAPDisplayNameandwinlog.event_data.AttributeValueshow 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 comparewinlog.event_data.TargetUserName,winlog.event_data.ObjectDN,winlog.event_data.AttributeLDAPDisplayName, andwinlog.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.
False positive analysis
- 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.TargetSidpluswinlog.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, exactwinlog.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.
Response and remediation
- 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-AllowedToDelegateToattribute, 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.