Secnora INC

🕵️ 𝗛𝗼𝘄 𝗲𝗕𝗣𝗙 𝗥𝗼𝗼𝘁𝗸𝗶𝘁𝘀 𝗪𝗼𝗿𝗸 𝗮𝗻𝗱 𝗪𝗵𝘆 𝗧𝗵𝗲𝘆’𝗿𝗲 𝗛𝗮𝗿𝗱 𝘁𝗼 𝗗𝗲𝘁𝗲𝗰𝘁

Imagine a malware that doesn't modify a single system file, doesn't load a traditional kernel module and yet operates with kernel-level privileges while remaining remarkably difficult to detect.

This marks the rise of eBPF rootkits, a sophisticated class of malware leveraging legitimate kernel features for stealth.

As organizations increasingly adopt Extended Berkeley Packet Filter (eBPF) for observability, performance monitoring and security telemetry, attackers are exploring how the same technology can be abused for stealthy post-compromise operations.

⚠️ 𝗛𝗼𝘄 𝗲𝗕𝗣𝗙 𝗥𝗼𝗼𝘁𝗸𝗶𝘁𝘀 𝗪𝗼𝗿𝗸
Traditional Linux rootkits often rely on Loadable Kernel Modules (LKMs) to hook system calls or modify kernel behavior, techniques that can leave detectable traces. eBPF takes a different approach, allowing programs to run within the Linux kernel in response to events such as system calls, network activity and tracepoints without modifying kernel code or loading a conventional kernel module.

🎯 𝗣𝗼𝘁𝗲𝗻𝘁𝗶𝗮𝗹 𝗖𝗮𝗽𝗮𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 𝗼𝗳 𝗠𝗮𝗹𝗶𝗰𝗶𝗼𝘂𝘀 𝗲𝗕𝗣𝗙 𝗣𝗿𝗼𝗴𝗿𝗮𝗺𝘀
In a compromised environment, malicious eBPF programs may be used to:
• Manipulate Data in Real Time: Filter or modify information before it reaches user-space applications, potentially hiding processes, files or network connections.
• Capture Sensitive Information: Observe data as it moves through system workflows, enabling the collection of credentials or other sensitive information.
• Establish Covert Backdoors: Create hidden network triggers that activate malicious functionality only when specific traffic patterns are received.

🔍 𝗪𝗵𝘆 𝗗𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗜𝘀 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗶𝗻𝗴
• Blends with Legitimate Activity: eBPF is widely used for observability and security, making malicious programs harder to distinguish from normal operations.
• Minimal System Footprint: eBPF-based malware can influence kernel behavior without modifying kernel code or system call tables.
• Visibility Gaps: If kernel-level data is altered before reaching user-space, security tools may receive incomplete or misleading telemetry.

🛡️ 𝗗𝗲𝗳𝗲𝗻𝗱𝗶𝗻𝗴 𝗔𝗴𝗮𝗶𝗻𝘀𝘁 𝗲𝗕𝗣𝗙 𝗔𝗯𝘂𝘀𝗲
• Monitor and audit usage of the bpf() system call.
• Regularly inventory loaded eBPF programs using tools such as bpftool.
• Restrict access to capabilities such as CAP_BPF and CAP_SYS_ADMIN.
• Investigate unexpected eBPF program loads, particularly on systems where eBPF is not routinely used.

🔐 As organizations continue to scale cloud-native environments, visibility into and control over kernel-level activity will remain critical to maintaining a strong security posture.

🛡️ August 2, 2026 is the next major enforcement date under the EU AI Act.

Most teams are tracking it for high-risk systems. Fewer realise the same date triggers Article 50 transparency obligations and those apply to any AI system that interacts with people, generates content or uses biometric data, whether or not it's high-risk.

No disclosure when a user talks to your chatbot? Violation.
Emotion recognition with no transparency notice? Violation.

And these breaches aren't a footnote - they sit in the €15M / 3%-of-turnover penalty tier.

This carousel breaks down what Article 50 actually requires, what your team needs in place before August 2 and how existing frameworks like NIST AI RMF already get you part of the way there.

➡️ Swipe through, then check where your organisation actually stands. The deadline isn't the hard part - not knowing what to do is.