CVE-2025-20333
CVE-2025-20362
CVE-2025-20363
September 26, 2025
·
0
Minutes Read

Cisco ASA WebVPN & HTTP Zero-Day Advisory

Threat Research
September 26, 2025
·
0
Minutes Read

Cisco ASA WebVPN & HTTP Zero-Day Advisory

Threat Research
September 26, 2025
·
0
Minutes Read
Kudelski Security Team
Find out more
table of contents
Share on
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Summary

In May 2025, Cisco assisted multiple government agencies in investigating a sophisticated attack campaign targeting Cisco Adaptive Security Appliance (ASA) 5500-X Series devices running Cisco Secure Firewall ASA Software with VPN web services enabled.
The attackers exploited multiple zero-day vulnerabilities to implant malware, execute commands, evade detection, and potentially exfiltrate data. Advanced techniques observed included disabling logging, intercepting CLI commands, and crashing devices to hinder forensic analysis.

Cisco attributes this activity with high confidence to the same threat actor behind the ArcaneDoor campaign disclosed in 2024.
Affected devices without Secure Boot and Trust Anchor technologies were observed to have their ROMMON modified to maintain persistence across reboots and software upgrades.

Cisco released security updates on September 25, 2025 to remediate vulnerabilities exploited in this campaign.

Affected Systems and/or Applications

Confirmed Compromised Models (no Secure Boot / Trust Anchor, running ASA Software 9.12 or 9.14 with VPN web services enabled):

  • Cisco ASA 5512-X, 5515-X (EoS: Aug 31, 2022)
  • Cisco ASA 5525-X, 5545-X, 5555-X (EoS: Sep 30, 2025)
  • Cisco ASA 5585-X (EoS: May 31, 2023)

At Risk but Not Observed Compromised (support Secure Boot / Trust Anchor, EoS Aug 31, 2026):

  • Cisco ASA 5505-X, 5506H-X, 5506W-X, 5508-X, 5516-X
  • Cisco Firepower and Cisco Secure Firewall models

Technical Details

The adversary exploited a small set of high-impact flaws in the ASA VPN/HTTP web stack and then chained those footholds into device control, persistence, and data access. Below is an integrated, descriptive view of what those vulnerabilities and observed techniques meant in practice, how the attack typically progressed, and which artifacts and behaviors operators should expect to see during detection and forensic work.

Vulnerabilities exploited

  • CVE-2025-20333 - VPN Web Server RCE (Critical, CVSS 9.9): This vulnerability was in the ASA VPN web service codepath that handles incoming SSL/TLS-based VPN connections and associated web UI/API endpoints. An unauthenticated remote attacker could send crafted requests that caused memory corruption and allow arbitrary code execution in the ASA process context. Because the VPN webserver runs with privileges that can affect configuration and runtime behavior, successful exploitation provided immediate capability to execute attacker-supplied payloads on the firewall itself - not just to create noisy denial-of-service, but to run commands, modify local files, and stage secondary implants.
  • CVE-2025-20363 - HTTP Server RCE (Critical, CVSS 9.0): A separate critical RCE in the embedded HTTP server allowed remote execution through specially crafted HTTP requests targeting management/API endpoints. This provided a parallel or fallback path for initial access or escalation — useful for multi-stage exploitation where one vector establishes a foothold and the other expands capabilities or persists payloads.
  • CVE-2025-20362 - VPN Web Server Unauthorized Access (Medium, CVSS 6.5): This flaw permitted unauthorized access to some VPN web resources (for example, profile or client update endpoints) without proper authentication checks. While lower in direct impact than a full RCE, it was valuable as an enabler: it allowed the attacker to query or manipulate VPN-related functionality (profiles, client update mechanisms) that could be combined with the RCEs to increase reliability of payload install and stealth.

Together these bugs made a chained exploitation model effective: an attacker used the unauthorized-access weakness to probe or prepare the environment, then triggered one RCE to run a small loader, and used the other RCE to drop a more capable payload or to manipulate boot/ROM components.

How the chain translated into on-device activity

After initial code execution the actor performed a predictable set of actions to convert a transient exploit into durable control:

  • Privilege consolidation and lateral hardening. The initial payload attempted to escalate or reuse in-process privileges to access the filesystem (disk0:), CLI, and lower-level boot components. Where possible the attacker invoked commands or wrote binaries to disk0: to persist or re-launch tools.
  • ROMMON/bootloader tampering for persistence. On ASA 5500-X models that lack Secure Boot and Trust Anchor protections, Cisco observed modification of the ROMMON (boot monitor) area. Modifying ROMMON allows the attacker to execute code earlier in the boot sequence and survive OS/software re-flashes, reboots, and some upgrades - effectively creating a persistence mechanism beneath the operating system. On platforms that support Secure Boot/Trust Anchors, such low-level tampering was not observed because the boot verification mechanisms prevent unsigned ROMMON changes from executing.
  • Telemetry suppression and anti-forensics. To delay discovery and hamper forensic collection, the implanted code suppressed certain verbose syslog messages in-memory (the actor altered runtime behavior so these messages were not emitted), and disabled periodic memory-integrity/heap validation (the checkheaps routine that by default runs about every 60 seconds). Additionally, the actor sometimes deliberately crashed devices at times that would interrupt diagnostic captures or force restarts before operators could collect evidence.
  • Credential abuse and lateral usage. The actor leveraged stolen VPN credentials to make authenticated sessions that looked legitimate by first-glance logs. Often these sessions exhibited “impossible travel” (same account used from very distant IPs within a short time span), indicating credential theft rather than local staff activity. Authenticated sessions were used to perform configuration queries, pull profiles, or move laterally into management consoles.
  • Command execution and potential exfiltration. With code execution and persistence in place, arbitrary CLI-style commands were run, files could be read from the device, and traffic could be proxied or copied for exfiltration. The implant’s behavior varied between devices, but the core risk was full device compromise: attackers could modify rules, create tunnels, or read certificates/keys stored on the appliance.

Defense-evasion specifics and why they matter for detection

  • Syslog suppression (IDs 302013, 302014, 609002, 710005): These IDs correspond to verbose informational and debug messages that are commonly relied upon during incident investigation. The attacker’s in-memory suppression means you will see a sudden drop or absence of these messages compared to historical baselines - not a distinct malicious entry. That makes baseline-aware log analytics critical (look for a downward deviation rather than a single “bad” line).
  • checkheaps disabling: checkheaps is an in-process health/heap-validation routine whose run counter normally increments each minute. If the counter does not increase over repeated checks, it indicates the routine was disabled or interfered with in memory. This is a behavioral indicator of manipulation of the runtime environment rather than a filesystem artifact.
  • Intentional crashes: Crashes can be used as cover to clear volatile memory, abort data collection, or create noisy failure that distracts responders. If devices repeatedly crash at times coinciding with suspicious access, treat that as a correlated indicator.

Mitigation

Immediate containment

  1. Isolate affected devices from untrusted networks where possible (place behind a management-only network or apply ACLs limiting management access to a small set of trusted operator IPs). Avoid full power-cycling - preserve volatile memory and logs where possible until you have captured forensic artifacts.
  2. Disable exposed web-based VPN services on devices you cannot immediately upgrade:
    • Disable SSL VPN entirely:
      conf t no webvpn
    • Disable IKEv2 client services (retains basic IPsec functionality but prevents client/profile updates):
      show running-config crypto ikev2 | include client-services conf t crypto ikev2 enable <interface>
  3. Block known malicious IPs at perimeter devices if you have confirmed IOCs; do not rely solely on dynamic blocking - record timestamps and packet captures for later analysis.

Detect & Monitor (ongoing while containment and remediation occur)

  1. Syslog baseline & alerting
    • Create alerts for sudden drops in counts for syslog IDs: 302013, 302014, 609002, 710005. (Alert on volumetric downward deviation from historical baseline, e.g., 3+ standard deviations below normal).
    • Temporarily increase log verbosity only as necessary for diagnostics - watch for log server capacity and performance impacts.
  2. Checkheaps health check
    • Run:
      show checkheaps
      once per minute for 5 minutes and record Total number of runs. If it does not increase across checks, treat as high-priority suspicion of runtime tampering.
  3. Impossible travel / VPN session analytics
    • Correlate VPN session logs for same username across geographically distant source IPs in short time windows. Flag and suspend affected accounts pending investigation
    • Export VPN session tables with timestamps, source IPs, and session durations for triangulation.
  4. Boot/upgrade verification monitoring
    • During upgrades to fixed images, monitor console/serial output for:
      • Expected: Bootloader verification succeeded. and ROMMON verification succeeded.
      • Suspicious: Any Bootloader verification failed at address ... or ROMMON verification failed at address ... messages - escalate immediately.
  5. Network telemetry
    • Deploy/collect PCAPs for suspected time windows and capture any management-plane HTTP(S) traffic to the ASA for replay/analysis.
    • Hunt for outbound tunnels, unusual proxying, or long-lived connections to odd destinations.

Forensic collection & evidence preservation

Collect these artifacts in order of volatility; preserve and checksum everything. If you open a Cisco TAC case, include these items.

  1. Volatile / immediate
    • Serial/console capture of current boot output (if rebooted or during upgrade).
    • Live show tech-support (full bundle) - run and save securely.
    • show running-config and show startup-config outputs.
    • show version (confirm model and software release).
    • show checkheaps outputs (once per minute × 5 minutes).
    • Current syslog export for at least the last 30 days (or as available).
  2. Filesystem / persistent
    • Inspect disk0: for unexpected files and specifically for firmware_update.log. If present, copy and preserve contents.
    • Directory listing of disk0: including timestamps and file hashes (SHA256).
    • Any suspicious binaries or script files on disk0:.
  3. Network / authentication
    • PCAPs from the time windows of suspicious activity (management interfaces and external egress).
    • VPN session logs (username, source IP, start/end times, client type).
    • Authentication logs for admin accounts and AAA logs.
  4. Configuration & ACLs
    • Export ACLs, NAT rules, proxy-bypass settings, and AAA configuration. Record any unexpected entries or new management interfaces.
  5. Timestamps & checksums
    • For every collected file, calculate and store SHA256/MD5 and a collection manifest. Use secure transfer (SCP/SFTP over dedicated channel) to an evidence repository.
  6. Share with TAC
    • If firmware_update.log exists or ROMMON verification failed, open a Cisco TAC case and attach show tech-support plus the firmware_update.log content.

Remediation & Recovery (post-collection)

  1. Upgrade to fixed release (primary remediation). Follow Cisco fixed release guidance for your specific ASA/FTD release; confirmed fixes include 9.12.4.72 and 9.14.4.28 for the affected 9.12/9.14 tracks and other fixed releases as listed in the advisories.
    • Prefer migration to Secure Boot–enabled hardware for devices that are end-of-life or cannot receive fixed releases.
  2. If persistence was detected or suspected (non-Secure Boot platforms): booting to the fixed release will attempt to remove ROMMON persistence. Check for firmware_update.log on disk0: after upgrade.
  3. Factory reset and reconfiguration:
    • After upgrading and verifying bootloader/ROMMON integrity, reset device to factory defaults and rebuild configuration from known-good sources:
      • configure factory-default (if available), or write erase + reload.
    • Replace all local credentials, shared secrets, certificates, and keys. Assume all prior local credentials are compromised.
  4. Reissue certificates and keys: rotate any keys/certificates stored on the device and any dependent endpoints (VPN clients, RADIUS/TACACS shared secrets).
  5. Tighten management-plane access: limit management access to dedicated management network/VPN, enforce MFA for administrative accounts, and restrict administrative IPs via ACLs.
  6. Hunt & compensate: perform a wider environment hunt for reuse of stolen credentials, unexpected tunnels, or lateral movement from the device.

Practical forensic checklist & quick commands

(Quick copy-paste checklist SOC/IR teams can run)

  • Gather basic device info:
    show version show running-config show startup-config show tech-support
  • Check heaps:
    show checkheaps -- run 1x/min for 5 minutes, record Total number of runs
  • Search disk0:
    dir disk0: more disk0:/firmware_update.log -- if exists, copy contents
  • Syslog checks:
    • Export logs and analyze counts for: 302013, 302014, 609002, 710005
  • VPN sessions:
    show vpn-sessiondb detail l2l show vpn-sessiondb ra-ikev2 show vpn-sessiondb anyconnect
  • Console/boot verification - capture during upgrade/boot:
    • Expect: Bootloader verification succeeded. / ROMMON verification succeeded.
    • If you see verification failed at address, preserve console output and escalate.

Please additionally check Supplemental Direction ED 25-03: Core Dump and Hunt Instructions | CISA - for Core Dump & Hunt Instructions for Cisco ASA Devices

Also, If you would like to have any doubts clarified, please contact our Incident Response (IR) team. This service is available if you have credits assigned for IR support.

What the Cyber Fusion Center is Doing

The CFC will continue to monitor the situation and send an advisory update if needed. At the moment, the only way to avoid the impact at this time is applying the available patches or mitigate vulnerability by applying mentioned temporary solutions. An advisory update will be issued if new indicators, techniques, or escalations are identified that could further impact affected systems or require additional mitigation steps.

Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

Qualys IDs: (317737, 317736)
Tenable IDs: CVE-2025-20333
Tenable IDs: CVE-2025-20362

References

Related Post