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 looks like 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 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 PHP files on disk unchanged.
• 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 carry HTTP 201 with a text/css content type.

A newly documented Linux rootkit is burrowing into F5 BIG-IP appliances, the network boxes 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 finding that the same sample had already been named PoisonedRefresh by ESET. First reported by BleepingComputer, the case is a clean example of tradecraft aimed squarely at appliances defenders rarely inspect. Our earlier coverage of a Chinese-speaking crew deploying a Linux rootkit via malicious Apache modules on 2 September shows this class of server-side implant is getting more crowded.

Attribution is thin. Neither vendor has publicly linked the implant to a named cluster, and I haven't seen infrastructure overlap tying it to any known group. Treat 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 the likely entry point as CVE-2025-53521, a critical remote code execution flaw in BIG-IP APM that F5 originally rated as a denial-of-service issue and reclassified in March once the true impact became clear.

A separate installer component tampered with the Apache binary at /usr/sbin/httpd, weakened SELinux (a Linux security layer that restricts what programs can do), and arranged to survive BIG-IP firmware upgrades. That last detail matters more than the rest. Persistence across upgrades 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 those in-memory copies to add malicious code.

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

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

Is there a second backdoor?

Yes, and it's careful about timing. 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 it an attacker can launch an interactive Bash shell without opening any network port a scanner would spot.

The socket isn't exposed to the internet directly, so attackers need another foothold on the box to reach it. Sophos didn't identify the client component used to do that.

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 comes first. A memory-level inspection of Apache comes second.