Deploy Container T1610
Tactic: Execution
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.
Events covered
1 catalog event is tagged with this technique by at least one rule.
| Provider | Event | Title |
|---|---|---|
| ESF | exec | Process Execution (Notify) |
Authoring guide
Patterns shared across the 22 rules above: which fields they filter on, what specific values they look for, and what they exclude. The catalog normalizes field names across vendors so Sigma's Image, Elastic's process.name, and Splunk's process_name collapse into one row. Each rule contributes at most once per row.
Fields filtered most (40 distinct)
The fields most rules look at when detecting this technique. The How column shows the operators authors use (eq, wildcard, regex_match, match) and how often each appears. Sample values are concrete examples to start from, not an exhaustive list.
Top indicator values (221 distinct)
Specific (field, operator, value) combinations the rules check for, ranked by how many rules under this technique use each one. The Corpus reach column counts how many rules across the entire catalog (any technique) check the same combination. High numbers point to widely-used indicators that are likely noisy on their own; combine them with another condition for useful signal. Blank means the combination is specific to rules under this technique. Click a value to expand the rules under this technique that use it.
Exclusions (187 distinct)
Field/operator/value combinations excluded by rules under this technique (top-level not() clauses), sorted by how many rules exclude each. These are the false-positive paths the community has learned to filter out. A new rule that ignores the high-count entries here will likely fire on the same noisy paths. Click a value to expand the rules under this technique that exclude it.
Rules under this technique
Every rule in the catalog tagged with this technique, grouped by vendor. Click a rule title for its full predicates, exclusions, and indicators.
Elastic 17 rules
- Direct Interactive Kubernetes API Request by Unusual Utilities
- Kubectl Apply Pod from URL
- Kubernetes Anonymous User Create/Update/Patch Pods Request
- Kubernetes Container Created with Excessive Linux Capabilities
- Kubernetes Pod Created with a Sensitive hostPath Volume
- Kubernetes Pod Created With HostIPC
- Kubernetes Pod Created With HostNetwork
- Kubernetes Pod Created With HostPID
- Kubernetes Pod Creation Using Common Debug or Base Images
- Kubernetes Privileged Pod Created
- Kubernetes Sensitive Configuration File Activity
- Pod or Container Creation with Suspicious Command-Line
- Potential Kubectl Masquerading via Unexpected Process
- Potential Privilege Escalation through Writable Docker Socket
- Potential Privilege Escalation via Container Misconfiguration
- Privileged Container Creation with Host Directory Mount
- Privileged Docker Container Creation