Deploy Container
Where this stands
No Sigma rule can address this — the telemetry MITRE names has no Sigma logsource behind it.
None of MITRE's analytics for this technique name a log source that maps to a Sigma logsource — they describe abstract data ("Process::None"), API-hook telemetry, or prose channels with no reliable field names behind them.
What the technique is
Adversaries may deploy a container into an environment to facilitate execution or evade defenses. In some cases, adversaries may deploy a new container to execute processes associated with a particular image or deployment, such as processes that execute or download malware. In others, an adversary may deploy a new container configured without network rules, user limitations, etc. to bypass existing defenses within the environment. In Kubernetes environments, an adversary may attempt to deploy a privileged or vulnerable container into a specific node in order to Escape to Host and access other containers running on the node. Containers can be deployed by various means, such as via Docker's create and start APIs or via a web application such as the Kubernetes dashboard or Kubeflow. In Kubernetes environments, containers may be deployed through workloads such as ReplicaSets or DaemonSets, which can allow containers to be deployed across multiple nodes. Adversaries may deploy containers based on retrieved or built malicious images or from benign images that download and execute malicious payloads at runtime.
Read it on attack.mitre.orgWhat MITRE says you would watch
- AN0693
Remote/API driven creation **and** start of a container whose image is not on an allow‑list (or is tagged latest), executed by a non-admin principal, and/or started with risky runtime attributes (e.g., --privileged, host PID/NET namespaces, sensitive host path mounts, capability adds). Correlates *create* ➜ *start* ➜ first network/process actions from that container within a short time window.
Technique names and descriptions © MITRE ATT&CK®, CC BY 4.0. Not endorsed by MITRE.