Hey security researchers and red teamers! Today, we're diving deep into Furtex, a Linux post-exploitation and evasion toolkit turning heads for its unique approach. Furtex is engineered to bypass modern detection systems by leveraging low-level Linux kernel capabilities: io_uring and eBPF.

What Is Furtex? More Than Just Another Toolkit

Furtex isn't your run-of-the-mill toolkit relying on third-party libraries or frameworks. Instead, it's built from the ground up using raw syscalls. This approach allows it to interact directly with the kernel, bypassing abstraction layers that often serve as hook points for detection solutions. The project is under active development, even accepting pull requests from the community. You can join the Rootkit Researchers Discord community for further discussion.

Critical reminder: Furtex is intended exclusively for security research, authorized penetration testing, CTF competitions, and defensive tooling development. Never deploy it on systems you don't own or lack explicit written authorization to test. Misuse violates applicable cyber laws.

Dissecting the Furtex Architecture

The toolkit is cleanly organized into several main directories, each targeting a specific facet of post-exploitation and evasion:

• io_uring/: Houses 13 tools leveraging raw io_uring operations for file manipulation, networking, injection, and exfiltration. This is the beating heart of Furtex's stealth capabilities.
• bpf/: Contains 15 tools for userspace manipulation of BPF maps and programs. Invaluable for understanding and modifying BPF behavior on a target system.
• ebpf/: Holds 9 kernel-side BPF programs and 2 runners to load them. These are designed to operate in-kernel for reconnaissance or evasion purposes.
• edrs/: The toolkit's largest component, packing 75 tools dedicated to EDR (Endpoint Detection and Response) evasion and general post-exploitation.
• techniques/: Provides 13 specific tools to bypass all 25 standard rules in Falco, a popular behavior-based EDR.

The Engine Under the Hood: io_uring and eBPF

Two pillars uphold Furtex: io_uring and eBPF. Grasping how they work is key to appreciating this toolkit's power.

io_uring for Stealthy Operations

io_uring is Linux's newer asynchronous I/O interface, offering exceptional performance and flexibility. Furtex, however, weaponizes it for evasion. I/O requests submitted via io_uring SQEs are processed through the kernel workqueue. This means the io_uring_enter(2) syscall never touches the sys_call_table and never triggers sys_enter_* tracepoints. It automatically sidesteps most EDR hooks relying on:

• sys_call_table pointer swapping.
• Livepatching native_sys_call or compat_sys_call.
• sys_enter_* tracepoints.

But io_uring alone doesn't cover every bypass scenario. For other hook points like kprobes or BPF LSM, Furtex supplies additional tools. For instance, ftrace_enum can nuke kprobe hooks, while bpf_link_detach can detach BPF LSM links.

eBPF: Granular Kernel Control

eBPF (extended Berkeley Packet Filter) allows userspace programs to run safely inside the kernel. Furtex exploits eBPF to manipulate BPF maps, load kernel-side BPF programs, and interact with kernel components at a deep level. Capabilities include:

• Dumping and wiping BPF map contents.
• Injecting PIDs into EDR allowlists.
• Detecting and detaching BPF LSM hooks.
• Even hiding ports or PIDs from /proc/net/tcp or getdents64 views.

System Requirements

Building and running Furtex demands a specific Linux environment with the necessary toolchain and headers.

Toolchain & Headers

Tool / Package	Required For
gcc	All userspace binaries
clang	Kernel-side BPF programs (ebpf/*.bpf.c)
make	Build system
linux-headers-$(uname -r)	<linux/bpf.h>, <linux/io_uring.h>, related kernel headers
libbpf-dev	<bpf/bpf_helpers.h> and related funcs in ebpf/ programs
bpftool	Generating vmlinux.h via make vmlinux inside ebpf/ (requires CONFIG_DEBUG_INFO_BTF=y in kernel)

On Debian, Kali, or Ubuntu, install the stack with:

bash
sudo apt install gcc clang make linux-headers-$(uname -r) libbpf-dev bpftool

Kernel Versions & Capabilities

Furtex taps into varying kernel features, so your kernel version dictates tool availability. Many tools also require specific Linux capabilities, typically needing root or CAP_SYS_ADMIN pre-kernel 5.8.

Minimum Kernel Version	Features Unlocked
5.4	Basic io_uring, BPF map iteration
5.6	IORING_OP_OPENAT, IORING_OP_STATX, pidfd_getfd
5.8	CAP_BPF + CAP_PERFMON split (replacing CAP_SYS_ADMIN for BPF)
5.9	BPF_LINK_DETACH
5.19	IORING_OP_SOCKET (used by af_packet_send, dns_exfil, etc.)

Capability	Tools Requiring It
CAP_BPF	All bpf/ tools, ebpf/ loaders
CAP_PERFMON	ebpf/ tracepoint and kprobe programs
CAP_NET_RAW	icmp_tunnel, af_packet_shell, skf_c2_runner, icmp_trigger
CAP_NET_ADMIN	xdp_socket_send, netfilter_flush
CAP_AUDIT_CONTROL	audit_kill

Building Furtex

The build process is straightforward via make:

bash
make all      # Build all binaries
make uring    # Build io_uring/ tools only
make bpf      # Build bpf/ userspace tools
make ebpf     # Build kernel-side BPF programs (requires clang + libbpf)
make edrs     # Build all edrs/ binaries
make techniques # Build Falco bypass tools
make clean    # Remove all binaries

The edrs/ directory has its own Makefile separating binaries by privilege requirements:

bash
cd edrs && make priv    # For tools needing root / CAP_*
cd edrs && make unpriv  # For tools needing no privileges

Exploring EDR Evasion Capabilities

The edrs/ directory is the core of Furtex's evasion muscle. With 75 tools, it offers a vast arsenal for dodging EDR detection. Standout examples include:

• edr_recon: Detects EDRs from 12 vendors by scanning processes, artifacts, modules, BPF, and kprobes.
• audit_kill: Disables or throttles Linux audit logging via NETLINK_AUDIT.
• ftrace_enum: Enumerates and removes kprobe or ftrace hooks.
• livepatch_bypass: Uses io_uring to bypass livepatch hooks on the syscall dispatcher.
• af_packet_shell: Raw Ethernet C2 bypassing netfilter OUTPUT.
• memfd_userexec: Executes ELF from stdin to memfd without traditional execve.
• hollow_proc: Performs process hollowing with a decoy name in ps.
• pidfd_steal: Steals open file descriptors from other processes via pidfd_getfd.

Targeting Falco: A Specific Case Study

The techniques/ directory specifically targets Falco, the popular behavioral threat detection engine, bypassing all 25 default rules. Furtex attacks Falco bypass from two primary vectors:

• Axis A (Prevent Event): Stop the event from reaching Falco entirely. Example: io_uring bypassing sys_enter_* tracepoints, or silently draining/flooding the Falco ring buffer.
• Axis B (Evade Rule Condition): The event reaches Falco, but the rule condition fails due to data manipulation. Examples: Process name spoofing (proc.name spoof), path pivot, or alternative flag usage.

Sample tools and bypassed Falco rules:

Falco Rule	Bypass Method (Axis)	Tool Used
1 Directory traversal monitored file read	io_uring OPENAT (A)	uring_ops cat, per_rule_bypass dir-traversal
3 Read sensitive file untrusted	io_uring or prctl (A/B)	uring_ops creds, bypass_file_rules read-masked
7 Contact K8S API Server	io_uring CONNECT (A)	uring_ops shell, per_rule_bypass k8s-connect
10 Clear Log Activities	ftruncate without O_TRUNC (B)	bypass_file_rules log-clear
18 Detect release_agent Escape	io_uring OPENAT+WRITE (A)	cgroup_escape proof/shell, uring_ops write
25 Fileless execution via memfd_create	Shellcode via mmap, no execve (B)	exe_from_memfd_bypass sc, proc_ghost ghost-sc
All Rules	Drain ring buffer or remove scap.ko (A)	ringbuf_overflow, kmod_unload

Critical Warning

As stated, Furtex is a potent toolkit demanding extreme caution and responsibility. All techniques demonstrated stem from public security research and kernel documentation. Misuse carries serious legal consequences. The Furtex developers accept zero liability for any abuse. By using this software, you agree you are fully responsible for complying with applicable laws.

Reference

• https://github.com/MatheuZSecurity/Furtex