Sophos Dissects Stealthy PHP Rootkit That Hides a Web Shell

Sophos Dissects a PHP Rootkit That Keeps Its Web Shell Out of Sight

Web shells are usually associated with malicious scripts left behind on a compromised server. Investigators can search web directories, compare files against known-good versions and inspect suspicious PHP code.

A newly analysed Linux implant shows why that approach can be insufficient.

Sophos X-Ops has dissected a malware sample associated with compromised F5 BIG-IP Access Policy Management (APM) environments using Apache and PHP. Rather than relying on a conventional web shell stored on disk, the implant manipulates Apache and PHP at runtime and creates a malicious in-memory view of selected PHP files.

That distinction is important.

The PHP files can remain unchanged on disk while the compromised Apache process sees additional malicious content in memory. This gives the attacker a web-shell capability without requiring the final malicious PHP code to exist as a conventional file.

Sophos also found a second access mechanism involving a local UNIX domain socket that can provide an interactive /bin/bash session without opening a traditional TCP listening port.

The result is a Linux implant that combines custom ELF loading, startup interception, Apache Portable Runtime (APR) hooks, runtime memory patching and fileless PHP web-shell delivery.

The BIG-IP APM connection

Sophos says the malware targets environments featuring Apache, libphp, APR module loading and BIG-IP APM webtop components.

The research links the observed activity to BIG-IP APM systems affected by CVE-2025-53521, an exploited unauthenticated remote code execution vulnerability under the conditions described by F5.

Sophos stresses that the observed targeting is focused on BIG-IP APM webtop environments rather than generic Apache/PHP servers or common CMS platforms. citeturn0view0

The researchers also analysed a related umount sample and believe the malware uses a staged architecture.

According to Sophos, the first-stage component appears to handle deployment, persistence and propagation, while the infected httpd component provides runtime manipulation, web-shell delivery and interactive access.

The researchers found evidence that the installer component can infect /usr/sbin/httpd, persist across BIG-IP upgrade images and modify SELinux configurations.

Sophos says the malicious prefix size in the infected httpd matches the payload embedded in the related umount sample, supporting the assessment that the latter was responsible for deploying the former.

Important: Sophos did not attribute the malware to a specific threat actor.

Why this rootkit is different from a traditional web shell

A conventional web shell normally leaves an artifact on disk.

An attacker may place a PHP file somewhere within a web-accessible directory and then send specially crafted HTTP requests to execute commands through it.

That creates several potential investigation opportunities:

The malicious file can be discovered.
File integrity monitoring can identify unexpected changes.
Web-server logs may reveal suspicious requests.
Security teams can compare the file against a known-good version.

The Sophos sample changes this model.

Sophos identifies three major characteristics:

Fileless web-shell delivery
Process-level manipulation
Multiple access paths

Instead of permanently modifying the targeted PHP file, the malware changes how PHP sees that file when it is mapped into memory.

The malicious web shell therefore exists as part of the process's runtime state rather than simply as an obvious file on disk.

A custom loader executes before normal application logic

One of the first technical details Sophos identified is the malware's unusual startup behaviour.

The infected binary does not simply follow the conventional Linux startup sequence.

Instead, its entry point transfers execution into a custom loader.

The loader reopens its own executable through /proc/self/exe, locates the preserved original executable and manually loads its embedded ELF content into memory.

It then redirects execution through a modified __libc_start_main path.

Conceptually, a normal execution path looks like:

_start
  |
  v
__libc_start_main
  |
  v
main()

The malware changes this to:

_start
  |
  v
Custom loader
  |
  v
real __libc_start_main
  |
  v
malware wrapper
  |
  v
main()

This gives the implant an opportunity to initialise itself before the legitimate application reaches its normal execution flow.

Sophos says this provides a stable execution point where the malware can resolve APIs and install hooks before application threads begin meaningful work.

For defenders, this means suspicious activity occurring extremely early in an Apache process can be significant.

Access to /proc, memory permission changes and unusual startup behaviour may provide useful clues before conventional application logging is fully active.

RC4 hides the implant's operational strings

The sample is stripped and statically linked, making conventional static analysis more difficult.

Sophos found that many important strings are stored in encrypted form and decrypted at runtime using RC4.

The researchers identified a hardcoded 16-byte RC4 key and recovered strings associated with:

/proc/self/exe
/proc/self/maps
__libc_start_main
apr_dso_load
apr_time_now
libphp
open
close
mmap
pthread_create
pthread_detach

Individually, these strings could appear unremarkable.

Together, however, they reveal an implant designed to understand Linux process internals, Apache's runtime architecture and PHP execution.

Sophos describes the RC4 functionality primarily as an obfuscation mechanism rather than as the core access mechanism.

This is significant for malware analysis because simple string extraction may not immediately reveal the implant's functionality.

Apache becomes the malware's control point

Once the implant gains early execution, it does not immediately manipulate every component inside Apache.

Instead, it waits for Apache to load PHP.

The malware hooks the APR function apr_dso_load, which is involved in dynamic module loading.

When the implant detects that libphp is being loaded, it begins modifying behaviour inside the PHP module.

This selective activation is important.

Rather than applying its modifications indiscriminately, the malware waits for the environment it appears designed to target.

Sophos also identified a hook on apr_time_now, which is frequently called by Apache.

The researchers assess that this function acts as a delayed trigger for additional activity, including starting the worker responsible for the UNIX socket backdoor.

This approach reduces the need for the implant to perform all of its activity immediately after process startup.

The implant finds libphp inside process memory

After PHP is loaded, the malware needs to identify where the PHP module resides in memory.

It uses:

/proc/self/maps

Linux exposes process memory mappings through this interface.

The implant searches those mappings for libphp and identifies its relevant memory range.

It then follows a sequence described by Sophos:

read /proc/self/maps
        |
        v
find libphp
        |
        v
change memory permissions
        |
        v
patch relocations
        |
        v
restore protections

The critical point is not simply that the malware reads /proc/self/maps.

Legitimate software can do that.

The stronger detection signal is the combination of:

process mapping inspection + memory permission changes + executable-region modification + Apache/libphp context.

Runtime hooking changes how PHP handles files

The implant then uses relocation-based hooking and direct modification of call targets inside libphp.

Among the affected operations are functions associated with file and memory handling, including:

open
close
mmap
__fxstat

This gives the malware control over how PHP opens, sizes and maps selected PHP scripts.

That capability becomes the foundation for the most notable part of the attack: the in-memory web shell.

The web shell is injected when PHP maps a file

Sophos identified three targeted PHP files:

apm_css.php3
full_wt.php3
webtop_popup_css.php3

These files appear to have been selected because they belong to the targeted BIG-IP APM webtop environment.

When PHP opens one of these files, the implant tracks its file descriptor.

When PHP subsequently maps the file into memory, the malware intercepts the mmap() operation.

Instead of simply exposing the original file contents to PHP, the implant creates a modified in-memory representation containing the embedded web shell alongside the legitimate script.

The important distinction is this:

The final malicious web shell does not need to be present in the file on disk.

The malicious content is created as part of the runtime memory representation.

This is the core reason the technique can undermine traditional file-centric investigations.

A responder could inspect the PHP file and find nothing obviously malicious while the compromised Apache process is executing a different in-memory representation.

The malicious PHP payload disguises itself as normal web traffic

The embedded PHP payload behaves like a conventional web shell but incorporates additional measures to make detection harder.

According to Sophos, it:

Reads request data through php://input
Looks for a specific request prefix
Decrypts the remainder of the request
Executes the resulting content
Returns HTTP status 201
Uses text/css; charset=utf-8 as its content type

The combination is notable because the endpoint can appear to behave like a CSS resource while actually providing attacker-controlled PHP execution.

Sophos also found that important web-shell strings were rewritten at runtime, further complicating static signature matching.

A second backdoor avoids a TCP listener

The implant does not rely exclusively on its HTTP-based web shell.

Sophos found that it also creates a UNIX domain socket:

/run/bigtlog.pipe

This gives the malware another potential access mechanism without requiring a conventional TCP listening port.

After authentication, the implant redirects standard input, output and error streams to the socket and launches:

/bin/bash

This can provide an interactive shell session.

Sophos notes an important uncertainty here: researchers did not find built-in client-side code that would allow the threat actor to connect to the socket, and they found no additional references to the authentication token.

Therefore, Sophos could not confirm how the attacker would interact with this socket.

The research explicitly leaves open the possibility that the web shell could be used to interact with the socket, but says there is not enough evidence to confirm that scenario.

That distinction is important because it separates an observed capability from an unconfirmed operational assumption.

What defenders should look for

Sophos recommends treating the observed behaviours as investigation leads and correlating them with filesystem, process, memory and BIG-IP-specific evidence.

Web-layer indicators

Security teams should investigate:

Requests to the identified .php3 endpoints
Rare requests involving those paths
PHP responses returning HTTP 201
Responses claiming text/css; charset=utf-8
Repeated POST requests with unusual structures or body sizes

A particularly interesting signal is a PHP endpoint behaving like a CSS resource while returning an unusual HTTP status.

That combination should be investigated when it does not match expected application behaviour.

Host-level indicators

Sophos highlights several host-level behaviours:

Apache workers reading /proc/self/maps
Temporary memory permission changes around libphp
RWX to RX memory protection transitions
Relocation patching inside executable memory
Creation of /run/bigtlog.pipe
Apache-related processes launching /bin/bash
Standard input, output and error streams being redirected to a local socket

None of these signals should automatically be treated as proof of compromise in isolation.

The strength comes from correlation.

Incident response needs to include memory

The research has a broader lesson for incident responders.

If a server is suspected of running this type of implant, checking the filesystem is not enough.

The response should account for volatile evidence and the possibility that the running process has been modified.

Sophos recommends incorporating process-memory collection and comparisons between on-disk and in-memory module contents into incident-response procedures for critical web servers.

This matters because a responder can otherwise encounter a misleading situation:

Disk:
"PHP file looks legitimate"

Memory:
"PHP process contains malicious code"

The difference between those two views is central to understanding this malware.

Hardening considerations

Sophos outlines several broad defensive measures, while stressing that configuration changes should be evaluated for application impact.

Where .php3 execution is not required, organisations can consider disabling it after appropriate change-control and compatibility review.

The research also recommends minimising unnecessary PHP execution functionality and reviewing the use of potentially dangerous PHP functionality.

Sophos additionally discusses restricting ptrace and provides an Apache configuration example for denying access to .php3 files.

However, Sophos explicitly warns against applying generic Apache or PHP hardening as a blanket mitigation to BIG-IP APM systems without following the appropriate F5 guidance.

The bigger security lesson

The most important finding is not simply that Sophos discovered another web shell.

It is that the traditional distinction between "malicious file" and "legitimate file" becomes less useful when malware can alter the runtime representation of an application.

The attacker does not necessarily need to modify the final PHP file.

Instead, the implant modifies the process that interprets the file.

That changes the defensive problem.

A traditional investigation might ask:

"Is this PHP file malicious?"

A runtime-aware investigation also needs to ask:

"What does the compromised process actually see when it executes this file?"

That is a much broader question.

The Sophos analysis demonstrates how a Linux implant can combine a custom ELF loader, early startup interception, Apache APR hooks, memory patching and runtime PHP manipulation into a single access mechanism.

For defenders, the practical lesson is straightforward: filesystem visibility, network telemetry, process monitoring and memory analysis need to complement one another.

No single layer necessarily provides the complete picture.

What this means for enterprise defenders

The announcement highlights a broader industry shift toward runtime-focused Linux threat detection.

As malware increasingly manipulates processes rather than simply dropping obvious files, defenders need visibility into how applications behave while running.

For enterprises operating critical Linux web infrastructure, this could mean placing greater emphasis on:

Process-level telemetry
Memory integrity monitoring
Module-loading behaviour
Executable memory changes
Unusual local IPC endpoints
Application-specific behavioural baselines
Correlation between network and host activity
Incident-response procedures that capture volatile evidence

The development does not make conventional file-integrity monitoring obsolete.

Instead, it shows why file integrity is only one layer of a broader detection strategy.

Final Takeaway

Sophos' analysis of this PHP rootkit illustrates a more difficult class of Linux compromise.

The attacker-facing capability remains familiar: server-side command execution through a web shell.

The implementation is what changes.

The implant executes early, waits for Apache to load PHP, locates libphp, modifies runtime behaviour and injects malicious PHP into memory when selected files are mapped.

At the same time, a UNIX socket provides another potential route to an interactive shell.

The most significant defensive challenge is that the malicious web shell does not need to exist in its final form on disk.

That means defenders investigating sophisticated Linux compromises need to examine not only what is stored on the server, but also what running processes are doing with that data.

In this case, the filesystem may tell one story while the Apache process tells another.

Technical Indicators From the Research

Sample SHA256

26bd5b0722d1dbab5db749a063c49bc8638653ac2addfead7a9cb3d6d57bccc9

Sophos detection

Linux/Agnt-IC

Targeted PHP files

apm_css.php3
full_wt.php3
webtop_popup_css.php3

Local UNIX socket

/run/bigtlog.pipe

Relevant Linux and Apache functions

__libc_start_main
apr_dso_load
apr_time_now
mmap
open
close
__fxstat

Important process path

/proc/self/maps

Primary technology stack

Linux + Apache + PHP/libphp + APR + BIG-IP APM

Sophos Dissects Stealthy PHP Rootkit That Hides a Web Shell in Apache Memory