From c349c8eca7519ed073cd7f0758a26d5591f359a9 Mon Sep 17 00:00:00 2001 From: Ruben Groenewoud <78494512+Aegrah@users.noreply.github.com> Date: Mon, 23 Feb 2026 16:33:17 +0100 Subject: [PATCH] [New Rules] Kernel Discovery & BPF Load/Tampering via bpftool (#5743) * [New Rules] BPF Load & Tampering via bpftool * Update persistence_bpf_program_or_map_load.toml * [New Rule] Kernel Instrumentation Discovery via kprobes and tracefs * Update defense_evasion_bpf_program_tampering.toml * Update persistence_bpf_program_or_map_load.toml * Enhance note with investigation and response details Added detailed investigation guide and response steps for kernel instrumentation discovery via kprobes and tracefs. --- ...defense_evasion_bpf_program_tampering.toml | 110 ++++++++++++++++ ...ion_discovery_via_kprobes_and_tracefs.toml | 111 ++++++++++++++++ .../persistence_bpf_program_or_map_load.toml | 120 ++++++++++++++++++ 3 files changed, 341 insertions(+) create mode 100644 rules/linux/defense_evasion_bpf_program_tampering.toml create mode 100644 rules/linux/discovery_kernel_instrumentation_discovery_via_kprobes_and_tracefs.toml create mode 100644 rules/linux/persistence_bpf_program_or_map_load.toml diff --git a/rules/linux/defense_evasion_bpf_program_tampering.toml b/rules/linux/defense_evasion_bpf_program_tampering.toml new file mode 100644 index 000000000..f23dcdf26 --- /dev/null +++ b/rules/linux/defense_evasion_bpf_program_tampering.toml @@ -0,0 +1,110 @@ +[metadata] +creation_date = "2026/02/20" +integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"] +maturity = "production" +updated_date = "2026/02/20" + +[rule] +author = ["Elastic"] +description = """ +Detects execution of bpftool commands used to detach eBPF programs or links, or to delete or modify eBPF maps. These +actions can disable, alter, or interfere with kernel-level instrumentation and enforcement mechanisms implemented +through eBPF. In environments relying on eBPF-based networking, observability, or security controls, unexpected +use of these operations may indicate defense evasion or runtime tampering. +""" +from = "now-9m" +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*", +] +language = "eql" +license = "Elastic License v2" +name = "BPF Program Tampering via bpftool" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating BPF Program Tampering via bpftool + +This rule detects bpftool executions that detach eBPF programs/links or delete/update eBPF maps, actions that can silently disable kernel-level visibility and enforcement built on eBPF. Attackers use these operations to evade detection or weaken runtime controls by removing loaded probes or rewriting map contents that drive policy decisions. A common pattern is running bpftool to detach a program from a hook or detach a link shortly before other suspicious activity. + +### Possible investigation steps + +- Pull the full bpftool command line and correlate it with the invoking user, session (TTY/SSH), parent process chain, and any preceding privilege escalation to determine whether it was interactive admin work or automated tampering. +- Capture current eBPF state (`bpftool prog show`, `bpftool link show`, `bpftool map show -j`) and compare with recent snapshots/logs to identify which program/link/map changed and what controls (sensor, CNI, LSM, XDP/TC) may have been impacted. +- Identify the affected attachment point by mapping the detached program/link ID to its hook (e.g., tc/xdp/cgroup/tracepoint/kprobe) and validate operational impact by checking for missing telemetry, policy gaps, or network behavior changes around the event time. +- Review audit/system logs and package history for installation or recent execution of bpftool, kernel/debug tooling, or custom eBPF loaders, and look for nearby suspicious binaries/scripts that could be orchestrating repeated detach/update actions. +- If malicious activity is suspected, preserve artifacts by exporting bpftool JSON output and relevant `/sys/fs/bpf` entries, then hunt for follow-on persistence or rootkit-like behavior (new eBPF loads, altered maps, hidden processes, unexpected kernel module activity) on the host. + +### False positive analysis + +- A system administrator or SRE running bpftool during incident response or troubleshooting may detach a program/link or update/delete a map to temporarily disable an eBPF hook and validate whether it is causing network drops, performance regressions, or incorrect enforcement. +- A maintenance workflow during kernel, CNI, or eBPF policy rollouts may use bpftool to detach and replace existing attachments or refresh map entries as part of a controlled upgrade/rollback, especially when reloading pinned objects under `/sys/fs/bpf`. + +### Response and remediation + +- Contain by isolating the host from the network or restricting outbound access while preserving access for forensics if bpftool detach/map operations are unexpected or coincide with loss of eBPF-based enforcement/telemetry. +- Eradicate by stopping and removing the controlling process/script (inspect the bpftool parent chain and cron/systemd units), revoking the initiating account’s sudo/root access, and deleting any unauthorized pinned objects under `/sys/fs/bpf` after exporting them for evidence. +- Recover by reloading the approved eBPF components (agent/CNI/LSM/XDP/TC) from trusted packages or images, reattaching required programs/links, and restoring known-good map contents from backups or redeploying policy to repopulate maps. +- Escalate to incident response and platform owners immediately if repeated bpftool tampering persists after containment, you find unknown pinned maps/programs with suspicious names/owners, or multiple hosts show simultaneous detach/update activity. +- Harden by limiting bpftool availability (remove from production images where not needed), enforcing least-privilege on CAP_BPF/CAP_SYS_ADMIN and sudoers, and adding immutable monitoring of `/usr/sbin/bpftool` and `/sys/fs/bpf` plus periodic snapshots of `bpftool prog/link/map show` for drift detection.""" +references = [ + "https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html", + "https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html", + "https://man.archlinux.org/man/bpftool-link.8.en", +] +risk_score = 47 +rule_id = "1b65429e-bd92-44c0-aff8-e8065869d860" +severity = "medium" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Defense Evasion", + "Threat: Rootkit", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "bpftool" and ( + (process.args == "prog" and process.args == "detach") or + (process.args == "map" and process.args in ("delete", "update")) or + (process.args == "link" and process.args == "detach") +) +''' + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1562" +name = "Impair Defenses" +reference = "https://attack.mitre.org/techniques/T1562/" + +[[rule.threat.technique.subtechnique]] +id = "T1562.001" +name = "Disable or Modify Tools" +reference = "https://attack.mitre.org/techniques/T1562/001/" + +[[rule.threat.technique]] +id = "T1014" +name = "Rootkit" +reference = "https://attack.mitre.org/techniques/T1014/" + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" diff --git a/rules/linux/discovery_kernel_instrumentation_discovery_via_kprobes_and_tracefs.toml b/rules/linux/discovery_kernel_instrumentation_discovery_via_kprobes_and_tracefs.toml new file mode 100644 index 000000000..401470b34 --- /dev/null +++ b/rules/linux/discovery_kernel_instrumentation_discovery_via_kprobes_and_tracefs.toml @@ -0,0 +1,111 @@ +[metadata] +creation_date = "2026/02/20" +integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"] +maturity = "production" +updated_date = "2026/02/20" + +[rule] +author = ["Elastic"] +description = """ +Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate +discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare +for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting, +performance analysis, or observability tooling validation. +""" +from = "now-9m" +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*", +] +language = "eql" +license = "Elastic License v2" +name = "Kernel Instrumentation Discovery via kprobes and tracefs" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Kernel Instrumentation Discovery via kprobes and tracefs + +This rule detects common Linux utilities and shells reading kprobes and tracing locations under debugfs/tracefs, signaling discovery of kernel instrumentation hooks. Attackers use this to understand which kprobe/tracepoint interfaces are available or already in use before deploying eBPF-based collection or stealthy monitoring. A typical pattern is a script that iterates tracing directories and reads kprobe and tracepoint listings to map callable probes and active tracing state. + +### Possible investigation steps + +- Review the full command line and the specific tracefs/debugfs paths accessed to determine whether this was benign directory enumeration or targeted inspection of sensitive files like `available_filter_functions`, `kprobe_events`, `set_ftrace_filter`, or `trace_pipe`. +- Identify the initiating user and process tree, then search nearby activity for follow-on steps such as writing to `kprobe_events`/`uprobe_events`, enabling tracing events, or sustained reads from `trace_pipe`. +- Validate whether `debugfs`/`tracefs` are mounted and assess the host’s role and installed observability/performance tooling to quickly separate routine diagnostics from unexpected tracing access. +- Hunt for adjacent signals of kernel instrumentation setup or abuse, including use of eBPF tooling (`bpftool`, `bpftrace`, BCC), `perf`, suspicious `bpf()` syscall activity, or module loading around the same time window. +- Compare current tracing configuration and recent file modification activity under `/sys/kernel/debug/tracing` and `/sys/kernel/tracing` against baseline expectations to detect tampering or persistence. + +### False positive analysis + +- A system administrator or automated diagnostic script may use basic utilities like `cat`, `grep`, or `find` to enumerate `/sys/kernel/debug/tracing` or `/sys/kernel/tracing` during kernel troubleshooting or performance triage to confirm tracefs/debugfs is mounted and to review available functions/events. +- Routine validation of tracing configuration after kernel upgrades or configuration changes can involve shells running `ls`, `stat`, or `readlink` over kprobe and tracing paths to verify current settings and permissions, even when no malicious instrumentation is intended. + +### Response and remediation + +- Contain suspected abuse by isolating the host and immediately stopping the offending script/process tree that is enumerating `/sys/kernel/debug/kprobes/*` or `/sys/kernel/*tracing/*`, then preserve the shell history and the script/binary on disk for analysis. +- Eradicate kernel instrumentation changes by checking for and removing any attacker-added entries in `kprobe_events`/`uprobe_events`, disabling any enabled tracing knobs, and remounting or unmounting `debugfs`/`tracefs` if they are not required for operations. +- Recover to a known-good state by rebooting to clear transient tracing state, validating that `trace_pipe` is not being read continuously, and confirming that expected observability tooling (if any) still functions after tracing is reset. +- Escalate to incident response immediately if you observe writes to `kprobe_events`/`uprobe_events`, sustained reads from `trace_pipe`, or nearby execution of eBPF/performance tooling (e.g., `bpftool`, `bpftrace`, `perf`) by an unexpected user or from an unusual parent process. +- Harden to prevent recurrence by restricting access to `debugfs`/`tracefs` to administrators only, disabling unprivileged BPF where feasible, and enforcing MAC policies (SELinux/AppArmor) to deny non-approved processes from reading or writing tracing interfaces.""" +risk_score = 21 +rule_id = "fb542346-1624-4cf2-bcc7-c68abaab261b" +severity = "low" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Discovery", + "Tactic: Defense Evasion", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name in ( + "cat", "grep", "head", "tail", "ls", + "less", "more", + "awk", "sed", "cut", "tr", "xargs", "tee", + "find", "stat", "readlink", + "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox" +) and +process.args like ("/sys/kernel/debug/kprobes/*", "/sys/kernel/debug/tracing/*", "/sys/kernel/tracing/*") +''' + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1082" +name = "System Information Discovery" +reference = "https://attack.mitre.org/techniques/T1082/" + +[rule.threat.tactic] +id = "TA0007" +name = "Discovery" +reference = "https://attack.mitre.org/tactics/TA0007/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1014" +name = "Rootkit" +reference = "https://attack.mitre.org/techniques/T1014/" + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/" diff --git a/rules/linux/persistence_bpf_program_or_map_load.toml b/rules/linux/persistence_bpf_program_or_map_load.toml new file mode 100644 index 000000000..af4757fbc --- /dev/null +++ b/rules/linux/persistence_bpf_program_or_map_load.toml @@ -0,0 +1,120 @@ +[metadata] +creation_date = "2026/02/20" +integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"] +maturity = "production" +updated_date = "2026/02/20" + +[rule] +author = ["Elastic"] +description = """ +Detects execution of bpftool commands used to load, attach, run, or pin eBPF programs, as well as create or update +eBPF maps and links. These operations interact directly with the Linux eBPF subsystem and can modify kernel-level +behavior. While commonly used by legitimate networking or observability tooling, unexpected or interactive usage +may indicate eBPF-based rootkit activity, policy tampering, or unauthorized kernel instrumentation. +""" +from = "now-9m" +index = [ + "auditbeat-*", + "endgame-*", + "logs-auditd_manager.auditd-*", + "logs-endpoint.events.process*", + "logs-sentinel_one_cloud_funnel.*", + "logs-crowdstrike.fdr*", +] +language = "eql" +license = "Elastic License v2" +name = "BPF Program or Map Load via bpftool" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating BPF Program or Map Load via bpftool + +This rule flags bpftool executions that load, attach, run, or pin eBPF programs and that create or pin maps/links, actions that can change kernel behavior without traditional user-space artifacts. Adversaries can use bpftool to load a malicious eBPF object, attach it to a tracepoint or traffic control hook, and pin the program and maps in bpffs so it persists and hides or filters activity across reboots. + +### Possible investigation steps + +- Capture full command line, parent process, user context, TTY/session, and current working directory to determine whether execution was interactive administration or automated tooling. +- Enumerate loaded and pinned eBPF artifacts and their attachment points using `bpftool prog show`, `bpftool map show`, `bpftool link show`, and a filesystem review of `/sys/fs/bpf` to identify unexpected persistence. +- Identify the eBPF object/source used for the load (path, inode, hash, package origin) and retrieve a copy for analysis, including checking for recent writes or downloads in the same directory tree. +- Correlate the event time with system logs and other telemetry for follow-on activity such as privilege escalation, module loads, network filtering changes, or suspicious process hiding indicators. +- Hunt for persistence mechanisms that would reload the same eBPF program after reboot (systemd units/timers, cron, init scripts, container entrypoints) and validate against known legitimate observability/network stacks in the environment. + +### False positive analysis + +- A system administrator or SRE may run `bpftool prog load/attach/pin` or `bpftool map create/pin` during planned troubleshooting or performance investigation to temporarily instrument kernel events and persist objects under `/sys/fs/bpf` for multi-step validation. +- A legitimate system service or boot-time automation may invoke `bpftool` to load and pin eBPF programs/maps as part of expected networking, security policy enforcement, or observability initialization, especially after upgrades or configuration changes that trigger reloading. + +### Response and remediation + +- Immediately isolate the host or container from the network and stop the initiating service/session, then detach any active hooks by removing pinned artifacts under `/sys/fs/bpf` and verifying with `bpftool prog show` and `bpftool link show` that the suspicious program/link is no longer attached. +- Preserve evidence by collecting the full `bpftool` command line and parent chain, a recursive copy of `/sys/fs/bpf`, and the exact eBPF object file used for the load (path, hash, permissions, timestamps) before deleting or modifying artifacts. +- Eradicate persistence by removing malicious eBPF pins, deleting or quarantining the associated `.o`/loader binaries, and disabling the boot-time mechanism that reloads them (systemd unit/timer, cron, init scripts, container entrypoint) followed by a controlled reboot to clear any remaining in-kernel state. +- Recover by restoring the system to a known-good configuration, validating expected networking/observability behavior, and monitoring that no new pinned programs/maps/links reappear under `/sys/fs/bpf` after reboot or service restarts. +- Escalate to incident response and kernel/rootkit specialists if the program attaches to security-relevant hooks (e.g., tracepoints/kprobes/LSM/tc) or if pinned objects reappear after removal, indicating an active persistence mechanism or compromised privileged runtime. +- Harden by restricting `bpftool` availability and access to bpffs, enforcing least-privilege for CAP_BPF/CAP_SYS_ADMIN, requiring signed/managed eBPF loaders, and enabling controls that limit eBPF usage to approved components in production images and hosts.""" +references = [ + "https://manpages.ubuntu.com/manpages/jammy/man8/bpftool-prog.8.html", + "https://manpages.ubuntu.com/manpages/noble/man8/bpftool-map.8.html", + "https://man.archlinux.org/man/bpftool-link.8.en", +] +risk_score = 47 +rule_id = "2d05fefd-40ba-43ae-af0c-3c25e86b54f1" +severity = "medium" +tags = [ + "Domain: Endpoint", + "OS: Linux", + "Use Case: Threat Detection", + "Tactic: Persistence", + "Tactic: Defense Evasion", + "Threat: Rootkit", + "Data Source: Elastic Endgame", + "Data Source: Elastic Defend", + "Data Source: Auditd Manager", + "Data Source: SentinelOne", + "Data Source: Crowdstrike", + "Resources: Investigation Guide", +] +timestamp_override = "event.ingested" +type = "eql" +query = ''' +process where host.os.type == "linux" and event.type == "start" and +event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and +process.name == "bpftool" and ( + (process.args == "prog" and process.args in ("load", "loadall", "attach", "run", "pin")) or + (process.args == "map" and process.args in ("create", "pin")) or + (process.args == "link" and process.args == "pin") +) +''' + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1547" +name = "Boot or Logon Autostart Execution" +reference = "https://attack.mitre.org/techniques/T1547/" + +[[rule.threat.technique.subtechnique]] +id = "T1547.006" +name = "Kernel Modules and Extensions" +reference = "https://attack.mitre.org/techniques/T1547/006/" + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + +[[rule.threat]] +framework = "MITRE ATT&CK" + +[[rule.threat.technique]] +id = "T1014" +name = "Rootkit" +reference = "https://attack.mitre.org/techniques/T1014/" + +[rule.threat.tactic] +id = "TA0005" +name = "Defense Evasion" +reference = "https://attack.mitre.org/tactics/TA0005/"