D3-DAM Domain Account Monitoring: Event IDs, ATT&CK Coverage and Verification Tests

An attacker who creates, changes or quietly re-enables a domain account gains persistence that survives malware clean-up, and most of those changes are recorded by the domain controller long before anyone looks. MITRE D3FEND names this countermeasure Domain Account Monitoring (D3-DAM) and defines it as "Monitoring the existence of or changes to Domain User Accounts." It sits under the Detect tactic as a child of User Behavior Analysis. This card covers what D3-DAM watches, which ATT&CK techniques D3FEND relates it to, the Windows and cloud directory events that implement it, how to prove the detections fire and where they fall short. It is written for detection engineers and identity security teams; the wider event catalogue is in the Active Directory Security Monitoring and Event IDs Guide, which this card does not repeat.

Key takeaways

• It is change detection on accounts. D3-DAM watches the lifecycle of domain user accounts: creation, enablement, attribute changes, group membership, password resets and deletion, rather than how the account is used to log on.
• D3FEND relates it to four technique families. Through the Domain User Account artefact, D3FEND infers links to Valid Accounts: Domain Accounts (T1078.002), Account Discovery: Domain Account (T1087.002), Create Account: Domain Account (T1136.002) and Account Manipulation: Additional Email Delegate Permissions (T1098.002).
• The audit policy is the control. On Windows, the Audit User Account Management and Audit Security Group Management subcategories produce events 4720, 4738, 4728 and related IDs; if they are not enabled on every domain controller, the countermeasure does not exist.
• Service accounts deserve the tightest rules. Non-human domain accounts rarely change legitimately, so any password reset, delegation change or group addition on them is a high-value alert.
• Verify with synthetic changes. A scheduled create, modify and delete of a test account proves the audit policy, log forwarding and SIEM rules all work end to end.

D3-DAM at a glance

What D3-DAM watches

D3FEND gives no extended description for D3-DAM beyond its definition and the Microsoft audit reference, so the practical scope comes from that reference. Monitoring the "existence of or changes to" domain accounts breaks into five event groups.

• Existence: accounts created (4720), deleted (4726), enabled (4722) and disabled (4725). A new account outside the provisioning process, or a dormant account re-enabled, is the classic persistence signal.
• Attribute changes: event 4738 "A user account was changed" lists changed attributes, including User Principal Name, Script Path, Password Last Set, Primary Group ID, AllowedToDelegateTo, SID History and the User Account Control flags.
• Credentials: password change attempts (4723) and resets (4724). A reset by a help desk account on a privileged or service account is worth an alert on its own.
• Group membership: members added to security-enabled global groups (4728) and universal groups (4756), with local group changes on domain controllers (4732) covering built-in groups such as Administrators.
• Sensitive state: SID History added (4765) or failed (4766), account name changed (4781), and the Directory Services Restore Mode password set attempt (4794).

Where identity fits

Domain service accounts are non-human identities with long-lived passwords, broad rights and no owner who would notice a change. Microsoft's own monitoring guidance for event 4738 singles out domain administrator and service accounts as the critical accounts whose changes should be watched by name. Build a watch list from your service account inventory, as described in the M1026 Privileged Account Management guide, and treat any change to those accounts as an incident until the change ticket is found.

ATT&CK techniques D3FEND relates to D3-DAM

Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-DAM. Every row below is inferred through the shared Domain User Account artefact and labelled "inferred and experimental" on the D3FEND site (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

Read the table as a coverage guide. D3-DAM is strong against creation and manipulation, partial against valid account abuse and weak against discovery. Defensive detail for each technique is in the MITRE ATT&CK T1136 Create Account Guide, the MITRE ATT&CK T1098 Account Manipulation Guide, the MITRE ATT&CK T1078 Valid Accounts Guide and the T1087 and T1069 Account and Permission Group Discovery Defensive Guide. A closely related technique, Additional Local or Domain Groups (T1098.007), is not in D3FEND's inferred list, but group membership events 4728 and 4756 are the main way to see it.

Where it is implemented

Detection rules worth building first

Microsoft's event 4738 guidance lists specific values that should be treated as suspicious. They make a good first rule set because they are rarely legitimate.

Which groups count as privileged is your decision; start with the built-in administrative groups and any group with rights over domain controllers, then add the groups that the BloodHound and Active Directory Attack Path Guide shows as stepping stones in your own directory.

Implementation steps

1. Set the audit policy. Enable Audit User Account Management (Success and Failure) and Audit Security Group Management (Success) through advanced audit policy on the Domain Controllers organisational unit. Confirm with auditpol on each domain controller.
2. Forward and retain. Send the DC Security log to the SIEM from every domain controller, including read-only DCs and DCs in small sites. Check the log size so that events are not overwritten before collection.
3. Build watch lists. Tier 0 accounts, privileged groups, service accounts and break-glass accounts. Keep them generated from the directory and the service account register, not hand-maintained.
4. Write rules in audit mode. Run the rules above as reports for two to four weeks. Record the legitimate sources of change: the provisioning system, the help desk, migration tooling.
5. Promote to alerts. Turn the low-noise rules into alerts, suppress only by named actor and change ticket, never by blanket account exclusions.
6. Add the cloud side. Collect identity provider audit logs and mirror the high-value rules for cloud role and group changes.
7. Roll back safely. If a rule floods the queue, return it to report mode rather than deleting it, and keep the audit policy on: the events are needed for investigations even when no rule uses them.

How to verify it works

• Synthetic lifecycle test: monthly, from an approved test account, create a test user, change one watched attribute, add it to a monitored test group, then delete it. Confirm events 4720, 4738, 4728 and 4726 arrive in the SIEM and the matching alerts fire.
• Per-DC coverage check: confirm every domain controller has sent account management events in the last period. A DC that never reports is a blind spot, since a change is logged on the DC that processed it.
• Policy drift check: compare effective audit policy on each DC with the baseline after every Group Policy change.
• Exercise test: in authorised adversary emulation, record whether account creation and group additions were detected and how quickly.

Limits, bypasses and failure patterns

• Discovery is invisible to change auditing: account enumeration through LDAP reads produces no account management event. Pair D3-DAM with LDAP query monitoring or decoy accounts; see Decoy accounts in Active Directory.
• Some changes produce no useful 4738: Microsoft states that some changes do not generate the event, and that changes to unlisted attributes, such as a DACL change, can produce a 4738 with every attribute shown as "-". ACL abuse needs directory service change auditing; see the Active Directory ACL and Delegation Hygiene Guide.
• Replication-based changes: techniques that write directly through replication, rather than through normal administration interfaces, may not produce the expected account management events. Detection then depends on replication monitoring, covered in the Golden Ticket, Silver Ticket and DCSync Guide.
• Noise from provisioning: rules that alert on every 4738 drown in password expiry and HR sync changes. Filter by actor and by watched attribute.
• Log tampering: an attacker with domain admin rights can change audit policy or clear logs. Alert on audit policy changes and on DCs that stop reporting.
• Cloud-only blind spots: accounts and roles created directly in the cloud identity provider never touch a domain controller.

Framework mapping

Practitioner checklist

• Enable Audit User Account Management (Success and Failure) and Audit Security Group Management (Success) on every domain controller.
• Forward the Security log from every DC and alert when a DC goes silent.
• Keep generated watch lists for Tier 0, privileged groups, service accounts and break-glass accounts.
• Alert on the 4738 flag changes Microsoft lists as suspicious, starting with "Don't Require Preauth" and SID History.
• Match every privileged group addition to a change ticket.
• Collect cloud identity provider audit logs and mirror the high-value rules there.
• Run a monthly synthetic account lifecycle test and record the result.
• Pair D3-DAM with logon analytics and discovery detection, since it does not see either.

Standards and references

• MITRE D3FEND: Domain Account Monitoring (D3-DAM)
• Microsoft Learn: Audit User Account Management
• Microsoft Learn: Audit Security Group Management
• Microsoft Learn: Event 4738, a user account was changed
• Microsoft Learn: Microsoft Entra audit log activities
• MITRE ATT&CK: T1136.002 Create Account: Domain Account
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-2)

Related NHI Mgmt Group resources: Active Directory Security Monitoring and Event IDs Guide · MITRE ATT&CK T1136 Create Account Guide · M1026 Privileged Account Management · D3-DUC Decoy User Credential · MITRE D3FEND Guide