How should security teams detect malicious eBPF activity without relying only on user-space monitoring?

Security teams should correlate eBPF program load events with the kernel or user-space probe that triggered them. That context shows what the program is attached to, whether it is a tracepoint, kprobe, uprobe, or return probe, and what symbol it targets. Without that linkage, a malicious program can look like routine instrumentation and evade user-space only detection.

Why kernel context matters more than user-space alerts for eBPF detection

Malicious eBPF activity is hard to judge from user-space telemetry alone because the same load path can be used for legitimate observability, security tooling, or abuse. The detection problem is not just that a program was loaded, it is what kernel object it attached to, which hook type it used, and whether that combination makes sense for the process and host role.

That context turns a generic load event into an intelligible security signal. A tracepoint, kprobe, uprobe, or return probe can each indicate a different collection intent, privilege requirement, and attack surface, so the attachment point is often more meaningful than the process name that initiated the load.

Security teams should therefore treat eBPF detection as a correlation problem between the load event and the kernel or user-space probe target. When that linkage is missing, an operator may see only normal instrumentation noise while the kernel is actually being instrumented in a way that supports covert monitoring, tampering, or persistence.

What a useful eBPF detection signal should include

A defensible detection view should preserve the full relationship between the program and its target. That usually means recording the program type, the attach event, the target symbol or tracepoint, the process that initiated the load, and the runtime context around the host or workload where it appeared.

For investigation, the most useful question is whether the observed attachment matches the system’s expected telemetry posture. A database host, CI runner, or security sensor may legitimately use eBPF in different ways, but the expected hooks, target symbols, and signing or deployment path should be predictable enough to separate approved instrumentation from suspicious behavior.

That is also why detections should avoid treating eBPF as inherently benign. eBPF can support observability, filtering, and performance work, but it can also be used to observe sensitive activity, hide malicious logic in kernel-adjacent code, or make endpoint monitoring blind to the real execution path.

Teams get better results when they baseline attachment patterns by asset class rather than by individual binary name. A security agent, observability daemon, and troubleshooting tool may all load eBPF, but they should not all attach to the same symbols or run with the same scope.

Detection logic should also favor corroboration. If the process is unfamiliar, the hook target is unusual, or the load happens outside the normal maintenance window, the event deserves higher priority even when the loader itself looks trusted. In other words, context should raise or lower confidence, not simply decide whether the event is visible.

Where possible, maintain visibility into both the loading workflow and the attachment outcome. That helps teams distinguish a failed attempt from a successful kernel-level instrumenting action, which is essential when the attacker’s goal is stealth rather than immediate disruption.

Risk and Threat Considerations

eBPF is attractive to attackers because it sits close to the kernel’s execution path while still blending into the kind of tooling many teams already deploy. If defenders only watch user-space processes, a malicious attachment can resemble ordinary observability and evade scrutiny until it is already influencing what the host can see or report.

Failure mechanism: The monitoring stack captures the loader but not the semantic meaning of the attach point, so suspicious hooks, target symbols, and probe types are never compared against expected host behavior.

Impact: Attackers can use that gap to hide telemetry collection, intercept sensitive activity, or sustain stealthy access while appearing to run legitimate instrumentation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find potentially adverse events	eBPF detection depends on monitoring runtime activity and adverse attachment behavior.
	DE.AE-02 — Potentially adverse events are analyzed to better understand attacks and indicators	Correlating load events with probe targets turns raw events into analyzable indicators.
Recommendation — Monitor kernel and host telemetry for suspicious eBPF attachment patterns. Analyze eBPF load-and-attach context to distinguish legitimate instrumentation from abuse.
MITRE ATT&CK	T1620 — Reflective Code Loading	Kernel-adjacent code loading and execution tradecraft can hide malicious functionality behind normal loading paths.
	T1055 — Process Injection	The question centers on covert code placement and execution in a trusted runtime path.
Recommendation — Map suspicious eBPF loading to ATT&CK-style execution and persistence hunting. Hunt for suspicious code placement that changes trusted execution behavior.

Practitioner Guidance

What to prioritise: Correlate every eBPF load with the specific attach target and probe type before deciding whether it is benign. A load event without target context is usually too weak to support a security conclusion on its own.

What to verify: Confirm that the hook type and symbol match the host role, deployment pattern, and approved tooling path. If the same host suddenly attaches to new kernel or user-space targets, treat that as an investigation trigger even when the loader is signed or familiar.

Practitioner takeaway: The key control is not simply seeing eBPF activity, it is preserving enough kernel-level context to explain why that activity exists and whether it fits the system’s normal instrumentation pattern.