Entrar
PoisonedRefresh: A Fileless Linux Rootkit That Injects PHP Web Shells Into F5 BIG-IP APM Server Memory
PoisonedRefresh rootkit injects PHP web shells into F5 BIG-IP APM Apache memory, leaving no disk artifacts.
SophosLabs published a detailed technical analysis on September 8, 2026, of a Linux implant, dubbed PoisonedRefresh by ESET, they found in compromised F5 BIG-IP Access Policy Manager environments. Sophos tracks it as Linux/Agnt-IC. F5 has confirmed exploitation of the underlying vulnerability and links the activity to a cluster it tracks internally as c05d5254.
“The malware targets deployments featuring Apache, libphp, APR module loading, BIG-IP APM webtop components, and BIG-IP upgrade workflows, suggesting it was developed for specific environments. F5 associates the related c05d5254 activity with BIG-IP APM systems affected by CVE-2025-53521, an exploited unauthenticated RCE in BIG-IP APM when an access policy is configured on a virtual server.” reads the report published by SophosLabs. “If you believe you are, or have been, using affected BIG-IP APM versions, follow F5’s remediation and compromise-assessment guidance before applying generic Apache or PHP hardening recommendations.”
The short version: the web shell is real and works as expected, but the implementation removes almost every artifact defenders normally use to find it.
The initial access vector is CVE-2025-53521, an unauthenticated remote code execution flaw in BIG-IP APM when an access policy is configured on a virtual server. The Shadowserver Foundation observed 795 internet-exposed endpoints vulnerable to this CVE at the time of disclosure. The vulnerability was previously classified as a denial-of-service issue before F5 confirmed it as an RCE.
PoisonedRefresh is the second-stage payload. The first stage, which Sophos found hidden inside a modified Linux umount binary, infects /usr/sbin/httpd, modifies SELinux configuration, and embeds itself in BIG-IP upgrade images to survive device updates. Whatever the first stage does to gain persistence, the second stage is what gives the attacker operational capability.
The second-stage malware is a standalone Linux ELF binary that includes its own loader instead of relying on the normal Linux loader. When it starts, it intercepts libc_start_main, the function that normally starts Apache. This lets the malware run its own setup before Apache begins normal work, before logging systems fully start, and before some security tools can monitor the process.
“The second-stage sample hides key operational strings with RC4, gains execution before the host application main() function is invoked by intercepting __libc_start_main, targets Apache’s PHP module by hooking the Apache Portable Runtime (APR) module loader (apr_dso_load), and injects a PHP web shell into memory. It does the latter by manipulating mmap behavior inside libphp at runtime – so that only the infected process sees the malicious content and nothing ever touches the disk.” continues the report. “Alongside this web‑based access, the implant also creates a local UNIX domain socket and can redirect a connection into /bin/bash, enabling interactive access without opening a TCP listening port.”
The malware then waits instead of immediately changing the Apache process. It hooks apr_dso_load, the Apache function that loads shared libraries, and waits for Apache to load the PHP module (libphp). Once PHP loads, the malware checks /proc/self/maps to find where libphp sits in memory.
It then temporarily changes the memory permissions and redirects calls to file functions such as open, close, and mmap. After making the changes, it restores the original protections. From that point on, the malware can control how PHP handles files inside the Apache process.
The web shell delivery is where the analysis is most distinctive. The implant watches for PHP opening any of three specific BIG-IP APM webtop script files: apm_css.php3, full_wt.php3, and webtop_popup_css.php3. These are legitimate files that exist on the device. When PHP opens one and then maps it into memory, the implant intercepts that mmap() call and returns a modified view: the original script content preceded by the embedded PHP web shell. The on-disk file is never changed. The running process sees different content than what ls or a file integrity scanner would report.
The injected web shell reads raw data from php://input and looks for a special prefix, BSOHAzPB. It then decrypts the rest with a stream cipher using the key wSLjN1beuR and executes the result. To make its traffic look normal, it responds with HTTP status 201 and sets the content type to text/css. This makes the response look like a successful CSS file request on a BIG-IP APM device.
The implant also creates a local UNIX socket at /run/bigtlog.pipe. After a short authentication step using the token Kzwd6jM5, it connects the shell’s input, output, and error streams to the socket and starts /bin/bash. This gives the attacker an interactive shell without opening a TCP port, making the activity harder for network monitoring tools to detect.
The malware uses Apache’s apr_time_now function as a delayed trigger. It waits until the server has fully started before launching the socket worker, reducing the risk of disrupting Apache during startup.
The binary also encrypts its operational strings with RC4 using the hardcoded key TrswBWIl90Z5e38n. It decrypts them only when needed. As a result, static analysis mainly reveals function names and gives little information about what the malware is actually designed to do.
“Web shell detection mechanisms should include runtime behavior and memory inspection, not just file scanning.” continues the report. “For this class of threat, it is entirely possible for the on‑disk PHP file to appear benign, while the in‑memory mapping contains malicious code.”
Sophos recommends checking several indicators that could point to this malware. These include unusual mmap() or mprotect() calls shortly after libphp loads inside Apache worker processes, access to /proc/self/maps followed by changes to memory permissions, and the presence of the local socket /run/bigtlog.pipe.
Teams should also look for HTTP 201 responses with Content-Type: text/css when they do not match legitimate CSS or other asset requests. Other signs include unexpected changes to SELinux settings or modified BIG-IP upgrade images.
The SHA-256 hash of the analyzed sample is 26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9.
F5 has published remediation and compromise assessment guidance for CVE-2025-53521 and should be the first stop for affected BIG-IP APM operators, before applying any generic Apache or PHP hardening.
“This implant demonstrates how modern Linux malware can deliver familiar attacker capabilities through sophisticated delivery mechanisms.” concludes the report. “While the embedded PHP ultimately behaves like a traditional web shell, the surrounding infrastructure is considerably more advanced: custom ELF loading, early startup interception, APR-aware module monitoring, relocation patching, and memory-only payload delivery.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, PoisonedRefresh)
