Detection engineering without a threat framework is just logging. You capture events, you write rules, but you do not have a way to answer the question: what are we actually trying to detect, and are we covering it?
MITRE ATT&CK for Containers gives you the answer. It is a structured catalog of adversary techniques observed against container and Kubernetes environments — organized by tactic, each with documented procedures and mitigations. When you map your Falco rules to this matrix, you go from “we have some detections running” to “we have coverage across these specific techniques and gaps here.”
This post walks through the ATT&CK Containers tactics and shows where Falco fits — and where it does not.
The ATT&CK Containers matrix: a quick orientation
The MITRE ATT&CK Containers matrix covers techniques observed in containerized environments. It maps onto the broader Enterprise matrix but adds container-specific techniques and sub-techniques.
The tactics follow the standard ATT&CK structure:
- Initial Access — how attackers get in
- Execution — how they run code
- Persistence — how they stay in
- Privilege Escalation — how they gain more access
- Defense Evasion — how they avoid detection
- Credential Access — how they steal credentials
- Discovery — how they learn about the environment
- Lateral Movement — how they move between containers and nodes
- Collection — how they gather data
- Impact — how they cause damage
Falco is a runtime security tool. It detects at the syscall and kernel event level, and increasingly also at the Kubernetes audit log level. This means its coverage is strong in the execution, privilege escalation, and discovery phases — and weaker in initial access (which often happens at the network or application layer before Falco is involved).
Tactic by tactic
Initial Access
Key techniques: Exploit Public-Facing Application (T1190), Valid Accounts (T1078), Supply Chain Compromise (T1195)
Falco coverage: Limited. Initial access usually happens before a detectable syscall event. The exploit itself, a stolen credential being used at the API level, or a compromised image being pulled — these are hard to detect with Falco alone.
What helps instead: Kubernetes audit log monitoring for unexpected API calls. Image scanning (Trivy) to catch compromised or malicious images before they run. Network-layer tooling for application exploits.
Where Falco picks up: If initial access succeeds and the attacker gains execution inside a container, Falco starts seeing events immediately — especially shell spawns, unexpected process activity, and outbound connections.
Execution
Key techniques: Container Administration Command (T1609), Deploy Container (T1610), Command and Scripting Interpreter (T1059)
Falco coverage: Strong. This is where Falco is most effective.
T1609 — Container Administration Command is directly detectable via the Kubernetes audit log. When someone runs kubectl exec, it appears as a create event on the exec subresource. This is one of the cleanest detections available:
# Audit log rule
verb: create
subresource: exec
namespace: productionT1610 — Deploy Container is detectable when a new workload is created via the API. Watch for pod creation events in sensitive namespaces, especially by service accounts that do not normally create pods.
T1059 — Command and Scripting Interpreter maps directly to Falco’s shell spawn detection. When bash or sh starts inside a container that should not have a shell, that is your signal.
condition: spawned_process and container and
proc.name in (shell_binaries) and
not proc.pname in (shell_binaries)Persistence
Key techniques: Implant Internal Image (T1525), Scheduled Task/Job: Cron (T1053.003)
Falco coverage: Partial.
T1525 — Implant Internal Image involves modifying a container image in a registry. Falco does not monitor registries. This is a supply chain control problem — Trivy and registry admission controllers are better suited here.
T1053.003 — Cron inside a container is detectable if the attacker modifies crontab files or starts a cron process. Falco can watch for writes to /etc/cron* or execution of cron binaries inside containers:
condition: spawned_process and container and
proc.name = cronA more powerful persistence detection is watching for new DaemonSets or CronJobs created via the Kubernetes API — this requires audit log monitoring.
Privilege Escalation
Key techniques: Escape to Host (T1611), Exploitation for Privilege Escalation (T1068)
Falco coverage: Strong for container escape indicators.
T1611 — Escape to Host is one of the most important things to detect in Kubernetes. When a container escapes to the host, it usually involves one of these indicators:
- Process running outside of a container namespace while originating inside one
- Access to host filesystem paths from within a container
- Privileged container becoming active
Falco has built-in macro support for detecting when a container process accesses host paths:
condition: open_write and container and
fd.name startswith /host/Privileged container detection is direct:
condition: container.privileged = true and
not container.image.repository in (known_privileged_images)T1068 — Exploitation for Privilege Escalation is harder — if the exploit is novel, Falco will not recognize it. But the post-exploit behavior (shell spawn, sensitive file access, new network connection) will be visible.
Defense Evasion
Key techniques: Masquerading (T1036), Rootkit (T1014), Indicator Removal (T1070)
Falco coverage: Moderate. Rootkits and sophisticated evasion may bypass Falco, especially if they operate at the kernel level and can interfere with eBPF probes.
T1036 — Masquerading — Falco can detect process names that do not match their binary path, or processes with suspicious name/binary combinations. This requires careful rule writing and knowledge of your normal process tree.
T1070 — Indicator Removal — watch for writes to log directories or deletion of audit artifacts from inside a container:
condition: open_write and container and
fd.name startswith /var/logPractical note: Defense evasion is where detection engineering gets hard. If an attacker is specifically targeting your detection layer, Falco rules based on process name or file path can be bypassed. Layer your detection: network layer, audit logs, and syscall monitoring together reduce the bypass surface.
Credential Access
Key techniques: Credentials from Password Stores (T1555), Unsecured Credentials (T1552), Container API (T1552.007)
Falco coverage: Good for file-based credential access. Audit log is essential for API-based access.
T1552 — Unsecured Credentials maps to reading sensitive files inside a container. Falco ships with sensitive_files macros covering common credential paths:
condition: open_read and container and
fd.name in (sensitive_files)T1552.007 — Container API requires audit log monitoring. When a service account reads a Secret it has no business reading, that shows up in the API audit trail — not in a syscall event.
Combining these two detection layers gives you solid credential access coverage: file reads via Falco, API reads via audit log.
Discovery
Key techniques: Network Service Scanning (T1046), Container and Resource Discovery (T1613)
Falco coverage: Moderate. Network scanning from inside a container is detectable by watching for unusual port sweep patterns. Service discovery via the Kubernetes API is better caught in audit logs.
T1613 — Container and Resource Discovery covers an attacker enumerating pods, services, and nodes. Watch the audit log for list/watch verbs from unusual service accounts:
# Audit log
verb: list
resource: pods/services/nodes
user.username: <unexpected service account>Lateral Movement
Key techniques: Container API (T1609), Taint Shared Content (T1080)
Falco coverage: Indirect. Lateral movement between containers usually involves either API calls (audit log detectable) or network connections (egress monitoring).
The most detectable lateral movement pattern is a container making connections to the Kubernetes API server from a process that should not be doing so. If your application containers do not need to talk to the API server, outbound traffic to the cluster IP on port 443 or 6443 is anomalous.
Impact
Key techniques: Resource Hijacking (T1496), Data Destruction (T1485), Denial of Service (T1498)
Falco coverage: Strong for resource hijacking. Moderate for data destruction.
T1496 — Resource Hijacking (cryptomining) is one of the cleanest detections in Falco. Known miner process names are highly specific and have almost no false positive rate:
condition: spawned_process and container and
proc.name in (crypto_miners)T1485 — Data Destruction is detectable if destruction involves writing to or deleting large numbers of files — watch for mass delete operations from container processes.
The coverage map
Here is a simplified view of where Falco provides coverage, where audit logs are needed, and where neither fully covers you:
| Tactic | Falco (syscall) | K8s Audit Log | Gap |
|---|---|---|---|
| Initial Access | Minimal | Partial | Network/app layer |
| Execution | Strong | Strong | — |
| Persistence | Partial | Partial | Registry layer |
| Privilege Escalation | Strong | Partial | Novel exploits |
| Defense Evasion | Moderate | Moderate | Kernel-level evasion |
| Credential Access | Strong | Strong | — |
| Discovery | Moderate | Strong | — |
| Lateral Movement | Indirect | Strong | — |
| Impact | Strong | Partial | — |
What this means for your detection program
A detection program built only on Falco syscall rules covers roughly half of the ATT&CK Containers matrix well. Adding Kubernetes audit log monitoring fills in most of the credential access, discovery, and lateral movement gaps. The remaining gap — initial access, supply chain, and registry-level attacks — requires a different layer: image scanning, admission control, and network policy.
This is why we structure the detection starter pack around both Falco rules and audit log detections. Neither layer alone gives you the coverage you need.
If you are mapping your current detection rules to this matrix and finding large gaps, the most common starting point is: enable Kubernetes audit logging with a focused audit policy, and add five to ten Falco rules targeting the execution and privilege escalation columns. That gets most lean teams to reasonable coverage quickly.
ClarifyIntel maps detection content to MITRE ATT&CK Containers and builds Falco detection packs for Kubernetes teams. If you want to understand your current coverage gaps, start with a note.