dMSA Account Creation by an Unusual User

  1[metadata]
  2creation_date = "2025/05/23"
  3integration = ["system", "windows"]
  4maturity = "production"
  5updated_date = "2026/05/03"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects creation of a delegated Managed Service Account by an unusual subject account. Attackers can abuse weak
 11child-object or msDS-DelegatedManagedServiceAccount rights during account migration to elevate privileges.
 12"""
 13from = "now-9m"
 14index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
 15language = "kuery"
 16license = "Elastic License v2"
 17name = "dMSA Account Creation by an Unusual User"
 18references = ["https://www.akamai.com/blog/security-research/abusing-dmsa-for-privilege-escalation-in-active-directory"]
 19risk_score = 73
 20rule_id = "f0dbff4c-1aa7-4458-9ed5-ada472f64970"
 21severity = "high"
 22tags = [
 23    "Domain: Endpoint",
 24    "OS: Windows",
 25    "Use Case: Threat Detection",
 26    "Tactic: Privilege Escalation",
 27    "Use Case: Active Directory Monitoring",
 28    "Data Source: Active Directory",
 29    "Data Source: Windows Security Event Logs",
 30    "Resources: Investigation Guide",
 31]
 32timestamp_override = "event.ingested"
 33type = "new_terms"
 34
 35query = '''
 36event.code:5137 and host.os.type:"windows" and winlog.event_data.ObjectClass:"msDS-DelegatedManagedServiceAccount"
 37'''
 38
 39note = """## Triage and analysis
 40
 41### Investigating dMSA Account Creation by an Unusual User
 42
 43#### Possible investigation steps
 44
 45- What dMSA object did the alert show, and where was it created?
 46  - Focus: use `winlog.event_data.ObjectClass`, `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectGUID`, `winlog.event_data.SubjectUserName`, and `winlog.computer_name` to identify the new msDS-DelegatedManagedServiceAccount, new-to-this-rule writer, and controller.
 47  - Implication: escalate when the object is in a privileged service, sync, backup, DC, or identity-infrastructure path, or when name or writer lacks a narrow service-account purpose; lower only when DN, writer, and controller match one exact planned dMSA rollout or lab path.
 48- Did the same dMSA receive migration or privilege-enabling attributes?
 49  - Why: BadSuccessor-style abuse elevates creation with `5136` changes such as msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPNs, delegation attributes, or gMSA membership.
 50  - Focus: review same-object `5136` and `5137` records on this controller with `winlog.event_data.ObjectGUID`, comparing `winlog.event_data.AttributeLDAPDisplayName`, `winlog.event_data.AttributeValue`, and `winlog.event_data.ObjectDN`. $investigate_0
 51  - Hint: if same-controller results have gaps, repeat the `winlog.event_data.ObjectGUID` search across DC Windows Security logs before treating missing follow-on changes as lower risk.
 52  - Implication: escalate when values link the dMSA to a privileged predecessor, advance migration state, or add SPN/delegation material; lower suspicion only when attributes form one bounded migration to the intended legacy service account.
 53- Who created the dMSA, and what session reached the domain controller?
 54  - Focus: identify writer and session with `winlog.event_data.SubjectUserSid` and `winlog.event_data.SubjectLogonId`, then recover `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`. $investigate_1
 55  - Hint: this pivot uses `winlog.event_data.TargetLogonId` for `4624` or `4634`; search `4648` separately with `winlog.event_data.SubjectLogonId` when explicit-credential use matters. Missing authentication telemetry is unresolved, not benign.
 56  - Implication: escalate for an unexpected human, helpdesk account, low-privilege service identity, unusual source, interactive/RDP session, or explicit-credential path; lower suspicion only when actor and source match the narrow identity-management path for this object.
 57- Did the same session touch other directory objects?
 58  - Focus: compare surrounding `5137` and `5136` records on the same `host.id` for `winlog.event_data.SubjectLogonId`, reading `winlog.event_data.ObjectDN`, `winlog.event_data.ObjectClass`, and `winlog.event_data.AttributeLDAPDisplayName`.
 59  - Implication: escalate when the session creates multiple dMSAs, edits ACLs, changes delegation, or touches unrelated privileged users, computers, groups, or service accounts; lower when every change stays tied to one bounded dMSA rollout.
 60- Did the new dMSA get used from systems that should not touch it?
 61  - Focus: derive the dMSA from the CN in `winlog.event_data.ObjectDN`, confirm it in `winlog.event_data.TargetUserName`, then review `4624` records for `source.ip`, `winlog.logon.type`, and `winlog.event_data.AuthenticationPackageName`; search `4648` separately for explicit credential use.
 62  - Hint: absent dMSA authentication is a timing or visibility gap, not proof creation is harmless.
 63  - Implication: escalate when the dMSA authenticates from unexpected servers, workstations, jump hosts, or non-service logon types; lower suspicion only when use stays inside the exact service host set for the confirmed rollout.
 64- If local evidence is suspicious or incomplete, do related Windows Security events show broader AD abuse?
 65  - Focus: review events for writer `user.id`, then compare records referencing the new `winlog.event_data.ObjectGUID`. $investigate_2
 66  - Hint: use the object-event view for shadow credentials, delegation abuse, unusual service changes, or other AD tampering tied to the same dMSA. $investigate_3
 67  - Implication: escalate and expand scope when either entity is tied to privilege abuse, directory tampering, or suspicious authentication; keep scope to this object when related events are quiet, but do not close solely because no other event exists.
 68- Escalate for sensitive placement, privileged migration links, unexpected writer/session context, broader directory edits, unexpected dMSA authentication, or related AD-abuse events; close only when telemetry and outside confirmation prove one exact planned migration or lab activity; if mixed or incomplete, preserve directory-change and session evidence and escalate.
 69
 70### False positive analysis
 71
 72- Planned dMSA rollout or service-account migration can legitimately create msDS-DelegatedManagedServiceAccount objects. Confirm expected `winlog.event_data.ObjectDN`, same-object `5136` attributes limited to the intended legacy service account, and `winlog.event_data.SubjectUserSid`, recovered `source.ip`, and `winlog.logon.type` matching the narrow migration account and host path. If change records, migration tickets, or owner confirmation are unavailable, leave unresolved unless telemetry proves the exact authorized workflow.
 73- Lab validation or staged service-account modernization can also trigger this rule. Confirm `winlog.event_data.ObjectDN` stays in the test/staging OU, the same `winlog.event_data.SubjectLogonId` avoids unrelated privileged objects, and any `winlog.event_data.TargetUserName`, `source.ip`, or `winlog.logon.type` activity stays limited to designated test systems. If test scope lacks outside confirmation, treat the alert as unresolved.
 74- Before creating an exception, validate exact writer `winlog.event_data.SubjectUserSid`, dMSA path pattern, bounded same-object `5136` attributes, controller path, and recovered source. Use a temporary or tightly scoped exception for one-time migrations, and avoid exceptions on event `5137`, all msDS-DelegatedManagedServiceAccount objects, or all dMSA creation activity.
 75
 76### Response and remediation
 77
 78- If confirmed benign, reverse any temporary containment and document the evidence that proved the authorized workflow: `winlog.event_data.SubjectUserSid`, `winlog.event_data.ObjectDN`, same-object `5136` sequence, recovered `source.ip`, `winlog.logon.type`, and exact rollout or lab scope.
 79- If suspicious but unconfirmed, preserve a case export with the triggering `5137`, related same-object `5136` records, recovered `4624` or `4648` records, and key object/session identifiers before containment. Apply reversible containment first, such as temporary DC access restrictions for the recovered source or heightened monitoring on the writer and dMSA. Disable the writer or isolate the source host only if privileged follow-on changes, unexpected authentication, or related events appear.
 80- If confirmed malicious, preserve the same directory-change and session evidence first, then remove the unauthorized dMSA and roll back related msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPN, delegation, or membership changes found in the same-object sequence. Isolate the recovered source host when endpoint response is available and host criticality permits, then disable or reset the compromised writer and any linked service accounts.
 81- Before deleting objects or closing the case, review hosts and services that used the new dMSA, verify rollback replication across domain controllers, then rotate affected secrets or restore service bindings.
 82- Post-incident hardening: restrict who can create dMSAs or start service-account migration, review CreateChild and delegated managed service account rights on service-account OUs, retain `5136`, `5137`, `4624`, and `4648` coverage on domain controllers, and record the confirmed workflow or BadSuccessor evidence pattern for future triage.
 83"""
 84
 85setup = """## Setup
 86
 87Audit Directory Service Changes must be enabled to generate the events used by this rule.
 88Setup instructions: https://ela.st/audit-directory-service-changes
 89"""
 90
 91[rule.investigation_fields]
 92field_names = [
 93    "@timestamp",
 94    "event.code",
 95    "user.name",
 96    "user.id",
 97    "winlog.event_data.SubjectUserName",
 98    "winlog.event_data.SubjectUserSid",
 99    "winlog.event_data.SubjectDomainName",
100    "winlog.event_data.SubjectLogonId",
101    "winlog.event_data.ObjectDN",
102    "winlog.event_data.ObjectGUID",
103    "winlog.event_data.ObjectClass",
104    "winlog.event_data.DSName",
105    "host.name",
106    "host.id",
107    "winlog.computer_name",
108]
109
110[transform]
111
112[[transform.investigate]]
113label = "Directory changes for the same dMSA object on this controller"
114description = ""
115providers = [
116  [
117    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
118    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" },
119    { excluded = false, field = "event.code", queryType = "phrase", value = "5137", valueType = "string" }
120  ],
121  [
122    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
123    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" },
124    { excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" }
125  ]
126]
127relativeFrom = "now-1h"
128relativeTo = "now"
129
130[[transform.investigate]]
131label = "Authentication events for the writer session on this controller"
132description = ""
133providers = [
134  [
135    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
136    { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
137  ]
138]
139relativeFrom = "now-48h/h"
140relativeTo = "now"
141
142[[transform.investigate]]
143label = "Windows Security events associated with the modifying account"
144description = ""
145providers = [
146  [
147    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
148  ],
149  [
150    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" }
151  ]
152]
153relativeFrom = "now-48h/h"
154relativeTo = "now"
155
156[[transform.investigate]]
157label = "Windows Security events associated with the new dMSA object"
158description = ""
159providers = [
160  [
161    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" }
162  ]
163]
164relativeFrom = "now-48h/h"
165relativeTo = "now"
166
167[rule.new_terms]
168field = "new_terms_fields"
169value = ["winlog.event_data.SubjectUserName"]
170[[rule.new_terms.history_window_start]]
171field = "history_window_start"
172value = "now-7d"
173
174[[rule.threat]]
175framework = "MITRE ATT&CK"
176
177[[rule.threat.technique]]
178id = "T1078"
179name = "Valid Accounts"
180reference = "https://attack.mitre.org/techniques/T1078/"
181
182[[rule.threat.technique.subtechnique]]
183id = "T1078.002"
184name = "Domain Accounts"
185reference = "https://attack.mitre.org/techniques/T1078/002/"
186
187[[rule.threat.technique]]
188id = "T1098"
189name = "Account Manipulation"
190reference = "https://attack.mitre.org/techniques/T1098/"
191
192[rule.threat.tactic]
193id = "TA0004"
194name = "Privilege Escalation"
195reference = "https://attack.mitre.org/tactics/TA0004/"
196
197[[rule.threat]]
198framework = "MITRE ATT&CK"
199
200[[rule.threat.technique]]
201id = "T1136"
202name = "Create Account"
203reference = "https://attack.mitre.org/techniques/T1136/"
204
205[[rule.threat.technique.subtechnique]]
206id = "T1136.002"
207name = "Domain Account"
208reference = "https://attack.mitre.org/techniques/T1136/002/"
209
210[rule.threat.tactic]
211id = "TA0003"
212name = "Persistence"
213reference = "https://attack.mitre.org/tactics/TA0003/"