T1078: Valid Accounts
Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Compromised credentials may be used to bypass access controls placed on various resources on systems within the network and may even be used for persistent access to remote systems and externally available services, such as VPNs, Outlook Web Access, network devices, and remote desktop.Citationvolexity_0day_sophos_FW Compromised credentials may also grant an adversary increased privilege to specific systems or access to restricted areas of the network. Adversaries may choose not to use malware or tools in conjunction with the legitimate access those credentials provide to make it harder to detect their presence.
In some cases, adversaries may abuse inactive accounts: for example, those belonging to individuals who are no longer part of an organization. Using these accounts may allow the adversary to evade detection, as the original account user will not be present to identify any anomalous activity taking place on their account.CitationCISA MFA PrintNightmare
The overlap of permissions for local, domain, and cloud accounts across a network of systems is of concern because the adversary may be able to pivot across accounts and systems to reach a high level of access (i.e., domain or enterprise administrator) to bypass access controls set within the enterprise.CitationTechNet Credential Theft
Security context for executives and security teams
Valid Accounts matters because an attacker using a real username, password, token, or account path can look like normal business activity while gaining initial access, maintaining persistence, escalating privileges, or evading defenses. This technique is especially material across hybrid environments because ATT&CK lists coverage across Windows, Linux, macOS, ESXi, containers, identity providers, IaaS, SaaS, office suites, and network devices. The business question is not only “do we have MFA?” but “can we prove account use is governed, logged, reviewed, and investigated across every place a valid account can open a door?”
Executive priority
Treat this as an identity and access governance risk, not just a SOC alerting problem. Valid account abuse can undermine access controls, remote access, cloud administration, privileged operations, and incident containment because the activity may not require malware. Leaders should prioritize evidence that inactive accounts are removed, privileged and default accounts are controlled, MFA is enforced on critical access paths, account use policies are in place, and authentication logs from identity, cloud, SaaS, endpoint, and network-device environments are available for investigation and audit.
Technical view
For SOC, detection engineering, and IR teams, validate coverage around the full account lifecycle and authentication surface: local, domain, cloud, and default accounts, including remote access services such as VPN, Outlook Web Access, remote desktop, and network-device administration where present. ATT&CK does not provide native detection text for T1078, but the relationship to DET0560 indicates a detection strategy focused on valid account abuse across platforms. Practical validation should correlate successful logons, privilege changes, account status, source locations, device context, service usage, and cloud/SaaS audit events rather than relying only on failed-login or malware detections.
Likely telemetry
- Identity provider authentication and MFA events
- Active Directory/domain logon, group membership, and account-management logs
- Local system logon and privilege-use events for Windows, Linux, macOS, ESXi, and containers where applicable
- Cloud, IaaS, SaaS, and office-suite audit logs for sign-ins, administrative actions, and token/session activity
- VPN, Outlook Web Access, remote desktop, and other externally available service access logs where deployed
Detection direction
- Inventory where valid accounts can authenticate across on-premises, cloud, SaaS, identity provider, ESXi, container, and network-device platforms before tuning analytics.
- Prioritize correlation of successful access with context: unusual source, new device, abnormal service, privilege level, impossible or unexpected account use, and access by inactive or rarely used accounts.
- Tune for account categories reflected in the sub-techniques: default accounts, domain accounts, local accounts, and cloud accounts.
- Avoid assuming malware telemetry will identify this behavior; ATT&CK explicitly notes adversaries may use legitimate access without malware or tools.
- Separate high-risk false positives such as administrators, service accounts, remote support, and automation by baselining expected use and requiring stronger change-control and logging evidence.
Mitigation priorities
- Start with User Account Management: remove or disable inactive accounts, define ownership, review access, and enforce least privilege.
- Harden privileged access through Privileged Account Management, role-based access, monitoring, and accountability for administrative accounts.
- Enforce Multi-factor Authentication on critical remote, cloud, identity provider, and administrative access paths, with attention to configuration gaps.
- Apply Account Use Policies such as lockout, login restrictions, inactivity timeouts, and controls around where and when accounts may be used.
- Strengthen Password Policies to reduce credential reuse and weak credential risk.
Additional notes and limits
The most decision-relevant point is that this technique spans identity, endpoint, cloud, SaaS, remote access, network infrastructure, and operationally sensitive environments. ATT&CK relationships include multiple campaigns and sub-techniques, showing that valid account abuse is a common enabling behavior rather than a narrow platform issue. For regulated or resilience-focused organizations, the audit evidence should include account lifecycle records, MFA enforcement, privileged access reviews, authentication logging, and incident-response procedures for suspected credential misuse.
The supplied ATT&CK object does not include official detection text, and the relationship to DET0560 is named but not detailed here. This take therefore provides validation direction rather than guaranteed analytics. Local architecture, enabled platforms, identity design, logging retention, MFA configuration, and account ownership data are required to determine actual exposure and detection maturity.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Valid Accounts
Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Compromised credentials may be used to bypass access controls placed on various resources on systems within the network and may even be used for persistent access to remote systems and externally available services, such as VPNs, Outlook Web Access, network devices, and remote desktop.Citationvolexity_0day_sophos_FW Compromised credentials may also grant an adversary increased privilege to specific systems or access to restricted areas of the network. Adversaries may choose not to use malware or tools in conjunction with the legitimate access those credentials provide to make it harder to detect their presence.
In some cases, adversaries may abuse inactive accounts: for example, those belonging to individuals who are no longer part of an organization. Using these accounts may allow the adversary to evade detection, as the original account user will not be present to identify any anomalous activity taking place on their account.CitationCISA MFA PrintNightmare
The overlap of permissions for local, domain, and cloud accounts across a network of systems is of concern because the adversary may be able to pivot across accounts and systems to reach a high level of access (i.e., domain or enterprise administrator) to bypass access controls set within the enterprise.CitationTechNet Credential Theft
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.