The question at hand
Your web shell scanner comes back clean. File integrity monitoring shows no changes. Hash verification passes. Yet, your F5 BIG-IP Access Policy Management environment is serving malicious code to every authenticated session.
This isn't theoretical. A rootkit targeting BIG-IP APM exploits CVE-2025-53521 to modify in-memory PHP files without touching the disk. The files you're scanning look legitimate because they are legitimate. The code Apache executes is something else entirely.
For SecOps teams, this creates a fundamental question: should detection strategies prioritize file-based scanning or memory analysis? The answer splits practitioners into two camps, each with defensible technical arguments.
The case for file-centric detection
File-based scanning remains the foundation of most detection programs for practical reasons. Your SIEM correlates file hashes. Your EDR watches for dropped payloads. Your compliance framework requires file integrity monitoring. When you respond to an incident, you image the disk, not the RAM.
The tooling ecosystem supports this approach. Commercial scanners index millions of malware signatures. Open-source projects like YARA let you write custom rules for suspicious PHP patterns. Your junior analysts know how to read file modification timestamps and check hashes against VirusTotal. Memory forensics requires specialized skills most teams don't have.
File-centric detection also produces durable evidence. A malicious file on disk persists through reboots, survives in backups, and holds up in legal proceedings. Memory contents change constantly and disappear when the process terminates. If you're building a case for attribution or regulatory reporting, you need artifacts that don't evaporate.
The performance argument matters too. Scanning files is cheap. You can hash every executable on a server in minutes. Memory analysis requires dumping process space, parsing data structures, and reconstructing execution state. That overhead doesn't scale when you're protecting thousands of endpoints.
For many threat scenarios, file scanning works. Most web shells still get dropped as .php or .jsp files. Most persistence mechanisms still modify startup scripts or cron jobs. If you're defending against commodity malware or script kiddies, file-based detection catches the majority of attacks.
The case for memory-first detection
The BIG-IP rootkit demonstrates why file-centric detection fails against sophisticated threats. The malware hooks Apache's PHP-loading process and modifies how selected files appear to the running process. It specifically targets three BIG-IP APM files: apm_css.php3, full_wt.php3, and webtop_popup_css.php3. When PHP attempts to memory-map one of those files, the rootkit intercepts the operation and creates a modified in-memory version containing the web shell alongside the legitimate script.
Your file scanner sees the original. Apache executes the poisoned copy. The gap between what's on disk and what's running is where the attacker lives.
Memory analysis reveals what's actually executing. You can dump the Apache process, extract loaded PHP code, and compare it to the files on disk. The discrepancy becomes visible immediately. You can also identify the rootkit's function hooks, its ELF loading mechanism, and the UNIX socket it opens for interactive shell access.
Behavioral telemetry complements memory forensics. Watch for Apache processes opening unexpected sockets. Monitor for PHP execution patterns that don't match the source files. Track system calls that indicate function hooking or runtime code patching. These signals appear only in memory and process behavior, never in file scans.
The threat landscape increasingly favors memory-resident techniques. Fileless malware, process injection, and reflective loading all bypass file-based detection. As defenders harden disk-based persistence, attackers move to volatile storage. If your detection strategy doesn't include memory analysis, you're defending against last decade's tactics.
For identity gateways specifically, memory-first detection is critical. BIG-IP APM processes credentials, SSO tokens, and policy decisions. An attacker with access can intercept authentication flows, inject authorization decisions, and pivot to downstream applications. Because these appliances sit at the network perimeter and terminate TLS, they're high-value targets. You can't afford to miss a compromise because your scanner only checked files.
Where practitioners actually land
Most SecOps teams run both, but the implementation varies widely. Large enterprises with mature detection programs layer memory forensics on top of file scanning. They use EDR platforms that capture process memory, correlate it with file activity, and flag discrepancies automatically.
Smaller teams rely on file scanning as their primary control and treat memory analysis as an incident response tool. They don't have the budget for advanced EDR or the staff to interpret memory dumps. When an alert fires, they check files first. If the investigation stalls, they escalate to specialists who can analyze memory.
The critical decision point is what triggers deeper analysis. Some teams use behavioral indicators: a BIG-IP appliance opening a UNIX socket, PHP executing code that doesn't match its source file, or Apache processes with unexpected memory mappings. Others rely on threat intelligence: if Sophos publishes indicators for a BIG-IP rootkit, you dump memory on every APM instance, regardless of what file scans show.
For systems that process authentication, the threshold should be lower. If you're running BIG-IP APM, Okta Access Gateway, or any identity proxy, assume file scanning isn't sufficient. These environments are commonly deployed by large enterprises, financial institutions, and public-sector organizations to provide remote access and federated SSO. The compromise implications extend beyond the appliance itself.
Our take
File-centric detection is necessary but not sufficient. You need it for baseline hygiene, compliance evidence, and catching commodity threats. But if you're defending identity infrastructure, memory analysis can't be optional.
The BIG-IP rootkit doesn't represent a distant threat. It exploits an unauthenticated remote code execution vulnerability, modifies in-memory files without altering disk contents, and establishes persistent access through techniques that defeat conventional monitoring. Applying the CVE-2025-53521 patch doesn't rule out earlier compromise. You need to investigate systems that were vulnerable before they were patched, combining file scans with memory and behavioral telemetry.
Start with systems that matter most. If an appliance processes credentials or issues tokens, treat it as high-risk. Dump memory periodically, compare running code to files on disk, and watch for behavioral anomalies. Build runbooks that don't assume the file on disk tells you what the server is running.
The tradeoff isn't between file scanning and memory analysis. It's between detecting what attackers did five years ago and what they're doing now. Choose accordingly.
