FIRESTARTER and the Firewall Persistence Problem

CISA's public analysis report, identified as AR26-113A, describes FIRESTARTER as a backdoor used for persistence on Cisco Firepower and Secure Firewall devices. Public summaries of the report state that CISA and the UK NCSC assess advanced persistent threat actors are using the malware to target publicly accessible Cisco Firepower and Secure Firewall devices running ASA or FTD software.

Cisco Talos reports that the activity is associated with UAT-4356, a threat actor Cisco previously connected to ArcaneDoor, a state-sponsored campaign focused on network perimeter devices for espionage. Talos says UAT-4356 exploited n-day vulnerabilities CVE-2025-20333 and CVE-2025-20362 to gain access to vulnerable devices and deploy FIRESTARTER.

CISA also updated Emergency Directive 25-03 for U.S. Federal Civilian Executive Branch agencies. Although the directive applies directly to those agencies, the operational lesson applies broadly: organizations using affected Cisco appliances should not assume that a patched device is automatically clean if it was already compromised.

Cisco's April 23, 2026 advisory gives defenders a concrete public indicator for the newly described persistence mechanism. The implant is known to start a malicious process named `lina_cs`. On Cisco Secure Firewall ASA, run `show kernel process | include lina_cs` from the appliance command-line interface. On Cisco Secure FTD, run the same command from the FTD command-line interface.

If the command returns empty output, Cisco says that is an indication that the persistence mechanism described in the advisory is not present. Empty output is not a guarantee that the organization never had related exposure; it simply means this specific public indicator was not observed. If the device is not already on a fixed release, it should still be upgraded immediately.

If the command returns any output for `lina_cs`, Cisco says the device is considered compromised. At that point the response path changes: do not treat the problem as a normal patching ticket. The device should be handled as a compromised perimeter control plane, with evidence preservation, reimaging and credential review.

A compromised firewall is different from a compromised workstation. A workstation is usually one asset inside the network. A firewall or remote-access appliance is a trust broker: it terminates remote sessions, sees traffic flows, enforces policy and often sits close to privileged administration.

That position makes appliance malware strategically useful. A threat actor does not need to compromise every internal host if the actor can maintain access through the device that already mediates remote access or network segmentation. Even limited persistence on an edge appliance can give an attacker time, visibility and a durable foothold.

This is why FIRESTARTER should be read as an infrastructure-trust problem. Patching the vulnerabilities matters, but restoring trust in the appliance requires a separate question: was this specific device compromised before the patch, and does it still contain persistence or attacker-controlled state?

The most important operational lesson is the gap between remediation and eviction. Remediation closes a vulnerability or applies a vendor fix. Eviction removes the threat actor's foothold and proves that the compromised system can be trusted again.

Cisco's April 2026 persistence advisory states that the ArcaneDoor actor developed a previously unknown persistence mechanism preserved across upgrades to the fixed releases published in September 2025. Cisco says the mechanism resides in the Cisco Firepower eXtensible Operating System (FXOS) base operating system for Cisco Secure Firewall ASA and FTD installations on affected hardware platforms.

That detail changes the response model. An ASA or FTD application upgrade may close the original VPN web server vulnerabilities, but it does not by itself prove that FXOS-level persistence has been removed. Cisco strongly recommends reimaging and upgrading the device with the fixed releases listed in the April advisory if compromise is confirmed.

For enterprise teams, the lesson is not to improvise. Edge appliances often require vendor-specific recovery steps. A patch-only response may stop the original exploit path but leave unanswered whether the device was already modified, whether credentials were observed, or whether configuration integrity has been affected.

Cisco describes a physical cold restart as an alternative mitigation when reimaging cannot be performed immediately. The wording matters: `shutdown`, `reboot` and `reload` command-line operations do not clear the malicious persistent implant. Cisco says the power cord must be physically pulled and plugged back in for the cold restart mitigation.

That is not the same as a recommended recovery path. Cisco explicitly warns that disconnecting device power can risk database or disk corruption, and that devices might not boot or run as expected afterward. In a production firewall cluster, remote-access gateway or segmentation enforcement point, that operational risk can become an outage.

The safe way to frame cold restart is therefore: it may remove the implant temporarily, but it should be reserved for emergency containment when reimaging is not immediately possible and when the business accepts the availability and corruption risk. The preferred path remains evidence-aware reimaging and upgrade.

If `lina_cs` is present, treat the device as compromised. Preserve available evidence according to Cisco, CISA and internal incident-response requirements. Open a vendor support or incident-response path. Prepare a clean replacement or maintenance window. Reimage the device and upgrade to the fixed release for the relevant train. Rotate credentials, certificates, keys and remote-access secrets that the appliance could have exposed. Review virtual private network sessions, administrative access, configuration changes and logs before returning the device to trust.

If `lina_cs` is not present and there is no other evidence of compromise, the priority is still to remove exposure. Confirm platform and software train, then upgrade to the fixed release or later release listed by Cisco. Because the initial exploitation path involved CVE-2025-20333 and CVE-2025-20362, devices exposed before patching should still be reviewed for suspicious authentication, remote-access and management events.

If the result is ambiguous, do not average the two paths. Escalate. A perimeter device with unclear integrity should be treated as untrusted until a qualified response team, Cisco guidance or forensic evidence says otherwise.

Cisco's April 2026 persistence advisory lists first fixed releases for the affected trains. If compromise is confirmed, Cisco says the device should be reimaged and upgraded using the fixed releases in that advisory. For devices without the public compromise indicator, the same fixed-release list is the baseline for removing exposure to the persistence issue described in April 2026.

For Secure Firewall ASA software, the first fixed releases are: 9.16.4.92 for train 9.16, 9.18.4.135 for train 9.18, 9.20.4.30 for train 9.20, 9.22.3.5 for train 9.22, 9.23.1.195 for train 9.23 and 9.24.1.155 for train 9.24.

For Secure FTD software, the first fixed releases are: 7.0.9 followed by Hotfix FZ-7.0.9.1-3, 7.2.11 followed by Hotfix HI-7.2.11.1-1, 7.4.7, 7.6.4 followed by Hotfix CC-7.6.4.1-1, 7.7.11 followed by Hotfix AE-7.7.11.1-4, and 10.0.0 followed by the relevant hot fix targeted by Cisco for April 30, 2026.

For Firepower 4100 and 9300 FXOS trains, the first fixed releases listed by Cisco are: 2.10.1.383, 2.12.1.117, 2.14.3.125, 2.16.2.119, 2.17.0.549 and 2.18.0.535. For exact platform compatibility and later combined fixes, teams should still use Cisco's advisory and Software Checker rather than copying a table into a change ticket without validation.

Start with inventory. Identify Cisco Firepower and Secure Firewall devices, their software trains, whether they run ASA or FTD software, whether they are internet-facing, and whether they provide virtual private network access. Unsupported, forgotten or externally managed appliances deserve special scrutiny.

Next, separate patch status from compromise status. A device may be running a fixed version and still require forensic review if it was exposed before the patch or shows suspicious behavior. Use vendor and CISA guidance for collection and detection rather than relying on generic endpoint tooling.

Finally, review everything the appliance could have touched. That includes local administrator credentials, remote-access identities, certificates, keys, configuration backups, authentication integrations, logging destinations and management access paths. A firewall compromise is rarely just about the firewall.

Firewall malware is uncomfortable because normal security telemetry can be thin at the exact point where defenders need confidence. Endpoint detection and response agents may not run on the appliance, and a successful implant may live close to the processes that enforce access.

Cisco Talos provides artifact-oriented detection notes and points customers to Cisco's advisory for more comprehensive detection guidance, indicators of compromise and affected products. CISA's Malware Analysis Report includes detection content such as YARA rules for analysis against disk images or core dumps, according to public summaries of the report.

The practical defender move is to make appliance telemetry part of the security operations center workflow. Device integrity checks, configuration change logs, unexpected process artifacts, unusual management sessions, virtual private network anomalies and traffic-flow changes should be reviewed together rather than in separate network and security silos.

FIRESTARTER should push security architects to treat network appliances as managed, monitored and recoverable platforms, not static boxes at the edge. The organization should know who owns them, how they are patched, how compromise is detected, how images are restored, how secrets are rotated and how traffic is rerouted during recovery.

The architecture conversation should also include blast radius. If one firewall or remote-access appliance is untrusted, what services depend on it? Can remote access be moved to a clean path? Are management interfaces isolated? Are logs centralized? Are backups and configuration exports protected from tampering?

A mature response plan does not begin on the day CISA publishes a malware analysis report. It begins with appliance lifecycle management, vendor supportability, centralized logging, out-of-band recovery plans and tested failover.

The quickest way to turn FIRESTARTER into useful work is to ask a small set of ownership questions. Do we know every Cisco Firepower and Secure Firewall appliance we run? Which ones are internet-facing? Which ones terminate remote access? Which ones are managed by a third party? Which ones are out of support?

Then ask response questions. If one appliance is suspected of compromise, who collects evidence? Who talks to Cisco or CISA? Who can reroute traffic? Who can rotate certificates and local credentials? Who decides whether the device is reimaged, replaced or physically power cycled?

The exact recovery path must follow vendor and official guidance. But the organizational preparation belongs to the enterprise now.