T1612 Build Image on Host — Attack Simulation

DC0015 collection page — Collect VM image create/register APIs from the cloud control plane; retain source instance/disk, image ID and final state. Container image events are a separate concept.

Providers and collection configuration

• AWS CloudTrail: Management-plane API activity; supported resource/data events require separate selectors.
• Azure Monitor Activity Log: Azure resource control-plane operations; resource data-plane logs are separate.
• Google Cloud Audit Logs: Admin Activity and other categories; configure Data Access where required.

• In the isolated account/project/subscription, route administrative audit logs to a protected destination with retention and access controls.
• Select the relevant service, regions and read/write operations. Confirm whether the API below is a management or data event in the provider documentation.
• Preserve actor/session, resource, request ID, service, operation, region and error details. Check delivery latency and avoid logging credentials or sensitive request bodies.

Required normalized fields: image_id, source_instance, action, state.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0015",
  "collector": "illustrative-lab-collector",
  "observation": {
    "image_id": "image-lab-1",
    "source_instance": "vm-lab-1",
    "action": "create",
    "state": "pending"
  }
}

Visibility limits: AWS, Azure and Google expose different APIs and event schemas. An accepted API request does not prove the final resource state; join asynchronous outcomes and inventory.

DC0082 collection page — Enable scoped Sysmon NetworkConnect (3), disabled by default, or a platform-equivalent process-aware network sensor.

Providers and collection configuration

• Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
• Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
• Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.

• On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
• Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
• For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_guid, destination_ip, destination_port, protocol, initiated.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0082",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "destination_ip": "198.51.100.20",
    "destination_port": 443,
    "protocol": "tcp",
    "initiated": true
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

MITRE detection strategy

No exact-tagged Sigma source rule was imported. This does not establish that the technique is undetectable; the MITRE guidance and collection requirements remain relevant.

Adversaries may build a container image directly on a host to bypass defenses that monitor for the retrieval of malicious images from a public registry. An adversary may take advantage of that build API to build a custom image on the host that includes malware downloaded from their C2 server, and then they then may utilize Deploy Container using that custom image.

Pinned Atomic procedure · 2db30061-589d-409b-b125-7b473944f9b3 · containers · sh.

Elevation: not declared required. Cleanup: defined upstream; review required. This is source documentation, not an execution approval.

No input arguments declared.

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

2 prerequisite definitions:

• Verify docker is installed.
• Verify docker service is running.

• M1026 Privileged Account Management

  Ensure containers are not running as root by default. In Kubernetes environments, consider defining Pod Security Standards that prevent pods from running privileged containers.[Kubernetes Hardening Guide]

• M1030 Network Segmentation

  Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls.

• M1035 Limit Access to Resource Over Network

  Limit communications with the container service to local Unix sockets or remote access via SSH. Require secure port access to communicate with the APIs over TLS by disabling unauthenticated access to the Docker API on port 2375. Instead, communicate with the Docker API over TLS on port 2376.[Docker Daemon Socket Protect]

• M1047 Audit

  Audit images deployed within the environment to ensure they do not contain any malicious components.