TripleCross/README.md

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¹ , Pat Hogan at DEFCON 29² , and Guillaume Fournier and Sylvain Afchain also at DEFCON 29³ . 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 is provided in the thesis document.

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 stealthy.
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.

TripleCross overview

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

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 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 rootkit modules functionality, and 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 user land programs used by the rootkits
src/vmlinux	Headers containing the definition of kernel data structures (this is the recommended method when using libbpf)

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.

Table of Contents

1. Build and Install
2. Library injection module
3. Backdoor and C2
4. Execution hijacking module
5. Rootkit persistence
6. Rootkit stealth

Build and Install

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 functionalities, 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 orderly. 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 exist 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 configurated 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 done by overwriting the value of the .GOT section of the process making the call.

The malicious library (src/helpers/injection_lib.c) will be injected and aftwerwards the flow of execution returns to the original function. The library will spawn a simple reverse shell to which the attacker machine can be listening.

You can check this functionality with 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_ TARGET_TIMERFD_SETTIME	Name of process to hijack at syscall sys_timerfd_settime
src/common/constants.h	TASK_COMM_NAME_INJECTION_ TARGET_OPEN	Name of process to hijack at syscall sys_openat
src/helpers/injection_lib.c	ATTACKER_IP & ATTACKER_PORT	IP address and port of attacker machine

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

nc -nlvp <ATTACKER_PORT>

Backdoor and C2

The backdoor works out of the box without any configuration needed. The backdoor can be controlled remotely using the rootkit client program:

CLIENT ARGUMENTS	ACTION DESCRIPTION
./injector -c <Victim IP>	Spawns a plaintext pseudo-shell by using the execution hijacking module
./injector -e <Victim IP>	Spawns an encrypted pseudo-shell by commanding the backdoor with a pattern-based trigger
./injector -s <Victim IP>	Spawns an encrypted pseudo-shell by commanding the backdoor with a multi-packet trigger (of both types)
./injector -p <Victim IP>	Spawns a phantom shell by commanding the backdoor with a pattern-based trigger
./injector -a <Victim IP>	Orders the rootkit to activate all eBPF programs
./injector -u <Victim IP>	Orders the rootkit to detach all of its eBPF programs
./injector -S <Victim IP>	(Simple PoC) Showcases how the backdoor can hide a message from the kernel
./injector -h	Displays help

Backdoor triggers

Actions are sent to the backdoor using backdoor triggers, which indicate the backdoor the action to execute depending on the value of the attribute K3:

K3 VALUE	ACTION
0x1F29	Request to start an encrypted pseudo-shell connection
0x4E14	Request to start a phantom shell connection
0x1D25	Request to load and attach all rootkit eBPF programs
0x1D24	Request to detach all rootkit eBPF programs (except the backdoor’s)

Pattern-based trigger

This trigger hides the command and client information so that it can be recognized by the backdoor, but at the same time seems random enough for an external network supervisor. It is based on the trigger used by the NSA rootkit Bvp47.

Multi-packet trigger

This trigger consists of multiple TCP packets on which the backdoor payload is hidden in the packet headers. This is based on the Hive implant leaked by WikiLeaks. The following payload is used:

A rolling XOR is then computed over the above payload and it is divided into multiple parts, depending on the mode selected by the rootkit client. TripleCross supports payloads hidden on the TCP sequence number:

And on the TCP source port:

Backdoor pseudo-shells

The client can establish rootkit pseudo-shells, a special rootkit-to-rootkit client connection which simulates a shell program, enabling the attacker to execute Linux commands remotely and get the results as if it was executing them directly in the infected machine. Multiple pseudo-shells are incorporated in our rootkit:

Plaintext pseudo-shell

This shell is generated after a successful run of the execution hijacking module, which will execute a malicious file that establishes a connection with the rootkit client as follows:

Encrypted pseudo-shell

An encrypted pseudo-shell can be requested by the rootkit client at any time. It is managed by the backdoor, and accepts either pattern-based triggers or both types of multi-packet trigger:

Phantom shell

A phantom shell uses a combination of XDP and TC programs to overcome eBPF limitations at the network, specifically that it cannot generate new packets. For this, the backdoor modifies existing traffic, overwriting the payload with the data of the C2 transmission. The original packets are not lost since TCP retransmissions send the original packet (without modifications) again after a short time.

The following protocol illustrates the traffic during the execution of a command using a phantom shell:

A phantom shell is requested by the rootkit client which issues a command to be executed by the backdoor:

After the infected machine sends any TCP packet, the backdoor overwrites it and the client shows the response:

Execution hijacking module

Although in principle an eBPF program cannot start the execution of a program by itself, this module shows how a malicious rootkit may take advantage of benign programs in order to execute malicious code at the user space. This module achieves two goals:

• Execute a malicious user program taking advantage of other program’s execution.
• Be transparent to the user space, that is, if we hijack the execution of a program so that another is run, the original program should be executed too with the least delay-

This module hijacks the sys_execve syscall, modifying its arguments so that a malicious program (src/helpers/execve_hijack.c) is run instead. This modification is made in such a way that the malicious program can then execute the original program with the original arguments to avoid raising concerns in the user space. The following diagram summarizes the overall functionality:

As we mentioned, the arguments of the original sys_execve call are modified in such a way that the original arguments are not lost (by taking advantage of argv[0]) so that the original program can be executed after the malicious one:

We have incorporated a sample test program (src/helpers/simple_execve.c) for testing the execution hijacking module. The module can also hijack any call in the system, depending on the configuration:

FILENAME	CONSTANT	DESCRIPTION
src/common/constants.h	PATH_EXECUTION_HIJACK_PROGRAM	Location of the malicious program to be executed upon succeeding to execute a sys_execve call
src/common/constants.h	EXEC_HIJACK_ACTIVE	Deactivate (0) or activate (1) the execution hijacking module
src/common/constants.h	TASK_COMM_RESTRICT_HIJACK_ACTIVE	Hijack any sys_execve call (0) or only those indicated in TASK_COMM_NAME_RESTRICT_HIJACK (1)
src/common/constants.h	TASK_COMM_NAME_RESTRICT_HIJACK	Name of the program from which to hijack sys_execve calls

After a successful hijack, the module will stop itself. The malicious program execve_hijack will listen for requests of a plaintext pseudo-shell from the rootkit client.

Rootkit persistence

After the infected machine is rebooted, all eBPF programs will be unloaded from the kernel, and the user space rootkit program will be killed. Moreover, even if they could be run again automatically, they would no longer dispose of the root privileges needed for attaching the eBPF programs again. Therefore, the rootkit persistence module aims to tackle these two challenges:

• Execute the rootkit automatically and without user interaction after a machine re- boot event.
• Once the rootkit has acquired root privileges the first time it is executed in the machine, it must keep them including after a reboot.

For this functionality, two secret files are created under cron.d and sudoers.d. These entries ensure that the rootkit is loaded automatically and with full privilege after a reboot. These files are created and managed by the deployer.sh script:

The script contains two constants that must be configured for the user to infect on the target system:

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

Rootkit stealth

Since the persistence module is based on creating additional files, they may get eventually found by the system owner or by some software tool, so there exists a risk on leaving them in the system. Additionally, the rootkit files will need to be stored at some location, in which they may get discovered.

Taing the above into account, the stealth module provides the following functionality:

• Hide a directory completely from the user (so that we can hide all rootkit files inside).
• Hide specific files in a directory (we need to hide the persistence files, but we cannot hide the sudoers.d or cron.d directories completely, since they belong to the normal system functioning).

The files and directories hidden by the rootkit can be customized by the following configuration constants:

FILENAME	CONSTANT	DESCRIPTION
src/common/constants.h	SECRET_DIRECTORY_NAME_HIDE	Name of directory to hide
src/common/constants.h	SECRET_FILE_PERSISTENCE_NAME	Name of the file to hide

By default, Triplecross will hide any files called "ebpfbackdoor" and a directory named "SECRETDIR". This module is activated automatically after the rootkit installation.

The technique used for achieving this functionality consists on tampering with the arguments of the sys_getdents system call:

License

The TripleCross rootkit and the rootkit client are licensed under the GPLv3 license. See LICENSE.

The RawTCP_Lib library is licensed under the MIT license.

The original thesis document and included figures are released under Creative Commons BY-NC-ND 4.0.

---

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 ↩︎