A short-ish reconnaissance phase. A short pause. Then a coordinated strike – each target hit once. Here’s what we observed and why blocking reconnaissance matters more than ever.
Background: The September Zero-Days
In September 2025, Cisco disclosed critical zero-day vulnerabilities in ASA/FTD WebVPN services (CVE-2025-20333 and CVE-2025-20362). These weren’t theoretical – they were already being exploited in the wild, prompting CISA to issue emergency directives.
As BleepingComputer reported, massive reconnaissance waves preceded the disclosure. Over 25,000 unique IPs probed ASA portals in late August alone. Administrators were warned to patch immediately, enforce MFA, and stop exposing WebVPN, Telnet, or SSH directly to the internet.
Fast forward to November. The patches are out. The advisories have been published. And yet – the scanning hasn’t stopped. It’s evolved.
The New Wave: November 2025
Reconnaissance Phase (Nov 10–17)
Between November 10-17, we observed an increase in reconnaissance activity against Cisco ASA/FTD WebVPN endpoints. Approximately 500 new unique IP addresses probed for ASA/FTD WebVPN portals during this window (and over the 90 days we have observed approximately 1,800 unique IP addresses in total).
What’s interesting is the infrastructure behind it. Our threat analytics platform tagged these IPs with a mix of signatures: about 59% matched “Favicon Scanner”, 27% “Palo Alto GlobalProtect Scanner,” 19% “WordPress Detector”.
This wasn’t a laser-focused ASA campaign – these IPs were used for broad, multi-purpose scanning, some from rented cloud infrastructure hitting many services simultaneously.
ASNs
Primary, these new IPs were located at AS215540 Global Connectivity Solutions and AS215929 Data Campus.
In other words: someone was building a target list.
Exploitation Phase (Nov 19)
Then, just two days later, the exploitation began.
But this phase looked nothing like the reconnaissance. Instead of hundreds of IPs hammering targets, only 75 IP addresses carried out exploit attempts. And here’s the telling detail: each of the targets was contacted exactly once with one exception – one IP contacted 2 sensors twice, probably due to retry logic.
No spray-and-pray. No repeated hammering from the same sources. Each sensor saw a single, deliberate hit – a POST request with path traversal to /+CSCOU+//../+CSCOE+/files/file_action.html, targeting the disclosed vulnerabilities.
The exploitation traffic came from different infrastructure than the reconnaissance phase, primarily AS26548 (PureVoltage Hosting) and AS43444 (Fast Servers).
This is a smart attack pattern. By distributing workload across dozens of VPS instances and limiting each source to one request per target, the attackers minimize their footprint. Rate-limiting won’t catch them.
Separate Infrastructures, Same Campaign (?)
Out of all the IPs we observed scanning for Cisco targets and all IPs that were sources of exploitation attempts, only one IP appeared in both pools.
This near-complete separation suggests a modular operation – possibly rented infrastructure for reconnaissance, handing off a curated target list to separate exploitation infrastructure. It’s efficient, compartmentalized, and makes attribution significantly harder.
Our current theory: after the initial release of information about CVE-2025-20333 and CVE-2025-20362, some actors waited a few months to check (or re-check) if companies that responded to the advisory took infrastructure down temporarily and then brought it back up without applying necessary patches.
Fingerprinting the Traffic
We examined TCP fingerprint data using MuonFP. The most common fingerprint during the exploitation phase was 65535:2-4-8-1-3:1460:14. However, this signature is fairly common – we’ve seen it across 330K+ IPs globally, including benign traffic. Fingerprints like these tell us something about the OS stack, but they’re not unique to this campaign.
Recommendations
Patch and harden your ASA/FTD devices. Ensure you’re updated against CVE-2025-20333, CVE-2025-20362, and related vulnerabilities.
Integrate real-time threat intelligence. A dynamic blocklist that ingests reconnaissance activity can stop the attack chain before it starts. If you have an existing EDL deployment on Cisco, Palo Alto, Check Point, or similar NGFWs, consider adding ELLIO Threat List MAX as an include source. It’s designed to catch exactly this type of pre-attack scanning as well as exploitation sources, and it’s updated continuously as new threats emerge, no need to build your own queries.
Disappear from target-building search engines. There are multiple ways threat actors build target lists. Some skip the hard work of scanning entirely – instead, they query search engines like Shodan or Censys, that continuously index internet-facing infrastructure. If your edge devices are visible in these databases, you’re already on someone’s list. Consider including ELLIO RECON blocklists in your EDL deployment. These block the IPs that feed data to such search engines, helping your infrastructure disappear from their indexes entirely.
While the reconnaissance IPs were already in Threat List MAX before exploitation/recon has began, the 75 exploitation IPs were added in real time as we detected the campaign – ensuring customers were protected as the attack unfolded.
Explore the Campaign Data
For ELLIO users, you can pivot directly on this activity in the platform:
Exploitation IPs (tag: “Cisco ASA/FTD WebVPN Exploit”): View in ELLIO →
Reconnaissance IPs (tag: “Cisco ASA/FTD WebVPN Scanner”): View in ELLIO →
Stay safe out there
