dMSA Account Creation by an Unusual User

  1[metadata]
  2creation_date = "2025/05/23"
  3integration = ["system", "windows"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  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    "Noise: Low",
 32    "Performance: Normal",
 33    "Rule Type: New Terms",
 34    "Platform: Windows",
 35]
 36timestamp_override = "event.ingested"
 37type = "new_terms"
 38
 39query = '''
 40event.code:5137 and host.os.type:"windows" and winlog.event_data.ObjectClass:"msDS-DelegatedManagedServiceAccount"
 41'''
 42
 43note = """## Triage and analysis
 44
 45### Investigating dMSA Account Creation by an Unusual User
 46
 47#### Possible investigation steps
 48
 49- What dMSA object did the alert show, and where was it created?
 50  - 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.
 51  - 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.
 52- Did the same dMSA receive migration or privilege-enabling attributes?
 53  - Why: BadSuccessor-style abuse elevates creation with `5136` changes such as msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState, SPNs, delegation attributes, or gMSA membership.
 54  - 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
 55  - 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.
 56  - 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.
 57- Who created the dMSA, and what session reached the domain controller?
 58  - 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
 59  - 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.
 60  - 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.
 61- Did the same session touch other directory objects?
 62  - 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`.
 63  - 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.
 64- Did the new dMSA get used from systems that should not touch it?
 65  - 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.
 66  - Hint: absent dMSA authentication is a timing or visibility gap, not proof creation is harmless.
 67  - 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.
 68- If local evidence is suspicious or incomplete, do related Windows Security events show broader AD abuse?
 69  - Focus: review events for writer `user.id`, then compare records referencing the new `winlog.event_data.ObjectGUID`. $investigate_2
 70  - 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
 71  - 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.
 72- 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.
 73
 74### False positive analysis
 75
 76- 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.
 77- 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.
 78- 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.
 79
 80### Response and remediation
 81
 82- 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.
 83- 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.
 84- 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.
 85- 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.
 86- 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.
 87"""
 88
 89setup = """## Setup
 90
 91Audit Directory Service Changes must be enabled to generate the events used by this rule.
 92Setup instructions: https://ela.st/audit-directory-service-changes
 93"""
 94
 95[rule.investigation_fields]
 96field_names = [
 97    "@timestamp",
 98    "event.code",
 99    "user.name",
100    "user.id",
101    "winlog.event_data.SubjectUserName",
102    "winlog.event_data.SubjectUserSid",
103    "winlog.event_data.SubjectDomainName",
104    "winlog.event_data.SubjectLogonId",
105    "winlog.event_data.ObjectDN",
106    "winlog.event_data.ObjectGUID",
107    "winlog.event_data.ObjectClass",
108    "winlog.event_data.DSName",
109    "host.name",
110    "host.id",
111    "winlog.computer_name",
112]
113
114[transform]
115
116[[transform.investigate]]
117label = "Directory changes for the same dMSA object on this controller"
118description = ""
119providers = [
120  [
121    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
122    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" },
123    { excluded = false, field = "event.code", queryType = "phrase", value = "5137", valueType = "string" }
124  ],
125  [
126    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
127    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" },
128    { excluded = false, field = "event.code", queryType = "phrase", value = "5136", valueType = "string" }
129  ]
130]
131relativeFrom = "now-1h"
132relativeTo = "now"
133
134[[transform.investigate]]
135label = "Authentication events for the writer session on this controller"
136description = ""
137providers = [
138  [
139    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
140    { excluded = false, field = "winlog.event_data.TargetLogonId", queryType = "phrase", value = "{{winlog.event_data.SubjectLogonId}}", valueType = "string" }
141  ]
142]
143relativeFrom = "now-48h/h"
144relativeTo = "now"
145
146[[transform.investigate]]
147label = "Windows Security events associated with the modifying account"
148description = ""
149providers = [
150  [
151    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
152  ],
153  [
154    { excluded = false, field = "winlog.event_data.SubjectUserSid", queryType = "phrase", value = "{{winlog.event_data.SubjectUserSid}}", valueType = "string" }
155  ]
156]
157relativeFrom = "now-48h/h"
158relativeTo = "now"
159
160[[transform.investigate]]
161label = "Windows Security events associated with the new dMSA object"
162description = ""
163providers = [
164  [
165    { excluded = false, field = "winlog.event_data.ObjectGUID", queryType = "phrase", value = "{{winlog.event_data.ObjectGUID}}", valueType = "string" }
166  ]
167]
168relativeFrom = "now-48h/h"
169relativeTo = "now"
170
171[rule.new_terms]
172field = "new_terms_fields"
173value = ["winlog.event_data.SubjectUserName"]
174[[rule.new_terms.history_window_start]]
175field = "history_window_start"
176value = "now-7d"
177
178[[rule.threat]]
179framework = "MITRE ATT&CK"
180
181[[rule.threat.technique]]
182id = "T1078"
183name = "Valid Accounts"
184reference = "https://attack.mitre.org/techniques/T1078/"
185
186[[rule.threat.technique.subtechnique]]
187id = "T1078.002"
188name = "Domain Accounts"
189reference = "https://attack.mitre.org/techniques/T1078/002/"
190
191[[rule.threat.technique]]
192id = "T1098"
193name = "Account Manipulation"
194reference = "https://attack.mitre.org/techniques/T1098/"
195
196[rule.threat.tactic]
197id = "TA0004"
198name = "Privilege Escalation"
199reference = "https://attack.mitre.org/tactics/TA0004/"
200
201[[rule.threat]]
202framework = "MITRE ATT&CK"
203
204[[rule.threat.technique]]
205id = "T1136"
206name = "Create Account"
207reference = "https://attack.mitre.org/techniques/T1136/"
208
209[[rule.threat.technique.subtechnique]]
210id = "T1136.002"
211name = "Domain Account"
212reference = "https://attack.mitre.org/techniques/T1136/002/"
213
214[rule.threat.tactic]
215id = "TA0003"
216name = "Persistence"
217reference = "https://attack.mitre.org/tactics/TA0003/"