-
Researchers have found a Linux rootkit that hides a PHP web shell in Apache’s memory on F5 BIG-IP APM devices.
-
ESET calls the malware PoisonedRefresh. The attacks appear to be tied to exploitation of the critical CVE-2025-53521 flaw.
-
Defenders may miss the backdoor by checking files alone because the malicious PHP code lives only in memory.
Researchers at Sophos discovered a Linux rootkit that is connected with hacked F5 BIG-IP APM. It is capable of allowing an attacker remote code execution via a PHP web shell. This malicious software does not need to have the final shell reside on the system. It does not need to leave the final shell on disk.
Sophos says the sample looks like a second-stage payload. A separate installer appears to infect the Apache /usr/sbin/httpd file. It also changes SELinux settings and can persist across BIG-IP upgrade images.
F5 connects this threat to CVE-2025-53521, a remote code execution bug in BIG-IP APM that doesn’t even need authentication. ESET researchers took a closer look at the same malware and gave it the name PoisonedRefresh.
How the Rootkit Gets Inside Apache
The second-stage implant starts before Apache reaches its normal code. This is accomplished through hooking the Linux __libc_start_main function.
The virus also hooks the apr_dso_load function of Apache. It waits for Apache to load the PHP module before it starts its main web-shell work.
The implant hides key strings with RC4 encryption. It also checks Apache memory maps and changes memory settings when needed. This gives the attackers a way to alter Apache without making the changes easy to spot on disk.
Web Shell Lives Only in Memory
The most unusual part of the attack is how the rootkit hides its web shell. It targets three legitimate BIG-IP APM webtop files: apm_css.php3, full_wt.php3 and webtop_popup_css.php3. Sophos says the names likely appeal to attackers because those files exist in the target APM webtop environment.
The malware intercepts PHP file operations. It then changes what Apache sees when it loads the files. The files on disk stay unchanged. The malicious code appears only in the copy held in memory.
That creates a major problem for defenders. A file scan can show a clean PHP script while Apache runs a changed version. Traditional file checks can therefore miss the active backdoor. Incident responders need both file and live-process evidence when they inspect a suspected device.
The web shell accepts specially formed requests. It decrypts the request data and passes the commands to PHP’s eval() function.
The shell also tries to blend its replies into normal web traffic. Sophos found that it returns HTTP 201 and uses a text/css content type.
A Second Backdoor Avoids Network Ports
The rootkit has another access method. It creates a password-protected UNIX socket at /run/bigtlog.pipe.
The socket can connect an attacker to /bin/bash. That gives the attacker an interactive shell without opening a normal TCP port.
Sophos could not identify the component that connects to this socket. Researchers also found no built-in client code for it.
Sophos said the web shell might reach the socket, but the research found no evidence to confirm that link. The two methods may instead work as separate access paths.
The malware also delays creation of the local backdoor until Apache makes routine time calls. According to Sophos, this would minimize the chance of service disruption and allow the implant to blend in with regular activity.
CVE-2025-53521 is Still a Very Risky Flaw
The suspected attack vector is important. That’s because CVE-2025-53521 targets BIG-IP APM systems that have an access policy on a virtual server.
The security problem was first disclosed by F5. In March 2026, the company changed its rating to unauthenticated remote code execution after new information came to light. F5 and the New Zealand NCSC also confirmed active exploitation.
The UK’s NCSC recommended that companies double-check their systems regardless of whether they’ve installed the latest update or not. The reason is that attackers may have gained access into the system before the patches went live. Security teams need to dig around for any tweaks or changes made by hackers before the updates happen.
That makes a simple patch check less useful on its own. Security teams should be on the lookout for any weird tweaks or changes hackers might’ve made before the patch. Sometimes those changes are sneaky as hell.
Shadowserver’s tracking spotted 795 endpoints that are exposed to CVE-2025-53521 as of September 7. That number measures exposed systems. It does not mean 795 systems had the rootkit.
What Defenders Should Look for
Sophos recommends watching for several signs of compromise. These include Apache workers reading /proc/self/maps, temporary memory permission changes around libphp, creation of /run/bigtlog.pipe and Apache-related processes launching /bin/bash.
Security teams should also review unusual POST requests to the three targeted PHP endpoints.
HTTP 201 responses paired with a text/css content type can also raise a warning when they do not fit normal traffic. Sophos recommends treating these signs as clues and checking them against other system evidence.
F5 and government security agencies have urged affected organizations to investigate for compromise, not just apply a patch. A compromised device may need a deeper response because attackers could have added more access before remediation.
The PoisonedRefresh case shows why appliance security cannot rely on file checks alone. Attackers can change what a running service sees without changing the files defenders expect to find.
Trust-based fraud also extends to healthcare. In California, criminals allegedly used stolen identities to enroll non-residents in Medi-Cal and fraudulently bill $267 million for hospice services. The scheme involved 14 fake providers and more than 130 shell companies.
For BIG-IP APM operators, patching remains critical. But teams should also review process behavior, network traffic, and memory when investigating possible compromise. A clean disk image does not, by itself, prove that a device was never breached.