DC0071: Active Directory Object Access
Object access refers to activities where AD objects (e.g., user accounts, groups, policies) are accessed or queried. Example: Windows Event ID 4661 logs object access attempts. Examples:
- Attribute Access: e.g., `userPassword`, `memberOf`, `securityDescriptor`. - Group Enumeration: Enumerating critical group members (e.g., Domain Admins). - User Attributes: Commonly accessed attributes like `samAccountName`, `lastLogonTimestamp`. - Policy Access: Accessing GPOs to understand security settings.
*Data Collection Measures:*
- Audit Policies: - Enable "Audit Directory Service Access" under Advanced Audit Policies (Success and Failure). - Path: `Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object AccessEnable: Audit Directory Service Access` (Success and Failure). - Captured Events: IDs 4661, 4662. - Event Forwarding: Use WEF to centralize logs for SIEM analysis. - SIEM Integration: Collect and parse logs (e.g., 4661, 4662) using tools like Splunk or Azure Sentinel. - Log Filtering: - Focus on sensitive objects/attributes like: - `Domain Admins` group. - `userPassword`, `ntSecurityDescriptor`. - Enable EDR Monitoring: - Detect processes accessing sensitive AD objects (e.g., samAccountName, securityDescriptor). - Log all attempts to enumerate critical groups (e.g., "Domain Admins").
Analyst context for executives and security teams
Active Directory Object Access is the evidence trail for who or what queried or accessed important AD objects such as users, groups, policies, and sensitive attributes. For leaders, this matters because AD often represents the control plane for enterprise identity; weak visibility into object access can leave teams unable to explain suspicious group enumeration, policy discovery, or access to high-value attributes during an investigation.
Executive priority
Prioritize this data component where Active Directory is material to authentication, privileged access, compliance evidence, or incident response readiness. The key business question is not simply whether AD exists, but whether the organization can prove when sensitive objects such as Domain Admins, GPOs, user attributes, or security descriptors were accessed, and whether those events are centralized and searchable for SOC and IR use.
Technical view
ATT&CK describes this component as object access or query activity against AD objects, with Windows Event IDs 4661 and 4662 as example captured events when Audit Directory Service Access is enabled for success and failure. SOC and detection teams should validate that audit policy is configured, logs are forwarded centrally, and parsing preserves object names, attributes, access attempts, account context, and process context where available. Because no ATT&CK detection logic or tactic mapping is supplied for this object, local detection engineering should focus on coverage validation and high-value object monitoring rather than assuming a complete analytic exists.
Likely telemetry
- Windows Security events for Directory Service Access, including Event IDs 4661 and 4662 where configured
- Audit policy configuration evidence for Advanced Audit Policy: Audit Directory Service Access success and failure
- Centralized Windows Event Forwarding or equivalent log forwarding records
- SIEM-parsed fields for accessed AD object, attribute, account, and access result
- Events involving sensitive groups such as Domain Admins
Detection direction
- Confirm that Directory Service Access auditing is enabled and producing usable 4661 and 4662 events before writing higher-level detections.
- Prioritize monitoring for access to sensitive objects and attributes named in the ATT&CK description, especially critical groups, GPOs, user account attributes, and security descriptors.
- Validate that event forwarding and SIEM parsing retain enough context to distinguish routine administrative activity from unusual enumeration or access patterns.
- Tune for expected administrative tools and service activity to reduce false positives, but require documented baselines for privileged group enumeration and GPO access.
- Check for blind spots created by missing success or failure auditing, incomplete Windows Event Forwarding, unparsed object attributes, or lack of endpoint process context.
Mitigation priorities
- Enable Advanced Audit Policy for Audit Directory Service Access with success and failure auditing where appropriate for the environment.
- Centralize AD object access logs through Windows Event Forwarding or equivalent collection into the SIEM.
- Define and maintain a list of sensitive AD objects and attributes, including privileged groups, GPOs, and security descriptor-related attributes, for focused monitoring.
- Validate SIEM parsing and retention so object access evidence is available during incident response and audit review.
- Use EDR monitoring where available to add process context for sensitive AD object access and group enumeration.
Analyst notes and limits
This object is a data component, not an attack technique. Its value is coverage-oriented: it helps teams determine whether they have evidence for AD object access and enumeration activity. The supplied ATT&CK content provides collection measures and examples, but not a specific detection analytic, tactic mapping, platform field, or relationships to techniques.
Platforms and tactics are not specified in the supplied STIX fields, and no official detection or relationship context is provided. Any assessment of malicious behavior, impact, or coverage must be based on local AD configuration, audit policy, log collection, SIEM parsing, and environment-specific baselines.
Active Directory Object Access
Object access refers to activities where AD objects (e.g., user accounts, groups, policies) are accessed or queried. Example: Windows Event ID 4661 logs object access attempts. Examples:
- Attribute Access: e.g., `userPassword`, `memberOf`, `securityDescriptor`. - Group Enumeration: Enumerating critical group members (e.g., Domain Admins). - User Attributes: Commonly accessed attributes like `samAccountName`, `lastLogonTimestamp`. - Policy Access: Accessing GPOs to understand security settings.
*Data Collection Measures:*
- Audit Policies: - Enable "Audit Directory Service Access" under Advanced Audit Policies (Success and Failure). - Path: `Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object AccessEnable: Audit Directory Service Access` (Success and Failure). - Captured Events: IDs 4661, 4662. - Event Forwarding: Use WEF to centralize logs for SIEM analysis. - SIEM Integration: Collect and parse logs (e.g., 4661, 4662) using tools like Splunk or Azure Sentinel. - Log Filtering: - Focus on sensitive objects/attributes like: - `Domain Admins` group. - `userPassword`, `ntSecurityDescriptor`. - Enable EDR Monitoring: - Detect processes accessing sensitive AD objects (e.g., samAccountName, securityDescriptor). - Log all attempts to enumerate critical groups (e.g., "Domain Admins").
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 | de5afd166af6… |
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 DC0071Open 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.