News Date: 2026-09-07
SophosLabs has detailed a Linux implant that challenges one of the most familiar assumptions in web-server incident response: that a PHP web shell must exist as a detectable file. The malware, observed in compromised F5 BIG-IP Access Policy Management environments, injects its server-side payload into memory while leaving the corresponding PHP files on disk apparently clean.
A rootkit built around the application runtime
The implant operates as a second-stage payload inside a modified Apache executable. It uses a custom ELF-loading process, intercepts the Linux startup sequence and waits for Apache to load libphp before activating its most important functions.
Once PHP is available, the malware hooks file and memory operations inside the running process. When selected BIG-IP webtop scripts are opened, it creates an altered in-memory version containing an embedded PHP web shell. The legitimate file remains unchanged on storage, meaning conventional file scanning and integrity monitoring may see nothing suspicious.
The rootkit also creates a local Unix domain socket capable of redirecting an authenticated connection into a command shell. This provides another access route without exposing a recognizable TCP listening port. Sophos found evidence that a related installation component could modify the Apache binary, weaken SELinux settings and preserve the compromise across BIG-IP upgrade workflows.
Why normal web-shell hunting may fail
- The malicious PHP code exists in process memory rather than in the web directory.
- Apache workers operate inside a manipulated runtime environment.
- Network scanning may miss the local socket-based command channel.
- Software upgrades may not remove the altered components.
Defenders responsible for potentially affected BIG-IP APM systems should follow F5's compromise-assessment guidance, isolate suspicious appliances and compare critical executables with trusted vendor images. Investigators should also look for unexpected access to process memory maps, changes to executable memory permissions, altered Apache binaries, unusual Unix sockets and modifications to SELinux configuration.
In my view, replacing or rebuilding a confirmed compromised appliance is safer than attempting to remove individual artifacts. When attackers have modified the web server's execution model, results collected from within that system can no longer be treated as fully trustworthy.
This research also highlights a broader change in Linux malware. Attackers are moving beyond obvious scripts and shared libraries toward runtime manipulation that defeats file-focused controls. Effective detection increasingly requires process, memory and behavioral visibility alongside traditional filesystem monitoring.