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, ortrace_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 fromtrace_pipe. - Validate whether
debugfs/tracefsare 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, suspiciousbpf()syscall activity, or module loading around the same time window. - Compare current tracing configuration and recent file modification activity under
/sys/kernel/debug/tracingand/sys/kernel/tracingagainst baseline expectations to detect tampering or persistence.
False positive analysis
- A system administrator or automated diagnostic script may use basic utilities like
cat,grep, orfindto enumerate/sys/kernel/debug/tracingor/sys/kernel/tracingduring 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, orreadlinkover 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 unmountingdebugfs/tracefsif they are not required for operations. - Recover to a known-good state by rebooting to clear transient tracing state, validating that
trace_pipeis 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 fromtrace_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/tracefsto 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
- BPF Program Tampering via bpftool
- BPF Program or Map Load via bpftool
- Kernel Module Load via Built-in Utility
- Docker Socket Enumeration
- Kubectl Permission Discovery