Furtex Linux Toolkit Tests io_uring and eBPF Evasion Gaps

A new open-source Linux toolkit called Furtex combines post-exploitation research, endpoint detection testing, eBPF inspection, and io_uring experiments in one project for authorized security assessments.

The Furtex GitHub repository, developed by MatheuZSecurity, contains more than 100 small utilities organized into five areas. The project uses raw Linux interfaces rather than liburing or a larger security framework.

Furtex can help red teams examine whether Linux endpoint products detect alternative file, network, process, and kernel activity. Its capabilities also make it a high-risk dual-use toolkit that defenders should study within isolated, authorized environments.

What is the Furtex Linux toolkit?

Furtex describes itself as a post-exploitation and evasion research toolkit built around io_uring and eBPF. The repository currently contains 13 io_uring tools, 15 BPF utilities, nine eBPF programs, two runners, approximately 75 EDR-focused tools, and 13 Falco-testing utilities.

Each tool generally demonstrates one behavior rather than providing a single interactive framework. This modular design lets researchers test individual visibility gaps, kernel controls, or detection assumptions without loading the entire toolkit.

The project explicitly limits its intended use to authorized security research, red-team engagements, penetration tests, CTF competitions, and defensive development. Its documentation warns users not to run the software against systems they do not own or have written permission to test.

Furtex area	Project count	Research focus
io_uring	13 tools	Asynchronous file, network, memory, and data-transfer visibility
bpf	15 tools	BPF map, program, link, and Linux Security Module inspection
ebpf	9 programs and 2 runners	Kernel-side process, file, network, terminal, and credential monitoring
edrs	Approximately 75 tools	Endpoint reconnaissance, logging tests, hook analysis, and evasion research
techniques	13 tools	Testing detection coverage for 25 Falco default rules

Why Furtex focuses on io_uring

Linux introduced io_uring as a high-performance asynchronous input and output interface. Applications place requests into a shared submission queue, while the kernel returns results through a completion queue.

The Red Hat io_uring overview explains that Linux exposes three related system calls: io_uring_setup, io_uring_register, and io_uring_enter. One submission can represent several file or network operations, reducing repeated syscall overhead.

This execution model can challenge monitoring products that expect a separate conventional syscall event for every sensitive action. A queued file read may not generate the same sys_enter_read event that a traditional read() operation would produce.

io_uring does not make activity completely invisible

Security tools can still observe io_uring setup and submission activity, depending on their sensors and configuration. Kernel-level controls such as Linux Security Module hooks may also continue to apply even when an operation arrives through io_uring.

Visibility therefore depends on the monitoring layer. A product watching only traditional syscall tracepoints may miss useful context, while a product using deeper kernel hooks, io_uring-specific instrumentation, or correlated process and network telemetry may retain coverage.

Furtex tests this distinction through file, networking, memory execution, raw packet, and process-manipulation examples. These demonstrations should serve as coverage tests rather than proof that every Linux EDR product can be bypassed.

Monitoring source	Potential limitation	Defensive response
Traditional syscall events	May record io_uring submission without equivalent events for every queued operation	Add io_uring-specific and lower-level kernel telemetry
User-space interception	Raw system interfaces may avoid library wrappers	Correlate user-space monitoring with kernel and network evidence
kprobes and kernel hooks	Coverage depends on which functions receive instrumentation	Test hooks against synchronous and asynchronous paths
BPF and eBPF sensors	Privileged users may inspect or attempt to alter loaded programs and maps	Monitor BPF administration and restrict required capabilities
Audit rules	Rules may focus on traditional commands or syscall sequences	Protect audit configuration and centralize audit records

BPF tools inspect maps, programs, and links

The BPF section includes utilities that enumerate loaded maps and programs, inspect BPF links, examine map contents, and check for active BPF Linux Security Module hooks. Several tools also explore whether a privileged operator could modify monitoring state.

Most BPF utilities require CAP_BPF or, on kernels before version 5.8, broader CAP_SYS_ADMIN privileges. Other tools depend on capabilities such as CAP_PERFMON, CAP_NET_RAW, CAP_NET_ADMIN, or CAP_AUDIT_CONTROL.

These requirements create a useful defensive boundary. Organizations can reduce exposure by preventing ordinary workloads and containers from receiving kernel-administration capabilities they do not require.

• Restrict CAP_BPF and CAP_PERFMON to approved monitoring components.
• Alert when new BPF programs, maps, or links appear unexpectedly.
• Record attempts to detach, replace, freeze, or modify BPF objects.
• Monitor changes under the BPF virtual filesystem.
• Apply least privilege to containers and administrative service accounts.

Furtex also contains defensive eBPF examples

The eBPF directory contains programs for observing process execution, file access, network connections, terminal input and output, and access to credential-related paths. These examples show that Furtex includes monitoring research as well as evasion tests.

Building the eBPF components requires Clang, libbpf development files, kernel headers, and a generated vmlinux.h file. The running kernel must expose BTF information through CONFIG_DEBUG_INFO_BTF=y.

The project’s eBPF programs depend on the running kernel and available attachment points. Security teams should validate every program on the same kernel versions and distributions used in production.

The EDR directory contains around 75 utilities

The edrs directory forms the largest part of Furtex. It separates tools according to whether they require root access, Linux capabilities, or no special privileges.

Its coverage includes EDR reconnaissance, kernel module inspection, BPF discovery, hook enumeration, namespace activity, audit testing, process masquerading, memory execution concepts, log visibility, and network-channel experiments.

Some tools explore highly disruptive behavior, including changes to audit settings, event flooding, log modification, kernel module operations, or interference with monitoring components. Researchers should only test these functions in disposable systems with rollback and out-of-band logging.

Falco rules receive dedicated coverage tests

Furtex’s techniques directory examines 25 Falco default rules using 13 utilities. The tests focus on assumptions involving process names, paths, namespaces, terminal state, file operations, event volume, and execution methods.

Falco added support for io_uring family syscalls in version 0.32.0, released in 2022. That support means defenders can identify io_uring-related syscall activity, but individual rules may still miss behavior when they depend on a different event, filename, or process pattern.

A bypass against one default rule does not establish that Furtex bypasses Falco as a complete platform. Detection results depend on the Falco version, driver, ruleset, custom rules, kernel configuration, and additional telemetry available in the environment.

• Test default and custom rules against asynchronous I/O paths.
• Avoid rules based only on a single process name or command line.
• Correlate file, process, capability, container, and network events.
• Keep Falco, its drivers, and rulesets updated.
• Forward alerts to remote storage that local administrators cannot modify.

Furtex requirements and kernel support

Furtex requires GCC, Clang, Make, matching Linux kernel headers, libbpf development files, and bpftool. Individual components have different dependencies and privilege requirements.

The project documents kernel feature milestones from Linux 5.4 through 5.19. Linux 5.4 provides the project’s base io_uring and BPF map functionality, while later kernels add operations and capability changes used by particular tools.

Running every component therefore requires a sufficiently recent kernel and compatible configuration. Researchers should not assume that a successful build means every test applies to the target distribution or endpoint product.

Minimum kernel	Relevant Furtex dependency
Linux 5.4	Base io_uring support used by the project and BPF map iteration
Linux 5.6	Additional io_uring file operations and pidfd functionality
Linux 5.8	Separate CAP_BPF and CAP_PERFMON capabilities
Linux 5.9	BPF link detach functionality
Linux 5.19	io_uring socket operations used by several networking experiments

How defenders should use Furtex research

Security teams can treat Furtex as a structured checklist for Linux detection engineering. Each test can reveal whether the monitoring stack observes an action, records sufficient context, and produces an alert that analysts can investigate.

The io_uring programming model also shows why monitoring only conventional per-operation syscalls can leave gaps. Defenders should combine io_uring events with kernel, filesystem, identity, capability, process, and network telemetry.

Teams using Falco should confirm which syscall events their driver supports and evaluate whether custom rules cover asynchronous alternatives. The project’s existence does not replace product-specific testing, controlled validation, or review of the current Falco event support.

1. Test Furtex only inside an isolated lab with written authorization.
2. Record baseline process, BPF, capability, and io_uring activity.
3. Run one controlled test at a time and document expected telemetry.
4. Compare endpoint, audit, kernel, and network records for each test.
5. Identify detections that rely on one syscall, path, or process name.
6. Add correlation rules for privilege, file, process, and network changes.
7. Forward logs outside the tested host before running disruptive tests.
8. Repeat validation after kernel, EDR, or ruleset updates.

Furtex remains an early-stage project

The Furtex project uses the MIT License and currently has no published software releases. Its repository history remains small, so organizations should review the source before compiling or running any component.

The toolkit packages several techniques that can damage systems, interrupt monitoring, or expose sensitive information. A legal-use warning does not make those operations safe for production infrastructure.

For defenders, Furtex provides a useful reminder that Linux detection cannot depend on one event source. Effective coverage requires layered telemetry, strict privilege control, protected logs, and recurring tests across kernel execution paths.

FAQ