When an attacker signs in with a real username and a working credential, most preventive controls see a legitimate user and let them through. MITRE ATT&CK tracks this as T1078 Valid Accounts, and in ATT&CK v20 it sits under four tactics at once: Initial Access, Persistence, Privilege Escalation and Stealth. This guide covers the technique and all four current sub-techniques (Default, Domain, Local and Cloud Accounts), the v20 detection strategies and analytics, the eight mitigations MITRE maps to it, and how to turn them into working detections and hardening. It is written for detection engineers, identity teams and SOC leads.
Key takeaways
- Valid Accounts is a logon problem, not a malware problem. MITRE notes that adversaries may avoid malware entirely because legitimate access is harder to spot, so detection has to come from authentication and session telemetry.
- Four sub-techniques, four different control owners. Default accounts sit with platform and appliance teams, domain accounts with the Active Directory team, local accounts with endpoint teams, and cloud accounts with the IdP and cloud platform teams.
- Dormant and orphaned accounts are the highest-value targets. ATT&CK calls out inactive accounts of former staff because nobody is there to notice misuse, which is exactly how the Colonial Pipeline attackers got in.
- Phishing-resistant MFA plus blocked legacy authentication removes most of the risk. M1032 Multi-factor Authentication and M1015 Active Directory Configuration (disable legacy authentication) are the two mitigations with the biggest effect on credential replay.
- Detection is behavioural baselining. The v20 analytics key on unusual logon types, impossible travel, rare access methods and first-time access, so the quality of your identity baseline decides the quality of your T1078 coverage. See the ITDR Guide.
How the attack works
T1078 describes obtaining and abusing the credentials of an existing account. ATT&CK does not care how the credential was obtained: that is covered by other techniques such as T1110 Brute Force, T1566 Phishing, T1003 OS Credential Dumping and the unsecured credentials covered in the MITRE ATT&CK T1552 Unsecured Credentials Guide. T1078 is the moment the credential is used; taking over accounts to build attack infrastructure is covered in the MITRE ATT&CK T1586 Compromise Accounts Guide. From the defender's point of view, the lifecycle has four observable stages:
- Credential exposure: a password, key or token leaks through infostealer malware, reuse, a public repository, a default that was never changed, or a dump from a compromised host.
- Authentication: the credential is presented to an externally reachable service (VPN, Outlook Web Access, remote desktop, an IdP, a cloud console or API) or used internally after a foothold.
- Use within normal permissions: the account's own rights are used for discovery, data access or lateral movement. ATT&CK highlights the overlap of permissions across local, domain and cloud accounts as the route to domain or enterprise administrator level.
- Persistence: the account is kept as a quiet way back in, often reinforced with T1098.001 Additional Cloud Credentials or T1098.003 Additional Cloud Roles. See the MITRE ATT&CK T1098 Account Manipulation Guide.
The four sub-techniques in ATT&CK v20
| ID | Name | Platforms (v20) | What ATT&CK highlights |
|---|---|---|---|
| T1078.001 | Default Accounts | Containers, ESXi, IaaS, Identity Provider, Linux, macOS, Network Devices, Office Suite, SaaS, Windows | Built-in OS accounts (Guest, Administrator), AWS root user, ESXi root, the Kubernetes default service account, appliance factory credentials, and accounts created by integration such as vpxuser on ESXi hosts joined to vCenter |
| T1078.002 | Domain Accounts | ESXi, Linux, macOS, Windows | Active Directory user, administrator and service accounts, often obtained through credential dumping or password reuse |
| T1078.003 | Local Accounts | Containers, ESXi, Linux, macOS, Network Devices, Windows | Accounts on a single system or service; shared local administrator passwords allow reuse across many machines |
| T1078.004 | Cloud Accounts | IaaS, Identity Provider, Office Suite, SaaS | Cloud-only, synced or federated accounts, service principals and managed identities; synced accounts can bridge on-premises and cloud in both directions |
Where it shows up
- Remote access without MFA: VPN, Citrix and remote desktop gateways that accept a password alone. The Change Healthcare breach began with one such Citrix login.
- SaaS and data platforms with local passwords: accounts that sit outside SSO and conditional access, as in the Snowflake breach, where infostealer credentials worked against customer accounts with single-factor authentication. See the Snowflake Security Guide.
- Hybrid identity plumbing: directory synchronisation accounts and on-premises admins that also hold cloud roles. See the Active Directory and Entra ID Hardening Guide.
- Non-human identities: service accounts, IAM access keys, Kubernetes service accounts and managed identities. They do not answer MFA prompts, rarely have an owner watching them, and often hold broad rights. See the Service Account Security Guide and the Kubernetes Service Account Token Guide.
- Appliances and hypervisors: network devices, firewalls and ESXi hosts with default or shared root credentials, usually outside central identity entirely.
Impact
Because T1078 spans four tactics, the impact depends on which account is abused and when:
| Tactic (v20) | What valid account abuse gives the attacker | Typical consequence |
|---|---|---|
| Initial Access | Entry through VPN, webmail, IdP or cloud console without an exploit | Intrusion that looks like a normal sign-in |
| Persistence | A way back in that survives malware clean-up and reimaging | Repeat compromise after an incident is "closed" |
| Privilege Escalation | Rights of a more privileged local, domain or cloud account | Domain Admin or Global Administrator control, tenant-wide changes |
| Stealth | Activity attributed to a legitimate user, often with no tooling dropped | Long dwell time, hard attribution, weak forensic trail |
Detection
ATT&CK v20 replaced the old data-source lists with detection strategies made of platform analytics. T1078 has one parent strategy and one per sub-technique. The table summarises the log sources each analytic names and the tunable elements MITRE says to adjust.
| Strategy | Analytics and platforms | Log sources named in v20 | Tune on |
|---|---|---|---|
| DET0560 Detection of Valid Account Abuse Across Platforms (T1078) | AN1543 Windows, AN1544 Linux, AN1545 macOS, AN1546 Identity Provider, AN1547 Containers | Windows Security 4624, 4625, 4776; Sysmon 1; auditd execve; sshd/PAM; IdP sign-in logs; Kubernetes audit (authentication.k8s.io) | Logon type, time window, geo-IP mismatch, hosts per user, password instead of key, MFA failure count, kubeconfig source IPs |
| DET0465 Default Account Abuse (T1078.001) | AN1283 Windows, AN1284 Linux, AN1285 Identity Provider, AN1286 ESXi, AN1287 Network Devices | 4624, 4648; auditd USER_LOGIN; CloudTrail ConsoleLogin and AssumeRole; ESXi /var/log/auth.log; device syslog | Renamed default accounts, maintenance windows, root by password, jump host allow lists, vCenter IP ranges |
| DET0210 Abuse of Domain Accounts (T1078.002) | AN0590 Windows, AN0591 Linux, AN0592 macOS, AN0593 ESXi | 4624, 4625, 4768, 4769; Sysmon 1, 3, 22; sssd and sudo logs; vpxd.log and hostd.log | Sensitive groups (Domain Admins), logon type, off-hours spikes, high-value hosts |
| DET0407 Local Account Abuse (T1078.003) | AN1137 Windows, AN1138 Linux, AN1139 macOS | 4624, 4648, 4672; auditd USER_LOGIN; sshd | List of legitimate interactive local users, server versus workstation role |
| DET0546 Abused or Compromised Cloud Accounts (T1078.004) | AN1503 Identity Provider, AN1504 IaaS, AN1505 SaaS, AN1506 Office Suite | Entra sign-in logs; Okta SSO events; CloudTrail ConsoleLogin, AssumeRole, ListAccessKeys, CreateUser; GCP admin audit; M365 FileAccessed and SharingSet | Impossible travel distance, legacy protocols, per-role service baseline, assume-role rate, download and sharing thresholds |
High-signal detections to build first
- Dormant account wakes up: any successful logon (4624, IdP sign-in, ConsoleLogin) by an account with no activity for 45 days or more. Few false positives.
- Wrong logon type for the account class: Microsoft's 4624 guidance suggests flagging mismatches such as a domain admin using Batch (4) or Service (5) logons, and service accounts using Interactive (2) or RemoteInteractive (10). Correlate the Logon ID with 4672 to see special privileges.
- Default and root account use: Windows Administrator or Guest logons outside maintenance windows, Linux root over SSH with a password, AWS root sign-in (GuardDuty reports
Policy:IAMUser/RootCredentialUsage), ESXi root orvpxuserfrom outside vCenter address ranges. - Cloud credential used from the wrong place: GuardDuty
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS,CredentialAccess:IAMUser/CompromisedCredentialsandUnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B; Entra ID Protection detections such as Leaked credentials, Password spray, Atypical travel, Unfamiliar sign-in properties and Anomalous token (most need Entra ID P2). - Legacy or downgraded authentication: NTLM where Kerberos is expected (the 4624 Authentication Package and Package Name fields), NTLM V1 or LM anywhere, and legacy protocol sign-ins in Entra sign-in logs.
Metrics that show coverage is working
- Percentage of interactive and remote access paths enforcing phishing-resistant MFA (target 100 percent for privileged and external access).
- Number of enabled accounts with no sign-in for 45 or more days, split by human and non-human.
- Median time from a leaked-credential or risky sign-in alert to forced reset and session revocation.
- Percentage of DET0560 to DET0546 analytics implemented per platform, tracked in your ATT&CK coverage map. See the MITRE ATT&CK Coverage Mapping Guide.
- Count of devices still using a shared local administrator password (target zero once LAPS is deployed).
Prevention and hardening
ATT&CK v20 maps eight mitigations to T1078. The table shows what each one means in practice and where the sub-technique guidance differs.
| Mitigation | Applies to (v20) | What to implement |
|---|---|---|
| M1032 Multi-factor Authentication | T1078 and all four sub-techniques | MFA on every account type, phishing-resistant (FIDO2, certificate-based) for admins and remote access. See the Phishing-Resistant MFA Guide. |
| M1015 Active Directory Configuration | T1078, T1078.004 | Disable legacy authentication that cannot do MFA; require modern authentication protocols. |
| M1036 Account Use Policies | T1078, T1078.004 | Conditional access that blocks non-compliant devices and logins from outside defined IP ranges. See the Conditional Access Guide. |
| M1027 Password Policies | T1078, .001, .002, .003, .004 | Change appliance and application defaults before production; no password reuse; unique local admin passwords; rotate cloud access keys and track key age. |
| M1026 Privileged Account Management | T1078, .002, .003, .004 | Audit permission levels; keep domain accounts out of local Administrators; tier administration; use just-in-time roles instead of standing Global Administrator; LAPS for local admin. |
| M1018 User Account Management | T1078, .002, .003, .004 | Regularly remove or disable inactive and unnecessary accounts; limit who can create accounts. |
| M1017 User Training | T1078, .002, .004 | Teach users to accept only push prompts they started and to report the rest. See the MFA Fatigue and Bypass Guide. |
| M1013 Application Developer Guidance | T1078 | No plaintext credentials in code, repositories or public storage; use a secrets manager or workload identity. |
Sub-technique specifics
- Default Accounts (T1078.001): rename or disable the built-in Windows Administrator and Guest; change every appliance default at installation; for AWS, follow the root user practices: no root access keys, MFA on root, and in AWS Organizations use "Centrally manage root access for member accounts" to remove root credentials from member accounts, with an SCP as fallback. Disable automounting of the Kubernetes default service account token where pods do not need the API.
- Domain Accounts (T1078.002): separate admin accounts per tier, Protected Users for privileged accounts, gMSA instead of password-based service accounts. See the Group Managed Service Accounts (gMSA) Guide.
- Local Accounts (T1078.003): Windows LAPS rotates and backs up each device's local administrator password to Entra ID or Active Directory, removing the shared password that enables reuse across machines. See the Local Administrator Password Solution (LAPS) Guide.
- Cloud Accounts (T1078.004): just-in-time role activation, alerts on unused privileged roles, short-lived credentials for workloads instead of long-lived keys, and network allow lists for data platforms. See the Privileged Identity Management (PIM) Guide.
Implementation order
- Inventory: enumerate accounts across AD, local systems, IdP, cloud and appliances, with owner, last sign-in and privilege. Include non-human identities.
- Remove the easy wins: disable dormant accounts (start with a disable-then-delete period of 30 days so a wrongly disabled account can be re-enabled), change defaults, remove root access keys.
- Enforce MFA and block legacy authentication: run conditional access in report-only mode for two weeks, review what would break, pilot on IT staff, then widen by ring. Keep a documented exclusion for break-glass accounts. See the Break-Glass Account Guide.
- Deploy detections: start with dormant-account, root/default and leaked-credential alerts, then add logon-type and geo baselines once you have 30 days of history.
- Automate response: on high-confidence alerts, revoke sessions and refresh tokens, force reset or rotate keys, and open an incident. See the Account Takeover Response Playbook.
Decision guidance
- Smaller organisations: rely on built-in IdP risk detections, cloud provider findings (GuardDuty, Defender) and conditional access before buying anything; the dormant-account and root-use alerts can be built in any SIEM.
- Larger or hybrid estates: on-premises AD plus several clouds produce identity signals in many silos, and correlating them across the account lifecycle is what ITDR tooling is for. See the ITDR Buyer's Guide.
- Human versus non-human: MFA protects humans; for service accounts, remove the static secret and restrict source networks.
Framework mapping
| Framework | Relevant items |
|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, AC-2(3) Disable Accounts, AC-2(12) Account Monitoring for Atypical Usage, AC-6(5) Privileged Accounts, IA-2(1) Multi-factor Authentication to Privileged Accounts, IA-5 Authenticator Management, SI-4 System Monitoring |
| NIST CSF 2.0 | PR.AA-01 identities and credentials managed, PR.AA-05 least privilege, DE.CM-03 personnel activity monitored |
| CIS Controls v8.1 | 5.1 account inventory, 5.3 disable dormant accounts, 5.4 dedicated admin accounts, 6.3 and 6.5 MFA for external applications and administrative access |
| MITRE D3FEND | D3-MFA Multi-factor Authentication, D3-UBA User Behavior Analysis, D3-DAM Domain Account Monitoring, D3-LAM Local Account Monitoring, D3-CRO Credential Rotation |
Lessons from incidents
- An unused account is still an entry point: in the Colonial Pipeline attack a legacy VPN profile that was no longer used, never disabled and protected only by a password found in a leak let attackers in.
- Test accounts with defaults are default accounts: the McHire default password flaw involved a test administrator account with the password 123456, no MFA and no sign-in since 2019, found by researchers.
- Single-factor accounts on data platforms scale badly: the Snowflake breach reached around 165 organisations through credentials stolen years earlier, never rotated, and accepted from any network.
- Hybrid sync accounts are domain and cloud accounts at once: in the Storm-0501 hybrid cloud attacks, Entra Connect Sync credentials and a Global Administrator without MFA carried an on-premises intrusion into the cloud.
Practitioner checklist
- Inventory every human and non-human account with owner, privilege and last sign-in; review quarterly.
- Disable accounts with no activity for 45 days and alert on any sign-in by a previously dormant account.
- Enforce phishing-resistant MFA on all remote access, admin and cloud console paths; block legacy authentication.
- Change all default credentials at installation; remove AWS root access keys and centralise root access.
- Deploy Windows LAPS and keep domain accounts out of local Administrators groups.
- Move privileged cloud roles to just-in-time activation and alert on standing assignments.
- Implement the v20 analytics for your platforms (DET0560, DET0465, DET0210, DET0407, DET0546) and record coverage.
- Subscribe to leaked-credential signals and automate reset plus session revocation.
- Replace static service account passwords and keys with workload identity where the platform supports it.
Standards and references
- MITRE ATT&CK: Valid Accounts (T1078)
- MITRE ATT&CK: Valid Accounts: Cloud Accounts (T1078.004)
- Microsoft Learn: 4624(S) An account was successfully logged on
- Microsoft Learn: What are risk detections? (Microsoft Entra ID Protection)
- AWS: Root user best practices for your AWS account
- AWS: GuardDuty IAM finding types
- Microsoft Learn: Windows LAPS overview
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: ITDR Guide · Identity Visibility, Posture and Threat Detection Guide · MITRE ATT&CK T1136 Create Account Guide · Account Takeover Prevention Guide · MITRE ATT&CK Guide for Defenders