If you've been following Linux security, you know that eBPF is a double-edged sword. It's incredible for observability and networking, but it's also the new favorite playground for Linux rootkits.
Most open-source security rules try to catch eBPF malware when it loads into the kernel (usually by watching bpftool **or the **bpf() syscall). But I noticed a gap in the Elastic Security detection-rules repository: What about when the malware compiles itself?
**
To dodge file hashes and static signatures, many attackers use the "Compile After Delivery" technique (T1027.004). They drop **.c source code onto the server and use the local **clang **toolchain to compile the eBPF object on the fly.
I just submitted a PR to Elastic (closing issue #6562) to detect exactly this behavior!
The Rule Logic The rule uses Event Query Language (EQL) to monitor process executions on Linux hosts. We're specifically looking for **clang **being executed with arguments targeting the BPF backend.
eql
process where host.os.type == "linux" and event.type == "start" and
process.name like "clang*" and (
(process.args == "-target" and process.args like ("bpf", "bpf-*", "bpfel*", "bpfeb*")) or
process.args like ("*-target=bpf*", "*-target=bpfel*", "*-target=bpfeb*")
)
Cool things I learned while writing this:
Attackers have options:
You can't just look for -target bpf. You have to account for little-endian (bpfel), big-endian (bpfeb), full target triples (bpf-unknown-none), and single-token flag variants (--target=bpf).Failed attempts matter:
If a threat actor makes a typo (like -target=bpf with one dash), *clang * will error out. However, Linux **execve **still logs the attempt! Capturing these syntax errors in the query is a great way to catch attackers making mistakes in real-time.Collaboration is awesome:
The original issue author provided an incredible corpus of real-world **clang **execution logs to help me harden the query and remove blind spots. Open-source security collaboration at its finest!
If you're running Elastic Defend or Auditbeat in your environment, look out for this new rule in an upcoming release!
Thanks
Shresth Paul
Top comments (0)