BPF Memory Forensics with Volatility 3

Introduction and Motivation

Have you ever wondered how an eBPF rootkit looks like? Well, here’s one, have a good look:

Upon receiving a command and control (C2) request, this specimen can execute arbitrary commands on the infected machine, exfiltrate sensitive files, perform passive and active network discovery scans (like nmap), or provide a privilege escalation backdoor to a local shell. Of course, it’s also trying its best to hide itself from system administrators hunting it with different command line tools such as ps, lsof, tcpdump an others or even try tools like rkhunter or chkrootkit.

Intro

This blog post reflects our exploration of the Dirty Pipe Vulnerability in the Linux kernel. The bug was discovered by Max Kellermann and described here . If you haven’t read the original publication yet, we’d suggest that you read it first (maybe also twice ;)). While Kellermann’s post is a great resource that contains all the relevant information to understand the bug, it assumes some familiarity with the Linux kernel. To fully understand what’s going on we’d like to shed some light on specific kernel internals. The aim of this post is to share our knowledge and to provide a resource for other interested individuals. The idea of this post is as follows: We take a small proof-of-concept (PoC) program and divide it into several stages. Each stage issues a system call (or syscall for short), and we will look inside the kernel to understand which actions and state changes occur in response to those calls. For this we use both, the kernel source code (elixir.bootlin.com , version 5.17.9) and a kernel debugging setup (derived from linux-kernel-debugging ). The Dirty Pipe-specific debugging setup and the PoC code is provided in a GitHub repository.