AN0986: Analytic 0986
Detects malicious containers or pods using names, labels, or namespaces that mimic legitimate workloads; also checks for image layer mismatches and unauthorized resource deployments.
Analyst context for executives and security teams
This analytic matters because container environments can be abused in ways that blend into normal operations: malicious pods or containers may use familiar names, labels, or namespaces to look like approved workloads. For leaders, the key issue is whether the organization can distinguish legitimate deployment activity from unauthorized or deceptive resources before they affect service reliability, audit confidence, or incident response timelines.
Executive priority
Prioritize this as a cloud/container governance and SOC readiness question: do teams have reliable visibility into what workloads are authorized, how they are labeled, and whether deployed images match expected build artifacts? This supports business continuity by reducing the chance that unauthorized container resources persist unnoticed, and it supports compliance evidence by showing that workload identity, deployment control, and monitoring are being validated.
Technical view
For container platforms, validate detection logic that compares pod/container names, labels, namespaces, image layers, and deployment events against known-good workload inventory and approved deployment sources. Because no ATT&CK tactic or detailed detection logic is supplied, teams should treat this as a detection objective rather than a complete rule: confirm what constitutes an authorized namespace, expected label schema, trusted image lineage, and normal deployment pattern in the local environment.
Likely telemetry
- Container or Kubernetes pod creation and update events
- Container names, pod names, labels, and namespace metadata
- Image identifiers, image layers, digests, and registry metadata
- Deployment, ReplicaSet, DaemonSet, Job, or similar workload resource creation records
- Admission control, orchestration API, or audit logs showing who or what created resources
Detection direction
- Validate alerting for newly created containers or pods whose names, labels, or namespaces closely resemble legitimate workloads but are not part of an approved inventory.
- Compare deployed image layers or digests against expected images to identify mismatches between a workload identity and its actual image content.
- Tune for normal CI/CD, autoscaling, and release activity to reduce false positives from legitimate workload churn.
- Correlate suspicious resource creation with actor identity, service account, namespace, image source, and deployment method to support triage.
- Watch for blind spots where container audit logs, image metadata, or namespace/label inventories are incomplete or not retained long enough for investigation.
Mitigation priorities
- Maintain an authoritative inventory of approved container workloads, namespaces, labels, and image sources.
- Enforce consistent naming and labeling standards so impersonation or lookalike resources are easier to identify.
- Restrict who and what can deploy resources into sensitive namespaces or production environments.
- Use image integrity and provenance checks where available to reduce risk from mismatched or unauthorized image layers.
- Ensure container orchestration audit logging and deployment telemetry are retained and accessible to SOC and incident response teams.
Analyst notes and limits
This object is a detection analytic for container platforms focused on deceptive workload metadata, image layer mismatches, and unauthorized resource deployments. There are no supplied relationships, tactics, aliases, or official detection implementation details, so local baselines and deployment governance determine how actionable the analytic becomes.
The supplied ATT&CK fields do not provide specific query logic, data source requirements, related techniques, threat actors, or evidence of active exploitation. Any production detection must be validated against the organization’s actual container platform, CI/CD process, workload inventory, and logging coverage.
Analytic 0986
Detects malicious containers or pods using names, labels, or namespaces that mimic legitimate workloads; also checks for image layer mismatches and unauthorized resource deployments.
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 | e60e8e4676cf… |
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 AN0986Open 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.