In-Memory PHP Shell Sidesteps Disk Scans

When an attacker compromises an F5 BIG-IP Access Policy Manager appliance, the final payload may never touch the disk. Researchers at Sophos have detailed how a malware family linked to breaches of these appliances keeps its web shell solely in memory, injecting it into PHP scripts only as they are loaded by the Apache web server. This lets the malicious code operate while a scan of the underlying files reveals nothing unusual.

Sophos published its analysis on September 7, explaining a technique that sidesteps a common defensive approach: comparing files on disk against known-good copies to detect tampering. The web shell's code is added to the in-memory copy of a legitimate PHP script right as Apache loads it, meaning the file stored on disk remains unchanged and can appear perfectly clean.

The analysis outlines how the malware achieves this and what it does once it has a foothold, while also noting the limits of current visibility into the full intrusion chain.

Three Scripts, One Target

Sophos examined a single sample and found the malware focuses on three specific PHP scripts that are part of the BIG-IP APM webtop interface: apm_css.php3, full_wt.php3, and webtop_popup_css.php3. These are the same files that F5 flagged to customers in March as indicators of compromise for the activity it tracks as c05d5254.

At the time, F5 cautioned that the mere presence of these files does not by itself indicate a security problem. The Sophos research explains why that guidance and observed attacks can both be accurate: the malware adds its web shell to the scripts' in-memory representation, not to the files themselves. As the researchers put it, the web shell "does not need to exist in its final form on disk."

F5 had also noted that while some observed cases did involve a web shell written to disk, others showed web shells working only in memory, which would leave the listed files unmodified.

The Underlying Vulnerability

F5 links the c05d5254 activity to exploitation of CVE-2025-53521, according to the Sophos report. The vendor first disclosed that flaw on October 15, 2025, initially describing it as a denial-of-service problem. On March 27, 2026, F5 revised its assessment after receiving new information, reclassifying the issue as remote code execution and confirming it had been exploited in the wild.

An attacker does not need any login credentials to exploit the vulnerability, and F5 rates its severity at 9.8 on the CVSS 3.1 scale and 9.3 on CVSS 4.0. The U.S. Cybersecurity and Infrastructure Security Agency added the flaw to its Known Exploited Vulnerabilities catalog the same day, giving federal civilian agencies until March 30 to remediate it.

The vulnerability applies in configurations where a BIG-IP APM access policy is set on a virtual server. F5's advisory lists specific affected and fixed releases, spanning versions from 15.1.0 through 17.5.1, with patches available in 15.1.10.8, 16.1.6.1, 17.1.3, and 17.5.1.3.

Patch Age and Persistence

For organizations that have applied the fix, the patch itself is now nearly a year old. Ireland's National Cyber Security Center said in a March 31 advisory that the update released in October remains valid and effective against exploitation of the flaw.

However, patching does not answer the question of whether an appliance was already compromised before the update was installed. The Irish NCSC noted that no timeline for exploitation is available and that some attacks may have occurred before the flaw and its fix were first publicized in October 2025. The UK's NCSC likewise advises organizations to investigate for signs of compromise "regardless of when the system was updated."

Infection Below the Web Server

The in-memory web shell is the final stage of a longer infection chain, and the earlier stages do leave marks on disk. Sophos said a separate installer, found in a sample called umount, infects the Apache web server binary at /usr/sbin/httpd by prepending malicious code to the real file. The size of that added code matches the payload carried inside the installer, which Sophos said strongly suggests the installer is responsible for placing it there.

ESET, which analyzed related samples in April and named the malware PoisonedRefresh, said the installer is designed to run as root and disables SELinux. It also infects umount, httpd, and rc.local inside BIG-IP installation images, which ESET said was presumably intended to spread the malware to other systems via installation media.

How the Shell Gets Into Memory

Because the malicious code lives inside the Apache binary, it executes before Apache's own routines start. Sophos said it hooks the Apache Portable Runtime function apr_dso_load and remains dormant until Apache loads the PHP module, libphp.

Once PHP is active, the malware reads /proc/self/maps to locate the module in memory. It briefly makes those memory pages writable, rewrites the function calls the module uses to open, size, and map files, then restores the original permissions. From that point onward, it controls what PHP sees whenever it accesses one of the three targeted scripts. When the file is mapped into memory, the malware inserts the web shell before the original content.

A Quiet Channel for Commands

The injected web shell operates discreetly. It reads the raw body of an incoming request, checks it for a short marker, decrypts the remainder, and executes it. The response is sent with HTTP status 201 and a CSS content type, making the exchange resemble a routine request for a stylesheet.

Separately, the malware opens a local socket at /run/bigtlog.pipe. After verifying a fixed token, it connects that socket to /bin/bash, providing an interactive shell without opening any network port. Sophos said it could not find code in the sample for connecting to that socket, nor any other use of the token, suggesting the two access methods are separate features. The researchers said they have no evidence either way on whether an attacker reaches the socket through the web shell.

Signs for Defenders to Check

Sophos emphasized that its behavioral signals are leads for investigation, not proof of compromise on their own, and should be weighed alongside file, process, and memory evidence. The list below combines those signals with indicators F5 published in March:

• File: presence of /run/bigtlog.pipe or /run/bigstart.ltm
• Binary: hash, size, or timestamp mismatch on /usr/bin/umount or /usr/sbin/httpd compared with a known good copy. F5 notes sizes and timestamps vary between releases and engineering hotfixes
• Tool: sys-eicheck failing because one of those two files has changed
• Log: an entry in /var/log/restjavad-audit showing a local user reaching the iControl REST API from localhost
• Log: an entry in /var/log/auditd showing SELinux being switched off via the same route
• Log: an entry in /var/log/audit showing a bash command run through iControl REST, with base64 data written to a file and /run/bigstart.ltm being executed
• Traffic: HTTP 201 responses carrying a CSS content type from the appliance
• Host behavior: an Apache worker reading /proc/self/maps, altering memory permissions around libphp, binding a socket under /run, or starting /bin/bash
• Hash: SHA-256 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9
• File (weak on its own): changes to the three .php3 scripts, though F5 says their presence alone does not prove a problem, and the Sophos analysis explains why the file need not change at all

F5's list also includes items the Sophos analysis does not cover, including /run/bigstart.ltm and the changes that affect sys-eicheck. Neither account describes the full intrusion.

Steps After Patching

For organizations that already applied the patch, Ireland's NCSC recommends running F5's built-in sys-eicheck integrity check; per F5's own indicators, modifications to /usr/bin/umount and /usr/sbin/httpd will cause this tool to fail, so a failure is itself a signal. It also advises collecting a qkview report and sending it to F5 while raising a support case, noting F5 can examine the report for signs of compromise and that an associated case yields a quicker, fuller response.

Sophos additionally recommends comparing the contents of modules in memory against their copies on disk, a step it suggests adding to incident response playbooks for critical web servers. Where a full investigation is not feasible, the UK NCSC advises isolating the appliance and rebuilding it as new, while acknowledging this may cause an outage.

What Remains Unknown

Several key facts are still unresolved. F5 has not disclosed when exploitation first began. None of the published advisories or analyses state whether upgrading an appliance to a fixed release removes malware that is already installed, and both Sophos and ESET describe a component designed to survive upgrade images.

No attacker has been publicly identified. Sophos said it lacks sufficient evidence to name a group, and ESET said in April that it had not settled the question either.

Why This Matters for Your Environment

This analysis points to a blind spot that may exist in many network teams' detection playbooks. Standard file-integrity monitoring and disk-based scanning would miss this web shell entirely, since the malicious code never persists to storage. For organizations running BIG-IP APM, the implications are direct: patching the underlying vulnerability is necessary but not sufficient, because clean files on disk do not rule out an active in-memory compromise.

The emphasis on memory-based detection and behavioral indicators suggests that defenders must look beyond filesystem artifacts when investigating these appliances. For teams that have not yet done so, this could mean adding memory inspection to incident response procedures and treating the presence of the listed indicators seriously, even when disk scans return clean results.

The apparent resilience of a component in upgrade images also means that a straightforward version upgrade may not clear an infection, making a full rebuild the safer course for any appliance with signs of prior compromise. Given that the underlying flaw has been confirmed as actively exploited and carries a near-maximum severity score, the practical takeaway is that verifying the absence of malware requires more than checking for file changes.