Detecting T1610 Deploy container

What T1610 Deploy container means for container platform defenders

T1610 Deploy container lets an adversary place a container or workload on a container platform so that it runs adversary code or supports later stages of an intrusion. For the SOC lead, the first sign is often an unexpected workload: a pod, deployment, or container that nobody on the platform team recognizes, running an image that was never built by the normal pipeline. In intrusions, this technique typically appears after the attacker already holds some level of access to the cluster or its management plane, and it is used to establish a foothold, run tooling close to workloads, or prepare for lateral movement across namespaces and nodes.

The ATT&CK framework places T1610 under the Execution tactic, TA0002, which MITRE defines as the point where "the adversary is trying to run malicious code or instructions on a system." This mapping targets Enterprise ATT&CK version 20.0. Because ATT&CK can rename, deprecate, or revoke techniques between releases, detection mappings should name the version they target and be rechecked when the framework changes. Readers should confirm the exact technique description and platform list for 20.0 in the MITRE ATT&CK tactic page for Execution before writing detection content against it.

For defenders, the practical decision is scope. Decide which container platforms, clusters, and namespaces are in the monitored estate, who is authorized to create workloads in each, and which image sources are approved. Then confirm that the audit trail and runtime telemetry for those platforms actually record workload creation events with the identity that issued them. If that record cannot answer who deployed what, from where, and when, the detection work described later on this page will have nothing reliable to trigger on.

Which telemetry reveals a deployed container

This table maps the ATT&CK data components most often referenced for Execution techniques to the signal a defender should look for in a T1610 Deploy container investigation and the open-source collector that can gather it. Read each row as a question to answer in the client's own environment, because orchestrator audit sources vary. The main takeaway is that no single source is sufficient, so pair control-plane audit events with runtime and network evidence.

Data component	Signal to look for	Open-source collector
Process Creation (DC0032)	New container workloads started from unexpected images, namespaces or hosts, and processes spawned inside them shortly after deployment	Wazuh agent on container hosts, Falco-style runtime logs where supported
Application Log Content (DC0038)	Orchestrator audit events showing create or update requests for pods, deployments or containers by an unexpected identity	Wazuh log collection from the orchestrator audit log, confirmed against the client's platform
Network Traffic Content (DC0085)	Image pull or registry traffic and API payloads that reference an unrecognized image, tag or deployment manifest	Zeek or Suricata sensors on the cluster and registry network segments
Command Execution (DC0064)	Commands issued through the orchestrator client or a container runtime to create or modify workloads outside the change process	Wazuh command monitoring on administrative hosts, runtime audit logs
Network Connection Creation (DC0082)	New outbound connections from a freshly deployed container to destinations never seen for that workload	Zeek connection logs, Suricata flow records, host firewall logs
Mapping basis	The mapping follows ATT&CK v18 detection strategies, so name that version in every detection record	Confirm exact audit sources with the client's container orchestrator before writing rules

Detection ideas for suspicious container deployments

Deploying a container is a legitimate administrative action, so T1610 detection depends on context: who deployed, what was deployed, where it landed and how it was configured. The five ideas below each look at one of those dimensions, and each needs a baseline from your own clusters before it becomes an alert.

Deployments from unexpected identities

Alert when a workload is created or updated by an identity that has never deployed to that namespace or cluster before, or by a human account outside the platform team. The logic is a comparison against an allowlist of deployers per namespace, built from audit records over a baseline period. Tune by reviewing the first few weeks of alerts and adding known automation identities. False positives come from CI/CD service accounts that rotate, GitOps controllers that act under their own identity, and scheduled jobs created by operators. Confirm which identity each pipeline uses before you widen the allowlist.

Images from unapproved registries

Flag any pod whose image reference points to a registry outside your approved list, including public registries used by developers during testing. The check is a string match on the registry host and, where your tooling supports it, on signed digests. Set the threshold at zero for production namespaces and allow a short review window for development ones. False positives come from base images pulled through a legitimate proxy or mirror that has a different hostname, so map mirrors to their upstream sources before you alert.

Workloads in sensitive namespaces

Alert on new deployments into namespaces that hold payment, identity, key management or regulated data workloads. The logic keys on the namespace name and the labels you assign to sensitive systems, so new workloads there get a second review. Set a baseline of expected change frequency per namespace and alert on deviations. False positives come from planned releases, incident hotfixes and cluster-wide tooling such as monitoring agents that legitimately run in every namespace. Keep a documented change record that the alert can reference.

Privileged settings and host mounts

Inspect deployment specifications for privileged mode, added Linux capabilities, host network or process namespace sharing, and host path volumes that expose node directories. Treat any match outside an approved exception list as a finding. The threshold is typically zero for non-system namespaces, and the exception list should name the owning team and reason. False positives come from node-level agents for logging, security scanning and storage, which need elevated settings by design. Review those agents as a group rather than one by one.

New outbound connections from fresh pods

Watch for outbound network connections initiated by pods within minutes of their start that go to destinations never seen for that workload. The logic combines pod age with a per-workload destination baseline, so a new pod contacting an unfamiliar external address stands out. Tune the window and the destination baseline over a representative period of normal releases. False positives come from init containers that fetch configuration, package installs during startup, and health checks to new dependencies after a planned change. Confirm each workload's expected egress before you set the alert.

How to turn these ideas into Sigma rules and tune them

Detection engineers express the T1610 Deploy Container logic as Sigma rules that read the Process Creation, Application Log Content and Network Traffic Content signals described above, one rule per distinct signal rather than one catch-all rule. Each rule should carry the ATT&CK technique tag for T1610 in its tags field, along with the relevant data component references, and should record the ATT&CK version it targets. Because MITRE can rename, deprecate or revoke techniques between releases, write the version into the rule metadata as ATT&CK 20.0 and review the mapping whenever a new release is published. Store the rules in version control so that every change to a condition, field name or tag leaves a reviewable history.

Tuning starts before the rules go live. Build an allowlist of approved deployers, meaning the service accounts, CI/CD runners and named administrators that are expected to create containers, along with the registries and image names your platform permits. Confirm the exact fields your container runtime and log pipeline emit before writing filters against them, since field names differ between sources. Then run the rules in alert-only mode for a two to three week baseline period and review every hit with the platform team. Expect the early output to surface pipelines and tooling you did not know about, and treat each new legitimate pattern as a change request to the allowlist, not a silent exclusion.

Document every threshold and exclusion as you set it: the value, the reason, the owner, the date and the evidence from the baseline review. Ask your implementation partner to deliver this log as part of the rule package so that auditors and future analysts can see why a rule fires and why it is quiet. Agree in advance who may approve an allowlist change and how often the list is re-reviewed. Alert volumes vary widely with platform size and deployment practice, so do not set a target volume in advance; instead, confirm with the platform owners what a manageable daily review load looks like and tune until the rules meet that bar.

How to validate that the T1610 detection fires

This sequence proves that the T1610 Deploy Container detections fire on the telemetry they depend on, with known test activity, measured time to alert and a documented record of misses and false positives. It also defines when the same tests must run again, so the detection stays valid as rules and ATT&CK mappings change.

Agree scope and rules of engagement
The security lead, the platform owner for the container environment and the detection engineer agree in writing which clusters, registries and namespaces are in scope, which deployment actions may be emulated, and who can stop the test. They also agree a named test identity, the window in which activity runs and how test artifacts will be removed afterward. The step is done when the signed scope lists every system the emulation touches and the stop conditions are written down.
Map each detection idea to expected telemetry
Before any activity runs, the detection engineer lists each detection idea for T1610 and the data components it relies on, such as Process Creation, Application Log Content and Network Traffic Content, using the ATT&CK version the rules target. For each idea, the team writes the fields that must appear in the SIEM, including the account, the target container platform, the image or workload identifier and the source host. The output is a table linking each detection to its expected log sources and fields, reviewed by someone who did not write the rule.
Confirm log sources are flowing before testing
The platform team checks that the container audit logs, runtime or node process telemetry and network sensors that feed each detection are reaching the SIEM and are parsed correctly. Stale ingestion, dropped fields or a changed log format will otherwise look like a detection gap. The step is complete when a benign, separately logged deployment event appears in the SIEM with every field from the table in the previous step.
Run the emulation under the test identity
A tester uses the agreed test identity to perform the planned deployment actions in the lab or cyber range, following the scenario script and without improvising beyond the scope. The script describes behavior and intent, not commands, and the tester logs the start and end time of each action. The step closes with a timeline that records every action, its timestamp and the account used, which becomes the ground truth for the next steps.
Verify alerts reach the SIEM with expected fields
The detection engineer compares the ground-truth timeline with the alerts raised in Wazuh, Security Onion or the chosen SIEM. For each action, they confirm that an alert fired, that it carries the expected account, workload and source fields, and that it maps to the intended detection strategy. An alert that fires without the right fields counts as a partial result and is logged as a defect in the rule or the parser.
Record time to alert, misses and false positives
The team calculates the delay between each action and its alert, notes every action that produced no alert, and records any alert triggered by unrelated activity during the window. Each miss is classified as a rule gap, a missing log source or a parsing error, and each false positive is traced to the condition that caused it. The output is a signed test report that the detection owner and the SOC lead accept, with the open items assigned to named owners.
Retest after rule changes and ATT&CK updates
Any change to a T1610 rule, its thresholds or its log sources triggers a repeat of the affected steps against the same scenario, so results can be compared directly. When MITRE publishes a new ATT&CK version, the team checks the STIX bundle for the version it targets to see whether T1610 or its detection strategies changed, then reruns the validation if they did. The step is done when the retest report references the rule version and the ATT&CK version it was run against.

Preventive controls that limit who can deploy containers

T1610 Deploy container depends on who is allowed to create workloads in the cluster or container platform. The cards below cover the two ATT&CK mitigations that map most directly to that question, User Account Management and Audit, plus two related mappings to review alongside them.

Restrict deployment rights to named accounts

Limit the ability to create or update workloads to named service accounts and a small set of administrator identities. Confirm in your own platform whether deployment permissions can be scoped by namespace or project, and whether human users can deploy directly or must go through a pipeline. Remove shared or long-lived credentials from deployment roles, since any identity with these rights can start new containers under its own authority. Mitigation User Account Management (M1018) is the ATT&CK control most directly tied to this restriction.

Review role bindings on a schedule

Role bindings tend to grow over time as teams request exceptions. Export the bindings that grant create, update or patch rights on workloads, and compare them against the list of approved deployers at a defined interval. Check for wildcard verbs, cluster-wide bindings granted to ordinary users and default service accounts that have acquired deployment rights. Record each review and its outcome so the evidence can be reproduced for an assessor. The exact export and comparison method depends on your platform, so confirm it with your platform team before relying on it.

Enable and forward deployment audit logs

Keep audit logging of deployment API calls enabled and forwarded to a store the cluster operators cannot silently edit. Confirm that the platform records create, update and patch requests against workload objects, including the identity, source address and request outcome. Forward those records to your central logging pipeline so that Wazuh, Security Onion or another SIEM can correlate them with network and host telemetry. Test the pipeline by generating a known deployment in a non-production namespace and confirming the event arrives. Mitigation Audit (M1047) covers this control.

Plan for privileged account separation

Privileged Account Management (M1026) is a related mapping for T1610. Deployment rights usually sit with cluster administrators, so confirm that those identities are separate from daily user accounts, that their use is logged and that break-glass access is documented. Ask whether your platform supports time-limited elevation for deployment tasks. Treat this as a companion control to the role review above, not a replacement for it.

Train teams on approved deployment paths

User Training (M1017) is a related mapping that supports the technical controls. Developers and operators who understand which deployment path is approved, such as a pipeline with reviewed manifests, are less likely to request broad rights for convenience. Document the approved path, the owner of each namespace and the process for requesting an exception. Training content should be reviewed when the platform's role model changes so that guidance does not describe permissions that no longer exist.

What to do when a deployment alert fires

When a deployment alert for T1610 Deploy container fires, the first decision is whether the deployment is authorized. Confirm which identity created the workload (a human user, a CI/CD service account or a platform controller) and whether the change matches an approved pipeline run or change ticket. Check the image source, the registry path, the image digest and the workload spec, including privileged settings, host namespace sharing, mounted host paths and the requested network exposure. A deployment with no matching ticket and an unfamiliar image is the trigger for escalation, not a reason to wait for more data. Where your platform keeps admission or policy decisions, record which policy allowed the request, since an allowed request from an unexpected identity is itself a finding about User Account Management.

Containment should use the platform's own controls so that evidence stays intact. In a Kubernetes-based platform, that usually means cordoning the node or scaling the workload to zero through the orchestrator API, or applying a restrictive network policy, rather than deleting pods that hold the only copy of volatile state. Before any change, export the workload manifest, the pod events, the container logs and the audit log entries for the create and update calls, and copy them to write-once storage. Confirm the exact audit policy and log retention in your own environment, because some clusters record request bodies only at higher audit levels. Disable or rotate the credential the identity used, and revoke any active sessions, once you know the scope.

Scope the incident by asking what else the same identity started or modified in the same window, across namespaces, clusters and cloud accounts, and whether the new workload pulled credentials or reached other services. Coordinate with platform engineering early, because they own the cluster, the pipelines and the change records that confirm or rule out approval. Escalate to incident handling as soon as the deployment is unapproved or the scope is unclear, and keep a timeline that records each decision, who made it and the evidence it relied on. That record, along with the alert logic and the ATT&CK version your detection targets, becomes the basis for the post-incident review and for any follow-on tuning of the rule.

Rehearsing T1610 detection in a private cyber range

A useful range for T1610 is a private replica of the container platform the organization runs, with the same audit and log pipeline feeding the same detection stack. If the production cluster ships API audit records to a log collector, the range should do the same, using the same format, retention settings and parsing rules. A range that uses a simplified logging path tests a pipeline that does not exist in production, and the results will not transfer. DeployOpen runs private cyber ranges and can scope one against your own platform, but the replica's fidelity is something your platform team must confirm line by line.

Matching audit policy: Confirm that the range records the same request stages and object types as production, so deployment events are visible at the same level of detail.
Identity model: Recreate the service accounts, human roles and namespaces used in production, since T1610 detections often depend on who deployed and where.
Log path parity: Verify that events reach the SIEM or Wazuh manager through the same agents, forwarders and parsers.
Synthetic workloads: Use benign images from an internal registry so no real workload data enters the range.
Clock and time sync: Align timestamps across the cluster and the detection stack so correlation windows behave as they will in production.

Before the exercise, ask the range provider to document every difference from production, because each gap is a finding you cannot test.

Questions SOC leads and detection engineers ask about T1610

How does T1610 Deploy container differ from T1609 Container administration command?

T1609 covers running a command inside a container that already exists, while T1610 covers placing a new container into the environment so it can execute the adversary's workload. The signals differ. For T1609, you watch for exec-style actions against running workloads in the orchestrator audit trail. For T1610, you watch for creation of new workload objects, image pulls from unexpected registries, and new containers with privileged settings or host mounts. The two overlap because an adversary can use a deployed container to reach a running one, so map both techniques in your coverage and review them together. Confirm the exact detection strategy IDs for each technique in the ATT&CK version you target.

Which data sources should we enable first for T1610 detection?

Start with the audit log of the container orchestrator's API server, because workload creation requests are recorded there and it gives you the identity behind each deployment. Next, enable process creation telemetry from container hosts and the runtime, so you can see what a new container actually starts. Third, collect image registry logs, which show where images came from and who pushed them. ATT&CK's Execution data components include Process Creation (DC0032), Application Log Content (DC0038) and Network Traffic Content (DC0085), which are the ones most often referenced for Execution techniques. Check the T1610 detection strategy in the enterprise-attack 20.0 bundle to confirm which components it names, and verify retention is long enough for investigations.

How do we handle GitOps and CI/CD false positives for container deployments?

Pipelines and GitOps controllers create most legitimate deployments, so they are the main source of noise. Reduce it by matching on identity rather than on workload names. Good tuning usually has three parts:

Allowlist the specific service accounts or controller identities that your pipelines use, and alert when any other identity creates workloads.
Check each deployment against the expected image registry, signed image policy and approved privilege settings, and alert on deviations.
Tie the allowlist to change records in version control, review it on a schedule, and remove entries when a pipeline is retired.

Illustrative example: a deployment from the approved controller identity pulling from the approved registry is expected, while the same action from a developer's personal account is not. Test each allowlist rule in the cyber range before production.

How do we map T1610 detections to ATT&CK v20.0 sub-techniques?

Check the enterprise-attack 20.0 STIX bundle for the current sub-technique list of T1610 instead of relying on older documentation, then record the ATT&CK version in the metadata of every rule. The bundle is published by MITRE in the attack-stix-data repository, one bundle per domain and version, so you can query it with your own tooling and keep the mapping in version control. Map each detection to the detection strategy and analytic it addresses, and mark any sub-technique with no detection as an explicit gap with an owner and a review date. Confirm mappings with each new release rather than assuming earlier coverage still applies.

What changes after an ATT&CK release and how should we respond?

Releases can rename, deprecate or revoke techniques, so detection mappings should name the version they target and be reviewed after every update. The v18 release on October 28, 2025 replaced detections in technique pages with detection strategies and analytics, updated data components and deprecated data sources. Later releases followed on April 28, 2026 (v19) and October 13, 2026 (v20). After each release, diff the new bundle against your previous one, check whether the T1610 identifiers, names and data components changed, update rules and mappings, and rerun your cyber range tests on the affected detections. Keep a dated change log so auditors can see when mappings changed and why.

How do we prove T1610 detection coverage to auditors?

Keep a coverage record that links each technique and sub-technique to its detection strategy, rule identifier, required data source, owner, and the test results from cyber range runs with dates and alert outcomes. Add the ticket history showing how alerts were triaged and how gaps were closed. DeployOpen can prepare the systems, controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Before building the evidence set, confirm with your auditor which framework and control IDs they will test against, and which evidence format they accept.

Can our own team build and test T1610 detections without an outside partner?

Often yes, if your team already runs the container orchestrator, its audit logging and your SIEM, and can write and test detection rules. The harder parts are usually the cyber range exercises, which need a realistic lab, controlled test deployments and a way to measure what fired. Ask yourself whether you can keep the rules and test evidence current after each ATT&CK release, since that work recurs. If you want outside help, DeployOpen works on fixed scopes agreed in writing before work starts, and offers ongoing retainers for continuous testing. Confirm your team's skills against the scope before deciding.

How DeployOpen builds T1610 detections and range exercises

DeployOpen treats T1610 Deploy container as a detection engineering project inside your own environment, not a generic tooling install. We agree the scope in writing, build and test the telemetry and rules on your container platform, then hand over documentation and rehearsal material your team can run again.

How we scope

Confirm which container platforms, clusters and namespaces are in the written scope for T1610 Deploy container
Inventory which log sources (audit, runtime, network) can actually be collected from each cluster before promising coverage
Agree the ATT&CK version the detection mapping targets, so later technique changes are traceable
Record which mitigations, including User Account Management and Audit, are owned by your teams versus ours

How we build

Design detection logic in plain language first, then map it to Process Creation, Application Log Content and Network Traffic Content
Deploy open-source collection and rules on Wazuh, Security Onion, Suricata or Zeek where they fit your architecture
Tune rules against your baseline deployment activity so routine pipeline and operator actions are documented separately
Test detections in a private cyber range before they reach production alerting

How we hand over

Deliver detection documentation covering data sources, logic, known blind spots and the ATT&CK version targeted
Provide a range exercise runbook describing how your team rehearses detection and response for T1610
Document how User Account Management and Audit controls were configured and where the evidence is kept
Walk your security and platform engineers through the handover so they can operate and adjust the rules

How we support

Fixed-scope engagements end with written acceptance of the agreed deliverables
Ongoing support is available as a retainer for rule tuning, log source changes and ATT&CK version updates
Retainers can include periodic range exercises that repeat the T1610 scenario after platform upgrades
Ask for a written quote that lists each deliverable, the environments covered and who maintains each component after handover

T1610 Deploy container