Are you blind to the next big firewall exploit? Warning signs and lessons learned from the recent Cisco exploit

It feels like the security world is caught in a recurring cycle. We see a spike in strange scanning activity, file it away as internet background noise, and then weeks later, a major zero-day exploit drops, targeting the very technology that was being scanned. The recent Cisco ASA vulnerabilities were a textbook example of this pattern. A September 4, 2025, report from GreyNoise highlighted a massive surge in scanning, with over 25,000 unique IPs probing Cisco ASA devices. Just a few weeks later, on September 25, Cisco disclosed two actively exploited zero-days, CVE-2025-20333 and CVE-2025-20362.

Historically, using raw scanning data for prediction has been difficult. It was just too noisy. But the game has changed. Security firms like GreyNoise now deploy sensors across the internet that don't just see that an IP address is scanning; they see what is being targeted, how it's being targeted, and even what exploits are being attempted. This turns chatter into actionable intelligence. It's no longer just noise; it’s a potential early warning.

The consequences of these campaigns are significant. For instance, F5 recently disclosed in an 8-K filing that a threat actor gained long-term, persistent access to its systems, including the BIG-IP product development environment. During this breach, the actor exfiltrated files containing portions of the company's source code and, critically, information about undisclosed vulnerabilities. This activity is often the prelude to sophisticated campaigns. Intelligence from Google's recent BRICKSTORM report and a joint advisory from CISA on the "Salt Typhoon" actor shows these edge devices are prime targets for establishing long-term persistence and launching espionage operations.

GreyNoise noted that a spike in crawling activity targeting F5 BIG-IP systems began the very same day F5 announced their security incident. This suggests the disclosure prompted both threat actors and researchers to immediately begin identifying how many devices were vulnerable and which organizations were exposed. The traffic appeared to be targeted rather than opportunistic, focusing on U.S. and French assets.

The U.K.'s National Cyber Security Center (NCSC) published a detailed malware analysis of "RayInitiator" and "LINE VIPER," a bootkit and payload combination used in the Cisco ASA attacks. This malware is complex, surviving reboots and firmware upgrades to maintain a foothold. Given the severity, CISA issued Emergency Directive 25-03, mandating immediate action for federal agencies. The message is clear: these aren't opportunistic attacks but calculated campaigns against critical infrastructure.

Detecting the Cisco ASA exploits

For defenders, the immediate priority is detection. Network-based signatures are one of the most effective tools for catching active exploitation attempts. The following Suricata rules can help identify attacks targeting the two recently disclosed Cisco vulnerabilities.

The first rule targets CVE-2025-20333, an authenticated buffer overflow. It looks for an HTTP POST request to a specific endpoint, /+CSCOE+/files/file_action.html, associated with a file upload. The key part of its logic is a regular expression (pcre) that inspects the Content-Type header for an unusually long boundary string, which is characteristic of the overflow attempt.

alert http any any -> $HOME_NET any (msg:"ET WEB_SERVER Cisco ASA/FTD Authenticated Buffer Overflow (CVE-2025-20333)"; flow:established,to_server; http.uri; content:"/+CSCOE+/files/file_action.html"; fast_pattern; content:!"fs|3d|"; content:"mode|3d|upload"; content:"server|3d|"; content:"path|3d|"; http.cookie; content:"webvpn|3d|"; http.content_type; pcre:"/^[^\x3b]*?\x3b\s*?[^\x3d]+\x3d[^$]{8192,}/"; reference:url,attackerkb.com/topics/Szq5u0xgUX/cve-2025-20362/rapid7-analysis; reference:cve,2025-20333; classtype:web-application-attack; sid:2065052; rev:1; metadata:affected_product Cisco_ASA, affected_product Cisco_FTD, attack_target Server, tls_state TLSDecrypt, created_at 2025_10_06, cve CVE_2025_20333, deployment Perimeter, deployment Internal, deployment SSLDecrypt, confidence High, signature_severity Major, tag Exploit, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2025_10_06, mitre_tactic_id TA0001, mitre_tactic_name Initial_Access, mitre_technique_id T1190, mitre_technique_name Exploit_Public_Facing_Application;)

The second rule targets CVE-2025-20362, an authentication bypass vulnerability. It identifies attempts to use path traversal sequences (like .., %2e%2e, ..%2f) in the raw HTTP URI to access restricted endpoints that should otherwise be inaccessible without authentication.

alert http any any -> $HOME_NET any (msg:"ET WEB_SERVER Cisco ASA/FTD WebVPN Authentication Bypass (CVE-2025-20362)"; flow:established,to_server; http.uri.raw; content:"/+CSCOU+"; pcre:"/^(?:\x2e|%2[Ee]|\x2f|\x5c|%5[Cc]|%2[Ff]){2,}/R"; content:"+CSCOE+/"; fast_pattern; distance:0; reference:url,attackerkb.com/topics/Szq5u0xgUX/cve-2025-20362/rapid7-analysis; reference:cve,2025-20362; classtype:web-application-attack; sid:2065051; rev:1; metadata:affected_product Cisco_ASA, affected_product Cisco_FTD, attack_target Server, tls_state TLSDecrypt, created_at 2025_10_06, cve CVE_2025_20362, deployment Perimeter, deployment Internal, deployment SSLDecrypt, confidence High, signature_severity Major, tag Exploit, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2025_10_06, mitre_tactic_id TA0001, mitre_tactic_name Initial_Access, mitre_technique_id T1190, mitre_technique_name Exploit_Public_Facing_Application; target:dest_ip;)

Corelight customers are already protected by these and other signatures. Beyond protocol analysis, file analysis is also crucial. The NCSC, Google, and CISA reports all released YARA rules to detect the malware families involved.

From the NCSC report, RayInitiator & LINE VIPER:

• RayInitiator_stage_1_search_for_booting_kernel_string
• RayInitiator_stage_2_identify_syscall_table
• RayInitiator_stage_3_install_phase_search_for_client_cert_fail_string
• RayInitiator_stage_3_deploy_phase_copy_LINE_VIPER_shellcode_stub
• LINE_VIPER_shellcode_deobfuscation_routine
• LINE_VIPER_shellcode_initial_execution
• LINE_VIPER_rsa_encrypted_random_aes_key_generation
• LINE_VIPER_aes_encrypted_tasking_and_exfiltration
• LINE_VIPER_icmp_tasking_shellcode_payloads

From Google's report, Another BRICKSTORM:

• G_APT_Backdoor_BRICKSTORM_1
• G_APT_Backdoor_BRICKSTORM_2
• G_APT_Backdoor_BRICKSTORM_3
• G_APT_BackdoorWebshell_SLAYSTYLE_1
• G_APT_BackdoorWebshell_SLAYSTYLE_2
• G_Backdoor_BRICKSTEAL_1
• G_Dropper_BRICKSTEAL_1
• G_Dropper_BRICKSTEAL_2

From CISA's advisory, AA25-239A:

• SALT_TYPHOON_CMD1_SFTP_CLIENT
• SALT_TYPHOON_NEW2_SFTP_CLIENT

These rules are vital for identifying malicious files. Platforms like Corelight can perform YARA scanning on files as they traverse the network, providing an opportunity to detect custom malware, like the SFTP clients detailed in the CISA advisory, before they are even executed on a system.

Proactive defense: know your management plane

Detecting active attacks is necessary, but it's a reactive posture. To get ahead of the next campaign, we need to think proactively. The common thread in these attacks is the targeting of network infrastructure management capabilities. To defend these devices, you must first understand them.

As stated by Google in their recent BRICKSTORM advisory:

“Especially important is to track the management interface addresses of these appliances, as they act as the default gateway that malware and threat actor commands will egress out of.”

A management interface is part of a network architecture concept called Out-of-Band (OoB) management. This approach uses a dedicated communication path to manage network devices and is critical for security because it separates traffic into two areas: the control plane and the data plane. The control plane carries management traffic, like an administrator connecting via Secure Shell (SSH) or a monitoring server polling with SNMPv3. The data plane carries the user traffic the network is built to serve.

The purpose of this separation, a practice recommended by the National Security Agency, is to prevent a compromise on the data plane from impacting network operations. This can be done with physical segmentation, using an entirely separate network, or with virtual segmentation, using technologies like Virtual Local Area Networks (VLANs) or Virtual Routing and Forwarding (VRFs). The goal is to ensure management traffic only travels over the dedicated OoB path.

Identifying management interfaces is best done by checking device configurations or IP Address Management (IPAM) documentation. However, you can also infer this information from monitoring network traffic. For example, Zeek's dhcp.log often contains hostnames that devices provide when requesting an IP address, such as firewall-01-mgmt. Searching for such patterns can help map IPs assigned to management interfaces, giving you a starting point for proactive threat hunting even without direct device access.

It is important to distinguish between a management interface and a management network. Ideally, a management interface connects exclusively to a segmented management network. Misconfigurations, however, can leave these interfaces accessible from the data plane, creating a direct path for attackers.

From reactive to proactive: Baselining your management interface for the next attack

So how do you find an adversary who lives where you can't easily look? A recent CISA advisory on the state-sponsored actor "Salt Typhoon" highlighted this exact challenge. These actors persist on network edge devices like routers and firewalls, creating a significant blind spot. A core lesson from these recent advisories is the importance of establishing a baseline of what "normal" looks like for your critical infrastructure. Management plane traffic is an ideal candidate for this because it should be consistent and predictable. Any deviation from that baseline becomes a high-fidelity signal that something is wrong.

For example, using Zeek's ssh.log data, you can baseline the hassh values (a fingerprint of the SSH client software) of all clients connecting to your management interfaces. An alert on a new, unapproved hassh value is a powerful, specific indicator. You can also baseline all outbound traffic originating from the management interfaces themselves using conn.log. Similarly, you can baseline all outbound traffic originating from the management interfaces themselves. Legitimate outbound connections for things like authentication (TACACS+), NTP, or software updates should be easy to identify and allowlist; any other outbound traffic—especially to other internal IP addresses—is immediately suspicious. This same principle applies to data volume; baselining outbound connections from the conn.log can spot a management interface that normally only sends small amounts of telemetry suddenly transferring gigabytes of data by tracking the orig_ip_bytes field, a classic sign of exfiltration. While this can be too noisy to alert on in some environments in their entirety, by limiting it to specific interfaces within the management network, you’re much less likely to see deviation.

This becomes even more suspicious if it's over an unusual port or to a new destination port entirely. If you have TLS decryption, this baseline can be even richer. Instead of just tracking software versions, you can baseline the user_agent field from the http.log for system information such as the observed operating system from admins. A management interface or administrator's workstation that has always appeared as 'Windows' (Windows NT 10.0; Win64; x64) suddenly connecting with a 'Linux' (X11; Linux x86_64) or 'MacOS' (Macintosh; Intel Mac OS X 10_15_7) user agent is a major anomaly. This is simple to verify and unlikely to change legitimately frequently if ever, though it's important to remember that user agents can be spoofed.

This proactive, baseline-driven method is a core component of a structured threat hunting program. To turn these one-time hunts into a repeatable, scalable process, we recommend adopting a methodology such as Splunk’s PEAK Threat Hunting Framework. PEAK, which stands for Prepare, Execute, Act, and Knowledge , organizes hunts into clear, repeatable processes. The strategy of "establishing a baseline of normal behavior and then searching for deviations" is a formal PEAK hunt type known as a Baseline Hunt.

This approach allows you to move beyond chasing specific CVEs. The CISA advisory on Salt Typhoon, for instance, noted that actors use non-standard high ports for SSH persistence (like 22x22or xxx22). A simple baseline hunt through Zeek's ssh.log for connections on unusual ports can easily detect this. The goal of using a framework like PEAK is to create these durable, automated detections. An alert on a new hassh value, an unexpected outbound connection from a firewall's management port, or scanning activity within a management network are the kinds of organization-specific detectors that are extremely difficult for adversaries to evade. This process turns a one-time hunt into a lasting security improvement, strengthening your defenses against the next inevitable edge device campaign.

For a more in-depth view of how to hunt and expose these adversary techniques, check out this report from Intel 471, which details a Volt Typhoon hunt using Corelight data. It provides specific query examples for platforms like Splunk, Elastic, and CrowdStrike Falcon LogScale. The report serves as a great companion piece for turning rich network evidence into actionable defense.

Closing: breaking the cycle of reaction

Threat actors have identified a critical blind spot in modern security programs: the network devices that form the backbone of our infrastructure. They are deliberately moving their operations to terrain where EDR has no visibility, knowing that many organizations are unprepared to detect them there.

The path forward is to shift our focus from hunting for specific indicators to hunting for anomalies in expected behavior. This begins with a simple but critical task: know your management plane. By applying a structured threat hunting methodology like the PEAK framework to baseline this highly predictable traffic, you turn the network itself into your most reliable sensor for these opaque devices. Don't wait for the next emergency directive. The opportunity to build a proactive defense is now, before the next surge in scanning becomes the next headline.

Learn how Network Detection and Response (NDR) solutions can help your organization gain the network visibility it needs to proactively counter threats that evade traditional EDR.

References

1. Cybersecurity and Infrastructure Security Agency. "AA25-239A: Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage System." September 03, 2025.
2. Cybersecurity and Infrastructure Security Agency. "ED 25-03: Identify and Mitigate Potential Compromise of Cisco Devices." September 25, 2025.
3. Google Threat Intelligence Group. "Another BRICKSTORM: Stealthy Backdoor Enabling Espionage into Tech and Legal Sectors." September 24, 2025.
4. GreyNoise. "25,000 IPs Scanned Cisco ASA Devices - New Vulnerability Potentially Incoming." September 4, 2025.
5. GreyNoise. "Early Warning Signals: When Attacker Behavior Precedes New Vulnerabilities." 2025.
6. GreyNoise. "Palo Alto Scanning Surges ~500% in 48 Hours, Marking 90-Day High." October 3, 2025.
7. National Cyber Security Centre. "Malware Analysis Report: RayInitiator & LINE VIPER." October 2025.
8. National Security Agency. "Performing Out-of-Band Network Management." September 2020.