Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1080: Analytic 1080

Monitors for the creation of accounts inside containers using names that resemble legitimate orchestrator or backup identities to mask adversary persistence.

EnterpriseAN1080AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic is about spotting new accounts created inside container environments with names that look like legitimate orchestrator or backup identities. For leaders, the practical issue is trust: if container account creation is not visible and governed, an attacker may blend persistence into names that operations teams expect to see. This matters for container security, SOC readiness, incident response scoping, and audit evidence around privileged or service-like identities.

Executive priority

Prioritize validation of container identity governance and logging. Security leaders should ask whether the organization can prove when accounts are created inside containers, who or what created them, whether the names align with approved operational patterns, and how suspicious service-like or backup-like accounts are reviewed. This is especially relevant where containers support critical business services and where compliance or resilience programs depend on evidence of controlled identity lifecycle management.

Technical view

The supplied ATT&CK object is a detection analytic for Containers. It monitors account creation inside containers where account names resemble legitimate orchestrator or backup identities. SOC and detection teams should validate whether container runtime, host, image, and orchestration telemetry can expose account creation events and whether detections compare new account names against approved service, orchestrator, and backup identity naming conventions. Because no official detection logic or tactic mapping is provided, teams should treat this as a coverage-validation analytic rather than a complete rule.

Likely telemetry

  • Container runtime events related to account or user creation
  • Container host process execution and command/audit logs showing account-management activity
  • Orchestrator audit logs, where available, that show workload changes or administrative actions
  • Container image build logs or CI/CD records that may explain expected account creation
  • Identity or configuration inventory for approved service, orchestrator, and backup account naming patterns

Detection direction

  • Confirm that account creation inside running containers is logged, retained, and searchable; many environments collect orchestration events but not in-container identity changes.
  • Build allowlists or baselines for approved orchestrator, backup, and service account names, then alert on newly created accounts that imitate those patterns but are not authorized.
  • Correlate suspicious account creation with workload deployment time, image provenance, container host activity, and administrative change records to reduce false positives.
  • Tune for legitimate image builds, maintenance scripts, backup agents, and platform automation that may create expected accounts.
  • Because no ATT&CK detection logic is supplied, require local testing against container platforms and logging architecture before treating coverage as reliable.

Mitigation priorities

  • Establish approved naming standards and ownership records for container-related service, orchestrator, and backup identities.
  • Restrict the ability to create accounts inside containers to approved build-time or administrative workflows.
  • Prefer immutable container practices where practical, so unexpected account creation at runtime becomes easier to identify and investigate.
  • Ensure container host, runtime, and orchestration audit logs are retained for SOC and incident response use.
  • Include suspicious in-container account creation in incident response playbooks for containerized services.
Analyst notes and limits

This object is an ATT&CK detection analytic, not a technique. It provides a clear monitoring intent but no official detection implementation, tactic mapping, or relationship context. The strongest use is as a prompt to validate whether container identity changes are visible and governed, particularly when account names are chosen to appear operationally legitimate.

The supplied data includes only the analytic description, platform scope of Containers, and a MITRE external reference. There are no relationships, no official detection text, no tactic assignment, and no evidence of active exploitation or attribution. Local architecture, logging coverage, and approved account naming conventions are required to operationalize this analytic.

Official MITRE ATT&CK definition

Analytic 1080

Monitors for the creation of accounts inside containers using names that resemble legitimate orchestrator or backup identities to mask adversary persistence.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
6b2bfabac9a7e653...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 6b2bfabac9a7…
Raw source

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 references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1080
    Open source URL
Source and licensing

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.