Runtime detection in Kubernetes is not about logging everything. It is about knowing which behaviors matter enough to alert on — and having the context to act when they fire.
Most teams start with Falco enabled and the default ruleset running. The default rules are a reasonable starting point, but they produce a lot of noise, and lean teams do not have time to triage 200 events per day. The real work is picking the subset of behaviors that are worth watching closely, tuning them to your environment, and making sure every alert has a clear triage path.
This is our recommended starting list. Ten behaviors. Each one tied to a real threat technique. Each one tuned for low false-positive volume.
How to use this list
For each behavior, we give you:
- What it is — the pattern being detected
- Why it matters — what an attacker or misconfigured workload is doing when this fires
- MITRE ATT&CK Containers technique — the threat framework mapping
- Falco detection logic — the rule kernel or key condition
- False positive note — what legitimate activity triggers this, and how to handle it
These are starting points, not production-ready rules. Every environment is different. Read the false positive notes carefully and tune before you enforce.
1. Shell spawned inside a container
What it is: A shell process (bash, sh, zsh) starts inside a running container.
Why it matters: Containers should not need interactive shells at runtime. When a shell spawns, it usually means someone has exec’d into the container manually, or a vulnerability is being exploited to gain execution.
MITRE technique: T1059 — Command and Scripting Interpreter (Containers)
Falco condition:
condition: spawned_process and container and
proc.name in (shell_binaries) and
not proc.pname in (shell_binaries)False positive note: CI/CD scripts that exec into containers for smoke tests. Add exceptions by container image name or namespace.
2. Sensitive file read inside a container
What it is: A process inside a container reads files like /etc/shadow, /etc/passwd, or files in /root/.ssh/.
Why it matters: Credential access from inside a container. An attacker who has already gained execution will often look for credentials to pivot laterally — to other pods, nodes, or the cloud provider API.
MITRE technique: T1552 — Unsecured Credentials
Falco condition:
condition: open_read and container and
fd.name in (sensitive_files)False positive note: Some base images run health checks that read system files. Review your base images and add image-level exceptions.
3. Write to /etc or binary directories inside a container
What it is: A process inside a container writes to /etc, /bin, /usr/bin, or similar system paths.
Why it matters: Persistence. Modifying system binaries or configuration files at runtime is a classic persistence technique. In a container, it also suggests the image is being modified live — a sign something has gone wrong.
MITRE technique: T1543 — Create or Modify System Process
Falco condition:
condition: open_write and container and
fd.name startswith /etc and
not proc.name in (known_init_processes)False positive note: Containers that generate config files at startup (e.g., rendering secrets into /etc/app/). Scope exceptions to the specific directory and image.
4. Unexpected outbound connection from a container
What it is: A container opens a network connection to an IP or domain outside your expected set.
Why it matters: Command and control. Data exfiltration. Many attacks involve a container reaching out to an attacker-controlled server. If your containers have predictable egress patterns, unexpected outbound connections are high-signal.
MITRE technique: T1071 — Application Layer Protocol
Falco condition:
condition: outbound and container and
not fd.sip in (allowed_outbound_ips) and
not fd.sport in (allowed_outbound_ports)False positive note: This rule requires that you define your expected egress set. Start in audit mode and build the allowed list from observed traffic before enforcing.
5. Container running as root
What it is: A process inside a container runs with UID 0.
Why it matters: Root inside a container is not the same as root on the host, but it dramatically increases blast radius if the container is escaped or misused. This is one of the most common misconfigurations in real clusters.
MITRE technique: T1078 — Valid Accounts (abuse of over-permissioned identity)
Falco condition:
condition: spawned_process and container and
proc.uid = 0 and
not container.image.repository in (known_root_containers)False positive note: Many older images run as root by default. Build an allowlist gradually. This rule is better used as a posture signal than a real-time alert in noisy environments.
6. Kubernetes secrets accessed via the API
What it is: A call to the Kubernetes API server reads a Secret object — logged via audit policy.
Why it matters: Secrets accessed at runtime, especially by service accounts that do not normally need them, can indicate lateral movement or credential harvesting. This is a Kubernetes audit log detection, not a Falco syscall rule.
MITRE technique: T1552.007 — Container API
Detection logic (audit log):
{
"verb": "get",
"resource": "secrets",
"user.username": "<not a known service account>"
}False positive note: Many controllers read secrets legitimately. Focus on service accounts that have no documented reason to read secrets, or on reads of specific high-value secrets.
7. kubectl exec into a running pod
What it is: The exec verb is used against a pod via the Kubernetes API, opening an interactive session.
Why it matters: Exec into a production pod is a high-privilege action that should be rare in a healthy environment. When it happens in production, it often indicates either a developer debugging a live issue or an attacker who has obtained API credentials.
MITRE technique: T1609 — Container Administration Command
Detection logic (audit log):
{
"verb": "create",
"subresource": "exec",
"namespace": "production"
}False positive note: Alert on production namespace execs only. Staging and dev environments will generate significant noise.
8. New privileged container started
What it is: A container starts with securityContext.privileged: true.
Why it matters: Privileged containers have access to the host kernel and devices. A privileged container that should not be privileged is either a misconfiguration or a sign that someone has modified a workload definition to gain host access.
MITRE technique: T1611 — Escape to Host
Falco condition:
condition: container.privileged = true and
not container.image.repository in (known_privileged_images)False positive note: Daemonsets and some node-level agents legitimately need privileged mode. Build a narrow allowlist by image and namespace.
9. Process attempting to modify iptables or network routes
What it is: A container process calls iptables, ip route, or similar network configuration tools.
Why it matters: Containers should not modify host networking. When they do, it is often a sign of a misconfigured CNI plugin, a container escape, or an active attack attempting to intercept traffic.
MITRE technique: T1562.004 — Disable or Modify System Firewall
Falco condition:
condition: spawned_process and container and
proc.name in (network_tool_binaries) and
not container.image.repository in (known_cni_images)False positive note: CNI plugins, service mesh sidecars, and some node agents use these tools. This rule requires careful allowlisting.
10. Cryptominer process signature
What it is: A process name or command line matching known cryptomining tools (xmrig, minerd, cgminer) starts inside a container.
Why it matters: Cryptomining is the most common opportunistic attack against exposed Kubernetes workloads. It is usually the first sign that an attacker has gained execution in your cluster and is using your compute.
MITRE technique: T1496 — Resource Hijacking
Falco condition:
condition: spawned_process and container and
proc.name in (crypto_miners)False positive note: Almost none. This rule has very low false positive rate and should be set to alert immediately.
Building on this list
These ten behaviors are not exhaustive. They are the starting set that gives most teams the best coverage-to-noise ratio before they have a dedicated detection engineering function.
From here, the next layer usually involves:
- Detecting abnormal process trees (unexpected parent-child relationships)
- Monitoring service account token usage patterns
- Detecting image pulls from unexpected registries
- Watching for new cron jobs or DaemonSets created at runtime
Each of these requires more tuning and more context about your environment. The ten above are designed to work with minimal tuning in most Kubernetes setups.
Turning this into something deployable
If you want to turn this list into a working Falco deployment, the steps are:
- Install Falco in your cluster (daemonset or eBPF mode)
- Start with these rules in
warnoutput only — no alerting, just logging - Run for one week and review the output to understand your baseline noise
- Add your environment-specific exceptions
- Enable alerting for the rules that are clean
- Move the noisy rules to a backlog for tuning
This is roughly the process we follow in the Kubernetes Detection Starter Pack. The goal is a detection foundation you can actually maintain — not a rule library that fires constantly and gets ignored.
ClarifyIntel builds detection content and security rollout plans for cloud-native teams. If you want a tuned detection starter pack for your Kubernetes environment, send us a note.