Repository navigation
Add Linux Auditd eBPF Program Load detection (T1556.003, T1003) - #4379
vahidmalekk wants to merge 4 commits into
Conversation
Detects a process loading an eBPF program (bpf BPF_PROG_LOAD) outside known container/runtime and eBPF-agent tooling. Covers eBPF-based credential theft via PAM hooking (e.g. pamspy attaching a uprobe to pam_get_authtok) and stealthy eBPF rootkits. Uses the native kernel BPF audit records (type=BPF + syscall=bpf), so no custom audit rule is required.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bb057b7c6b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| data_source: | ||
| - Linux Auditd Syscall | ||
| search: |- | ||
| `linux_auditd` type=SYSCALL SYSCALL=bpf |
There was a problem hiding this comment.
Require success before reporting a BPF load
When an audit policy also records failed bpf syscalls (for example, an always,exit rule for -S bpf), this predicate accepts every call with a0=5 regardless of success or exit. Verifier failures and EPERM attempts are therefore emitted as risk events whose message says a program was loaded, even though no program was installed; filter for success=yes (or a nonnegative exit value) before aggregating.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch - fixed. Added a success=yes guard to the base search so verifier failures and EPERM attempts (which still emit a SYSCALL record) are no longer reported as successful program loads, and updated how_to_implement to note it. Pushed in 43dfec5.
Adds a new endpoint detection: Linux Auditd eBPF Program Load.
Detects a process loading an eBPF program via the bpf() syscall (BPF_PROG_LOAD) outside known container/runtime and eBPF-agent tooling. Covers eBPF-based credential theft via PAM hooking (e.g. pamspy attaching a uprobe to pam_get_authtok in libpam to capture plaintext passwords during sshd/sudo/su auth) and stealthy eBPF rootkits/backdoors. It is the auditd counterpart to Elastic BPF Program or Map Load via bpftool; there is currently no equivalent eBPF program-load detection in security_content.
Why auditd / no custom rule: the kernel emits a native type=BPF record plus a companion type=SYSCALL (syscall=bpf, a0=BPF_PROG_LOAD) for every program load while auditd runs, so no custom audit syscall rule is required.
Tuning: modeled as type Anomaly because container runtimes (runc, containerd), CNIs (Cilium) and eBPF security/observability agents (Falcon, Tetragon, sysdig, bpftrace) legitimately load eBPF; these are allowlisted via linux_auditd_ebpf_program_load_filter.
Testing: validated against real auditd telemetry generated by running pamspy on an isolated test host. A companion attack_data dataset PR provides the test log referenced in tests.
MITRE ATT&CK: T1556.003 (Pluggable Authentication Modules), T1003 (OS Credential Dumping)