No PoCs? No problem. How to hunt for F5 exploitation even when details are sparse

Endpoint detection and response (EDR) tools, and the analysts using them, have become incredibly effective. They have become so good, in fact, that we're now seeing a clear shift in adversary behavior: attackers are being pushed off the endpoint and onto places where EDR cannot run. This isn't just a theory. As I was writing a separate blog about a recent Cisco exploit which spurred an immediate CISA emergency directive, news dropped about another major network edge vendor, F5.

F5 announced in an 8-K filing that nation-state actors had "gained unauthorized access to its BIG-IP product development environment and exfiltrated files containing source code and information about undisclosed vulnerabilities." As part of the response, on the same day, F5 also released 44 new CVEs, which prompted CISA to issue yet another emergency directive in response.

The F5 release was sparse on specifics when it came to details regarding the vulnerabilities. As of writing this, there are still no public Proof-of-Concepts (PoCs). So how do you build detections or hunt for a compromise when no PoCs exist? With attackers holding the source code, how do we find exploits that F5 hasn’t publicly disclosed? In this post, I'll share detection advice and proactive ways to hunt for signs of F5 exploitation, even when the details are thin.

F5's official guidance: patch, harden, and monitor

Let's begin by reviewing what F5 officially recommends. Most of the guidance seems to be general best practices, though. With the exception of that threat intel guide for customers, nothing feels specific to this particular incident.

The first and most obvious one is patching. F5 strongly advises updating your software, even while stating that they have "no knowledge of undisclosed critical or remote code execution vulnerabilities." The patches are available in their latest Quarterly Security Notification, and cover BIG-IP, F5OS, BIG-IQ, and APM clients. Given that attackers have the source code, patching what F5 does know about is the bare minimum level of protection that defenders can start putting into place today.

Next, F5 emphasizes the importance of hardening. This is standard advice, but they're pointing people to the F5 iHealth Diagnostic Tool. It can automatically scan your setup, surface configuration gaps, and link you to the correct remediation guides. This is a good, practical step that's more useful than just reading a generic "best practices" guide.

They also, thankfully, stressed monitoring. F5 recommends streaming BIG-IP events to your SIEM. They even provided step-by-step guides for syslog configuration (KB13080) and monitoring for login attempts (KB13426). This is critical. It gives you visibility into admin logins, failed authentications, and any privilege or configuration changes, which is exactly where you'd expect to spot an intruder.

Finally, F5 has also put together a threat intelligence guide specifically for their customers. It's available by contacting F5 support, so if you're running their gear, this is your best starting point.

But what if we want to hunt for things not in that specific guide? F5 was clear that source code was stolen. That means adversaries could be looking for new exploits that F5 isn't even aware of yet. With that in mind, we'll focus on the potential adversary behaviors we can infer from details from the exploit notice, and then build some starting points for detection— despite only having limited public data.

A quick refresher: management networks and interfaces

In my recent posts about the Cisco exploit and hunting Salt Typhoon, we've covered why the management plane is such a critical blind spot. As a quick refresher, this architecture separates your network into two distinct areas. F5's knowledge base (K44525501) defines these as the data plane and the control plane. For a BIG-IP, the data plane is what handles almost all runtime network traffic; this is the work done by the Traffic Management Microkernel (TMM). The control plane is separate and deals with "management (non-TMM) traffic." This includes all the administrative tasks: logging, licensing, iControl REST, and, most importantly for us, access via the Configuration utility, tmsh, and SSH. This management traffic should be highly predictable, making it a perfect place to hunt for anomalies.

Narrowing the scope and identifying the assets

With 44 CVEs released at once, trying to hunt for all of them immediately is impractical. A core part of any structured hunt, like those described in the PEAK framework, is the "Prepare" phase. This means defining a manageable scope and critically identifying your assets. You can't defend what you don't know you have. As I mentioned in my post on the Cisco exploit, the best way to identify your management interfaces is using configuration files or IPAM documentation.

If you don't have that documentation, finding your F5 assets can be tricky. One potential indicator is the HTTP Server header; by default, BIG-IP devices may identify themselves with Server: BigIP, though administrators can disable this. Another approach involves looking for network traffic originating from the F5 devices themselves. Specifically, watch for DNS queries or SSL connections (checking the server_name field in Zeek's ssl.log) destined for F5's own license activation and update servers, such as hostnames ending in (activate|api|callhome).f5.com. Devices making these specific outbound connections are likely F5 BIG-IPs, and as this is associated with the control plane, should originate from the management interface of the device.

Once you have that asset list, you can narrow your focus. For the rest of this post, we'll skip the other 43 CVEs and concentrate on one specific vulnerability: K000151902, the BIG-IP SCP and SFTP vulnerability (CVE-2025-53868). This one is a perfect target because F5 states it's exploitable only via the management interface.

Deconstructing the SCP/SFTP vulnerability: a hunt based on inference

F5's advisory for CVE-2025-53868 (K000151902) gives us some crucial clues, even without a PoC. The vulnerability affects the Secure Copy (SCP) protocol and SFTP specifically when a BIG-IP system is running in Appliance mode. According to F5's documentation, Appliance mode limits administrative access to make the system behave more like a typical network appliance rather than a multi-user UNIX device. This means access to the Advanced shell (bash) is removed, and the root user cannot log in by any means; administrators are restricted to using only the Configuration utility and the TMOS Shell (tmsh). This bug allows a "highly privileged authenticated attacker" who already has access to SCP/SFTP to bypass those restrictions using "undisclosed commands." This implies someone who already has admin-level access (needed for SCP/SFTP by default) can break out of the intended limitations of Appliance mode.

F5 explicitly states, "This is a control plane issue; there is no data plane exposure". This confirms that our focus on management interfaces is correct. The vulnerability is also classified as CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') . While we don't know the exact "undisclosed commands," knowing it is an OS command injection that’s targeting SCP/SFTP on the management plane gives us a behavioral pattern to hunt for, rather than a specific signature.

SCP & SFTP basics

Secure Copy Protocol (SCP) and SSH File Transfer Protocol (SFTP) are both network protocols used to securely transfer files between computers, leveraging the Secure Shell (SSH) protocol for authentication and encryption. Think of SSH as the secure tunnel, and SCP/SFTP as the methods for sending files through it. SCP was initially designed for basic file copying like the cp command, but over the network. However, SFTP has largely replaced SCP in modern use because it's a more robust protocol. SFTP provides a wider range of file management capabilities similar to the traditional File Transfer Protocol (FTP), such as listing remote directories, deleting files, resuming transfers, and creating directories, all operating within the secure SSH connection.

Distinguishing between interactive SSH sessions, SCP, and SFTP

Because SSH traffic is encrypted, figuring out what is happening within a session (like distinguishing an interactive login from a file transfer) requires looking beyond the packet contents. At Corelight, we've developed techniques to infer the nature of SSH activity by analyzing the metadata–specifically the size, order, and direction of encrypted packets. This approach allows us to draw conclusions about the session's purpose without needing to decrypt the traffic.

Our SSH Inference package, part of the Encrypted Traffic Insights Collection, applies this concept. For example, interactive sessions often exhibit a distinct "echo" pattern where small client packets (keystrokes) are quickly followed by small server packets (the echo). In contrast, file transfers using SCP or SFTP tend to show sustained transfers involving maximum-sized packets. By modeling these and other patterns, we can tag SSH sessions with inferences like Keystrokes (indicating an interactive session) or Client_File_Upload / Server_File_Download (indicating file transfers) directly in ssh.log,a high-fidelity transaction log from Zeek®.

Further research, including work by Corelight co-founder Vern Paxson and Julien Piet of Corelight’s Labs team (among others), specifically targets the detection of SSH impostors–attackers using stolen credentials. The core concept, detailed in research presented at USENIX Security '23, uses deep learning models, particularly transformers, to analyze sequences of client packet timings and lengths from interactive sessions. The core idea is that even though the keystrokes themselves are encrypted, the timing and size of the packets carrying them reflect the user's unique typing rhythm. By identifying discrepancies between the observed typing dynamics and the legitimate user's known patterns, the model can detect impostors without needing to see the typed characters. This research showed that this subtle metadata within encrypted flows is enough to authenticate users with high accuracy. For a deeper dive into these techniques, check out the blog posts introducing the SSH Inference package and discussing detection, inference, and identification.

Hunting on and detecting the unknown exploit

At this point, we’ve recommended implementing the PEAK threat hunting framework, which requires us to identify our assets–such as management interfaces and networks. This framework provides an overview of what a management interface is and why it's important. It also requires us to understand both the publicly available information on the vulnerability and how the protocols in question actually work. But the question remains: how do we detect the activity?

Method 1: Corelight SSH Inference Package - Client Authentication Bypass (ABP)

Hunt for SSH Inferences in Zeek's ssh.log Corelight has simplified a lot of these inferences for you with our SSH Inference package which makes difficult aspects of the hunt much easier than trying to determine them yourself. For an analyst, this provides a clear, actionable starting point: hunt for specific tags in the inferences field of your Zeek ssh.log.

For example, our Client Authentication Bypass (ABP) inference detects whether a connection did not adhere to certain expectations of SSH according to the RFCs. As referenced in our prior writeup:

"This can occur when a client exploits a server or when a client and server switch to a protocol other than SSH once encryption begins.

What’s interesting with this inference is that the exploit occurs within encrypted packets, which means we do not identify the exploit by content, but rather by behavior. We cannot link the exploit to a CVE but we can tell that an exploit occurred. This approach may be useful for identifying some types of zero-day exploits, because it doesn’t require knowledge of the specifics of the attack, but instead only requires a general understanding of how such attacks could succeed.

This inference is related to MITRE ATT&CK techniques:

T1210 (Exploitation of Remote Services)
T1190 (Exploit Public-Facing Application)
T1212 (Exploitation for Credential Access)"

Finding an ABP tag on an SSH connection to a BIG-IP management interface is a high-priority indicator of compromise and should be investigated immediately. As we covered, CVE-2025-53868 is an OS command injection vulnerability affecting SCP/SFTP on BIG-IP systems in Appliance mode. A threat actor who already has high-level authenticated access can exploit this to bypass the restrictions of Appliance mode, specifically the limitation of being confined to the TMOS Shell (tmsh). Successfully exploiting this would allow them to run commands directly on the underlying operating system, which Appliance mode is designed to prevent. Certain SSH analysis techniques can help identify behaviors potentially associated with command injection attempts.

SSH anomaly detection may indicate activity related to identifying the vulnerability prior to exploitation. For instance, Corelight’s SSH Version Scanning and SSH Capabilities Scanning inferences may signal that an attacker is probing the F5 device to determine if it is vulnerable.

Additionally, the SSH Inference package identifies file transfers. An inference tagged Client_File_Upload shows a file being uploaded to the F5 appliance via SCP/SFTP. While potentially legitimate, this could also indicate an adversary uploading malicious tools or scripts as part of an attack chain, similar to tactics observed in attacks against other types of infrastructure like VMware ESXi environments.

Method 2: baselining the management interface/network

I've gone into more detail on baselining management plane traffic in my posts about the Cisco exploit and hunting Salt Typhoon, but the core idea applies here too. Assuming your management interfaces aren't exposed directly to the internet, any attacker trying to exploit CVE-2025-53868 would likely need to first compromise another system on your internal network, and then move laterally to the F5's management IP. This makes baselining incoming SSH connections crucial. You should know which subnets house your administrators or jump boxes; SSH or SFTP connections originating from outside those approved sources, especially from server or application networks, are highly suspicious and could indicate lateral movement. Tracking fields like the source IP and the hassh value in Zeek's ssh.log provides a good starting point for this baseline.

Method 3: SSH imposter detection (advanced)

For organizations with highly mature threat hunting programs, the SSH imposter detection technique mentioned above is a powerful, research-driven option. As a recap, this approach uses typing dynamics to distinguish a legitimate user from an imposter.

But be warned: this approach requires significant effort. You'd need to collect sufficient labeled training data per user and then build and maintain the machine learning models. Still, the research demonstrated impressive accuracy. For teams monitoring critical infrastructure like management networks, where interactive SSH logins are expected but highly sensitive, experimenting with this technique could offer a powerful layer of defense against credential theft. While this is an advanced concept, management networks and interfaces are perhaps the most sensitive.

Closing: hunting in the dark isn't flying blind

The lack of a public PoC for CVE-2025-53868 doesn't mean defenders are powerless. F5's confirmation that nation-state actors accessed source code and vulnerability details is a serious development, reinforcing the trend of attackers targeting network edge devices–areas often invisible to EDR. Waiting for precise indicators is a losing game when adversaries might be leveraging exploits vendors don't even know about yet. The path forward requires shifting our focus to behavioral analysis and anomaly detection directly on the network.

By applying structured hunting methodologies like the PEAK framework, establishing strong baselines for critical management plane traffic, and leveraging network visibility tools to spot deviations. Whether defenders are hunting through SSH inferences like authentication bypasses and unexpected file transfers, tracking unusual hassh values, or even exploring advanced analytic models for analysis, they can build effective defenses against opaque threats. The key is to realize that the network itself holds the evidence; understanding what's normal for your critical infrastructure is the first step toward finding the adversary, even when the details are sparse.

For more about the importance of the network, check out our primers on network forensics and network security monitoring.