LinkPro Linux Rootkit

A recent compromise of an Amazon Web Services (AWS) environment revealed a previously undocumented GNU/Linux rootkit, tracked as LinkPro. This backdoor is notable for its dual use of eBPF modules: one set for hiding artifacts, and another that acts as a stealthy trigger — a 'knock' that awakens remote command functionality only after a specially crafted TCP packet is seen. The attack chain and the rootkit's mechanisms illustrate a sophisticated operator who blends container abuse, kernel-level concealment, and flexible network activation to frustrate detection and forensic correlation.

Infection Vector And Initial Deployment

The intrusion began with the exploitation of an exposed Jenkins instance vulnerable to CVE‑2024‑23897 (CVSS 9.8). From that foothold, the attackers pushed a malicious Docker image (kvlnt/vv, since removed from Docker Hub) into multiple Kubernetes clusters. The image used a Kali Linux base and carried a small application folder intended to establish persistence, remote access, and a staged backdoor download.

Inside The Malicious Docker Image

The image's app folder contained three key files with distinct roles:

start.sh — a shell script that launches an SSH service and executes the other two components.

link — an open-source program (vnt) compiled/packaged to act as a VPN/proxy client, connecting outbound to vnt.wherewego[.]top:29872. This lets the attacker reach the compromised host from anywhere and pivot to other targets through it.

app — a Rust-based downloader (referred to as vGet) that fetches an encrypted vShell payload from an S3 bucket, then establishes a WebSocket link to its command-and-control (C2) server at 56.155.98[.]37.

Additional Payloads Delivered To Kubernetes Nodes

Alongside the malicious image, the operators also dropped two other components onto the nodes: a dropper that installs another vShell backdoor, and LinkPro, a Golang-written rootkit. LinkPro is designed to run in one of two modes — passive (reverse) or active (forward) — depending on its configuration. In passive mode, it waits to be activated by a special network packet; in active mode, it initiates contact to the C2 itself. Forward mode supports five transport protocols (HTTP, WebSocket, UDP, TCP, DNS), whereas reverse mode limits communications to HTTP.

How LinkPro Persists

The malware's overall execution and persistence behavior follow a clear sequence:

• Install the Hide eBPF module. This module includes Tracepoint and Kretprobe eBPF programs used to conceal LinkPro's processes and network activity.
• If installing the Hide eBPF module fails — or if it has been disabled — install a shared library at /etc/libld.so and add that path to /etc/ld.so.preload as a fallback hiding mechanism.
• For reverse (passive) operation, install the Knock eBPF module. Knock contains an XDP program and a TC program, so the C2 channel only becomes active after receiving a specific 'magic packet.'
• Establish persistence by creating a systemd service.
• Execute commands received from the C2.
• On shutdown or when signaled (SIGHUP, SIGINT, SIGTERM), uninstall eBPF modules and remove/restore the /etc/libld.so preload modification so the system returns to its prior state.

The Magic Packet And The Knock Activation Mechanism

LinkPro's passive activation depends on a precise TCP packet: any TCP packet whose window size equals 54321 is treated as the 'magic packet.' When Knock detects that packet, it stores the source IP and tags it with a one‑hour expiration. Subsequent TCP packets from that source are monitored and, when appropriate, Knock rewrites headers so the operator's traffic is redirected to LinkPro's listening port (2333). Outbound packets are adjusted to present the original port back to the network (source port rewritten to 2233). The intent is straightforward but effective: allow the attacker to reach LinkPro through any port the front-end firewall permits, while making it difficult to correlate external firewall logs with the host's internal network activity.

How LinkPro Conceals Itself

LinkPro uses a two-tier concealment strategy:

Kernel/eBPF hiding: The Hide eBPF module installs Tracepoint and Kretprobe programs that intercept system calls such as getdents (to hide files/directories) and sys_bpf (to hide its own BPF programs). This approach requires a kernel built with CONFIG_BPF_KPROBE_OVERRIDE enabled.

User-space LD_PRELOAD fallback: If the kernel capability is not present, LinkPro writes a shared library (libld.so) and places its path in /etc/ld.so.preload. Because /etc/ld.so.preload causes the specified library to be loaded into every dynamically linked process (those using /lib/ld-linux.so and glibc), the implanted libld.so hooks libc functions early (before glibc's own behavior) and alters returns from libc calls to hide artifacts that would otherwise expose its presence.

Rootkit Capabilities And Command Set

LinkPro supports both interactive and automated remote actions. Its implemented features include:

• Starting a /bin/bash pseudo‑terminal and running interactive shell sessions.
• Executing arbitrary shell commands.
• Enumerating files and directories and performing file operations.
• Downloading and writing files to disk.
• Establishing a SOCKS5 proxy tunnel for pivoting and living-off-the-land proxying.

Network Protocol Support And C2 Behavior

In active (forward) mode LinkPro is flexible: it can communicate using HTTP, WebSocket, UDP, TCP, or DNS transports. In passive (reverse) mode its communication is constrained to HTTP but benefits from stealth because it only listens after the Knock magic packet has opened a temporary one‑hour command window.

Cleanup And Uninstall Behavior

If the process receives termination signals, LinkPro aims to remove traces: it uninstalls installed eBPF modules and deletes or restores the /etc/libld, grouping it to its previous state so the system appears unchanged. This deliberate cleanup routine indicates an operator concerned about evasion and minimizing long-term forensic footprints.

Operational Context And Attribution

The campaign used a high-severity Jenkins exploit, malicious container images, multiple backdoor variants, and kernel-level stealth — a combination that points to a motivated, capable operator. No definitive attribution has been made public; however, the toolset and the apparent use of the compromise for proxying and persistent remote access strongly suggest financially motivated activity (pivoting, proxying for additional intrusions, or resale of access).

Kernel Dependency And Fallback Behavior

Because LinkPro relies on BPF kprobe override features for its stealthy kernel interception, it only applies the kernel‑level hiding technique when the host kernel exposes CONFIG_BPF_KPROBE_OVERRIDE. Where that kernel capability is missing, LinkPro deliberately falls back to the LD_PRELOAD shared‑library method to hide itself in user space, ensuring concealment across a wide range of environments.

Closing Note

LinkPro demonstrates how modern intrusions can combine container compromise, staged loaders, kernel instrumentation (eBPF), and clever network tricks (magic‑packet activation and port-rewriting) to maintain stealth and flexibility. Detection and remediation require careful inspection for unauthorized eBPF programs, unexpected entries in /etc/ld.so.preload, unusual systemd services, and network connections to the indicated infrastructure (forensic indicators include the IP 56.155.98[.]37, ports 29872, 2333, 2233, and the removed Docker image name kvlnt/vv).