{
	"id": "4d4ae671-5f2c-4630-9dc8-651772ebe126",
	"created_at": "2026-04-06T00:22:31.24606Z",
	"updated_at": "2026-04-10T03:24:18.061628Z",
	"deleted_at": null,
	"sha1_hash": "cd0870230ac81b8b2a406413dee1c528b164b07d",
	"title": "GitHub - h3xduck/TripleCross: A Linux eBPF rootkit with a backdoor, C2, library injection, execution hijacking, persistence and stealth capabilities.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1117055,
	"plain_text": "GitHub - h3xduck/TripleCross: A Linux eBPF rootkit with a backdoor,\r\nC2, library injection, execution hijacking, persistence and stealth\r\ncapabilities.\r\nBy h3xduck\r\nArchived: 2026-04-05 14:21:08 UTC\r\nlliicceennssee GGPPLL--33..00\r\n rreelleeaassee vv00..11..00 mmaaiinnttaaiinnaabbiilliittyy B llaasstt ccoommmmiitt mmaarrcchh 22002233\r\nTripleCross is a Linux eBPF rootkit that demonstrates the offensive capabilities of the eBPF technology.\r\nTripleCross is inspired by previous implant designs in this area, notably the works of Jeff Dileo at DEFCON 271, Pat Hogan\r\nat DEFCON 292, Guillaume Fournier and Sylvain Afchain also at DEFCON 293, and Kris Nóva's Boopkit4. We reuse and\r\nextend some of the techniques pioneered by these previous explorations of the offensive capabilities of eBPF technology.\r\nThis rootkit was created for my Bachelor's Thesis at UC3M. More details about its design are provided in the thesis\r\ndocument.\r\nDisclaimer\r\nThis rookit is purely for educational and academic purposes. The software is provided \"as is\" and the authors are not\r\nresponsible for any damage or mishaps that may occur during its use.\r\nDo not attempt to use TripleCross to violate the law. Misuse of the provided software and information may result in criminal\r\ncharges.\r\nContents\r\n1. Features\r\n2. TripleCross overview\r\n3. Build and install\r\n4. Library injection module\r\n5. Backdoor and C2\r\n6. Execution hijacking module\r\n7. Rootkit persistence\r\n8. Rootkit stealth\r\n9. License\r\nFeatures\r\n1. A library injection module to execute malicious code by writing at a process' virtual memory.\r\n2. An execution hijacking module that modifies data passed to the kernel to execute malicious programs.\r\n3. A local privilege escalation module that allows for running malicious programs with root privileges.\r\n4. A backdoor with C2 capabilities that can monitor the network and execute commands sent from a remote rootkit\r\nclient. It incorporates multiple activation triggers so that these actions are transmitted stealthily.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 1 of 21\n\n5. A rootkit client that allows an attacker to establish 3 different types of shell-like connections to send commands and\r\nactions that control the rootkit state remotely.\r\n6. A persistence module that ensures the rootkit remains installed maintaining full privileges even after a reboot event.\r\n7. A stealth module that hides rootkit-related files and directories from the user.\r\nTripleCross overview\r\nThe following figure shows the architecture of TripleCross and its modules.\r\nThe raw sockets library RawTCP_Lib used for rootkit transmissions is of my authorship and has its own repository.\r\nThe following table describes the main source code files and directories to ease its navigation:\r\nDIRECTORY COMMAND\r\ndocs Original thesis document\r\nsrc/client Source code of the rootkit client\r\nsrc/client/lib RawTCP_Lib shared library\r\nsrc/common\r\nConstants and configuration for the rootkit. It also includes the implementation of elements common\r\nto the eBPF and user space side of the rootkit, such as the ring buffer\r\nsrc/ebpf Source code of the eBPF programs used by the rootkit\r\nsrc/helpers\r\nIncludes programs for testing the functionality of several rootkit modules, and also the malicious\r\nprogram and library used at the execution hijacking and library injection modules, respectively\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 2 of 21\n\nDIRECTORY COMMAND\r\nsrc/libbpf Contains the libbpf library integrated with the rootkit\r\nsrc/user Source code of the userland programs used by the rootkits\r\nsrc/vmlinux\r\nHeaders containing the definition of kernel data structures (this is the recommended method when\r\nusing libbpf)\r\nBuild and Install\r\nRequirements\r\nThis research project has been tested under the following environments:\r\nDISTRIBUTION KERNEL GCC CLANG GLIBC\r\nVERSION Ubuntu 21.04 5.11.0 10.3.0 12.0.0 2.33\r\nWe recommend using Ubuntu 21.04, which by default will incorporate the software versions shown here. Otherwise, some\r\nof the problems you may run into are described here.\r\nCompilation\r\nThe rootkit source code is compiled using two Makefiles.\r\n# Build rootkit\r\ncd src\r\nmake all\r\n# Build rootkit client\r\ncd client\r\nmake\r\nThe following table describes the purpose of each Makefile in detail:\r\nMAKEFILE COMMAND DESCRIPTION RESULTING FILES\r\nsrc/client/Makefile make Compilation of the rootkit client src/client/injector\r\nsrc/Makefile make help\r\nCompilation of programs for\r\ntesting rootkit capabilities, and the\r\nmalicious program and library of\r\nthe execution hijacking and library\r\ninjection modules, respectively\r\nsrc/helpers/simple_timer,\r\nsrc/helpers/simple_open,\r\nsrc/helpers/simple_execve,\r\nsrc/helpers/lib_injection.so,\r\nsrc/helpers/execve_hijack\r\nsrc/Makefile make kit\r\nCompilation of the rootkit using the\r\nlibbpf library\r\nsrc/bin/kit\r\nsrc/Makefile make tckit\r\nCompilation of the rootkit TC\r\negress program\r\nsrc/bin/tc.o\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 3 of 21\n\nInstallation\r\nOnce the rootkit files are generated under src/bin/, the tc.o and kit programs must be loaded in order. In the following\r\nexample, the rootkit backdoor will operate in the network interface enp0s3:\r\n// TC egress program\r\nsudo tc qdisc add dev enp0s3 clsact\r\nsudo tc filter add dev enp0s3 egress bpf direct-action obj bin/tc.o sec classifier/egress\r\n// Libbpf-powered rootkit\r\nsudo ./bin/kit -t enp0s3\r\nAttack scenario scripts\r\nThere are two scripts, packager.sh and deployer.sh, that compile and install the rootkit automatically, just as an attacker\r\nwould do in a real attack scenario.\r\nExecuting packager.sh will generate all rootkit files under the apps/ directory.\r\nExecuting deployer.sh will install the rootkit and create the persistence files.\r\nThese scripts must first be configured with the following parameters for the proper functioning of the persistence module:\r\nSCRIPT CONSTANT DESCRIPTION\r\nsrc/helpers/deployer.sh CRON_PERSIST Cron job to execute after reboot\r\nsrc/helpers/deployer.sh SUDO_PERSIST Sudo entry to grant password-less privileges\r\nLibrary injection module\r\nThe rootkit can hijack the execution of processes that call the sys_timerfd_settime or sys_openat system calls. This is\r\nachieved by overwriting the Global Offset Table (GOT) section at the virtual memory of the process making the call. This\r\nleads to a malicious library (src/helpers/injection_lib.c) being executed. The library will spawn a reverse shell to the attacker\r\nmachine, and then returns the flow of execution to the original function without crashing the process.\r\nTripleCross is prepared to bypass common ELF hardening techniques, including:\r\nASLR\r\nStack canaries\r\nDEP/NX\r\nPIE\r\nFull RELRO\r\nIt is also prepared to work with Intel CET-compatible code.\r\nThe module functionality can be checked using two test programs src/helpers/simple_timer.c and src/helpers/simple_open.c.\r\nAlternatively you may attempt to hijack any system process (tested and working with systemd).\r\nThe module configuration is set via the following constants:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 4 of 21\n\nFILENAME CONSTANT DESCRIPTION\r\nsrc/common/constants.h\r\nTASK_COMM_NAME_INJECTION_\r\nTARGET_TIMERFD_SETTIME\r\nName of the process to hijack at syscall\r\nsys_timerfd_settime\r\nsrc/common/constants.h\r\nTASK_COMM_NAME_INJECTION_\r\nTARGET_OPEN\r\nName of the process to hijack at syscall\r\nsys_openat\r\nsrc/helpers/injection_lib.c\r\nATTACKER_IP \u0026\r\nATTACKER_PORT\r\nIP address and port of the attacker machine\r\nReceiving a reverse shell from the attacker machine can be done with netcat:\r\nLibrary injection via GOT hijacking technique\r\nThe technique incorporated in TripleCross consists of 5 stages:\r\nLocating GOT and the return address\r\nThe rootkit hooks the system call using a tracepoint program. From there, it locates the address at the GOT section which the\r\nPLT stub used to make the call to the glibc function responsible of the syscall.\r\nIn order to reach the GOT section, the eBPF program uses the return address stored at the stack. Note that:\r\nThe .text makes a call to the .plt, so rip is saved as ret in the stack.\r\nThe .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.\r\nGlibc makes a syscall, which does not save rip in the stack, but rather saves it in rcx.\r\nTherefore in order to check from eBPF that an address in the stack is the return address that will lead us to the correct GOT,\r\nwe must check that it is the return address of the PLT stub that uses the GOT address that jumps to the glibc function making\r\nthe system call we hooked from eBPF.\r\nTwo techniques for finding the return address have been incorporated:\r\nWith sys_timerfd_settime, the eBPF program scans forward in the scan using the syscall arguments.\r\nWith sys_openat, the eBPF program scans uses the data at tracepoints' pt_regs struct for scanning the return address.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 5 of 21\n\nLocating key functions for shellcode\r\nThe shellcode must be generated dynamically to bypass ASLR and PIE, which change the address of functions such as\r\ndlopen() on each program execution.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 6 of 21\n\nInjecting shellcode in a code cave\r\nA code cave can be found by reverse engineering an ELF if ASLR and PIE are off, but usually that is not the case. The eBPF\r\nprogram issues a request to an user space rootkit program that uses the /proc filesystem to locate and write into a code cave\r\nat the .text (executable) section.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 7 of 21\n\nOverwriting the GOT section\r\nDepending on whether Partial or Full RELRO are active on the executable, the eBPF program overwrites the GOT section\r\ndirectly or with the /proc filesystem.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 8 of 21\n\nWaiting for the next system call\r\nWhen the next syscall is issued in the hijacked program, the PLT section uses the modified GOT section, hijacking the flow\r\nof execution which gets redirected to the shellcode at the code cave. The shellcode is prepared to keep the program from\r\ncrashing, and calls the malicious library (src/helpers/lib_injection.so). This library issues a fork() and spawns a reverse shell\r\nwith the attacker machine. Afterwards the flow of execution is restored.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 9 of 21\n\nBackdoor and C2\r\nThe backdoor works out of the box without any configuration needed. The backdoor can be controlled remotely using the\r\nrootkit client program:\r\nCLIENT\r\nARGUMENTS\r\nACTION DESCRIPTION\r\n./injector -c \u003cVictim IP\u003e Spawns a plaintext pseudo-shell by using the execution hijacking module\r\n./injector -e \u003cVictim IP\u003e\r\nSpawns an encrypted pseudo-shell by commanding the backdoor with a pattern-based\r\ntrigger\r\n./injector -s \u003cVictim IP\u003e\r\nSpawns an encrypted pseudo-shell by commanding the backdoor with a multi-packet trigger\r\n(of both types)\r\n./injector -p \u003cVictim\r\nIP\u003e\r\nSpawns a phantom shell by commanding the backdoor with a pattern-based trigger\r\n./injector -a \u003cVictim IP\u003e Orders the rootkit to activate all eBPF programs\r\n./injector -u \u003cVictim\r\nIP\u003e\r\nOrders the rootkit to detach all of its eBPF programs\r\n./injector -S \u003cVictim\r\nIP\u003e\r\nShowcases how the backdoor can hide a message from the kernel (Simple PoC)\r\n./injector -h Displays help\r\nBackdoor triggers\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 10 of 21\n\nActions are sent to the backdoor using backdoor triggers, which indicate the backdoor the action to execute depending on\r\nthe value of the attribute K3:\r\nK3 VALUE ACTION\r\n0x1F29 Request to start an encrypted pseudo-shell connection\r\n0x4E14 Request to start a phantom shell connection\r\n0x1D25 Request to load and attach all rootkit eBPF programs\r\n0x1D24 Request to detach all rootkit eBPF programs (except the backdoor’s)\r\nPattern-based trigger\r\nThis trigger hides the command and client information so that it can be recognized by the backdoor, but at the same time\r\nseems random enough for an external network supervisor. It is based on the trigger used by the recently discovered NSA\r\nrootkit Bvp47.\r\nMulti-packet trigger\r\nThis trigger consists of multiple TCP packets on which the backdoor payload is hidden in the packet headers. This design is\r\nbased on the CIA Hive implant described in the Vault 7 leak. The following payload is used:\r\nA rolling XOR is then computed over the above payload and it is divided into multiple parts, depending on the mode\r\nselected by the rootkit client. TripleCross supports payloads hidden on the TCP sequence number:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 11 of 21\n\nAnd on the TCP source port:\r\nBackdoor pseudo-shells\r\nThe client can establish rootkit pseudo-shells, a special rootkit-to-rootkit client connection which simulates a shell program,\r\nenabling the attacker to execute Linux commands remotely and get the results as if it was executing them directly in the\r\ninfected machine. Multiple pseudo-shells are incorporated in our rootkit:\r\nPlaintext pseudo-shell\r\nThis shell is generated after a successful run of the execution hijacking module, which will execute a malicious file that\r\nestablishes a connection with the rootkit client as follows:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 12 of 21\n\nEncrypted pseudo-shell\r\nAn encrypted pseudo-shell can be requested by the rootkit client at any time, consisting of a TLS connection between the\r\nrootkit and the rootkit client. Inside the encrypted connection, a transmission protocol is followed to communicate\r\ncommands and information, similar to that in plaintext pseudo-shells.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 13 of 21\n\nSpawning an encrypted pseudo-shell requires the backdoor to listen for triggers, which accepts either pattern-based triggers\r\nor both types of multi-packet trigger:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 14 of 21\n\nPhantom shell\r\nA phantom shell uses a combination of XDP and TC programs to overcome eBPF limitations at the network, specifically\r\nthat it cannot generate new packets. For this, the backdoor modifies existing traffic, overwriting the payload with the data of\r\nthe C2 transmission. The original packets are not lost since TCP retransmissions send the original packet (without\r\nmodifications) again after a short time.\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 15 of 21\n\nThe following protocol illustrates the traffic during the execution of a command using a phantom shell:\r\nA phantom shell is requested by the rootkit client which issues a command to be executed by the backdoor:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 16 of 21\n\nAfter the infected machine sends any TCP packet, the backdoor overwrites it and the client shows the response:\r\nExecution hijacking module\r\nIn principle, an eBPF program cannot start the execution of a program by itself. This module shows how a malicious rootkit\r\nmay take advantage of benign programs in order to execute malicious code at the user space. This module achieves two\r\ngoals:\r\nExecute a malicious user program taking advantage of other program's execution.\r\nBe transparent to the user space, that is, if we hijack the execution of a program so that another is run, the original\r\nprogram should be executed too with the least delay.\r\nThis module works by hijacking the sys_execve() syscall, modifying its arguments so that a malicious program\r\n(src/helpers/execve_hijack.c) is run instead. This modification is made in such a way that the malicious program can then\r\nexecute the original program with the original arguments to avoid raising concerns in the user space. The following diagram\r\nsummarizes the overall functionality:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 17 of 21\n\nThe arguments of the original sys_execve() call are modified in such a way that the original arguments are not lost (using\r\nargv[0]) so that the original program can be executed after the malicious one:\r\nWe have incorporated a sample test program (src/helpers/simple_execve.c) for testing the execution hijacking module. The\r\nmodule can also hijack any call in the system, depending on the configuration:\r\nFILENAME CONSTANT DESCRIPTION\r\nsrc/common/constants.h PATH_EXECUTION_HIJACK_PROGRAM\r\nLocation of the malicious program to be\r\nexecuted upon succeeding to execute a\r\nsys_execve call\r\nsrc/common/constants.h EXEC_HIJACK_ACTIVE\r\nDeactivate (0) or activate (1) the execution\r\nhijacking module\r\nsrc/common/constants.h TASK_COMM_RESTRICT_HIJACK_ACTIVE\r\nHijack any sys_execve call (0) or only those\r\nindicated in\r\nTASK_COMM_NAME_RESTRICT_HIJACK\r\n(1)\r\nsrc/common/constants.h TASK_COMM_NAME_RESTRICT_HIJACK\r\nName of the program from which to hijack\r\nsys_execve calls\r\nAfter a successful hijack, the module will stop itself. The malicious program execve_hijack will listen for requests of a\r\nplaintext pseudo-shell from the rootkit client.\r\nRootkit persistence\r\nAfter the infected machine is rebooted, all eBPF programs will be unloaded from the kernel and the userland rootkit\r\nprogram will be killed. Moreover, even if the rootkit could be run again automatically, it would no longer enjoy the root\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 18 of 21\n\nprivileges needed for attaching the eBPF programs again. The rootkit persistence module aims to tackle these two\r\nchallenges:\r\nExecute the rootkit automatically and without user interaction after a machine reboot event.\r\nOnce the rootkit has acquired root privileges the first time it is executed in the machine, it must keep them even after\r\na reboot.\r\nTripleCross uses two secret files, created under cron.d and sudoers.d, to implement this functionality. These entries ensure\r\nthat the rootkit is loaded automatically and with full privilege after a reboot. These files are created and managed by the\r\ndeployer.sh script:\r\nThe script contains two constants that must be configured for the user to infect on the target system:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 19 of 21\n\nSCRIPT CONSTANT DESCRIPTION\r\nsrc/helpers/deployer.sh CRON_PERSIST Cron job to execute after reboot\r\nsrc/helpers/deployer.sh SUDO_PERSIST Sudo entry to grant password-less privileges\r\nRootkit stealth\r\nThe persistence module is based on creating additional files, but they may get eventually found by the system owner or by\r\nsome software tool, so there exists a risk on leaving them in the system. Additionally, the rootkit files will need to be stored\r\nat some location, in which they may get discovered.\r\nTaking the above into account, the stealth module provides the following functionality:\r\nHide a directory completely from the user (so that we can hide all rootkit files inside).\r\nHide specific files in a directory (we need to hide the persistence files, but we cannot hide the sudoers.d or cron.d\r\ndirectories completely, since they belong to the normal system functioning).\r\nThe files and directories hidden by the rootkit can be customized by the following configuration constants:\r\nFILENAME CONSTANT DESCRIPTION\r\nsrc/common/constants.h SECRET_DIRECTORY_NAME_HIDE Name of directory to hide\r\nsrc/common/constants.h SECRET_FILE_PERSISTENCE_NAME Name of the file to hide\r\nBy default, TripleCross will hide any files called \"ebpfbackdoor\" and a directory named \"SECRETDIR\". This module is\r\nactivated automatically after the rootkit installation.\r\nThe technique used for achieving this functionality consists of tampering with the arguments of the sys_getdents() system\r\ncall:\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 20 of 21\n\nLicense\r\nThe TripleCross rootkit and the rootkit client are licensed under the GPLv3 license. See LICENSE.\r\nThe RawTCP_Lib library is licensed under the MIT license.\r\nThe original thesis document and included figures are released under Creative Commons BY-NC-ND 4.0.\r\n1. J. Dileo. Evil eBPF: Practical Abuses of an In-Kernel Bytecode Runtime. DEFCON 27. slides ↩\r\n2. P. Hogan. Warping Reality: Creating and Countering the Next Generation of Linux Rootkits using eBPF. DEFCON\r\n27. presentation ↩\r\n3. G. Fournier and S. Afchain. eBPF, I thought we were friends! DEFCON 29. slides ↩\r\n4. Kris Nóva. Boopkit. github ↩\r\nSource: https://github.com/h3xduck/TripleCross\r\nhttps://github.com/h3xduck/TripleCross\r\nPage 21 of 21\n\n   https://github.com/h3xduck/TripleCross   \nThe following protocol illustrates the traffic during the execution of a command using a phantom shell:\nA phantom shell is requested by the rootkit client which issues a command to be executed by the backdoor:\n   Page 16 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://github.com/h3xduck/TripleCross"
	],
	"report_names": [
		"TripleCross"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434951,
	"ts_updated_at": 1775791458,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cd0870230ac81b8b2a406413dee1c528b164b07d.pdf",
		"text": "https://archive.orkl.eu/cd0870230ac81b8b2a406413dee1c528b164b07d.txt",
		"img": "https://archive.orkl.eu/cd0870230ac81b8b2a406413dee1c528b164b07d.jpg"
	}
}