A newly analyzed Linux rootkit gives attackers a stealthy way to maintain control of compromised F5 BIG-IP Access Policy Manager appliances. Rather than saving an easily discovered malicious PHP file, the implant modifies selected scripts only after the Apache process maps them into memory, leaving the corresponding files on disk unchanged.

Sophos researchers found the malware while investigating affected systems. F5 has linked related activity to CVE-2025-53521, an exploited unauthenticated remote-code-execution vulnerability. The available evidence points to a purpose-built second-stage implant for BIG-IP APM webtop environments, although researchers have not attributed it to a named threat group.

Runtime manipulation defeats simple file checks

The rootkit takes control very early in process startup. It opens its own executable image, manually loads the original program and intercepts a core Linux initialization routine before the application reaches its normal main function. This position lets it prepare hooks before ordinary Apache behavior begins.

It then monitors Apache’s module-loading activity and waits for the PHP library, libphp, to appear. Once present, the malware changes selected file and memory operations. When the server maps one of three targeted APM webtop scripts, the implant constructs a modified in-memory version that combines legitimate content with an attacker-controlled web shell.

Disk-based integrity tools can therefore report that the PHP files are clean while the running server executes altered code. Specially formed requests deliver encrypted commands to the injected shell. Responses use HTTP status 201 and appear to be CSS resources, a combination designed to blend malicious exchanges into routine web traffic.

A second channel avoids listening ports

The implant also establishes a local Unix socket capable of passing an authenticated connection to Bash. Because this mechanism does not create a conventional TCP listening port, network scans alone may not reveal it. On an appliance that controls remote access, durable server-side execution can provide an intruder with a valuable bridge toward protected internal systems.

Researchers believe the observed rootkit belongs to a broader installation chain. A related component may infect the HTTP server binary, alter SELinux settings and carry persistence into BIG-IP upgrade images. Merely restarting Apache, or even performing a routine upgrade without validating its source image, may leave the earlier persistence layer intact.

Detection requires memory and behavioral evidence

Responders should preserve volatile evidence before rebooting or rebuilding a suspected appliance. Process memory, active mappings, open local sockets and the process tree may expose behavior that cannot be reconstructed from the filesystem afterward.

• Look for Apache workers reading process memory maps or making unusual write-and-execute transitions around libphp.
• Compare the PHP content executing in memory with the corresponding files on disk.
• Investigate webtop endpoints that return status 201 while labeling responses as CSS.
• Review local Unix sockets and Apache child processes that launch Bash.
• Check SELinux configuration and verify the integrity of upgrade images.

Recovery should address the original entry point

Administrators should follow F5’s product-specific remediation and compromise-assessment guidance for affected APM releases. Where operationally appropriate, removing unneeded legacy PHP execution can reduce the exposed attack surface, but generic Apache hardening is not a substitute for addressing the BIG-IP vulnerability and hunting for persistence.

The discovery is a reminder that security appliances deserve the same endpoint-level visibility as ordinary servers. Their privileged position, specialized operating environments and limited monitoring often make them attractive targets. Effective recovery requires closing the initial flaw, analyzing both disk and memory, replacing untrusted components and rotating credentials that may have passed through the device.

Teams should also baseline normal response codes, module loads and child-process behavior on these appliances. That context can turn subtle anomalies into actionable alerts before an intruder uses the remote-access gateway to reach more valuable systems.