Cisco ASA FTD VPN DoS Exploited: Hunt Unexpected Reloads

Inception Security

20 hours ago

8 min read

Inceptor reads an uptime of zero off a scanner while Glitch hides in a server cabinet holding a remote, next to a firewall rebooting and a laptop stuck on a VPN login page.

What this means for your clients: attackers are using a flaw in Cisco's remote-access firewalls to force them to restart. The fix is a software upgrade, plus checking each VPN connection profile for one setting.

The VPN login page on a Cisco ASA or FTD can be used to crash the firewall. A device is exposed when secondary authentication is set on a tunnel group it serves: with the login page's group list on, that is any tunnel group, including the default group, DefaultWEBVPNGroup, whether or not it appears in the list; with the list off, it is DefaultWEBVPNGroup. Anyone who can reach the SSL VPN login page on that device can send the crafted request. Cisco says a successful VPN login is not required. The only impact Cisco claims is a denial of service: the device reloads and sessions drop.

Cisco published advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 on 28 October 2026 for CVE-2026-76418 in Cisco Secure Firewall ASA and Threat Defense (FTD) software. Cisco rates it CVSS 8.6 High. Below is what to check and hunt for on each Cisco ASA FTD device that runs the SSL VPN.

As of 30 October 2026, NVD lists the CVE as Analyzed and shows only Cisco's CVSS score, marked Secondary. As of the same date, CISA's Known Exploited Vulnerabilities catalog listed the CVE as added 29 October 2026, due 1 November 2026.

Cisco says its PSIRT became aware of active exploitation in October 2026 and names no actor or IOC. Eric Fernald found the bug during a Cisco TAC case.

Why secondary auth is the trigger

Cisco roots the flaw in logic errors when secondary authentication is configured on a tunnel group (CWE-690). Cisco's CVSS vector scores availability impact only (C:N/I:N/A:H). Neither Cisco nor NVD (as of 30 October 2026) claims RCE, auth bypass, or data access.

If tunnel-group-list enable is on, check every tunnel group, including DefaultWEBVPNGroup, for secondary-authentication-server-group. Turning the list off does not clear exposure when the default group still uses secondary auth. On FTD, review the Remote Access VPN policy in FMC or FDM and the deployed running config.

What to change first

Cisco says there are no workarounds. Upgrade to a first fixed release and confirm with Cisco Software Checker. Cloud-delivered Firewall, cdFMC, Secure Access, and Secure FMC Software are not affected.

ASA first fixed builds Cisco lists:

9.16 and earlier: first fixed 9.16.4.104
9.18: first fixed 9.18.4.96
9.20: first fixed 9.20.4.50
9.22: first fixed 9.22.3.200
9.23: first fixed 9.23.1.48
9.24: first fixed 9.24.1.27 and 9.24.10.1

FTD first fixed builds Cisco lists:

7.0 and earlier: first fixed 7.0.11
7.2: first fixed 7.2.13
7.4: first fixed 7.4.9
7.6: first fixed 7.6.7
7.7: first fixed 7.7.14
10.0: first fixed 10.0.3
10.1: first fixed 10.1.1

Cisco offers a temporary mitigation that depends on how DefaultWEBVPNGroup is set up, and says it was proven successful in a test environment, and says customers should test it in their own environment before deploying. If DefaultWEBVPNGroup has no secondary auth, no tunnel-group-list enable turns off the group list, so users must know their profile name. If DefaultWEBVPNGroup uses secondary auth, no secondary-authentication-server-group removes secondary auth from that group, and Cisco says that lowers remote access VPN security posture. If the group list stays enabled, also remove secondary-authentication-server-group from every tunnel group.

Inventory every internet-facing Cisco ASA or FTD with WebVPN enabled, check tunnel-group and webvpn config for secondary auth, and match show version to Cisco's table.

BleepingComputer reports Shadowserver tracking more than 51,000 internet-exposed ASA SSL VPN devices, not a count of vulnerable boxes.

Hunts to run (test first)

Cisco publishes no detections or syslog IDs for this CVE; the IDs and pairings below are our own. The IDs are confirmed in the ASA Series Syslog Messages guide, and they can show attempts or impact rather than proof. ASA messages start with %ASA-; FTD 6.3 and later use %FTD-, so the regexes match both. All four platforms use the same IDs, a 30 day lookback, and the same filters.

Field names are assumptions; map them to your parser. Replace YOUR_ASA_INDEX first. Group by the firewall's own name, not the syslog collector: set logging device-id hostname on each firewall, or several firewalls behind one forwarder collapse into one row.

Feed check (run first). Hunt 1 only matches reload IDs, so a healthy feed from a firewall that has not rebooted returns nothing. Before any hunt, count all Cisco syslog events by device over 30 days with no message-ID filter. Every firewall you manage should show up with recent events; a missing device means a missing or misparsed feed.

Splunk

index=YOUR_ASA_INDEX (sourcetype="cisco:asa" OR sourcetype="cisco:ftd") earliest=-30d
| stats count as events, max(_time) as last_seen by host
| convert ctime(last_seen)
| sort - events

Elastic

// ES|QL; field names assumed
FROM logs-cisco_asa.*, logs-cisco_ftd.*
| WHERE @timestamp > NOW() - 30 days
| EVAL device = COALESCE(observer.hostname, host.name)
| STATS events = COUNT(*), last_seen = MAX(@timestamp) BY device
| SORT events DESC

CrowdStrike

// Time picker: last 30 days; host field assumed
@rawstring=/%(?:ASA|FTD)-\d+-\d{6}:/
| groupBy([host], function=[count(as=events), max(@timestamp, as=last_seen)])
| sort(events, order=desc)

Microsoft KQL

CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DeviceVendor == "Cisco" and DeviceProduct in ("ASA","FTD")
| extend Device = coalesce(DeviceName, DeviceAddress, Computer)
| summarize Events=count(), LastSeen=max(TimeGenerated) by Device
| order by Events desc

Hunt 1: unexpected reload or boot. Reload messages are the best evidence of impact. Count 199005, 199002, and 199001 by device over 30 days.

If the feed check shows the device but Hunt 1 is empty, the most likely reason is that the device did not reboot in the range. If the device is missing from both, the feed is missing or the sourcetype differs; confirm on the device with show version (uptime) and show crashinfo. When rows appear, treat unticketed 199005 and 199002 pairs as the escalate path; use 199001 for known CLI reloads.

Splunk

index=YOUR_ASA_INDEX (sourcetype="cisco:asa" OR sourcetype="cisco:ftd") earliest=-30d
| rex field=_raw "%(?:ASA|FTD)-\d+-(?<msg_id>\d{6}):"
| fillnull value="-" host msg_id
| where msg_id IN ("199001","199002","199005")
| stats count as events, min(_time) as first_seen, max(_time) as last_seen by host, msg_id
| convert ctime(first_seen) ctime(last_seen)
| sort - events

Elastic

// ES|QL; field names assumed
FROM logs-cisco_asa.*, logs-cisco_ftd.*
| WHERE @timestamp > NOW() - 30 days
  AND event.code IN ("199001", "199002", "199005")
| EVAL device = COALESCE(observer.hostname, host.name)
| STATS events = COUNT(*), first_seen = MIN(@timestamp), last_seen = MAX(@timestamp) BY device, event.code
| SORT events DESC

observer.hostname comes first because it usually holds the firewall's own name, while host.name can be the collector. If observer.hostname is not mapped in any of these indices, drop it from COALESCE.

CrowdStrike

Falcon sensors do not run on ASA or FTD. Use this only when Cisco syslog is ingested into Falcon LogScale or Next-Gen SIEM.

// Time picker: last 30 days; host field assumed
@rawstring=/%(?:ASA|FTD)-\d+-(?<msg_id>199001|199002|199005):/
| groupBy([host, msg_id], function=[count(as=events), min(@timestamp, as=first_seen), max(@timestamp, as=last_seen)])
| sort(events, order=desc)

Microsoft KQL

Defender XDR endpoint tables do not see the firewall. Use Sentinel only when ASA or FTD syslog lands in CommonSecurityLog.

CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DeviceVendor == "Cisco" and DeviceProduct in ("ASA","FTD")
| where DeviceEventClassID in ("199001","199002","199005")
| extend Device = coalesce(DeviceName, DeviceAddress, Computer)
| summarize Events=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by Device, DeviceEventClassID
| order by Events desc

Hunt 2: VPN-path noise before a reload. Look for SSL handshake starts (725001) and AAA rejects (113005) in the same short window as a 199002 or 199005 boot. 199001 marks an admin reload, so Hunt 2 leaves it out. Session disconnects (113019) and post-login WebVPN or AnyConnect lines (716001, 716002, 722022, 722023) can add context, but those often need a completed login.

Each query puts a device's syslog into 30 minute windows and keeps a window only when it holds at least one boot ID and at least one VPN-path ID. Boot messages carry no source address, so the pairing is by device and time, and the source IPs listed on each row come from the VPN lines. A pair that straddles a window edge will be missed.

Splunk

index=YOUR_ASA_INDEX (sourcetype="cisco:asa" OR sourcetype="cisco:ftd") earliest=-30d
| rex field=_raw "%(?:ASA|FTD)-\d+-(?<msg_id>\d{6}):"
| where msg_id IN ("725001","113005","113019","716001","716002","722022","722023","199002","199005")
| rex field=_raw "IP (?:= )?<?(?<src_ip>\d+\.\d+\.\d+\.\d+)"
| rex field=_raw "user IP = (?<src_ip2>\d+\.\d+\.\d+\.\d+)"
| rex field=_raw "%(?:ASA|FTD)-\d+-725001: .*? (?<ifc>\S+):(?<src_ip3>\d+\.\d+\.\d+\.\d+)/"
| eval src=coalesce(src_ip, src_ip2, src_ip3)
| fillnull value="-" host msg_id
| bin _time span=30m
| stats values(msg_id) as msg_ids, values(src) as srcs, count as events by host, _time
| eval has_boot=if(mvfind(msg_ids,"199002")>=0 OR mvfind(msg_ids,"199005")>=0, 1, 0)
| eval has_vpn=if(mvfind(msg_ids,"725001")>=0 OR mvfind(msg_ids,"113005")>=0 OR mvfind(msg_ids,"113019")>=0 OR mvfind(msg_ids,"716001")>=0 OR mvfind(msg_ids,"716002")>=0 OR mvfind(msg_ids,"722022")>=0 OR mvfind(msg_ids,"722023")>=0, 1, 0)
| where has_boot=1 AND has_vpn=1
| sort - _time

Elastic

// ES|QL; field names assumed
FROM logs-cisco_asa.*, logs-cisco_ftd.*
| WHERE @timestamp > NOW() - 30 days
  AND event.code IN ("725001","113005","113019","716001","716002","722022","722023","199002","199005")
| EVAL src = TO_STRING(source.ip)
| EVAL device = COALESCE(observer.hostname, host.name)
| EVAL is_boot = CASE(event.code IN ("199002", "199005"), 1, 0)
| EVAL is_vpn = CASE(event.code IN ("725001","113005","113019","716001","716002","722022","722023"), 1, 0)
| EVAL bucket = DATE_TRUNC(30 minutes, @timestamp)
| STATS boot = MAX(is_boot), vpn = MAX(is_vpn), ids = VALUES(event.code), srcs = VALUES(src), events = COUNT(*) BY device, bucket
| WHERE boot == 1 AND vpn == 1
| SORT bucket DESC

VALUES() needs Elasticsearch 8.14 or later; on older stacks, drop ids and srcs and the boot and VPN flags still work. If source.ip is empty on 725001 events in your data, parse the address from the message text, as the Splunk query does.

CrowdStrike

As above, this needs ASA or FTD syslog in LogScale or Next-Gen SIEM.

// Time picker: last 30 days; host field assumed
@rawstring=/%(?:ASA|FTD)-\d+-(?<msg_id>725001|113005|113019|716001|716002|722022|722023|199002|199005):/
| regex(regex="IP (?:= )?<?(?<src_ip>\d+\.\d+\.\d+\.\d+)", flags="i", field=@rawstring, strict=false)
| regex(regex="%(?:ASA|FTD)-\d+-725001: .*? \S+:(?<src_725>\d+\.\d+\.\d+\.\d+)/", flags="i", field=@rawstring, strict=false)
| src := coalesce([src_ip, src_725])
| bucket(span=30m, field=[host], limit=500, function=[collect(msg_id), collect(src), count(as=events), max(@timestamp, as=last_seen)])
| msg_id=/(199002|199005)/
| msg_id=/(725001|113005|113019|716001|716002|722022|722023)/
| sort(last_seen, order=desc)

Microsoft KQL

CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DeviceVendor == "Cisco" and DeviceProduct in ("ASA","FTD")
| where DeviceEventClassID in ("725001","113005","113019","716001","716002","722022","722023","199002","199005")
| extend src = tostring(SourceIP)
| extend bucket = bin(TimeGenerated, 30m)
| extend Device = coalesce(DeviceName, DeviceAddress, Computer)
| summarize Events=count(), Ids=make_set(DeviceEventClassID), srcs=make_set(src), LastSeen=max(TimeGenerated) by Device, bucket
| where array_length(set_intersect(Ids, dynamic(["199002","199005"]))) > 0
  and array_length(set_intersect(Ids, dynamic(["725001","113005","113019","716001","716002","722022","722023"]))) > 0
| order by LastSeen desc

If SourceIP is empty on 725001 events, parse the address from the message text, as the Splunk query does.

Hunt 3: exposure from config, not logs. This is a manual config check with no SIEM query. Export or script show running-config tunnel-group and show running-config webvpn, and for FTD also review the deployed Remote Access VPN policy. If tunnel-group-list enable is on, flag any tunnel group that lists secondary-authentication-server-group on a device with WebVPN enabled on an internet-facing interface; if it is off, flag DefaultWEBVPNGroup.

Interpret before you escalate

Finding	Benign read	Escalate when
199005 then 199002	Planned reboot or power event	No change ticket, or repeats while VPN is still reachable
199001 present	Admin ran reload	Verify the change ticket; do not ignore unattended boots
725001 or 113005 spike then boot	Scan noise or flaky clients	Same source IP appears in several rows just before an unticketed boot
716001 or 722022 only	Normal successful VPN use	Alone, this does not point to this CVE without a boot or config hit
Config still has secondary auth on an exposed tunnel group (any group with the list on, DefaultWEBVPNGroup with it off)	Required MFA design	Vulnerable release in production; patch or apply mitigation

What to alert on

Alert when an unticketed 199005 or 199002 boot lands on an internet-facing device with WebVPN enabled that still has secondary-authentication-server-group on any tunnel group (group list on) or on DefaultWEBVPNGroup (group list off). A human confirms the ticket gap and config.

Also review the source IPs on Hunt 2 rows by hand: one address showing 725001 or 113005 across several rows ahead of an unticketed boot is worth escalating. The queries do not count events per source IP.

Bottom line

If an internet-facing device with WebVPN enabled has secondary authentication on any tunnel group while the group list is on, or on DefaultWEBVPNGroup while it is off, treat the login page as a reboot button until the fixed code is in. Upgrade to a fixed release, and use Cisco's mitigation only until you can.

Sources

Cisco Security Advisory, cisco-sa-asaftd-tunnel-dos-s6mgkb75: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-tunnel-dos-s6mgkb75
Cisco Secure Firewall ASA Series Syslog Messages: https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/asa-syslog.html
CISA alert, 29 October 2026: https://www.cisa.gov/news-events/alerts/2026/10/29/cisa-adds-two-known-exploited-vulnerabilities-catalog
CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
NVD, CVE-2026-76418: https://nvd.nist.gov/vuln/detail/CVE-2026-76418
BleepingComputer, New Cisco firewall zero-day exploited to crash SSL VPN devices: https://www.bleepingcomputer.com/news/security/cisco-warns-of-firewall-zero-day-exploited-to-crash-ssl-vpn-devices/
Cisco Software Checker: https://sec.cloudapps.cisco.com/security/center/softwarechecker.x

Inception Protection

Inception Protection is our managed detection and response service, and it works with the Microsoft licenses you already have. We can bring firewall syslog into the same place we already watch, so an unscheduled reload gets a human look.

Inception Foresight

If you want to see whether signals like firewall reboots would reach your Microsoft security tools at all, try the free Inception Foresight M365 Assessment: https://www.inceptionsecurity.com/m365assessment.