---
{
  "title": "Deploy Container",
  "summary": "Unauthorized container deployment introduces a new workload through orchestration or runtime authority.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1610"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1610: Deploy Container",
      "url": "https://attack.mitre.org/techniques/T1610"
    }
  ],
  "editorialVersion": 2
}
---

## A new workload changes the environment

Unauthorized container deployment introduces a workload through a runtime or orchestration interface. The actor may use it to execute code, access mounted resources, or operate under a configuration different from approved workloads. The security implications depend on the deployment authority and the container's actual permissions and connections.

Deploying a container is routine engineering work. A new workload is not suspicious solely because it is new or short-lived. Investigators need to understand who requested it, which artifact and settings were used, and whether it belongs to an approved process.

## An unfamiliar workload starts

In a fictional academy, a production cluster starts a container outside its normal pipeline. The analyst reviews the creation request, principal, namespace, image identifier, workload configuration, and resulting runtime activity. They compare the deployment with release records and the service owner's expectations.

A developer may have performed approved emergency diagnostics. The team checks whether that exception was authorized and whether the deployed settings match its purpose. A familiar image name is insufficient because tags may change and runtime settings can grant access beyond the image's ordinary behavior.

The investigation separates a requested deployment from a running workload. An API acceptance record may not prove that the scheduler placed the workload or that its program executed successfully. Use state and runtime evidence to establish those stages.

## Review the configuration boundary

Examine mounted storage, service identities, network access, and other capabilities relevant to the incident. A container may be constrained or unusually privileged; do not assume either from the word “container.” The configuration determines which resources it can reach.

[[build-image-on-host]] describes local artifact creation. [[container-administration-command]] covers commands through management interfaces, while [[escape-to-host]] concerns crossing the workload-to-host boundary. Evidence of deployment alone does not establish those additional behaviors.

Short-lived resources can disappear before an investigation begins. Preserve audit records, image identifiers, configuration, and relevant runtime evidence promptly through an approved process.

## Restrict deployment authority deliberately

Containment may involve stopping the workload, restricting the abused identity, or changing the management path. Coordinate with operations so evidence preservation and service continuity are considered. Deleting one container does not prevent the same identity from creating another.

For practice, compare a normal pipeline deployment with a fictional interactive deployment using an unexpected service identity. Identify the provenance, approval, configuration, and runtime records needed for a decision. Explain what can be concluded if the creation request succeeded but no execution evidence survives. [[cloud-incident-response]] and [[incident-reporting]] connect the workload finding to the wider incident.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]