Stealthy Linux rootkit hides inside F5 BIG-IP devices and runs entirely from memory

Key points

• Sophos and ESET have analysed a Linux rootkit, tracked by ESET as PoisonedRefresh, that targets F5 BIG-IP APM appliances used by large enterprises for remote access.
• The malware appears to be a second-stage payload delivered after attackers exploit CVE-2025-53521, a critical remote code execution flaw in BIG-IP that F5 reclassified from a lesser denial-of-service bug in March.
• The implant hooks Apache and injects a web shell, a hidden control panel that lets attackers run commands, straight into memory, leaving the PHP files on disk untouched.
• The Shadowserver Foundation counted 795 vulnerable BIG-IP APM endpoints exposed to the internet as of this week.
• Defenders should hunt for Apache workers spawning /bin/bash, POST requests to obscure .php3 pages, and PHP responses that return HTTP 201 with a text/css content type.

A newly documented Linux rootkit is burrowing into F5 BIG-IP appliances, the network boxes that many companies use to publish internal apps to remote staff, and running a hidden backdoor entirely from memory.

Sophos published the technical breakdown this week, after discovering that the same sample had already been picked up by ESET under the name PoisonedRefresh. First reported by BleepingComputer, the case is a good example of tradecraft aimed squarely at appliances that defenders rarely inspect.

Attribution is thin so far. Neither vendor has publicly linked the implant to a named cluster, and I have not seen infrastructure overlap tying it to a known group. Treat any China-nexus or Russia-nexus speculation as low confidence until someone puts a flag on it.

How did the attackers get in?

The rootkit looks like a second-stage tool, meaning something else broke in first. Sophos assesses that the likely entry point is CVE-2025-53521, a critical remote code execution flaw in F5 BIG-IP APM. F5 originally rated the bug as a denial-of-service issue, then reclassified it in March once the true impact became clear.

A separate installer component then tampered with the Apache web server binary at /usr/sbin/httpd on the device, weakened SELinux (a Linux security layer that restricts what programs can do), and set itself up to survive BIG-IP firmware upgrades. That last part matters. Persistence across upgrades is what turns an intrusion into a long-term foothold.

What does the rootkit actually do?

It hides a web shell inside Apache without changing any files on disk. When Apache starts, the implant intercepts a low-level Linux function called __libc_start_main so it runs before the web server proper. It then hooks the Apache module loader and, when PHP scripts are read into memory, quietly edits the in-memory copy to add malicious code.

The targeted scripts, including apm_css.php3, full_wt.php3 and webtop_popup_css.php3, are legitimate parts of the BIG-IP APM webtop interface. Because the files on disk are untouched, integrity checks and file scanners see nothing wrong.

The injected shell only answers specially formatted "magic" HTTP requests. It decrypts the payload, runs it through PHP's eval() function, and returns an HTTP 201 response dressed up as a CSS stylesheet.

Is there a second backdoor?

Yes, and it is careful about when it appears. The implant waits for Apache to settle into normal activity before spawning a worker thread that opens a password-protected local UNIX socket, a kind of internal communication channel. Through that socket an attacker can launch an interactive Bash shell without ever opening a network port that a scanner would spot.

The socket is not exposed to the internet directly, so the attackers need another foothold on the box to talk to it. Sophos did not identify the client component used to reach it.

What should defenders look for?

Shadowserver's public tracker for CVE-2025-53521 listed 795 exposed BIG-IP APM systems as of this week. If yours is one of them, patching is the first move, and a memory-level inspection of Apache is the second.