DET0586: Detection of NTDS.dit Credential Dumping from Domain Controllers
This detection strategy matters because NTDS.dit is the Active Directory domain database on domain controllers. If an adversary can access or copy it, they...
Analyst context for executives and security teams
This detection strategy matters because NTDS.dit is the Active Directory domain database on domain controllers. If an adversary can access or copy it, they may obtain credential material and information about users, devices, and access rights. For leaders, the key decision is whether domain controllers and AD backup locations are monitored closely enough to produce usable evidence during a credential-access incident.
Executive priority
Prioritize this as an identity and business-continuity control question: can the organization prove who accessed sensitive domain-controller database files or backups, when, from where, and by what process or account? Coverage gaps here can weaken incident response, privileged-access assurance, audit evidence, and recovery decisions after suspected domain compromise.
Technical view
The ATT&CK relationship maps this detection strategy to T1003.003, NTDS, under credential access for Windows. SOC and IR teams should validate monitoring around domain controllers and any backup locations that may contain NTDS.dit. Because the supplied object has no official detection text or platform field, detection engineering should be grounded in local Windows/Active Directory architecture, focusing on unusual access, copying, or staging of the AD database and related sensitive files by accounts, processes, or hosts that do not normally perform domain-controller maintenance or backup operations.
Likely telemetry
- Domain controller file access auditing for NTDS.dit and related Active Directory database paths
- Process creation and command-line telemetry on domain controllers
- Endpoint detection and response telemetry from domain controllers
- Windows security and system event logs from domain controllers
- Backup platform logs for jobs, restores, exports, or access to domain-controller backups
Detection direction
- Baseline legitimate domain-controller maintenance, backup, restore, and security tooling activity before alerting on NTDS.dit access.
- Tune for unusual users, service accounts, processes, source hosts, or time windows interacting with the AD database or backups containing it.
- Correlate file access with process execution, privileged logons, and backup activity to reduce false positives from authorized backup and recovery operations.
- Confirm whether domain controllers have sufficient auditing enabled; absence of file access telemetry is a material blind spot.
- Review backup repositories as part of detection scope, since the related technique notes adversaries may look for backups containing NTDS data.
Mitigation priorities
- Restrict and review administrative access to domain controllers and AD backup repositories.
- Ensure domain-controller and backup access is logged, retained, and available to the SOC and incident responders.
- Harden privileged account use around domain-controller administration and backup operations.
- Protect backups containing Active Directory data with strong access controls and monitoring.
- Periodically test whether security teams can reconstruct NTDS.dit access or copy attempts from available logs.
Analyst notes and limits
The ATT&CK object is a detection strategy named DET0586, Detection of NTDS.dit Credential Dumping from Domain Controllers. It detects T1003.003, NTDS, a credential-access technique associated with Windows and Active Directory domain controllers. The supplied strategy object does not include official description, detection logic, tactics, or platforms, so this take emphasizes validation questions and telemetry classes rather than specific analytics.
This assessment is limited to the supplied STIX fields, the MITRE external reference, and the relationship to T1003.003. It does not assert active exploitation, attacker attribution, guaranteed detection, or complete platform coverage. Local architecture, audit policy, EDR configuration, backup design, and retention determine whether the recommended evidence is actually available.
Detection of NTDS.dit Credential Dumping from Domain Controllers
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.
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 | 0299fde842eb… |
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 DET0586Open 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.