DET0465: Detection of Default Account Abuse Across Platforms
DET0465 is a detection strategy for abuse of default accounts, tied to ATT&CK technique T1078.001. The business issue is not just “someone used a built-in...
Analyst context for executives and security teams
DET0465 is a detection strategy for abuse of default accounts, tied to ATT&CK technique T1078.001. The business issue is not just “someone used a built-in account”; it is whether the organization can prove default, factory, provider, or root-style accounts are controlled, monitored, and investigated across critical environments. Because the related technique spans initial access, persistence, privilege escalation, and stealth, gaps here can affect incident containment, identity assurance, cloud/virtualization administration, and audit confidence.
Executive priority
Treat this as an identity and operational resilience control question: which default accounts still exist, which are enabled, where can they authenticate, and who reviews their use? Security leaders should prioritize evidence that default accounts in identity providers, IaaS, ESXi, and container-related environments are inventoried, governed, and monitored. This supports incident decision-making and compliance readiness because default-account use is often hard to attribute to an individual unless ownership, logging, and approval controls are clear.
Technical view
The ATT&CK object itself provides no official description, detection logic, platforms, or tactics, so implementation must be anchored to the related technique T1078.001: Default Accounts. SOC and detection teams should validate monitoring for successful and failed authentication, privilege use, configuration changes, and administrative actions involving known default or provider-created accounts. Because the related technique lists Containers, ESXi, IaaS, and Identity Provider platforms, coverage should be tested in those control planes where present, without assuming this detection strategy is limited to them.
Likely telemetry
- Authentication logs for default, built-in, factory, provider, root, guest, administrator, or default service accounts
- Identity provider sign-in, token, MFA, and administrative audit logs where default or break-glass-style accounts exist
- IaaS control-plane audit logs for root or provider-created account activity
- ESXi or virtualization management authentication and administrative logs
- Container platform or orchestration audit logs for default service account usage where applicable
Detection direction
- Build or validate an authoritative list of default accounts per platform before writing alerts; detections are weak if account naming and ownership are not known locally.
- Alert on interactive login, remote access, privilege escalation, administrative action, or configuration change by default accounts, especially where the account should be disabled or non-interactive.
- Tune for expected maintenance, recovery, or provider-required activity to reduce false positives, but require documented ownership and approval for exceptions.
- Correlate default-account use with source location, device, time, MFA status, and recent account or role changes to distinguish approved administration from suspicious persistence or privilege use.
- Review blind spots in identity provider, IaaS, ESXi, and container audit collection; missing control-plane logs can make default-account abuse appear as normal administration or leave no usable trail.
Mitigation priorities
- Inventory default accounts across relevant platforms and assign accountable owners.
- Disable or restrict default accounts where business and platform requirements allow.
- Where default accounts must remain, enforce strong access controls, logging, limited scope, and documented emergency-use procedures.
- Remove unnecessary privileges and validate role assignments for provider-created, root, guest, administrator, and default service accounts.
- Periodically review evidence of default-account status, use, and exceptions for audit and incident-readiness purposes.
Analyst notes and limits
This take is based on the detection strategy object DET0465 and its relationship to T1078.001 Default Accounts. The source object is sparse: it has no official ATT&CK description, detection text, tactics, or platforms of its own. Practical guidance is therefore derived from the related technique context and should be validated against the organization’s actual account inventory and logging architecture.
No active exploitation, attribution, specific detection analytics, or guaranteed platform coverage is provided in the supplied ATT&CK fields. Local environment evidence is required to determine which default accounts exist, whether their use is legitimate, and whether telemetry is sufficient for reliable detection.
Detection of Default Account Abuse Across Platforms
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1078.001 | Default Accounts Sub-technique | This object detects Default Accounts. |
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 | a1aa3bbbdf1f… |
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 DET0465Open 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.