9 Min. Read Time<\/p>\n
Attackers were inside German Kubernetes clusters longer in 2025 than the DACH CISO median wants to admit. Sysdig’s Threat Report 2026 documented that the average dwell time of a container intruder is 196 hours, while Mandiant’s M-Trends Report puts it at 21 days. The gap between cluster reality and EDR visibility is wide and structural. Classic endpoint detection works at the host level and often misses most relevant activities in a container. With eBPF and the open-source tools Falco and Tetragon built on top of it, this gap closes in 2026. Black Hat USA 2026 has elevated eBPF to an official track, shaping the detection engineering market for the next twelve months.<\/strong><\/p>\n Related<\/span>Detection Engineering Without Vendor Lock<\/a> \/<\/span> Self-Replication: AI Agents<\/a><\/p>\n Endpoint detection and response was designed for classic server and workstation setups. An EDR agent runs on the host, monitoring process genealogy, file operations, network connections, and responding to predefined anomalies. In a Kubernetes environment, this model falls short for three reasons.<\/p>\n Firstly: Containers are ephemeral. A pod that lives only 90 seconds leaves behind at best a trail that falls through telemetry sampling in host EDR. Detection logic assumes minute-long processes; reality is seconds. Observing container workloads with host granularity means missing 70 to 80 percent of relevant events.<\/p>\n Secondly: In-memory execution. Modern attacker toolchains for containers use memory-only loaders that never put a file on disk. Classic EDR detection, built on file system events, is conceptually blind here. eBPF, on the other hand, sees the underlying syscalls because they necessarily go through the kernel.<\/p>\n Thirdly: Sidecar and service mesh architectures. If a single pod maintains five containers and seven network connections running internally over mTLS, host EDR sees mostly unclear network packets. The semantic level is missing. eBPF can enrich this telemetry at the workload level because it comes from the kernel before mTLS takes effect.<\/p>\n Both tools rely on eBPF, but differ in focus and maturity. Falco is the older project, CNCF-graduated, provides an established rule library, and integrates smoothly with Prometheus, Loki, and SIEM pipelines. Its strength lies in breadth and maturity: a standard Falco rule set catches between 60 and 80 percent of MITRE ATT&CK-for-Container techniques right out of the box.<\/p>\n Tetragon comes from the Cilium ecosystem, is closely intertwined with the Cilium CNI, and offers two features that Falco does not provide in this depth: firstly, complete process genealogy, i.e., the parent-child lineage of every container activity, and secondly, a real-time enforcement layer. Tetragon can not only detect that a process calls a forbidden syscall but also block the call directly in the kernel.<\/p>\n For 2026, the pragmatic stack for larger DACH cluster operators often looks like this: Falco as a broadly positioned detector with rule library and SIEM integration, Tetragon supplementing process genealogy in particularly sensitive namespaces and selective runtime enforcement. If you only want to deploy one of the two in 2026, start with Falco, as its learning curve is flatter and operator integration is more advanced.<\/p>\n Telemetry Reach 2026<\/p>\n Sysdig Threat Report 2026: 73 percent of container intrusions remained undetected in hosts with pure EDR telemetry, 11 percent in clusters with Falco-based detection. Black Hat USA 2026 features eBPF in the speaker selection with 9 talks – more than ever.<\/strong><\/p>\n<\/div>\n Three example patterns that have measurably increased in DACH clusters in 2026 and can be grasped with eBPF telemetry.<\/p>\n Memfd Loader and Fileless Execution.<\/strong> Attackers create an anonymous memory file descriptor using memfd_create, write code into it, and execute it without disk traces. Falco rule pattern: alert on memfd_create followed by execveat within the same process group in a productive namespace. Host EDR sees no file here, eBPF sees the two syscalls.<\/p>\n Container Escape via cap_sys_admin Privilege Escalation.<\/strong> Classic escape pattern that reappears more frequently in honeypot logs in 2025\/2026. Tetragon tracing policy alert on capability change within a container that does not start in the privileged namespace. Host EDR sees the container only as a generic process of the container runtime; the privilege shift remains invisible.<\/p>\n eBPF-Based Rootkits.<\/strong> Attackers load their own eBPF programs that patch syscalls and hide activity from classic tools. Falco plugin ebpf-program-loaded alert on bpf_prog_load in a non-released namespace. Only telemetry from the kernel itself helps here, as the user-space view is manipulated by the rootkit.<\/p>\n Pro Falco<\/p>\n Contra Falco<\/p>\n Pro Tetragon<\/p>\n Contra Tetragon<\/p>\n eBPF Detection Rollout in Four Waves<\/p>\n Week 1 to 4.<\/strong> Falco operator in two pilot clusters (staging, one productive namespace), standard rules enabled, telemetry streamed to Loki and SIEM. Goal: Baseline for alert volume and false-positive rate.<\/p>\n Week 5 to 12.<\/strong> Build custom rule library, use MITRE ATT&CK for Containers as mapping, prioritize top three to five risks (privilege escalation, memfd loader, crypto mining, reverse shell, eBPF program load).<\/p>\n Week 13 to 20.<\/strong> Introduce Tetragon in parallel in the most sensitive namespaces, initially only tracing, no enforcement. Process genealogy as supplement to Falco telemetry in SIEM.<\/p>\n From week 21.<\/strong> Selective Tetragon enforcement for clearly defined anti-patterns (e.g., fork-exec from an init container, capability escalation in workload namespace). Careful change control with workload owners.<\/p>\n<\/div>\n It’s crucial to approach the rollout not as a tool introduction, but as a detection engineering program. An eBPF-based pipeline without documented rules, without CI tests for detection logic, and without alert triage routine in SOC layers produces data without impact. Those who want to seriously deploy Falco and Tetragon plan for 2026 with two to three FTE detection engineering, which cannot be absorbed by normal SOC day-to-day business.<\/p>\n Three open issues accompany the eBPF trend in 2026 and should be reflected in every concept. First: kernel version drift. eBPF programs are closely tied to the kernel interface, which can change between kernel versions. Those relying on long-lived worker nodes must take CO-RE (Compile Once, Run Everywhere) seriously, otherwise, every kernel update will break the detection pipeline.<\/p>\n Second: performance overhead in dense clusters. Falco with moderate rules costs between 1 and 3 percent of worker CPU under normal load, but can be significantly higher in dense multi-tenant clusters. Careful rule performance profiles and targeted filters are mandatory in 2026, otherwise, FinOps discussions will start that jeopardize the program.<\/p>\n Third: cloud-managed Kubernetes with lockdown lifecycles. AWS EKS, GKE, and AKS now allow eBPF programs, but with different restrictions. Those operating multi-cloud K8s must build a consistent detection strategy across platforms, not for each cluster separately.<\/p>\n No. Classical EDR remains relevant for host-level and worker node compromise. eBPF-based tools close the container visibility gap and extend the stack. A modern cluster detection in 2026 combines EDR on worker level with Falco or Tetragon on pod level and with network detection on mesh level.<\/p>\n With moderate rules, the CPU overhead per worker node typically ranges between 1 and 3 percent. In dense multi-tenant clusters with aggressive rules, 5 to 8 percent can occur. Those actively maintaining rule performance profiles keep the overhead in the single-digit percentage range.<\/p>\n Realistically, two to four weeks for Falco until productive rule maintenance, four to eight weeks for Tetragon. More important than tool expertise is detection engineering practice: MITRE ATT&CK mapping, CI for rules, alert triage loops. Without this practice, eBPF remains an expensive telemetry source.<\/p>\n In large clusters with twenty or more worker nodes and several sensitive namespaces, parallel operation is worthwhile. Falco provides broad coverage and SIEM connection, Tetragon deepens process genealogy and delivers enforcement. In smaller setups, Falco alone usually suffices.<\/p>\n Positively. NIS2 obliged parties must demonstrate detection and response capabilities. eBPF-based telemetry significantly improves audit trail quality because kernel syscalls are the most reliable source for forensics. Those upgrading their NIS2 set in 2026 should include eBPF coverage as an argument.<\/p>\n More from the MBF Media Network<\/p>\n cloudmagazin<\/span>Multi-Cluster without New Ops Silo: What Teams Solve Wrongly<\/a><\/p>\n MyBusinessFuture<\/span>Cloud Costs are a Matter for Top Management: When CFO and CIO No Longer Calculate Side by Side<\/a><\/p>\nKey Takeaways<\/h2>\n
\n
Why Classic EDR Isn’t Enough in the Cluster<\/h2>\n
How Falco and Tetragon work concretely<\/h2>\n
Concrete Detection Examples for In-Memory Threats<\/h2>\n
Pros and Cons of the Two Tools<\/h2>\n
\n
\n
\n
\n
What a Realistic Rollout Looks Like in 2026<\/h2>\n
Where Discipline Wavers in 2026<\/h2>\n
Frequently Asked Questions<\/h2>\n
Does eBPF detection replace classical EDR in the cluster?<\/h3>\n
What is the performance overhead of Falco in production?<\/h3>\n
What learning curve should SOC teams plan for eBPF?<\/h3>\n
Should one deploy Falco and Tetragon simultaneously?<\/h3>\n
How does eBPF change the NIS2 compliance discussion?<\/h3>\n
Editor’s Reading Recommendations<\/h2>\n
\n