An investigation into a compromise of Amazon Web Services, AWS, hosted infrastructure uncovered a new GNU/Linux rootkit named LinkPro, according to Synacktiv. The backdoor relies on two eBPF, extended Berkeley Packet Filter, modules for stealth and remote activation. The initial access vector was an exposed Jenkins server exploited via CVE-2024-23897, after which a malicious Docker Hub image, “kvlnt/vv” (now removed), was deployed across multiple Kubernetes clusters.
How the attackers gained a foothold, and what they dropped
The malicious Docker image used a Kali Linux base and included an app folder with three files, each playing a role in the compromise, as follows,
- start.sh, a shell script that starts the SSH service, and launches the remaining components,
- link, which is an open source program named vnt, functioning as a VPN server and proxy by connecting to vnt.wherewego[.]top:29872, enabling the attacker to reach the compromised host remotely,
- app, a Rust based downloader called vGet, which pulls an encrypted VShell payload from an S3 bucket and then communicates with a command and control server at 56.155.98[.]37 over a WebSocket connection.
In addition to vGet and the vShell backdoor (delivered by a dropper), the attackers installed LinkPro, a Golang rootkit. LinkPro can operate in two modes, passive (reverse) and active (forward), depending on configuration, allowing either a listener-only behavior triggered by a magic packet, or direct outbound connection to the actor controlled C2 server.
LinkPro components and persistence
LinkPro uses a combination of techniques to remain hidden and persistent on infected nodes, the main steps are,
1, Install the “Hide” eBPF module, which contains Tracepoint and Kretprobe type eBPF programs, to conceal processes and network artifacts,
2, If the “Hide” module fails or is disabled, fall back to installing a shared library, libld.so, and adding it to /etc/ld.so.preload, to hide activity in user space,
3, If reverse mode is configured, install the “Knock” eBPF module, which includes XDP and Traffic Control, TC, eBPF programs, so the C2 channel only becomes active after receiving a specially crafted magic TCP packet,
4, Achieve persistence by creating a systemd service,
5, Execute received C2 commands,
6, On signals such as SIGHUP, SIGINT, SIGTERM, uninstall eBPF modules and restore /etc/ld.so.preload to its original state.
To hide itself at the user level, LinkPro writes a path to the embedded libld.so library inside /etc/ld.so.preload. Because libld.so is loaded before glibc for programs that use shared libraries, it hooks several libc functions to alter program outputs, for example when listing files, so indicators of compromise are masked.
The magic packet activation mechanism
Synacktiv describes the magic packet as a TCP packet whose window size field equals 54321. When the Knock eBPF module detects such a packet, it records the packet source IP and sets an expiration time of one hour. During that hour, the operator may send commands, targeting any port allowed by the front end firewall, because the Knock module rewrites packet headers. Specifically, it can change the incoming TCP packet destination port to LinkPro’s listening port, 2333, and modify outgoing packet source port from 2233 back to the original port. This technique, in effect, lets the attacker piggyback on firewall allowed traffic, complicating correlation between firewall logs and the compromised host network activity.
In plain terms, once the magic packet is received, the attacker has a one hour window to interact with LinkPro, using any externally accessible port, while the Knock module handles the port translation and makes the activity look like allowed traffic.
Communication modes and capabilities
LinkPro supports two main communication modes, each with different protocol support,
- Forward mode, which can initiate connections to the C2 and supports HTTP, WebSocket, UDP, TCP, and DNS,
- Reverse mode, which only uses HTTP, and relies on the Knock module to activate communications after the magic packet.
The rootkit offers a set of commands commonly found in backdoors, including, execute /bin/bash in a pseudo terminal, run shell commands, enumerate files and directories, perform file operations, download files, and establish a SOCKS5 proxy tunnel. This gives the operator interactive control, remote file access, and tunneling through compromised nodes.
Kernel vs user space hiding, prerequisites, and fallback
At kernel level, LinkPro’s Hide module uses eBPF tracepoint and kretprobe programs to intercept system calls like getdents, for file hiding, and sys_bpf, to hide its own BPF programs. Notably, the technique requires a kernel compiled with CONFIG_BPF_KPROBE_OVERRIDE enabled. If that kernel configuration is absent, LinkPro falls back to the user space technique of loading a malicious library via /etc/ld.so.preload to achieve concealment.
Operational impact and attribution
Synacktiv did not attribute the operation to a specific group, but the presence of proxy tools, credential theft style backdoors, and the use of compromised cloud infrastructure suggests financially motivated actors. The use of Docker Hub delivery, exploitation of an exposed Jenkins server, and deployment across Kubernetes clusters shows the attackers targeted automation pipelines and containerized workloads, creating a rapid, scalable infection path.
Mitigations and detection suggestions, quick checklist
- Patch exposed CI servers and fix known vulnerabilities such as CVE-2024-23897, reduce public exposure of Jenkins and other management interfaces,
- Monitor for unexpected Docker images and containers, including images with unusual base images or unknown registries,
- Audit /etc/ld.so.preload and unexpected shared libraries, watch for modifications to that file,
- Monitor for unusual eBPF program loading activity, and log bpf syscalls where possible,
- Correlate firewall logs with host level activity, but be aware that LinkPro rewrites ports, so additional endpoint telemetry is required,
- Harden Kubernetes node access, scan for unauthorized containers, and restrict use of Docker Hub images to known trusted registries,
- Use kernel configurations and security modules to limit eBPF capabilities where feasible, and consider kernel upgrades or configuration changes if dangerous features like CONFIG_BPF_KPROBE_OVERRIDE are not required.
