AN1007: Analytic 1007
Connections to exposed container services (e.g., Docker API, Kubernetes API server) from unauthorized external IPs → abnormal container creation/start → lateral activity within cluster nodes.
Analyst context for executives and security teams
This analytic describes a container-environment risk pattern: exposed container management services, such as Docker API or Kubernetes API server, receiving connections from unauthorized external IPs, followed by abnormal container creation or startup and possible lateral activity across cluster nodes. For leaders, the business issue is not just a container alert; it is whether externally reachable control-plane or management interfaces could let an unauthorized party influence workloads that support production services.
Executive priority
Prioritize this as a cloud/container security and operational resilience validation item. Executives should ask whether container management APIs are externally exposed, how unauthorized access is defined and enforced, and whether SOC and incident response teams can quickly prove when abnormal container activity occurred. This also supports audit and compliance evidence around management-plane access control, logging, and segmentation, but local environment data is required to assess actual exposure.
Technical view
SOC, detection engineering, and IR teams should validate visibility across the sequence described by the analytic: external connections to exposed container services, authorization context for the source IP, container creation or start events, and subsequent lateral activity among cluster nodes. Because ATT&CK provides no separate detection logic for this analytic, teams should avoid assuming coverage from generic network or container logs alone; they should test whether events can be correlated across network telemetry, container orchestration audit data, and node-level activity.
Likely telemetry
- Network connection logs showing external IP access to container services such as Docker API or Kubernetes API server
- Container or orchestration audit logs showing container creation and start events
- Authentication and authorization records for container management services
- Cluster node activity logs that can show lateral movement or node-to-node access
- Asset and exposure inventory identifying externally reachable container management endpoints
Detection direction
- Validate that exposed container service access can be distinguished between authorized and unauthorized external IPs.
- Correlate external management-plane access with abnormal container creation or start events rather than alerting on either signal in isolation.
- Tune for expected administrative activity, automation, and approved CI/CD or operations sources to reduce false positives.
- Confirm whether node-to-node or cluster-internal activity after container startup is visible enough for incident scoping.
- Document blind spots where container API, Kubernetes audit, network, or node telemetry is missing or not retained.
Mitigation priorities
- Inventory container management services and determine which are externally reachable.
- Restrict management-plane access to approved networks, identities, and administrative paths.
- Ensure container API and orchestration audit logging is enabled and retained for investigation.
- Review segmentation between cluster nodes and management services to limit lateral activity if unauthorized access occurs.
- Run incident response validation exercises using this event sequence to confirm triage, containment, and evidence collection readiness.
Analyst notes and limits
The supplied object is a detection analytic for the Containers platform with no ATT&CK tactics specified and no relationship context supplied. The practical value is in validating whether the organization can detect and investigate the described chain from exposed service access through container activity and cluster lateral movement.
Official detection content is not provided, and no related techniques, mitigations, groups, software, or campaigns were supplied. This take therefore avoids attribution, active exploitation claims, and guaranteed detection guidance. Local architecture, exposure data, identity controls, and telemetry coverage are required to determine material risk.
Analytic 1007
Connections to exposed container services (e.g., Docker API, Kubernetes API server) from unauthorized external IPs → abnormal container creation/start → lateral activity within cluster nodes.
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 | 28f6421a38c7… |
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 AN1007Open 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.