DET0003: T1136.002 Detection Strategy - Domain Account Creation Across Platforms
This detection strategy matters because unauthorized domain account creation is a persistence risk: a new user, administrator, or service account managed b...
Analyst context for executives and security teams
This detection strategy matters because unauthorized domain account creation is a persistence risk: a new user, administrator, or service account managed by Active Directory Domain Services can give an adversary durable access across domain-connected systems and services. For leaders, the key question is not simply whether account creation is logged, but whether the organization can quickly distinguish approved identity administration from suspicious persistence activity.
Executive priority
Prioritize this as an identity and resilience control validation. Domain account creation affects incident containment, privileged access governance, audit evidence, and recovery decisions because newly created accounts can survive password resets or endpoint cleanup if not identified. Executives should ask whether domain account creation is monitored centrally, tied to change approval, reviewed for privilege and service-account misuse, and included in incident response playbooks for persistence eradication.
Technical view
The supplied ATT&CK relationship says DET0003 detects T1136.002, Domain Account, under persistence, with related platforms Linux, macOS, and Windows. SOC and IR teams should validate visibility into domain account creation in the directory control plane and correlate it with who performed the action, source host, time, target account type, assigned groups or privileges, and any supporting change record. Because the detection strategy object itself provides no official detection logic, teams should avoid assuming coverage from a generic account-management alert and instead test whether creation of user, administrator, and service accounts is visible and reviewable across domain-connected environments.
Likely telemetry
- Directory service or Active Directory Domain Services audit records for domain account creation
- Identity administration logs showing actor, target account, timestamp, and source system where available
- Privileged access and group membership change records associated with the new account
- Endpoint or command/process telemetry from administrative systems where account creation activity is initiated and collected
- Change-management, ticketing, or identity governance evidence used to separate authorized provisioning from suspicious creation
Detection direction
- Validate that domain account creation events are collected from authoritative directory sources, not only from endpoints.
- Tune for context: creator account, source host, account naming pattern, account type, privilege assignment, creation time, and whether there is an approved business request.
- Pay special attention to newly created administrator or service accounts, since the related technique notes domain accounts can include user, administrator, and service accounts.
- Correlate account creation with immediate privilege changes or use across domain-connected Linux, macOS, and Windows environments where applicable.
- Identify blind spots where directory audit logging, SIEM ingestion, or identity governance records do not retain enough detail to support incident response.
Mitigation priorities
- Establish clear ownership and approval workflows for domain account creation, especially privileged and service accounts.
- Limit who can create domain accounts and periodically review delegated directory administration rights.
- Require auditable identity lifecycle records so SOC findings can be compared against approved provisioning activity.
- Review newly created accounts for privilege, group membership, and continued business need as part of access governance.
- Include domain account creation review in persistence-focused incident response procedures and post-containment validation.
Analyst notes and limits
This take is based on the DET0003 detection strategy object and its relationship to ATT&CK technique T1136.002, Domain Account. The business value is strongest for identity security, SOC detection engineering, managed detection validation, incident response readiness, and compliance evidence around account administration. The supplied object has no official description or detection text, so recommendations are framed as validation directions rather than specific analytics.
The detection strategy lists no platforms, tactics, official description, or official detection. Platform and tactic context comes only from the related T1136.002 technique, which identifies persistence and Linux, macOS, and Windows. Local directory architecture, logging configuration, retention, and identity governance processes are required to determine actual detection coverage.
T1136.002 Detection Strategy - Domain Account Creation Across Platforms
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1136.002 | Domain Account Sub-technique | This object detects Domain Account. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | aea0de42f2c9… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0003Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.