The Problem
Your vendor operates a crucial F5 BIG-IP APM device. It's patched and monitored under your standard security controls. Then a rootkit exploits CVE-2025-53521, injecting a fileless web shell that never touches disk. Your monitoring tools detect nothing unusual. The vendor's security team is unaware of the compromise. Despite following protocols, you're still at risk.
This scenario prompts a critical question for third-party risk management (TPRM) teams: should you monitor vendors for advanced rootkit indicators, or is that the vendor's responsibility? This isn't just theoretical. With 795 endpoints exposed to this specific F5 vulnerability, according to the ShadowServer Foundation, and rootkits now intercepting PHP file operations in memory, the line between vendor responsibility and your oversight is blurring.
Why You Might Need to Monitor
Some experts argue you can't outsource risk detection for critical suppliers. If a vendor's infrastructure processes your data or controls access to your systems, you need visibility into their threat posture.
Technically, this argument is strong. Sophos analysis shows this rootkit modifies SELinux configurations, persists across upgrades, and creates password-protected local sockets without exposing TCP ports. It intercepts Apache's PHP module loader, injecting malicious code into memory copies of scripts like apm_css.php3. Traditional endpoint detection won't catch it because the files on disk remain unchanged. Relying on a vendor's quarterly assurance that they're "monitoring for threats" may not be enough.
From a regulatory standpoint, the EBA Outsourcing Guidelines require institutions to "monitor on an ongoing basis the service provider's performance." For Critical or Important Functions, this means more than just tracking SLAs. If a vendor breach could trigger a Major ICT-Related Incident under DORA, you need real-time threat intelligence. SR 23-4 also emphasizes "Continuous Monitoring of Active Arrangements" of third-party arrangements, which some interpret as needing threat-level visibility for high-criticality vendors.
Practically, you can require vendors to share specific indicators: Apache workers reading /proc/self/maps, unusual POST requests to .php3 endpoints, PHP responses with HTTP 201 status combined with text/css content type, or processes creating /run/bigtlog.pipe. You can integrate vendor SIEM feeds into your threat intelligence platform or deploy agent-based monitoring on vendor infrastructure under Right to Audit clauses. The technology isn't the constraint.
Why It Might Be the Vendor's Job
Others argue that monitoring for rootkit indicators crosses into operational management, which could undermine the vendor relationship and create a false sense of security. You're not the vendor's security operations center. You lack their system context, baseline behavior data, and incident response expertise.
Resource constraints are clear. Most TPRM teams struggle to complete annual assessments on time, let alone monitor indicators of compromise across hundreds of vendors. Sophos identified this rootkit by analyzing memory operations and encrypted strings, which is specialized malware analysis. Trying to do this for every vendor running F5 devices means duplicating a security function that may never match the vendor's native capability.
Liability is also a concern. If you're monitoring vendor infrastructure and miss a rootkit, are you partially responsible for the breach? If you detect suspicious indicators but the vendor disagrees, who decides? The complexity of shared monitoring could create more risk than it mitigates.
A more effective model is to define security outcomes in contracts and verify them through independent testing. Require vendors to deploy EDR capable of detecting memory-resident threats. Mandate quarterly penetration testing that includes rootkit scenarios. Include Notification Timelines that trigger within hours of detecting indicators like unauthorized /bin/bash launches. Build Liability and Indemnification clauses to cover losses from undetected threats. Verify compliance through annual audits, not daily monitoring.
This approach scales. You can apply the same contractual framework to 500 vendors without monitoring each environment for rootkit indicators.
Practical Approaches
In practice, most TPRM teams tier their approach. For vendors in the highest criticality classification, they require threat intelligence sharing and may deploy their own monitoring where contracts permit. For vendors running primary authentication infrastructure or core payment systems, the risk justifies the investment.
For the broader vendor population, they rely on contractual controls, third-party attestations, and Cyber Risk Ratings. They don't monitor for rootkits but verify the vendor has controls capable of detecting them. The SIG Core questionnaire asks about EDR deployment, memory protection mechanisms, and incident detection capabilities. The vendor's SOC 2 report should cover threat monitoring procedures. If the vendor can't demonstrate these capabilities during Pre-Contractual Assessment, they're not approved for high-risk functions.
A middle ground is requiring vendors to share specific indicators when detected. You're not monitoring their systems, but you receive alerts when they identify rootkit behavior, providing early warning without the operational burden.
Conclusion
You can't monitor every vendor for rootkit indicators, and you shouldn't try. But for critical vendors, you need more than contractual assurances. The sophistication gap between this rootkit and standard EDR is too wide to bridge with annual audits alone.
Start with Criticality Classification. If a vendor runs infrastructure where a fileless rootkit could access your data, disrupt operations, or create regulatory exposure, they're critical. For those vendors, require real-time threat intelligence sharing as a contract term. Specify the indicators they must report: processes modifying memory protections, unexpected socket creation, HTTP responses with suspicious status-content-type combinations. Make Incident Escalation automatic when those indicators appear.
Then verify the vendor's detection capability during onboarding. Don't just ask if they have EDR. Ask if their EDR can detect memory-resident threats that never write to disk. Ask how they monitor for Apache process anomalies. Ask when they last tested their detection against rootkit scenarios. If they can't answer these questions, they don't belong in your critical tier.
For non-critical vendors, contractual controls and periodic verification are enough. But don't assume annual questionnaires will catch a rootkit that hides web shells in memory and disguises responses as CSS content. The threat sophistication demands a tiered response, not a universal one.
