AN1261: Analytic 1261
Detection of container image build activity directly on the host using Docker or Kubernetes APIs. Defenders may observe Docker build requests, anomalous Dockerfile instructions (such as downloading code from unknown IPs), or creation of new images followed by immediate deployment. This behavior chain typically consists of an unexpected image creation event correlated with outbound network communication to non-standard or untrusted destinations.
Analyst context for executives and security teams
AN1261 matters because building container images directly on a host can be a sign that container build and deployment controls are being bypassed or abused. For leaders, the practical question is whether the organization can distinguish approved image-build activity from unexpected image creation that is quickly deployed, especially when it is paired with outbound network connections to untrusted or non-standard destinations.
Executive priority
Prioritize this as a container security and operational resilience validation item. If production or sensitive container hosts can build images outside approved pipelines, security teams may lack reliable evidence for change control, audit readiness, incident scoping, and rapid containment. Executives should ask whether image creation is restricted to approved build systems, whether Docker or Kubernetes API activity is monitored, and whether SOC teams can correlate image builds with outbound network behavior and immediate deployments.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into container image build activity on container platforms, specifically Docker or Kubernetes API events where available. The key behavior described by ATT&CK is an unexpected image creation event correlated with outbound communication to non-standard or untrusted destinations, and possibly followed by immediate deployment. Since no official detection logic is supplied, teams should build local analytics around approved build locations, expected Dockerfile behavior, image creation timing, deployment timing, and network destination reputation or trust status.
Likely telemetry
- Docker API build requests and image creation events
- Kubernetes API activity related to image use or deployment after creation
- Container host process and command activity where available
- Container image metadata, creation timestamps, tags, and deployment timing
- Outbound network connection logs from container hosts or build environments
Detection direction
- Baseline where container images are expected to be built and alert on image build activity directly on hosts that are not approved build systems.
- Correlate new image creation with outbound network communication to destinations that are non-standard, untrusted, or outside expected repositories and package sources.
- Look for rapid sequencing: image creation followed by immediate deployment, especially outside normal release windows or change-control patterns.
- Tune for legitimate CI/CD, developer testing, maintenance, and emergency release workflows to reduce false positives.
- Validate whether Docker and Kubernetes API logs are actually retained and searchable; host-only logging may miss API-level context, while API-only logging may miss network correlation.
Mitigation priorities
- Restrict container image builds to approved build pipelines and environments where feasible.
- Limit Docker or Kubernetes API permissions so only authorized identities and systems can create, build, or deploy images.
- Enforce change-control and deployment approval evidence for image creation and promotion into runtime environments.
- Monitor and control outbound network access from container hosts and build environments, especially to untrusted or non-standard destinations.
- Maintain trusted registries, approved source locations, and asset ownership records so detections can separate expected builds from suspicious host-based activity.
Analyst notes and limits
This take is based on the supplied ATT&CK detection analytic AN1261. The object is scoped to Containers and describes detection of container image build activity directly on the host using Docker or Kubernetes APIs. No ATT&CK tactics, relationships, aliases, or official detection logic were supplied, so the defensive guidance is framed as validation and control direction rather than a claim of known coverage.
The source provides a behavioral description but no formal detection query, data component list, tactic mapping, or relationship context. Environment-specific baselines, approved build locations, trusted destinations, and CI/CD workflows are required before this can be operationalized reliably.
Analytic 1261
Detection of container image build activity directly on the host using Docker or Kubernetes APIs. Defenders may observe Docker build requests, anomalous Dockerfile instructions (such as downloading code from unknown IPs), or creation of new images followed by immediate deployment. This behavior chain typically consists of an unexpected image creation event correlated with outbound network communication to non-standard or untrusted destinations.
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 | 4eb57ea817a7… |
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 AN1261Open 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.