Security · 10 Sep 2026 · Rob Nidschelm

The Files Look Clean. The F5 Appliance Could Still Be Backdoored.

An investigator can inspect three legitimate files on an F5 BIG-IP appliance, calculate clean hashes and still miss the web shell that Apache is executing.

SophosLabs has analysed a Linux implant associated with compromised BIG-IP Access Policy Manager environments. The malware modifies the running Apache and PHP process so that malicious PHP is added only when selected files are mapped into memory. The final web shell does not need to exist on disk.

F5 associates the related activity cluster, tracked as c05d5254, with systems affected by CVE-2025-53521. That critical BIG-IP APM vulnerability allows unauthenticated remote code execution when an access policy is configured on a virtual server. It is the access path connected to the broader activity, but Sophos describes the analysed implant as a second-stage capability installed after compromise.

The file on disk is not the file PHP executes

Traditional web-shell hunting assumes that the malicious script exists somewhere in the web root. Analysts compare files with known-good copies, look for recently created PHP pages and search for suspicious functions or obfuscated strings.

This implant changes that relationship. It waits for Apache to load libphp, locates the module in process memory and redirects the functions PHP uses to open, inspect and map files. When PHP opens one of three targeted BIG-IP APM webtop scripts, the malware prepends a web shell to the in-memory representation while leaving the stored file untouched.

• apm_css.php3
• full_wt.php3
• webtop_popup_css.php3

The result is a split view of the same path. A filesystem scanner sees the legitimate script. The infected Apache worker receives the legitimate content plus attacker-controlled PHP in memory.

The rootkit activates before Apache reaches its normal code

Sophos says the sample uses a custom ELF loader and intercepts __libc_start_main, giving it execution before the host application’s normal main function. It then hooks the Apache Portable Runtime function apr_dso_load and waits until Apache loads PHP.

After locating libphp through /proc/self/maps, the implant temporarily makes relevant memory pages writable and executable, patches selected calls and restores their permissions. The sequence is useful for hunting because Apache workers have little legitimate reason to inspect their own mappings and then alter executable pages inside PHP.

The web payload reads the raw HTTP request body, checks for the marker BSOHAzPB, decrypts the remaining content and passes it to PHP’s eval function. Its response uses HTTP status 201 and a text/css content type, allowing command traffic to resemble a stylesheet request.

A second shell does not open a TCP port

The implant also creates a local Unix socket at /run/bigtlog.pipe. After a token check, it connects the socket to /bin/bash and provides an interactive shell without listening on a new TCP port.

Sophos did not find a built-in client for reaching that socket and found no evidence proving whether the attacker accesses it through the web shell. Responders should therefore treat the two access paths as separate capabilities and avoid filling the missing connection with assumption.

The implant appears designed for BIG-IP upgrade workflows

The analysed payload is not generic PHP malware sprayed across ordinary web servers. Sophos found signs of a staged architecture targeting BIG-IP APM, Apache, PHP and appliance upgrade processes.

A related installer component infects /usr/sbin/httpd, modifies SELinux settings and places malicious content inside BIG-IP install images under paths such as /mnt/tm_install. This creates a persistence problem that a service restart cannot reliably solve. An infected upgrade image can carry the compromise into a later appliance installation.

ESET previously analysed related malware and named it PoisonedRefresh. Sophos independently observed overlapping behaviour. Neither company has publicly attributed the implant to a named threat actor, and implementation sophistication is not attribution.

Patching and compromise assessment are different jobs

The official vulnerability record lists fixed versions 17.5.1.3, 17.1.3, 16.1.6.1 and 15.1.10.8 for the affected branches. Products that have reached end of technical support were not evaluated. Administrators should follow F5’s current advisory because support status and recommended upgrade destinations can change.

An update prevents the disclosed entry path from being used against a corrected system. It does not remove code that executed before the patch, prove that an upgrade image is clean or restore trust in logs produced by a compromised appliance.

F5’s remediation and compromise-assessment guidance should therefore lead the response. Generic Apache hardening can support defence, but it is not a substitute for assessing the appliance as a potentially compromised control plane.

What defenders should hunt

• Requests to apm_css.php3, full_wt.php3 and webtop_popup_css.php3, especially unusual POST bodies.
• PHP endpoints that return HTTP 201 while identifying the response as text/css.
• Apache worker processes reading /proc/self/maps and then changing memory permissions around libphp.
• The Unix socket /run/bigtlog.pipe.
• Apache-lineage processes redirecting standard input and output before executing /bin/bash.
• Unexpected modifications to httpd, umount, rc.local, SELinux configuration or BIG-IP installation images.
• The SHA-256 hash 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9 for the Sophos sample.

Sophos cautions that individual behaviours are investigatory leads, not standalone proof of compromise. A legitimate process can read /proc/self/maps, and a request to a normal APM script is not automatically malicious. The value comes from correlating file, process, memory and network evidence.

Capture volatile evidence before restarting

An in-memory payload creates a difficult response trade-off. Restarting can interrupt malicious processes, but it can also destroy the most direct evidence of how the implant works and what it touched.

Where the incident plan and F5 guidance permit it, responders should capture process memory, running-process information, open files, local sockets, network connections and relevant logs before changing the appliance. Evidence should be stored outside the suspected system.

• Apply F5’s current remediation for the affected APM configuration and version.
• Follow F5’s compromise-assessment steps before relying on generic hardening.
• Collect volatile evidence from suspected systems before a restart or rebuild where this is operationally safe.
• Compare the in-memory behaviour of Apache and PHP with the corresponding files on disk.
• Inspect upgrade and installation images as potential persistence carriers.
• Rebuild from trusted media when compromise is confirmed or trust cannot be restored.
• Rotate credentials and keys that the appliance could access after preserving the evidence needed for the investigation.
• Move security telemetry off the appliance so an attacker cannot make the compromised control plane the only source of truth.

The most important lesson is forensic. File integrity is still useful, but it answers only what is stored. This implant changes what a trusted process sees and executes after the file has passed that check.

When the process can lie about the file, a clean hash is no longer a clean bill of health.

Sources

• SophosLabs: Dissecting a PHP web server rootkit, published 7 September 2026. The primary page provides a date but no publication time.
• F5 advisory K000156741, the vendor advisory referenced by the official CVE record.
• Official CVE record, published 15 October 2025 at 13:55:52 UTC and updated 31 March 2026 at 16:04:27 UTC.
• BleepingComputer: Hackers breach F5 BIG-IP APM devices to deploy Linux rootkit, published 8 September 2026. A precise publication time was not verified in this review.