New research from Sophos X-Ops dismantles a core assumption behind years of web shell detection: that malicious code must eventually touch disk.
That assumption went out the door when Sophos X-Ops discovered a Linux rootkit found on compromised F5 Access Policy Manager appliances. The rootkit hijacks the Apache PHP module at the memory level.
It also demonstrates advanced cyber techniques. These include function hooking, runtime code patching, and custom ELF loading—where an OS kernel reads an Executable and Linkable Format file and maps its contents into virtual memory so the CPU can execute it.
Malware Payload Able to Bypass Controls
These techniques allow the rootkit malware to evade detection while maintaining persistent access through hidden web shells. In addition, the rootkit can intercept three legitimate webtop scripts as they load and silently prepend a web shell to the in-memory copy that Apache executes.
The result: As the file on the disk stays untouched, the malware payload can bypass file-integrity checks, signature scans, and static analysis with a clean bill of health. The compromise exists only in the memory of the running process—not in anything that a scanner can read from storage.
“The significance here isn't just that the web shell is stealthier,” points out Sean Malone, Chief Information Security Officer at BeyondTrust. “It defeats the assumption most response playbooks rest on: that the file on disk tells you what the server is running. The malware serves a poisoned copy of three legitimate BIG-IP APM files only inside the running Apache process—so hashes match, file-integrity monitoring passes, and the box looks clean while it's owned.”
Can a File Indicate Compromise But Not Prove Compromise?
This discovery resolves an apparent contradiction in the guidance provided by F5 earlier this year. In March, the company named the same three files as indicators of compromise while cautioning that their mere presence did not confirm a breach.
But this frames the core conundrum: How can a file be both an indicator of compromise and not proof of compromise?
In light of the new developments, the earlier statement from F5 now reads less like hedging and more like an early acknowledgment that the detection guidance couldn't fully account for what the malware was doing.
However, both F5 statements could be true at the same time. Files can appear unmodified on disk while compromised in memory.
“This is essentially a PHP shared-memory injection,” explains Mark Odom, Senior Solutions Engineer at Black Duck. “Three scripts are part of the portal's infrastructure, and when these files are read from disk into memory for execution, the malware intercepts that process. The timing is key: the injection happens after the file is read but before it actually runs, which is when the web shell code is inserted into the in-memory copy. “
Odom adds that a file integrity check compares a clean disk copy against a known-good hash and comes back clean, while the web shell stays hidden in memory. “This means file integrity checks can't be trusted as an indicator of compromise here,” Odom notes. “The most immediate guidance is to treat anything unpatched as potentially compromised. And because this is so difficult to detect, the best course of action is to re-image to a patched version or contact F5 directly for remediation guidance.”
Inside the Memory-Only Injection Mechanism
The F5 incident is tied to CVE-2025-53521, an unauthenticated remote-code-execution flaw that F5 originally classified as a denial-of-service bug before revising that assessment five months later. The new case provides a pointed reminder: Linux server malware is increasingly built to defeat the exact tools that defenders trust most.
Here’s how the rootkit malware injection mechanism works. Apache Portable Runtime hooking—the extension mechanism that lets developer modules register callback functions to run at specific processing stages—detects when the PHP software library loads. This allows web servers and applications to embed and execute the PHP code.
The malware intercepts the three BIG-IP webtop scripts as PHP maps them into memory. The web shell is prepended to the in-memory copy while the disk file is left clean. From there, custom ELF loading and early execution occur via hijacking of the library function that initializes the execution environment.
What Should Defenders Do?
As the Sophos analysis explains, the operational mechanics behind the F5 attack are a single-sample scope—with no named victim and an unclear acquisition method. The attribution of the attack is also unclear, but the implementation suggests an experienced operator.
Large enterprises, financial institutions, and public-sector organizations using the F5 appliances are likely affected by this issue. They will need to deal with dual-access channels that combine the web shell with a local Unix socket backdoor. The malware parallels other stealthy, memory-resident Linux implants.
This has major implications for how threat actors are adapting to file-based detection. It’s now clear that disk-based scanning alone can no longer confirm a clean system, and performing memory forensics and behavioral monitoring on exposed appliances is now mandatory.
“A layered response is essential,” warns Agnidipta Sarkar, Chief Evangelist at ColorTokens. “Establish a patching zone with software controls, apply patches to prevent new breaches, and use F5's IOCs along with memory and behavioral telemetry for threat hunting. If a compromise is found, rotate all credentials and tokens that have passed through the gateway. The compromised device serves as the identity gateway.”
