T1078.001: Default Accounts
Adversaries may obtain and abuse credentials of a default account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Default accounts are those that are built-into an OS, such as the Guest or Administrator accounts on Windows systems. Default accounts also include default factory/provider set accounts on other types of systems, software, or devices, including the root user account in AWS, the root user account in ESXi, and the default service account in Kubernetes.[1][2][3]
Default accounts are not limited to client machines; rather, they also include accounts that are preset for equipment such as network devices and computer applications, whether they are internal, open source, or commercial. Appliances that come preset with a username and password combination pose a serious threat to organizations that do not change it post installation, as they are easy targets for an adversary. Similarly, adversaries may also utilize publicly disclosed or stolen Private Keys or credential materials to legitimately connect to remote environments via Remote Services.[4]
Default accounts may be created on a system after initial setup by connecting or integrating it with another application. For example, when an ESXi server is connected to a vCenter server, a default privileged account called `vpxuser` is created on the ESXi server. If a threat actor is able to compromise this account’s credentials (for example, via Exploitation for Credential Access on the vCenter host), they will then have access to the ESXi server.[5][6]
Analyst context for executives and security teams
Default accounts matter because they are legitimate access paths that may be forgotten during deployment, integration, or operations. If default credentials, root accounts, built-in administrator accounts, service accounts, or provider-created accounts remain weakly controlled, an adversary can appear as a valid user across endpoints, cloud, SaaS, containers, ESXi, identity providers, and network devices.
Executive priority
Treat this as an identity and asset-governance risk, not only a password issue. Leaders should ask whether default and built-in accounts are inventoried, owned, monitored, protected by strong password policy and MFA where feasible, and included in audit evidence. The business risk is that legitimate access can support initial access, persistence, privilege escalation, and stealth, making incident scoping and recovery harder if these accounts are unmanaged.
Technical view
SOC, IR, IAM, cloud, and infrastructure teams should validate controls for default account use across the listed platforms: Containers, ESXi, IaaS, Identity Provider, Linux, macOS, Network Devices, Office Suite, SaaS, and Windows. ATT&CK provides no official detection text for this sub-technique, but the relationship to DET0465 indicates a detection strategy for default account abuse across platforms. Detection engineering should focus on account names and account types that are default, built-in, root, provider-created, or integration-created, including examples in the source object such as Windows Guest/Administrator, AWS root user, ESXi root/vpxuser, and Kubernetes default service account.
Likely telemetry
- Authentication and sign-in logs from identity providers, SaaS, Office Suite, and cloud/IaaS platforms
- Cloud IAM/root account activity logs, especially for highly privileged root or provider-created accounts
- Windows local account logon events for built-in Administrator or Guest-style accounts
- Linux and macOS local authentication and privilege-use logs for root or default local accounts
- ESXi and vCenter authentication, account creation, and privileged activity logs, including integration-created accounts such as vpxuser
Detection direction
- Build an inventory-driven watchlist of default, built-in, root, factory, provider-set, and integration-created accounts by platform; alerting without ownership context will create noise.
- Prioritize detections for first-time use, use from unusual source locations, use outside maintenance windows, failed-then-successful authentication, and access to remote services by default accounts.
- Correlate account activity with asset onboarding and integration events, especially where a default account may be created after setup, such as ESXi connected to vCenter.
- Tune for legitimate administrative workflows: some default or root accounts may be required, but they should have documented break-glass or operational justification.
- Validate blind spots in non-endpoint systems: network devices, SaaS tenants, cloud root accounts, containers, ESXi, and identity providers often sit outside traditional EDR visibility.
Mitigation priorities
- Inventory default and built-in accounts across all supported platforms and assign clear ownership, business justification, and monitoring requirements.
- Change factory/default credentials during deployment and after integration; disable or remove default accounts where the platform and business process allow.
- Apply M1027 Password Policies to reduce weak, reused, or unchanged passwords on default and built-in accounts.
- Apply M1032 Multi-factor Authentication for critical systems and services where supported, with particular attention to cloud, SaaS, identity provider, and privileged administrative accounts.
- Restrict default/root account use to documented emergency or platform-required scenarios, and require reviewable evidence for any exception.
Analyst notes and limits
The relationship context shows use by multiple ATT&CK groups, a campaign, and software, but that should be treated as historical ATT&CK context rather than proof of current exposure. The material decision point for defenders is whether default accounts are known, hardened, monitored, and auditable across both traditional IT and platforms such as cloud, containers, ESXi, SaaS, identity providers, and network devices.
The supplied ATT&CK object does not include official detection analytics. DET0465 is related as a detection strategy, but no detailed logic is provided here. Local account names, logging availability, MFA support, and acceptable administrative use vary by platform and environment, so validation requires local asset, identity, and telemetry evidence.
Default Accounts
Adversaries may obtain and abuse credentials of a default account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Default accounts are those that are built-into an OS, such as the Guest or Administrator accounts on Windows systems. Default accounts also include default factory/provider set accounts on other types of systems, software, or devices, including the root user account in AWS, the root user account in ESXi, and the default service account in Kubernetes.[1][2][3]
Default accounts are not limited to client machines; rather, they also include accounts that are preset for equipment such as network devices and computer applications, whether they are internal, open source, or commercial. Appliances that come preset with a username and password combination pose a serious threat to organizations that do not change it post installation, as they are easy targets for an adversary. Similarly, adversaries may also utilize publicly disclosed or stolen Private Keys or credential materials to legitimately connect to remote environments via Remote Services.[4]
Default accounts may be created on a system after initial setup by connecting or integrating it with another application. For example, when an ESXi server is connected to a vCenter server, a default privileged account called `vpxuser` is created on the ESXi server. If a threat actor is able to compromise this account’s credentials (for example, via Exploitation for Credential Access on the vCenter host), they will then have access to the ESXi server.[5][6]
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.
Related techniques
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1078 | Valid Accounts | This object subtechnique of Valid Accounts. |
Groups, software, and campaigns
G1016: FIN13
G1048: UNC3886
UNC3886 is a China-nexus cyberespionage group that has been active since at least 2022, targeting defense, technology, and telecommunication organizations located in the United States and the Asia-Pacific-Japan (APJ) regions. UNC3886 has displayed a deep understanding of edge devices and virtualization technologies through the exploitation of zero-day vulnerabilities and the use of novel malware families and utilities.[1][2]
G0059: Magic Hound
Magic Hound is an Iranian-sponsored threat group that conducts long term, resource-intensive cyber espionage operations, likely on behalf of the Islamic Revolutionary Guard Corps. They have targeted European, U.S., and Middle Eastern government and military personnel, academics, journalists, and organizations such as the World Health Organization (WHO), via complex social engineering campaigns since at least 2014.[1][2][3][4][5]
G1003: Ember Bear
Ember Bear is a Russian state-sponsored cyber espionage group that has been active since at least 2020, linked to Russia's General Staff Main Intelligence Directorate (GRU) 161st Specialist Training Center (Unit 29155).[1] Ember Bear has primarily focused operations against Ukrainian government and telecommunication entities, but has also operated against critical infrastructure entities in Europe and the Americas.[2] Ember Bear conducted the WhisperGate destructive wiper attacks against Ukraine in early 2022.[3][4][1] There is some confusion as to whether Ember Bear overlaps with another Russian-linked entity referred to as Saint Bear. At present available evidence strongly suggests these are distinct activities with different behavioral profiles.[2][5]
S0537: HyperStack
HyperStack is a RPC-based backdoor used by Turla since at least 2018. HyperStack has similarities to other backdoors used by Turla including Carbon.[1]
S0603: Stuxnet
Stuxnet was the first publicly reported malware to specifically target industrial control systems devices. Stuxnet is a large and complex malware that utilized multiple behaviors, including numerous zero-day vulnerabilities, a sophisticated Windows rootkit, and network infection routines.[1][2][3][4] Stuxnet was discovered in 2010, with some components being used as early as November 2008.[1]
C0038: HomeLand Justice
HomeLand Justice was a disruptive cyber campaign conducted by Iranian state-affiliated actors against Albanian government networks in July and September 2022. The activity combined ransomware, wiper malware, and data leak operations. Initial access for HomeLand Justice was established as early as May 2021, and threat actors moved laterally, exfiltrated sensitive information, and maintained persistence for approximately 14 months prior to the destructive phase of the operation. Responsibility was claimed by the "HomeLand Justice" front, which framed the campaign as retaliation against the Mujahedeen-e Khalq (MEK), an Iranian opposition group with a presence in Albania. Multiple Iran-nexus groups are assessed to have participated in the campaign, including HEXANE who probed victim infrastructure.[1][2][3] A second wave of attacks was launched in September 2022 using similar tactics following public attribution of the previous activity to Iran and the severing of diplomatic ties between Iran and Albania.[3]
All related ATT&CK context
Mitigation direction
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 | 8a596113843d… |
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]
Microsoft Local Accounts Feb 2019
Microsoft. (2018, December 9). Local Accounts. Retrieved February 11, 2019.
Open source URL -
[2]
AWS Root User
Amazon. (n.d.). AWS Account Root User. Retrieved April 5, 2021.
Open source URL -
[3]
Threat Matrix for Kubernetes
Weizman, Y. (2020, April 2). Threat Matrix for Kubernetes. Retrieved March 30, 2021.
Open source URL -
[4]
Metasploit SSH Module
undefined. (n.d.). Retrieved April 12, 2019.
Open source URL -
[5]
Google Cloud Threat Intelligence VMWare ESXi Zero-Day 2023
Alexander Marvi, Brad Slaybaugh, Ron Craft, and Rufus Brown. (2023, June 13). VMware ESXi Zero-Day Used by Chinese Espionage Actor to Perform Privileged Guest Operations on Compromised Hypervisors. Retrieved March 26, 2025.
Open source URL -
[6]
Pentera vCenter Information Disclosure
Yuval Lazar. (2022, March 29). Mitigating VMware vCenter Information Disclosure. Retrieved March 26, 2025.
Open source URL -
[7]
mitre-attack T1078.001Open 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.