A web shell normally leaves something behind. A PHP file, a timestamp, a suspicious parameter, perhaps an eval() buried in a directory that nobody remembers creating. Investigators hunt for these artifacts because they anchor the investigation to the filesystem, where tools are mature and evidence is relatively stable.

Now imagine opening the filesystem and finding nothing.

cover

The PHP files are legitimate. Their hashes match known-good versions. File integrity monitoring shows no changes. Yet Apache is serving a web shell.

That scenario describes a Linux implant recently analysed by Sophos in compromised F5 BIG-IP Access Policy Manager environments (ESET independently analyzed the same malware and named it PoisonedRefresh). The rootkit doesn’t replace files or leave malicious code on disk. Instead, it hooks Apache and PHP at runtime to modify how legitimate scripts appear to the running process.

This is a useful reminder that “fileless” doesn’t mean “artifactless.” It means the artifacts have moved somewhere else, and for incident responders, that distinction matters considerably.

In brief

  • F5 BIG-IP APM devices have been targeted with a Linux rootkit that hides a PHP web shell in Apache process memory rather than writing the final payload to disk.
  • The activity has been associated with CVE-2025-53521, an unauthenticated RCE vulnerability in BIG-IP APM that CISA added to its Known Exploited Vulnerabilities catalogue.
  • The implant hooks Apache’s APR module loading and PHP’s memory-mapping behaviour, altering the in-memory representation of selected PHP scripts.
  • A second access mechanism uses a Unix domain socket to hand an authenticated connection directly to /bin/bash, avoiding a conventional TCP listener.
  • Traditional filesystem scanning produces a reassuringly clean result on a compromised system.
  • Proper response requires combining filesystem, process, memory, network, and platform-specific forensic analysis, with volatile evidence collected before any remediation.

The vulnerability that opened the door

The rootkit is interesting, but the story starts earlier.

CVE-2025-53521 affects F5 BIG-IP APM when an access policy is configured on a virtual server. The vulnerability is an unauthenticated remote code execution flaw that F5 initially misclassified, then corrected when exploitation was observed in the wild.

CISA added it to its Known Exploited Vulnerabilities catalogue in March 2026. That timing is significant. This wasn’t simply another vulnerability sitting in a scanner dashboard. It was already being weaponized.

The attack surface is particularly valuable from an attacker’s perspective. BIG-IP APM sits in a privileged position: it controls authentication and access to downstream applications, APIs, and data. Compromising an application server is unpleasant. Compromising something that sits in front of applications and controls access to them opens entirely different possibilities.

F5 has associated the activity described by Sophos with systems compromised via CVE-2025-53521. The Sophos analysis suggests the malware is a second-stage payload, deployed after initial exploitation.

That detail deserves attention. A rootkit that disappears when Apache restarts is annoying. A rootkit with mechanisms to survive the platform’s own upgrade process is a different problem entirely.

The web shell that isn’t a file

The most interesting technical aspect is how the implant exploits the boundary between a file on disk and its runtime representation.

BIG-IP APM’s webtop environment contains PHP scripts like apm_css.php3, full_wt.php3, and webtop_popup_css.php3. The rootkit doesn’t replace these files with malicious versions. Instead, after Apache loads PHP, it hooks the relevant runtime functions. When Apache tries to read one of the targeted scripts, the implant intercepts the operation and constructs a different view in memory. The filesystem remains clean. The PHP interpreter receives something malicious.

Suppose an investigator runs sha256sum /path/to/apm_css.php3 and compares it to a known-good reference. Everything matches. Now Apache opens that same file. The running process doesn’t necessarily see what the investigator sees on disk. The implant has changed what the application believes that file contains.

Web shells are normally implemented as malicious content. This implant implements the web shell as malicious runtime behaviour.

MITRE ATT&CK classifies traditional web shells under T1505.003, describing them as server-side components providing adversaries with access and often a command-line interface. That taxonomy assumes the shell is something you can find, examine, and remove from the filesystem. This approach breaks that model entirely.

A detector looking for “new PHP files” has nothing to find. A detector looking for “modified PHP files” finds nothing. A detector looking for suspicious eval() statements in the source finds nothing. The malicious code exists, but your filesystem scanner is looking in the wrong place.

That’s the sort of thing that tends to make incident responders develop a healthy distrust of clean hashes.

What the rootkit actually does

Sophos’s reverse engineering reveals a sophisticated implementation.

The sample is a stripped, statically linked ELF binary that doesn’t behave like a typical Linux executable. It contains its own loader logic and takes control very early in the process startup sequence. One critical target is __libc_start_main, the function that normally bridges the raw process startup and the application’s main() function.

Normally a Linux process follows this path:

_start
   |
   v
__libc_start_main()
   |
   v
main()

The implant inserts itself into that startup path, establishing its hooks before Apache’s normal application logic begins. This gives it control over what happens during Apache’s entire lifetime, not just after it’s fully initialized.

The malware also uses runtime string decryption. Sophos identified RC4-based obfuscation protecting strings related to process inspection, Apache, PHP, and memory operations. That’s telling. The implant isn’t dropping a generic Linux backdoor onto an arbitrary server. It is specifically engineered for Apache, APR, PHP, and the particular structure of BIG-IP APM’s webtop.

The implant hooks apr_dso_load, effectively waiting for Apache to load the PHP module. Once libphp is present, it can manipulate PHP-related behavior at a deep level. The result is process-level compromise. The attacker isn’t just controlling one malicious PHP script. The runtime environment executing PHP has been tampered with.

Sophos identified three particularly effective elements:

  1. The implant executes before the normal application startup path.
  2. It activates specifically when the PHP runtime is present.
  3. It provides multiple routes to command execution.

The second access mechanism is especially interesting. The malware creates a Unix domain socket at /run/bigtlog.pipe. After a token check, a connection to the socket gets redirected to /bin/bash. There’s no conventional TCP listener. Sophos didn’t find code in the sample that directly exposes this mechanism over HTTP.

From a network monitoring perspective, that’s inconvenient. There’s no obvious LISTEN socket on an unusual port. There may be no reverse shell connection to an external address. Just a local Unix socket and a process capable of turning it into an interactive shell.

The attacker gets two access primitives: an HTTP-facing web shell and a local interactive shell. That’s considerably more useful than another obfuscated cmd.php.

Why memory becomes the crime scene

This is where the incident becomes critically relevant to DFIR.

The traditional web shell investigation workflow is filesystem-centric:

web root
   |
   +-- suspicious files
   +-- modified timestamps
   +-- unexpected scripts
   +-- suspicious permissions
   +-- known web-shell signatures

That workflow remains useful, but it is simply insufficient for this attack.

When malicious content is assembled after the file has been opened, investigators need to examine the state of the process that interpreted the file, not only the file itself. That’s where memory forensics becomes essential.

I’ve written before about how memory analysis can recover evidence that has disappeared from conventional artifacts, including how Windows manages memory and how Volatility reads it. The same principles apply here.

A memory image can potentially expose:

  • Unexpected executable memory regions
  • Modified memory mappings
  • Hooks on libc, Apache, or PHP functions
  • Injected code
  • Decrypted strings
  • Process relationships and loaded modules
  • Unix sockets and associated kernel structures
  • Suspicious memory permissions
  • PHP content that differs from what’s on disk

That difference between disk and memory is particularly valuable. If the filesystem is acquired after compromise, the PHP file may look perfectly legitimate. If the Apache process is captured while the rootkit is active, the malicious in-memory representation may still be present.

The memory image is often where the attacker stopped being careful. This principle appears repeatedly in memory forensics work. My recent analysis of eBPF rootkits and the limitations of conventional Linux memory analysis makes a similar point: when a rootkit operates at a deep level of the kernel, it tends to leave more traces in RAM than on disk.

There’s an important operational consequence here. If you suspect a BIG-IP device has been compromised, do not reboot it because “the latest image is installed anyway.” A reboot destroys precisely the volatile evidence that can explain what happened.

The first objective should be evidence preservation, followed by platform-specific compromise assessment and remediation according to F5’s published guidance.

What defenders should look for

Sophos identified several practical detection signals.

HTTP traffic to specific PHP scripts: Requests to apm_css.php3, full_wt.php3, or webtop_popup_css.php3 deserve investigation, particularly in conjunction with other signals.

Anomalous HTTP response patterns: Sophos observed PHP endpoints returning HTTP 201 (Created) while presenting themselves as CSS resources. That combination is sufficiently unusual to warrant investigation.

Process behavior: Apache worker processes accessing /proc/self/maps and subsequently changing memory permissions. Individually, either behavior is potentially benign. Together, in context with other suspicious activity, they’re worth examining.

Local Unix sockets: The presence of /run/bigtlog.pipe associated with Apache. Again, context matters. A Unix socket with a plausible name isn’t automatically malware. But a socket tied to an Apache process, accompanied by suspicious PHP behavior and unexplained memory modifications, is worth investigating.

The absence of obvious filesystem artifacts: A clean filesystem should no longer be considered exculpatory. This is perhaps the most important lesson. MITRE’s detection guidance for web shells still emphasizes file creation, process creation, and suspicious HTTP traffic. Those signals remain valuable, but the F5 case demonstrates why filesystem cleanliness alone is an insufficient basis for declaring a system safe.

For a suspected compromise, structure the investigation around several correlated questions rather than looking for a single magic indicator:

  1. Was the appliance vulnerable? Establish the BIG-IP version, APM configuration, and exposure to CVE-2025-53521.

  2. Was exploitation possible or observed? Review relevant HTTP, APM, and system logs for anomalous requests and suspicious activity preceding the compromise.

  3. Has Apache been modified? Validate the integrity of /usr/sbin/httpd and investigate unexpected changes to installation or upgrade artifacts.

  4. Does the runtime differ from the filesystem? Compare known-good PHP content with what’s mapped into the Apache process.

  5. Are there suspicious hooks or memory regions? Examine process memory, mappings, permissions, and loaded components.

  6. Are there unexpected local communication channels? Investigate Unix domain sockets as well as conventional network connections.

  7. Can persistence survive remediation? Treat suspicious upgrade images, SELinux changes, and other platform-level modifications as evidence rather than assuming that restarting Apache has solved the problem.

The last point is particularly important. The related installer analyzed by Sophos can infect the Apache binary and persist through BIG-IP upgrade images. Incident response becomes a platform-integrity problem, not simply a PHP cleanup exercise.

The appropriate remediation path should follow F5’s compromise-assessment and remediation guidance, rather than improvising generic Apache hardening measures on a specialized appliance.

The bigger lesson: fileless does not mean invisible

There’s a temptation to describe this as an especially clever web shell. I think that undersells what’s happening.

The more interesting development is the movement of malicious state across forensic boundaries. First-generation web shells were files. Then attackers became better at hiding files. Then came memory-only execution, reflective loading, injected code, and runtime manipulation.

Now we have a case where the attacker doesn’t merely execute malicious code from memory. The attacker changes what the application believes a legitimate file contains. The filesystem remains one version of reality. The compromised process sees another. Both can be technically correct from their respective perspectives.

This is exactly the situation where DFIR methodology has to evolve. The investigator can’t simply ask “Where is the malware?” The better question is “Which layer of the system has been modified?” The answer might be the filesystem. It might be the process. It might be the kernel. It might be firmware. And increasingly, it might be all of them simultaneously.

The F5 incident reinforces a principle that appears repeatedly in modern memory forensics: volatile evidence isn’t secondary evidence. If the decisive malicious component exists only in an Apache worker’s address space, waiting until after reboot to collect evidence is equivalent to arriving at a crime scene with a mop.

This reasoning applies beyond F5. Linux servers running Apache, PHP, Java, Node.js, or other extensible runtimes should not be considered safe simply because their web roots contain no suspicious files.

The good news is that memory still remembers. Process mappings, executable pages, hooks, decrypted strings, sockets, module state, and other runtime structures leave traces long after the obvious filesystem artifact has disappeared. That makes memory forensics increasingly less of a specialist technique and more of a basic requirement for serious incident response.

The F5 rootkit is a particularly elegant demonstration of why. The web shell is still there. You just have to look in RAM.

FAQ

What makes the F5 BIG-IP rootkit different from a traditional web shell?

The web shell exists only in memory. The rootkit modifies how selected PHP files are mapped into Apache’s address space, creating a malicious in-memory version while the filesystem copy remains untouched.

Which F5 BIG-IP vulnerability is associated with this activity?

F5 linked the activity to CVE-2025-53521, an unauthenticated remote code execution vulnerability in BIG-IP APM that was exploited in the wild.

Can memory forensics detect a web shell that does not exist on disk?

Yes. A memory image can expose modified process mappings, injected code, unexpected memory permissions, hooks, strings, sockets, and other runtime artifacts that filesystem analysis cannot detect.