TripleCross

TripleCross is a Linux eBPF rootkit that demonstrates the offensive capabilities of the eBPF technology.

TripleCross is inspired by previous implant designs in this area, notably the works of Jeff Dileo at DEFCON 27[^1], Pat Hogan at DEFCON 29[^2], Guillaume Fournier and Sylvain Afchain also at DEFCON 29[^3], and Kris Nóva's Boopkit[^4]. We reuse and extend some of the techniques pioneered by these previous explorations of the offensive capabilities of eBPF technology.

This rootkit was created for my Bachelor's Thesis at UC3M. More details about its design are provided in the thesis document.

Disclaimer

This rookit is purely for educational and academic purposes. The software is provided "as is" and the authors are not responsible for any damage or mishaps that may occur during its use.

Do not attempt to use TripleCross to violate the law. Misuse of the provided software and information may result in criminal charges.

Contents

1. Features
2. TripleCross overview
3. Build and install
4. Library injection module
5. Backdoor and C2
6. Execution hijacking module
7. Rootkit persistence
8. Rootkit stealth
9. License

Features

1. A library injection module to execute malicious code by writing at a process' virtual memory.
2. An execution hijacking module that modifies data passed to the kernel to execute malicious programs.
3. A local privilege escalation module that allows for running malicious programs with root privileges.
4. A backdoor with C2 capabilities that can monitor the network and execute commands sent from a remote rootkit client. It incorporates multiple activation triggers so that these actions are transmitted stealthily.
5. A rootkit client that allows an attacker to establish 3 different types of shell-like connections to send commands and actions that control the rootkit state remotely.
6. A persistence module that ensures the rootkit remains installed maintaining full privileges even after a reboot event.
7. A stealth module that hides rootkit-related files and directories from the user.

[^1]: J. Dileo. Evil eBPF: Practical Abuses of an In-Kernel Bytecode Runtime. DEFCON 27. slides [^2]: P. Hogan. Warping Reality: Creating and Countering the Next Generation of Linux Rootkits using eBPF. DEFCON 27. presentation [^3]: G. Fournier and S. Afchain. eBPF, I thought we were friends! DEFCON 29. slides [^4]: Kris Nóva. Boopkit. github

TripleCross overview

The following figure shows the architecture of TripleCross and its modules.

<img src="docs/images/rootkit.png" float="left">

The raw sockets library RawTCP_Lib used for rootkit transmissions is of my authorship and has its own repository.

The following table describes the main source code files and directories to ease its navigation: | DIRECTORY | COMMAND | | ------------- | ------------- | | docs | Original thesis document | | src/client | Source code of the rootkit client | | src/client/lib | RawTCP_Lib shared library | | src/common | Constants and configuration for the rootkit. It also includes the implementation of elements common to the eBPF and user space side of the rootkit, such as the ring buffer | | src/ebpf | Source code of the eBPF programs used by the rootkit | | src/helpers | Includes programs for testing the functionality of several rootkit modules, and also the malicious program and library used at the execution hijacking and library injection modules, respectively | | src/libbpf | Contains the libbpf library integrated with the rootkit| | src/user | Source code of the userland programs used by the rootkits| | src/vmlinux | Headers containing the definition of kernel data structures (this is the recommended method when using libbpf) |

Build and Install

Requirements

This research project has been tested under the following environments: || DISTRIBUTION | KERNEL | GCC | CLANG | GLIBC | | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | VERSION | Ubuntu 21.04 | 5.11.0 | 10.3.0 | 12.0.0 | 2.33 |

We recommend using Ubuntu 21.04, which by default will incorporate the software versions shown here. Otherwise, some of the problems you may run into are described here.

Compilation

The rootkit source code is compiled using two Makefiles.

# Build rootkit
cd src
make all
# Build rootkit client
cd client
make

The following table describes the purpose of each Makefile in detail:

| MAKEFILE | COMMAND | DESCRIPTION | RESULTING FILES | | ------------- | ------------- | ------------- | ------------- | | src/client/Makefile | make | Compilation of the rootkit client | src/client/injector | | src/Makefile | make help | Compilation of programs for testing rootkit capabilities, and the malicious program and library of the execution hijacking and library injection modules, respectively | src/helpers/simple_timer, src/helpers/simple_open, src/helpers/simple_execve, src/helpers/lib_injection.so, src/helpers/execve_hijack | | src/Makefile | make kit | Compilation of the rootkit using the libbpf library | src/bin/kit | | src/Makefile | make tckit | Compilation of the rootkit TC egress program | src/bin/tc.o |

Installation

Once the rootkit files are generated under src/bin/, the tc.o and kit programs must be loaded in order. In the following example, the rootkit backdoor will operate in the network interface enp0s3:

// TC egress program
sudo tc qdisc add dev enp0s3 clsact
sudo tc filter add dev enp0s3 egress bpf direct-action obj bin/tc.o sec classifier/egress
// Libbpf-powered rootkit
sudo ./bin/kit -t enp0s3

Attack scenario scripts

There are two scripts, packager.sh and deployer.sh, that compile and install the rootkit automatically, just as an attacker would do in a real attack scenario.

• Executing packager.sh will generate all rootkit files under the apps/ directory.

• Executing deployer.sh will install the rootkit and create the persistence files.

These scripts must first be configured with the following parameters for the proper functioning of the persistence module: | SCRIPT | CONSTANT | DESCRIPTION | | ------------- | ------------- | ------------- | | src/helpers/deployer.sh | CRON_PERSIST | Cron job to execute after reboot | | src/helpers/deployer.sh | SUDO_PERSIST | Sudo entry to grant password-less privileges |

Library injection module

The rootkit can hijack the execution of processes that call the sys_timerfd_settime or sys_openat system calls. This is achieved by overwriting the Global Offset Table (GOT) section at the virtual memory of the process making the call. This leads to a malicious library (src/helpers/injection_lib.c) being executed. The library will spawn a reverse shell to the attacker machine, and then returns the flow of execution to the original function without crashing the process.

TripleCross is prepared to bypass common ELF hardening techniques, including:

• ASLR
• Stack canaries
• DEP/NX
• PIE
• Full RELRO

It is also prepared to work with Intel CET-compatible code.

The module functionality can be checked using two test programs src/helpers/simple_timer.c and src/helpers/simple_open.c. Alternatively you may attempt to hijack any system process (tested and working with systemd).

The module configuration is set via the following constants:

| FILENAME | CONSTANT | DESCRIPTION | | ------------- | ------------- | ------------- | | src/common/constants.h | TASK_COMM_NAME_INJECTION_<br>TARGET_TIMERFD_SETTIME | Name of the process to hijack at syscall sys_timerfd_settime | | src/common/constants.h | TASK_COMM_NAME_INJECTION_<br>TARGET_OPEN | Name of the process to hijack at syscall sys_openat | | src/helpers/injection_lib.c| ATTACKER_IP & ATTACKER_PORT| IP address and port of the attacker machine|

Receiving a reverse shell from the attacker machine can be done with netcat:

nc -nlvp <ATTACKER_PORT>

Library injection via GOT hijacking technique

The technique incorporated in TripleCross consists of 5 stages:

Locating GOT and the return address

The rootkit hooks the system call using a tracepoint program. From there, it locates the address at the GOT section which the PLT stub used to make the call to the glibc function responsible of the syscall.

In order to reach the GOT section, the eBPF program uses the return address stored at the stack. Note that:

• The .text makes a call to the .plt, so rip is saved as ret in the stack.
• The .plt makes a jump to glibc using .got, so no other rip is saved. It also does not modify or save the value of rbp.
• Glibc makes a syscall, which does not save rip in the stack, but rather saves it in rcx.

<img src="docs/images/plt_got_glibc_flow.jpg" float="left">

Therefore in order to check from eBPF that an address in