Hackers deploy Linux rootkit on F5 BIG-IP APM devices, hiding web shell in memory

A rootkit found on hacked F5 BIG-IP APM devices skips the usual step of writing a web shell to disk, hiding it in memory instead, according to Sophos.

F5 BIG-IP APM provides access policy enforcement to secure access to apps, APIs, and data. It’s primarily used by enterprises, financial institutions, government agencies, and public sector organizations.

“The implant delivers a familiar outcome – on-demand server-side code execution commonly associated with web shells – but implements it using deeper Linux- and Apache-specific tradecraft,” Sophos said.

“The malware targets deployments featuring Apache, libphp, APR module loading, BIG-IP APM webtop components, and BIG-IP upgrade workflows, suggesting it was developed for specific environments,” they added.

F5 has linked related activity to CVE-2025-53521, an unauthenticated remote code execution flaw in BIG-IP APM that has already been exploited in the wild.

While digging through the sample, the Sophos team learned that ESET had already looked at the same malware and given it a name, PoisonedRefresh.

Web shell lives in memory

The malware analyzed is a second-stage payload, according to Sophos. During a parallel analysis of a related sample called “umount,” researchers identified a separate installer component responsible for infecting the Apache binary at /usr/sbin/httpd, persisting across BIG-IP upgrade images, modifying SELinux configurations, and deploying the second-stage payload.

“The second-stage sample hides key operational strings with RC4, gains execution before the host application main() function is invoked by intercepting __libc_start_main, targets Apache’s PHP module by hooking the Apache Portable Runtime (APR) module loader (apr_dso_load), and injects a PHP web shell into memory.”

Once Apache loads PHP, the second-stage implant intercepts PHP file operations and rewrites them in memory to hide a web shell inside legitimate scripts, including apm_css.php3, full_wt.php3, and webtop_popup_css.php3.

Sophos says these files were likely chosen because they’re common in BIG-IP APM webtop environments and unlikely to draw attention. The files on disk stay unchanged, cutting down what file-based scanning can detect.

“When PHP opens one of these files, the implant records the file descriptor. When that file is subsequently memory mapped, the implant creates a modified in-memory view containing both the embedded web shell and the original script content. The on-disk file does not need to contain the final web shell content at all; execution follows from the modified in-memory representation created by the implant at runtime,” researchers explained.

A second route to a shell

Alongside the web shell, the malware sets up a Unix domain socket at /run/bigtlog.pipe. After a short token check, a connection to that socket gets handed straight to /bin/bash, giving an attacker an interactive shell. Because it’s a local socket rather than a network listener, it won’t show up as a listening TCP port or in network monitoring that only looks for open TCP ports.

Researchers found no code inside the sample that would let an attacker reach that socket from outside the server, so it’s not clear how the two access methods are meant to work together, or whether the web shell is used to reach the socket indirectly.

What defenders can look for

Sophos lists a handful of signals worth checking for on Apache servers, including requests to the three .php3 files named above, PHP endpoints that return an HTTP 201 status while claiming to serve CSS content, and Apache worker processes that read /proc/self/maps and then change memory permissions shortly after.

It also suggests blocking .php3 execution where it isn’t needed, though administrators of BIG-IP APM systems should follow F5’s guidance before making such changes.

Sophos also recommends restricting ptrace access to reduce other ways processes can be inspected or manipulated, while noting that this would not necessarily stop the implant’s in-process behavior.

“Based on our analysis of the related umount and infected httpd samples, we assess that this campaign involves a staged architecture.”

“Perhaps the most significant finding is that the web shell does not need to exist in its final form on disk. Instead, the implant alters how targeted PHP files are presented to the running process, meaning the content observed by Apache and PHP can differ from the content visible to traditional file-based inspection. As a result, responders who focus exclusively on the filesystem may overlook critical evidence,” Sophos concluded.