T1078.002: Domain Accounts
Adversaries may obtain and abuse credentials of a domain account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.CitationTechNet Credential Theft Domain accounts are those managed by Active Directory Domain Services where access and permissions are configured across systems and services that are part of that domain. Domain accounts can cover users, administrators, and services.CitationMicrosoft AD Accounts
Adversaries may compromise domain accounts, some with a high level of privileges, through various means such as OS Credential Dumping or password reuse, allowing access to privileged resources of the domain.
Security context for executives and security teams
Domain Accounts matters because compromised Active Directory-managed credentials can turn normal business access into an adversary’s access path. The risk is not limited to one workstation: domain users, administrators, and service accounts can carry permissions across systems and services, making this a priority identity-control and monitoring problem rather than only an endpoint issue.
Executive priority
Treat this as a business resilience and audit-evidence issue for enterprise identity. Leaders should ask whether domain account lifecycle controls, privileged account governance, password policy, MFA, and user training are consistently enforced and evidenced. The supplied ATT&CK relationships show this behavior appearing across multiple campaigns and groups, including activity involving energy, manufacturing, government, managed service providers, and data theft contexts, so domain identity assurance should be prioritized where disruption, sensitive data access, or cyber-physical dependencies exist.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around abnormal use of legitimate domain credentials across ESXi, Linux, macOS, and Windows environments. MITRE provides no official detection text for this sub-technique, but it is related to detection strategy DET0210, Abuse of Domain Accounts. Build validation around authentication patterns, privilege changes, service account use, remote access, and post-compromise sources such as OS Credential Dumping or password reuse referenced by the technique description. IR playbooks should assume a valid login may not look like malware execution and should include rapid account scoping, privilege review, session/token review where available, and password/MFA reset decision points.
Likely telemetry
- Active Directory domain controller authentication and account management logs
- Kerberos and NTLM authentication evidence
- Successful and failed logon events from Windows, Linux, macOS, and ESXi systems joined to or dependent on the domain
- Privileged group membership and role change records
- Service account authentication and usage logs
Detection direction
- Confirm whether DET0210-style logic exists for abnormal domain account use, not just failed-login alerting.
- Baseline normal account behavior by user, administrator, and service account class; tune for unusual source host, destination host, time, frequency, privilege level, or cross-platform access.
- Correlate credential use with preceding credential theft indicators such as OS credential dumping where telemetry exists.
- Prioritize detections for high-privilege and service accounts because abuse can support persistence, privilege escalation, initial access, and stealth.
- Watch for blind spots where successful authentication is retained but not centrally collected, especially non-Windows systems or ESXi assets using domain credentials.
Mitigation priorities
- Start with User Account Management: enforce account lifecycle discipline, remove stale accounts, and apply least privilege.
- Apply Privileged Account Management for administrator and high-impact service accounts, including restricted scope, accountability, and monitoring.
- Enforce Password Policies that reduce password reuse and weak credential exposure.
- Deploy Multi-factor Authentication where domain-backed access to critical systems and services supports it.
- Use User Training to reduce human-driven credential compromise paths such as phishing and social engineering.
Additional notes and limits
This take is based on ATT&CK T1078.002 Domain Accounts, its parent Valid Accounts relationship, mitigation relationships M1017, M1018, M1026, M1027, M1032, and the DET0210 detection-strategy relationship. Campaign and group relationships indicate broad relevance, but they should be used for prioritization and threat-model context, not as proof of current exposure in a specific environment.
MITRE does not provide official detection guidance for this object in the supplied fields. Local architecture, domain design, logging configuration, identity provider integrations, and service account usage are required to determine actual detection coverage and residual risk.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Domain Accounts
Adversaries may obtain and abuse credentials of a domain account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.CitationTechNet Credential Theft Domain accounts are those managed by Active Directory Domain Services where access and permissions are configured across systems and services that are part of that domain. Domain accounts can cover users, administrators, and services.CitationMicrosoft AD Accounts
Adversaries may compromise domain accounts, some with a high level of privileges, through various means such as OS Credential Dumping or password reuse, allowing access to privileged resources of the domain.
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.
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.
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.