Hackers hide a web shell in F5 BIG-IP server memory

Published

SophosLabs has taken apart a Linux implant recovered from compromised F5 BIG-IP Access Policy Manager (APM) appliances, and the interesting part is what a defender would not find. The malware hands an attacker the same thing a web shell does, on-demand code execution over ordinary web requests, except the shell is never written to disk. It is stitched into a legitimate script only as Apache reads that script into memory.

Sophos X-Ops researcher Luke Mitchell published the analysis this week. F5 associates the related activity cluster, tracked as c05d5254, with BIG-IP APM systems affected by CVE-2025-53521, an exploited unauthenticated remote code execution flaw that applies when an access policy is configured on a virtual server. Sophos is explicit about the order of operations for anyone who ran an affected version: follow F5's remediation and compromise assessment guidance first, before reaching for generic Apache or PHP hardening.

A web shell with no file to find

Once Apache has loaded its PHP module, the implant watches for three scripts belonging to the BIG-IP APM webtop: apm_css.php3, full_wt.php3 and webtop_popup_css.php3. When PHP opens one of them the implant notes the file descriptor, and when that file is memory mapped it hands PHP a modified view with the attacker's web shell sitting in front of the original script. The file on disk is left alone. As Sophos puts it, anything executing through the tampered PHP runtime may see a different version of those files than the one actually stored on the server, which quietly breaks the assumption behind file integrity monitoring and web root scanning. The shell is conventional once it runs, reading raw request bytes from php://input and waking only when the body opens with a short magic value, BSOHAzPB.

Running before Apache does

The binary is stripped and statically linked, and it skips the normal Linux startup path entirely. Its entry point jumps into a loader the authors wrote themselves, which reopens the process image through /proc/self/exe and wraps libc's __libc_start_main so implant code runs before the host program's own main function. The strings that would give the game away are RC4 encrypted and decrypted only at runtime, with a hardcoded key of TrswBWIl90Z5e38n. Then it waits. A hook on apr_dso_load, the Apache function that loads modules, keeps the implant dormant until Apache loads libphp, at which point it reads /proc/self/maps to locate the module, loosens the page protections on that mapping, patches the calls PHP makes to open, close, mmap and __fxstat, and puts the protections back.

A second door with no open port

Alongside the web shell, the implant opens a local UNIX domain socket and, after authentication, redirects input, output and error streams into /bin/bash. That is an interactive shell with nothing listening on a TCP port. Sophos also describes a separate installer component, found while analysing a related sample named umount, that infects /usr/sbin/httpd, survives BIG-IP upgrades by targeting install-image workflows, and edits SELinux configuration.

Sophos says it lacks sufficient evidence to attribute the malware to a specific threat actor, while reading the targeting and implementation as the work of an experienced team. Researchers at ESET analysed the same malware separately and named it PoisonedRefresh. The observed targeting centres on BIG-IP APM webtop environments rather than generic Apache or PHP deployments, so this is not a mass web hosting problem.

Hunt for the memory, not the file

File-centric detection will not catch this one. Sophos points defenders at behaviour instead: a process reading /proc/self/maps and then immediately changing memory permissions or writing into executable memory, and memory-protection changes inside an Apache worker shortly after libphp is loaded. An Apache worker has almost no legitimate reason to inspect its own memory map and then patch it. For anyone who ran an affected BIG-IP APM build, F5's compromise assessment work comes before hardening, because a patched appliance that was already implanted stays implanted. The reported sample carries SHA256 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9.

It joins a run of Linux implants built to defeat the tools defenders reach for first, alongside the kernel-level rootkit that hides from every tool you would use, and it lands on an appliance line that already had a BIG-IP flaw ship with workarounds instead of a patch last month.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions