AN0083: Analytic 0083
Containerized apps or sidecar containers generating excessive outbound traffic or being leveraged for proxy networks. Includes sudden increases in network interface stats, especially in dormant or low-util apps.
Analyst context for executives and security teams
This analytic highlights a container risk signal: an application or sidecar that suddenly starts producing unusually high outbound traffic, including from workloads that are normally dormant or low-use. For leaders, the practical issue is not just network volume; it is whether container environments can reveal when a workload is being abused as an outbound relay or proxy path before it affects cost, availability, incident scope, or compliance evidence.
Executive priority
Prioritize this where containerized services are business-critical, internet-connected, or expected to have tightly bounded network behavior. Security leaders should ask whether teams can baseline normal egress by workload, detect sudden outbound spikes, and investigate sidecar behavior with enough evidence to support incident decisions. This is also relevant to cloud/container cost control and audit readiness because unexplained egress can indicate weak workload governance or insufficient monitoring.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into container network interface statistics and outbound traffic patterns at the workload level. The supplied ATT&CK object is limited to the Containers platform and does not specify tactics or a formal detection query, so teams should focus on environment-specific baselining: compare current outbound volume against normal behavior for the same app, namespace, pod, service, or sidecar role, especially for dormant or low-utilization workloads.
Likely telemetry
- Container network interface statistics
- Outbound traffic volume by container, pod, workload, namespace, or service
- Sidecar container network activity
- Historical baseline of normal egress for low-use or dormant applications
- Container orchestration metadata needed to map traffic to workloads
Detection direction
- Validate that outbound traffic can be attributed to specific containerized apps and sidecars, not only to nodes or clusters.
- Tune for sudden increases relative to workload-specific baselines rather than static global thresholds.
- Pay special attention to dormant or low-utilization apps that begin generating sustained outbound traffic.
- Account for false positives from deployments, scaling events, batch jobs, backups, legitimate service mesh activity, or expected traffic shifts.
- Because no official detection logic is provided, require local testing against known-good workload behavior before treating alerts as high confidence.
Mitigation priorities
- Establish expected egress patterns for containerized applications and sidecars.
- Limit unnecessary outbound network paths where policy and architecture allow.
- Ensure container network telemetry is retained long enough to support incident response and compliance evidence needs.
- Review sidecar usage and ownership so unexpected traffic can be mapped quickly to an application team.
- Integrate container traffic anomalies into SOC triage workflows with orchestration context.
Analyst notes and limits
This is a detection analytic, not a technique description. The official description focuses on excessive outbound traffic from containerized apps or sidecars, including proxy-network-like behavior and sudden network interface statistic increases. No relationship context, tactics, detection query, or mitigations were supplied, so recommendations are framed as validation and monitoring priorities rather than confirmed ATT&CK-mapped procedures.
The supplied ATT&CK fields do not include official detection logic, tactics, related techniques, adversary use, impact claims, or non-container platforms. Local architecture, workload baselines, and available telemetry are required to determine materiality and alert confidence.
Analytic 0083
Containerized apps or sidecar containers generating excessive outbound traffic or being leveraged for proxy networks. Includes sudden increases in network interface stats, especially in dormant or low-util apps.
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 | 00420ed7100d… |
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 AN0083Open 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.