This post is part of a series about Offensive BPF that I’m working on to learn how BPFs use will impact offensive security, malware and detection engineering.
Click the “ebpf” tag to see all relevant posts.
In the last few posts, we talked about a
bpftrace and how attackers can use it to their advantage. This post is about my initial ideas and strategies to detecting malicious usage.
Detecting BPF misuse
There are a set of detection ideas for Blue Teams. Since we primarily talked about
bpftrace so far, let’s explore that angle.
There will be more recommendations down the road as I learn and understand BPF better.
Collecting telemetry around BPF syscalls is a crucial to getting insights into its usage across the fleet. Make sure that whatever tool or product you are using does collect the proper information and that it is centrally available in your threat detection pipeline.
Inspecting loaded BPF programs
Loaded BPF programs can be inspected via the
bpftool prog will show you the details and you can see the loaded programs:
With the BPF tools also comes
bpflist, which lists all user space programs currently running BPF:
Collecting this information will allow to build an inventory on what BPF running, and if there are any unexpected outliers.
One challenge remaining for defenders is that if a malicous BPF program starts running before log collection or detection tools run, then a BPF program can install itself as a rootkit to evade detections. Be aware of that.
Unsafe bpftrace usage and system() calls
The usage of a
system() call seems very unusual. So, looking for command line logs that contain
bpftrace --unsafe seems a good way to catch dangerous bpf programs also.
BPF programs don’t survive a reboot, so an adversary will try to restart them (cron jobs, etc..). Be on the lookout.
Supply chain attack or tampering with valid BPF programs
There is also the attack avenue to backdoor existing programs that performance teams use or that are executed regularly on hosts.
I haven’t seen any signature validation approaches yet, which could help detect such changes. Which brings us to the next point of the idea of having an inventory of known good BPF programs.
Creating an inventory of known BPF programs
Creating and maintaining and inventory of valid BPF programs of your environments seems a good strategy. This allows catching unknown ones to investigate.
Perform a Red Team Exercise using the BPF TTP
Assume Breach operations can help identify detection and prevention opportunities in your environments. Hence, I’d recommend performing a red or purple team operation that emulates usage of malicious BPF programs.
Hooking the BPF system call itself!
A nifty attacker will likely hook the
bpf() system call itself to change blue teams reality.
Performing static analysis on BPF programs can help identify such programs, as can monitoring all calls to the
bpf system call dynamically.
Investigate and leverage existing BPF malware detection kits
There has not been a lot of work in this regard, but there are two projects I want to look at more closely when it comes to detections:
- https://github.com/pathtofile/bpf-hookdetect (might not be just about eBPF, but general kernel rootkits)
Hope this post is helpful to provide more practical and technical perspective on what defenders need to start looking for.
I’m still pretty new to BPF, but the possibilities for attack seem to be limited by creativity, hence I think BPF malware will be quite common in the not-so-distant future, so let’s get a step ahead with testing and building detections.