DC0068: Active Directory Object Deletion
Object deletion in AD (e.g., user accounts, groups, OUs) is logged as Event ID 5141. Examples:
- User Account: Deleted user. - Group: Deleted security/distribution group. - Organizational Unit (OU): Loss of configurations or policies. - Service Account: Disrupted operations or cover tracks. - Trust Object: Removed domain trust, disrupting connectivity.
*Data Collection Measures:*
- Audit Policy: - Enable "Audit Directory Service Changes" (Success and Failure). - Path: `Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Directory Service Changes`. - Key Event: Event ID 5141. - Log Forwarding: Use WEF to centralize logs for SIEM tools (e.g., Splunk). - Enable EDR Monitoring: - Detect processes or users that initiate unauthorized object deletions. - Monitor tools and scripts that may delete key directory objects.
Analyst context for executives and security teams
Active Directory object deletion is a high-value signal because deleted users, groups, OUs, service accounts, or trust objects can affect access, policy enforcement, operations, and connectivity. For leaders, the practical question is not only whether deletion events exist, but whether the organization can quickly distinguish approved directory administration from actions that disrupt services or remove evidence.
Executive priority
Prioritize this as an identity resilience and audit-evidence issue. If key AD deletions are not logged, centralized, and reviewed, incident responders may lack the facts needed to explain account loss, group removal, OU policy disruption, service-account outages, or trust changes. Security leaders should confirm that directory change auditing is enabled and that SIEM/EDR workflows can support timely investigation of unauthorized or high-risk deletions.
Technical view
Validate collection of Windows Security Event ID 5141 for Active Directory object deletion. Confirm that 'Audit Directory Service Changes' is enabled for Success and Failure through Advanced Audit Policy Configuration, and that logs are forwarded centrally, such as through Windows Event Forwarding, for SIEM review. SOC and IR teams should be able to identify the deleted object type, the initiating user or process where available, and whether the deletion affected users, groups, OUs, service accounts, or trust objects. Because no ATT&CK detection analytics or tactic mappings were supplied, local baselining and administrative context are required.
Likely telemetry
- Windows Security Event ID 5141 for AD object deletion
- Directory Service Changes audit logs with Success and Failure auditing enabled
- Centralized Windows Event Forwarding or equivalent SIEM-ingested AD security logs
- EDR telemetry showing processes, users, tools, or scripts associated with directory object deletion
- Change-management or administrative approval records for expected AD deletions
Detection direction
- Confirm Event ID 5141 is generated on relevant directory systems and is retained centrally for investigation.
- Tune review around high-impact object classes noted by ATT&CK: users, security or distribution groups, OUs, service accounts, and trust objects.
- Correlate deletion events with authorized change windows and known administrators to reduce false positives from legitimate directory maintenance.
- Investigate deletions initiated by unexpected users, processes, tools, or scripts, especially when they affect operational service accounts, policy-bearing OUs, or domain trusts.
- Validate blind spots: disabled Directory Service Changes auditing, missing failure auditing, incomplete log forwarding, short retention, or lack of EDR context around the initiating process.
Mitigation priorities
- Enable 'Audit Directory Service Changes' for Success and Failure where AD object deletion evidence is required.
- Centralize Event ID 5141 collection using Windows Event Forwarding or equivalent log forwarding into the SIEM.
- Ensure EDR monitoring can provide user and process context for tools or scripts that delete directory objects.
- Align monitoring with change-management processes so approved deletions can be separated from unauthorized or disruptive activity.
- Review access governance for accounts permitted to delete sensitive AD objects, especially groups, OUs, service accounts, and trust objects.
Analyst notes and limits
This data component is primarily a logging and validation requirement for Active Directory change monitoring. Its value increases when paired with identity administration context, change approvals, and endpoint/process telemetry. Relationship context was not supplied, so this take does not map the component to specific ATT&CK techniques or tactics.
The supplied ATT&CK object has no platforms, tactics, aliases, relationships, or official detection text beyond the description and data collection measures. Environment-specific AD architecture, audit policy deployment, SIEM parsing, retention, and administrative procedures must be validated locally.
Active Directory Object Deletion
Object deletion in AD (e.g., user accounts, groups, OUs) is logged as Event ID 5141. Examples:
- User Account: Deleted user. - Group: Deleted security/distribution group. - Organizational Unit (OU): Loss of configurations or policies. - Service Account: Disrupted operations or cover tracks. - Trust Object: Removed domain trust, disrupting connectivity.
*Data Collection Measures:*
- Audit Policy: - Enable "Audit Directory Service Changes" (Success and Failure). - Path: `Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Directory Service Changes`. - Key Event: Event ID 5141. - Log Forwarding: Use WEF to centralize logs for SIEM tools (e.g., Splunk). - Enable EDR Monitoring: - Detect processes or users that initiate unauthorized object deletions. - Monitor tools and scripts that may delete key directory objects.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2.0 | Current bundle | f632ebd7b36a… |
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 DC0068Open 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.