AN1492: Analytic 1492
Ephemeral or unauthorized container instantiation using public images (e.g., from DockerHub) that initiate high CPU usage shortly after startup. Often scheduled via Kubernetes or Docker socket abuse.
Analyst context for executives and security teams
AN1492 focuses on spotting short-lived or unauthorized containers launched from public images that begin consuming high CPU soon after startup. For leaders, the business issue is not just a container event; it is whether cloud-native runtime governance can distinguish expected workload scaling from unauthorized compute use before it affects service capacity, cost, or incident response timelines.
Executive priority
Treat this as a container security and operational resilience validation point. Executives and security leaders should ask whether teams can prove which containers were authorized, which images came from public sources such as DockerHub, and whether abnormal CPU spikes after startup generate actionable review. This supports budget decisions around container runtime visibility, Kubernetes/Docker governance, SOC triage readiness, and audit evidence for workload control.
Technical view
For SOC, detection engineering, and IR teams, validate coverage on the Containers platform for container creation, image source, scheduler activity, Docker socket use, and CPU behavior shortly after startup. Because ATT&CK provides no official detection logic and no tactic mapping for this analytic, local baselining is essential: compare new container or pod instantiation against approved deployment sources, expected namespaces/projects, service accounts, image allowlists, and normal post-start CPU profiles.
Likely telemetry
- Container runtime container/pod creation events
- Kubernetes scheduling and audit events where applicable
- Docker socket access or API activity where collected
- Image pull metadata, including public registry source such as DockerHub
- Container or pod CPU utilization shortly after startup
Detection direction
- Correlate new or ephemeral container starts with immediate high CPU usage rather than alerting on CPU alone.
- Differentiate authorized autoscaling, batch jobs, CI/CD tasks, and performance tests from unexpected public-image execution.
- Validate whether public image use is expected, approved, and attributable to a known deployment pipeline or operator.
- Review for Kubernetes or Docker socket abuse indicators only where those telemetry sources are actually collected.
- Tune around environment-specific baselines for startup CPU behavior, since legitimate workloads may spike during initialization.
Mitigation priorities
- Establish and maintain an inventory of approved container images, registries, namespaces, and deployment paths.
- Restrict or monitor use of public images where business processes do not require them.
- Control access to Kubernetes scheduling capabilities and Docker socket/API interfaces according to least privilege.
- Ensure container runtime, Kubernetes audit, image pull, and resource utilization telemetry are retained for SOC and IR use.
- Create incident response procedures for unauthorized container instantiation, including owner validation, workload isolation decisions, and evidence preservation.
Analyst notes and limits
This object is a detection analytic for the enterprise ATT&CK domain with platform limited to Containers. The official description emphasizes ephemeral or unauthorized container instantiation from public images with high CPU soon after startup, often scheduled through Kubernetes or Docker socket abuse. No ATT&CK relationships, tactic mapping, aliases, labels, or official detection text were supplied, so the take is framed as defensive validation guidance rather than a specific rule.
The source does not provide detection logic, data components, relationships, tactics, threat actors, active exploitation claims, or impact statements. Local environment context is required to determine what counts as unauthorized, which public images are permitted, what CPU level is abnormal, and which Kubernetes or Docker telemetry is available.
Analytic 1492
Ephemeral or unauthorized container instantiation using public images (e.g., from DockerHub) that initiate high CPU usage shortly after startup. Often scheduled via Kubernetes or Docker socket abuse.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | ad7946f16987… |
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 AN1492Open 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.