| CARVIEW |
Detection Guide for Continued Attacks against Cisco Firewalls by the Threat Actor behind ArcaneDoor
Version 1.1: September 26, 2025
The information contained in this document allows for the identification of potentially malicious traffic targeting devices running Cisco ASA or FTD Software that are configured as VPN head ends.
Affected device configuration are IKEv2 with client services and any SSL VPN configurations.
Detection Guidance
The following detection logic and guidance are not indicative of conclusive compromise evidence but serve as a solid foundation for identifying potentially malicious activity that warrants more in-depth forensic data collection and analysis.
If you suspect malicious activity based on the detection logic and guidance in this document, open a case with the Cisco Technical Assistance Center (TAC), referencing the ArcaneDoor keyword, for further analysis.
Scanning vs. Compromise
The threat actor continues to scan targets of interest from malicious IP addresses that are continuously changing to avoid detection. Observing scanning traffic from the threat actor does not mean the device is compromised. Follow the guidance in this document for identifying potentially malicious activity that warrants more in-depth forensic data collection and analysis.
Also note that the only confirmed compromised Cisco ASA devices are the following Cisco ASA 5500-X Series models that are running Cisco ASA Software Release 9.12 or 9.14 with VPN web services enabled:
- 5512-X and 5515-X
- 5525-X, 5545-X, and 5555-X
- 5585-X
Syslog Changes
The following syslog IDs have been observed to be suppressed by this threat actor as a forensic countermeasure. This happens in-memory and will not be visible in the running-config.
- 302013 (“informational” level)
- 302014 (“informational” level)
- 609002 (“debug” level)
- 710005 (“debug” level)
The absence or volumetric shift (downward) of these messages in the logs serve as an indicator that there may be malicious activity occurring within your network. Historic analysis of these syslog IDs may also provide evidence of a potential previous compromise. In both cases full forensic collections are advised.
Note: Syslogs at “informational” level and especially at “debug” level are verbose. Log at “debug” level only temporarily, when debugging issues. This log level can potentially generate so many messages that system performance can be affected.
Instead of enabling all syslogs messages of the “informational” or “debug” level customer can also change the severity level of the above syslog messages to the syslog level they have currently enabled using the logging message syslog_id level severity_level command in global configuration mode. For more information, see Change the Severity Level of a Syslog Message in the Cisco Secure Firewall ASA Series General Operations CLI Configuration Guide.
Note: Syslog IDs 302013, 302014, 609002, and 710005 are verbose. Cisco recommends that customers closely monitor that enabling these syslog IDs does not overwhelm their syslog servers.
Splunk Analytics
Splunk, a Cisco company, has made the following analytics story available https://research.splunk.com/stories/arcanedoor/. This analytic story is designed to help security teams detect and respond to ArcaneDoor-related activity.
Checkheaps Manipulation
This threat actor has been observed to disable the checkheaps function. By default, checkheaps will run once every 60 seconds. Issuing the command show checkheaps will produce the following output:
firewall# show checkheaps Checkheaps stats from buffer validation runs -------------------------------------------- Time elapsed since last run : 28 secs Duration of last run : 0 millisecs Number of buffers created : 106 Number of buffers allocated : 103 Number of buffers free : 3 Total memory in use : 110620 bytes Total memory in free buffers : 124 bytes Total number of runs : 6352 firewall#
This command should be executed once a minute for a period of five minutes. There should be an observable change in the Total number of runs counter. If there is no observable positive change in this value, this is evidence of a potential compromise, and full forensic collections are advised.
Impossible Travel
This threat actor has been observed utilizing stolen credentials to make authenticated VPN connections. In all observed instances, the connections have been sourced from within the continental United States but have varied widely regarding the geographic location, often varying thousands of miles. It is recommended that seemingly valid VPN connections have their source IP address profiled to identify impossible travel which may serve as an indicator that malicious activity is occurring.
If the same user connects from two different locations within a time period that is shorter than it would take to travel between the two locations through conventional air travel, that is an “impossible travel”.
Bootloader and/or ROMMON Verification Failure
Customers who upgraded a Cisco ASA 5512-X, 5515-X, 5525-X, 5545-X, or 5555-X device to Cisco ASA Software Release 9.12.4.72 or 9.14.4.28 should look for a file called firmware_update.log on disk0:. The existence of that file could indicate that the device was compromised prior to the upgrade to Cisco ASA Software Release 9.12.4.72 or 9.14.4.28.
If the file firmware_update.log is found on disk0: after upgrade to a fixed release, customers should open a case with the Cisco Technical Assistance Center (TAC) with the output of the show tech-support command and the content of the firmware_update.log file.
Customers should also monitor the device console during the initial boot of the device during the upgrade to Cisco ASA Software Release 9.12.4.72 or 9.14.4.28. Seeing the following messages indicates that the persistence mechanism observed in this attack campaign was not present on this device (message IDs may differ):
. . . Message #113 : Verifying bootloader: Message #114 : .Message #115 : .Message #116 : .Message #117 : Bootloader verification succeeded. Message #118 : Verifying ROMMON: Message #119 : .Message #120 : .Message #121 : .Message #122 : .Message #123 : ROMMON verification succeeded. . . .
If the highlighted messages were to start with Bootloader verification failed at address and/or ROMMON verification failed at address instead, that would be an indication that the persistence mechanism observed in this attack campaign was present on this device. In this case, a file called firmware_update.log would be written to disk0: (or appended to if the file exists) and the device is rebooted to load a clean system immediately afterward.
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.