Kernel Instrumentation Discovery via kprobes and tracefs

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/02/20"
  3integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/02/20"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects common utilities accessing kprobes and tracing-related paths in debugfs/tracefs, which may indicate
 11discovery of kernel instrumentation hooks. Adversaries can enumerate these locations to understand or prepare
 12for eBPF, kprobe, or tracepoint-based activity. This behavior can also be benign during troubleshooting,
 13performance analysis, or observability tooling validation.
 14"""
 15from = "now-9m"
 16index = [
 17    "auditbeat-*",
 18    "endgame-*",
 19    "logs-auditd_manager.auditd-*",
 20    "logs-endpoint.events.process*",
 21    "logs-sentinel_one_cloud_funnel.*",
 22    "logs-crowdstrike.fdr*",
 23]
 24language = "eql"
 25license = "Elastic License v2"
 26name = "Kernel Instrumentation Discovery via kprobes and tracefs"
 27note = """## Triage and analysis
 28
 29> **Disclaimer**:
 30> 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.
 31
 32### Investigating Kernel Instrumentation Discovery via kprobes and tracefs
 33
 34This 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.
 35
 36### Possible investigation steps
 37
 38- 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`.  
 39- 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`.  
 40- 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.  
 41- 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.  
 42- 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.
 43
 44### False positive analysis
 45
 46- 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.
 47- 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.
 48
 49### Response and remediation
 50
 51- 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.  
 52- 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.  
 53- 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.  
 54- 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.  
 55- 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."""
 56risk_score = 21
 57rule_id = "fb542346-1624-4cf2-bcc7-c68abaab261b"
 58severity = "low"
 59tags = [
 60    "Domain: Endpoint",
 61    "OS: Linux",
 62    "Use Case: Threat Detection",
 63    "Tactic: Discovery",
 64    "Tactic: Defense Evasion",
 65    "Data Source: Elastic Endgame",
 66    "Data Source: Elastic Defend",
 67    "Data Source: Auditd Manager",
 68    "Data Source: SentinelOne",
 69    "Data Source: Crowdstrike",
 70    "Resources: Investigation Guide",
 71]
 72timestamp_override = "event.ingested"
 73type = "eql"
 74query = '''
 75process where host.os.type == "linux" and event.type == "start" and
 76event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 77process.name in (
 78  "cat", "grep", "head", "tail", "ls",
 79  "less", "more",
 80  "awk", "sed", "cut", "tr", "xargs", "tee",
 81  "find", "stat", "readlink",
 82  "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "busybox"
 83) and
 84process.args like ("/sys/kernel/debug/kprobes/*", "/sys/kernel/debug/tracing/*", "/sys/kernel/tracing/*")
 85'''
 86
 87[[rule.threat]]
 88framework = "MITRE ATT&CK"
 89
 90[[rule.threat.technique]]
 91id = "T1082"
 92name = "System Information Discovery"
 93reference = "https://attack.mitre.org/techniques/T1082/"
 94
 95[rule.threat.tactic]
 96id = "TA0007"
 97name = "Discovery"
 98reference = "https://attack.mitre.org/tactics/TA0007/"
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[[rule.threat.technique]]
104id = "T1014"
105name = "Rootkit"
106reference = "https://attack.mitre.org/techniques/T1014/"
107
108[rule.threat.tactic]
109id = "TA0005"
110name = "Defense Evasion"
111reference = "https://attack.mitre.org/tactics/TA0005/"

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.

Related rules

to-top