AN1060: Analytic 1060
Detects lateral discovery or container breakout attempts using netcat, curl, or custom binaries probing other services within the same namespace or VPC subnet.
Analyst context for executives and security teams
Analytic 1060 matters because container environments often rely on internal network boundaries, namespaces, and service-to-service trust. Probing with tools such as netcat, curl, or custom binaries inside the same namespace or VPC subnet can indicate an attempt to map reachable services or test paths toward container breakout. For leaders, the value is not simply detecting a tool name; it is validating whether container runtime, workload, and network telemetry can show suspicious internal probing before it becomes a broader incident.
Executive priority
Prioritize this as a cloud/container security and SOC readiness question: can the organization see unexpected internal service probing from containers, and can responders determine which workload, namespace, image, and subnet were involved? This supports incident decision-making, segmentation validation, compliance evidence for monitoring controls, and resilience planning for containerized applications. Because ATT&CK provides no detection logic or relationships for this analytic, it should be treated as a validation prompt rather than proof of existing coverage.
Technical view
For SOC, detection engineering, and IR teams, validate visibility for Containers where a workload executes or drops netcat, curl, or custom binaries and then initiates repeated or unusual connections to peer services in the same namespace or VPC subnet. Since tactics are not specified and no official detection query is provided, build context around process execution, container identity, namespace, image, pod/task metadata, destination service, destination port, connection frequency, and whether the behavior is expected for the workload. Tune carefully because curl and similar utilities may be legitimate in health checks, diagnostics, installers, or application workflows.
Likely telemetry
- Container runtime process execution events, including command line where available
- Workload metadata such as container ID, image, namespace, pod/task, node, and service account
- Network connection logs from containers to internal services, namespaces, or VPC subnet destinations
- Cloud or platform network flow records showing east-west traffic within the VPC subnet
- DNS or service-discovery lookups initiated by containerized workloads
Detection direction
- Inventory which container platforms and namespaces have process and network telemetry sufficient to associate activity with a specific workload.
- Look for unexpected use of netcat, curl, or nonstandard binaries followed by internal connection attempts to multiple services, ports, or peers in the same namespace or VPC subnet.
- Baseline legitimate application, health-check, deployment, and troubleshooting behavior to reduce false positives around curl and administrative diagnostics.
- Correlate process telemetry with network flow records; network-only detections may miss the initiating binary, while process-only detections may miss probing scope.
- Treat custom binaries cautiously: absence of a known tool name should not exclude suspicious internal probing behavior.
Mitigation priorities
- Establish least-privilege container execution controls and restrict unnecessary diagnostic utilities in production images where operationally feasible.
- Harden container images and CI/CD review so unexpected custom binaries are less likely to appear unnoticed.
- Enforce network segmentation and namespace/VPC access controls so workloads can reach only required internal services.
- Centralize container runtime, workload metadata, and internal network telemetry for SOC investigation and audit evidence.
- Prepare IR playbooks that can quickly identify the source workload, image lineage, affected namespace, reachable services, and containment options.
Analyst notes and limits
This is a detection analytic object, not a technique object. The supplied ATT&CK fields identify the platform as Containers and describe detection of lateral discovery or container breakout attempts using netcat, curl, or custom binaries probing services within the same namespace or VPC subnet. No tactics, relationships, aliases, labels, or official detection logic were supplied, so the take focuses on validation questions and telemetry coverage rather than a specific query.
The object does not provide a detection query, data source list, tactic mapping, related techniques, procedures, mitigations, or evidence of active exploitation. Local architecture, workload behavior, container platform logging, and network design are required to determine severity, false-positive rate, and actual coverage.
Analytic 1060
Detects lateral discovery or container breakout attempts using netcat, curl, or custom binaries probing other services within the same namespace or VPC subnet.
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 | d61fe95852ca… |
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 AN1060Open 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.