BIG-IP Malware Hides a Web Shell in RAM, Making Disk Scans Useless

Sophos published an analysis this week detailing a particularly clever piece of malware targeting F5 BIG-IP Access Policy Manager appliances. The trick: instead of dropping a web shell as a file on disk where any half-decent scanner might catch it, this one injects the shell directly into Apache's memory at runtime. The files on disk stay clean. Your scan comes back fine. The attackers are still in.

A conventional web shell is a script sitting in a web server directory, waiting for HTTP requests that tell it to run commands. Defenders find those by scanning files or comparing them to known-good copies. That playbook doesn't apply here. As Sophos put it, the web shell "does not need to exist in its final form on disk."

The three PHP scripts being targeted are apm_css.php3, full_wt.php3 and webtop_popup_css.php3, all part of the BIG-IP APM webtop. F5 flagged them back in March as indicators of compromise for the malware it tracks as c05d5254, but also noted that changes to those files alone don't confirm a breach. Sophos's analysis explains why both things are simultaneously true: the files don't have to change at all.

The underlying vulnerability is CVE-2025-53521. F5 originally published it in October 2025 as a denial-of-service issue, then quietly reclassified it in March 2026 as remote code execution after realising it had been actively exploited. No authentication required. CVSS scores of 9.8 and 9.3 depending on which version of the scale you prefer. CISA added it to its Known Exploited Vulnerabilities catalog the same day F5 updated its advisory, giving US federal agencies until March 30 to do something about it.

The patch has existed since October. The NCSC in Ireland confirmed it's still valid and still works. Plenty of appliances are apparently still unpatched.

How It Actually Works

The infection chain does touch the disk in its early stages. A separate installer, found in a sample called umount, prepends malicious code to the real Apache binary at /usr/sbin/httpd. Because the malware lives inside the Apache executable, it runs before Apache itself does.

From there it hooks an Apache Portable Runtime function, apr_dso_load, and waits. It does nothing until Apache loads the PHP module, libphp. Once that happens, the malware reads /proc/self/maps to locate the module in memory, briefly marks those memory pages as writable, rewrites the function calls PHP uses to open and map files, then restores the original permissions. After that, it controls what PHP sees when it reads any of the three target scripts. At load time, it inserts the web shell in front of the legitimate content.

The shell itself reads incoming request bodies, checks for a short marker, decrypts the payload, and executes it. Responses come back as HTTP 201 with a CSS content type, so the traffic looks like a stylesheet request. Nothing unusual to see here.

There's also a local Unix socket at /run/bigtlog.pipe. After validating a fixed token, it connects directly to /bin/bash, giving an interactive shell without touching the network. Sophos couldn't find code in the sample responsible for connecting to that socket, and isn't sure whether it's accessed via the web shell or something else entirely. Two entry points, possibly independent.

ESET, which analysed related samples in April under the name PoisonedRefresh, noted the installer runs as root, disables SELinux, and infects BIG-IP install images themselves. That last part is the nasty bit: it suggests the malware was designed to spread through installation media to other systems.

What to Actually Check

Sophos is clear that its behavioural indicators are starting points for investigation, not confirmation of compromise on their own.

On the file side: check for /run/bigtlog.pipe or /run/bigstart.ltm. Compare the hash, size, and timestamp of /usr/bin/umount and /usr/sbin/httpd against known-good copies for your specific release. Run F5's built-in sys-eicheck integrity tool. If it fails on either of those binaries, that failure is the signal.

In logs: look for entries in /var/log/restjavad-audit showing local users hitting the iControl REST API from localhost. Check /var/log/auditd for SELinux being switched off via the same route. F5 has noted that some audit log lines show base64 data being written to a file and /run/bigstart.ltm being executed.

In traffic: HTTP 201 responses with a CSS content type originating from the appliance deserve a second look.

On the host: an Apache worker process reading /proc/self/maps, fiddling with memory permissions around libphp, binding a socket under /run, or spawning /bin/bash are all worth investigating.

The SHA-256 for the known sample is 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9.

If You've Already Patched

Patching now doesn't tell you whether the appliance was compromised before the patch went on. Ireland's NCSC has said there's no reliable timeline for when exploitation started, and suspects it was happening before the flaw was even publicly disclosed in October 2025. The UK's NCSC advises investigating for compromise regardless of when the system was patched.

Collect a qkview report and raise a case with F5 directly. Ireland's NCSC says F5 can analyse that report for signs of compromise, and that opening a formal case gets a faster and more thorough response.

Sophos recommends adding memory-to-disk comparison of loaded modules to incident response playbooks for critical web servers. If a full investigation isn't feasible, the UK NCSC suggests isolating the appliance and rebuilding from scratch, accepting that this will likely cause an outage.

Three questions remain unanswered. Nobody has established when exploitation actually began. Nobody has confirmed whether upgrading to a patched release removes malware already present, and both Sophos and ESET describe components specifically engineered to survive upgrade images. And nobody has named the attacker. Sophos said it lacks sufficient evidence to attribute the activity to a known group. ESET said the same in April. For now, it's unattributed, actively exploited, and apparently designed to outlast your remediation efforts.