AN0222: Analytic 0222
Adversary exploits containerized app via ingress or service. Chain: (1) suspicious request in ingress/app logs → (2) container process spawns a shell/exec/sidecar (kubectl exec/docker exec) → (3) egress to Internet or metadata service (169.254.169.254).
Analyst context for executives and security teams
This analytic is about spotting a containerized application compromise that starts through an ingress or service path and then turns into interactive container activity and outbound access. For leaders, the business value is validating whether cloud-native workloads have enough end-to-end visibility to connect an external request, container execution behavior, and risky egress in one incident story.
Executive priority
Prioritize this where containers host business-critical applications or have access to cloud metadata services. The key decision is whether the organization can prove, during an incident or audit, that it can trace suspicious ingress activity to container runtime behavior and outbound network activity. Gaps here can slow containment, weaken incident scoping, and obscure whether application-layer exposure has become a broader cloud or workload compromise.
Technical view
ATT&CK supplies a container-platform analytic description, but no formal detection logic. SOC and detection teams should validate correlation across three evidence points: suspicious ingress or application requests, container process activity that indicates shell or exec-style interaction, and egress to the Internet or the metadata service address 169.254.169.254. Because no tactics or relationships are supplied, this should be treated as a detection-pattern validation task rather than a fully specified ATT&CK technique mapping.
Likely telemetry
- Ingress controller logs and service access logs
- Application request logs from containerized services
- Container runtime process execution telemetry
- Kubernetes or container orchestration audit events related to exec activity
- Network egress logs from containers, nodes, service mesh, or cloud network controls
Detection direction
- Validate that ingress/app logs, runtime process telemetry, and egress telemetry can be joined by workload, pod, container, namespace, node, timestamp, and source where available.
- Tune for sequences rather than single events: suspicious external request followed by shell or exec-like container activity and then outbound Internet or metadata-service access.
- Account for legitimate administrative exec activity, troubleshooting shells, health checks, and expected outbound application traffic to reduce false positives.
- Pay special attention to blind spots in ephemeral containers, short-lived pods, unmanaged namespaces, and environments where metadata-service access is not logged or restricted.
- Use this analytic as a coverage test for container incident reconstruction, since the official object does not provide a ready-made detection query.
Mitigation priorities
- Ensure container ingress and application logging is enabled and retained long enough for incident response.
- Restrict and monitor exec-style administrative access to containers through orchestration controls and audit logging.
- Limit unnecessary container egress, especially access to Internet destinations and cloud metadata services where not required.
- Apply least privilege to workloads and service identities so a compromised container has limited reach.
- Run tabletop or detection validation exercises that confirm responders can pivot from an ingress event to container runtime activity and network egress.
Analyst notes and limits
The object is a MITRE detection analytic for Containers, external ID AN0222, under DET0080. Its most useful contribution is the described event chain linking ingress/application activity, container execution behavior, and outbound access. Glexia should position this as a cloud/container detection engineering and incident-response readiness check rather than as a statement of known adversary use.
The supplied ATT&CK fields do not include tactics, relationships, aliases, labels, or official detection logic. No active exploitation, attribution, impact, or coverage claims can be inferred. Local architecture, logging configuration, workload behavior, and cloud/container control-plane data are required to make this operational.
Analytic 0222
Adversary exploits containerized app via ingress or service. Chain: (1) suspicious request in ingress/app logs → (2) container process spawns a shell/exec/sidecar (kubectl exec/docker exec) → (3) egress to Internet or metadata service (169.254.169.254).
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 | 2e793d4a33f7… |
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 AN0222Open 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.