Rootkit hides web shells in F5 BIG-IP memory

A newly analyzed Linux rootkit may have given attackers a way to run hidden shells inside recently compromised F5 BIG-IP Access Policy Management environments, all without leaving the malicious PHP code on disk. The finding, reported by Sophos, describes an implant built specifically for BIG-IP APM webtop environments rather than a generic Apache or PHP attack. Because BIG-IP APM often sits at the edge of enterprise networks handling authentication and session traffic, a successful compromise could expose far more than the appliance itself.

What Sophos actually found

Sophos said the malware appears in compromised BIG-IP APM environments that use Apache and PHP components. The implant relies on custom ELF loading, function hooking, and runtime code patching to establish persistent access, according to the company's blog post. The company described the implant as tailored specifically to BIG-IP APM webtop environments, noting that it does not behave like a broad Apache or PHP attack.

The activity has been linked to exploitation of CVE-2025-53521, an unauthenticated remote code execution vulnerability affecting BIG-IP APM when an access policy is configured on a virtual server. According to Sophos, the sample it has now found and analyzed is a second-stage payload, while a previously identified component is responsible for infecting the Apache "httpd" process and deploying that payload.

The web shell that isn't a file

Sophos' analysis focused on how the malware delivers its web shell. Instead of dropping a suspicious PHP file onto the server, the implant hooks Apache's PHP-loading process and modifies the way selected PHP files are presented to the running process.

Sophos found it specifically targeting three PHP files used by BIG-IP APM's webtop environment: apm_css.php3, full_wt.php3, and webtop_popup_css.php3. When PHP attempts to memory-map one of those files as part of the routine PHP runtime, the rootkit intercepts the operation and creates a modified in-memory version containing the malicious web shell alongside the legitimate script. The file on disk remains unchanged.

That technique makes the implant nearly invisible to conventional web-shell detection tools. A scan of the filesystem would show a perfectly legitimate PHP file while the Apache process is executing a modified version in memory. The malware serves a poisoned copy of the three legitimate BIG-IP APM files only inside the running Apache process, according to the analysis.

Why file checks miss it

Because the on-disk files are untouched, hashes match and file-integrity monitoring passes even while the system is compromised. That gap between what is stored and what is actually executing is the core problem the implant exploits.

"The significance here isn't just that the web shell is stealthier. It's that it defeats the assumption most response playbooks rest on: that the file on disk tells you what the server is running."

— Sean Malone, chief information security officer at BeyondTrust

Malone explained that the box can look clean while it is owned, because the poisoned copies only exist inside the running Apache process. Detecting that kind of activity requires looking at memory and process behavior rather than file contents alone.

A second door through a UNIX socket

The implant also establishes a second access mechanism through a local UNIX socket rather than opening a conventional TCP listener. After authentication, the socket can provide an interactive "/bin/bash" session, giving an attacker another way into the system while avoiding some network-based detection.

Sophos said the combination of these techniques creates a web-shell capability that is harder to detect using file-centric or PHP-only monitoring. The two access paths — the in-memory web shell and the local socket — mean a defender who closes one route may still leave the other open.

What a BIG-IP compromise exposes

The implications extend beyond the F5 appliance itself. According to experts cited in the report, an attacker with access to BIG-IP APM can reach the identity and access functions the appliance manages.

"An attacker with access to BIG-IP APM can intercept SSO tokens and credentials, inject policy decisions, monitor user traffic, and move laterally to downstream applications and SaaS tenants that trust the appliance."

— Agnidipta Sarkar, chief evangelist at ColorTokens

Sarkar noted that BIG-IP APM is commonly deployed by large enterprises, financial institutions, and public-sector organizations to provide remote access and federated SSO to internal applications, APIs, and cloud services. Because the appliances sit at the network perimeter, process credentials and session tokens, and terminate TLS, they represent particularly valuable targets.

What defenders should check

For defenders, Sarkar recommended investigating systems that were vulnerable before they were patched, since applying the fix does not rule out an earlier compromise. He also recommended combining F5's indicators of compromise with memory and behavioral telemetry, because file scans alone may miss the rootkit's in-memory activity.

That guidance points to a broader operational reality: patching closes the door to new exploitation, but it does not tell you whether someone already walked through it. The three targeted PHP files and the local socket are concrete places to start looking.

• Three PHP files targeted: apm_css.php3, full_wt.php3, and webtop_popup_css.php3.
• One unauthenticated remote code execution vulnerability linked to the activity: CVE-2025-53521.
• Two access mechanisms described: an in-memory web shell and a local UNIX socket offering an interactive "/bin/bash" session.

The limits of file-based detection

The Sophos analysis adds detail to a technique that has been discussed in security circles for years: keeping malicious code in memory so that file-based tools have nothing to find. In this case, the rootkit intercepts the memory-mapping of specific BIG-IP APM files, meaning the malicious code never needs to touch disk at all.

For organizations running BIG-IP APM, the practical takeaway from the report is that a clean filesystem scan is not proof of a clean system. The implant's design assumes defenders will check files first — and it is built to survive exactly that check.

What this means for the industry

This report suggests that the gap between patch status and actual compromise may be wider than many organizations assume. If the technique works as described, then a system that was vulnerable before it was patched could still be serving a hidden shell to an attacker, and file-integrity monitoring would not flag it.

For businesses that rely on BIG-IP APM as an identity gateway, the stakes are elevated: the appliance holds the keys to SSO tokens, credentials, and policy decisions that downstream applications and SaaS tenants trust. A compromise that hides in memory could mean that trust is being abused long after the initial vulnerability is closed. The clear implication is that defenders need to treat memory and runtime behavior as first-class evidence, not as a fallback when file scans come back clean.