Executive summary
On 23 April 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) and the UK National Cyber Security Centre (NCSC) published an analysis of FIRESTARTER, a backdoor found during investigation of a Cisco Firepower device running Adaptive Security Appliance (ASA) software. The agencies assess that the implant preserved access after security patches and enabled the actor to return without exploiting the original vulnerabilities again. CISA’s confirmed in-the-wild implant observation concerns that Firepower/ASA combination, although the report discusses a broader technical scope. We assess it is likely (B2) that organisations treating a successful firmware update as proof of eviction will overlook an important recovery question: whether an implant installed before patching remains present.
Contextual background
The joint report follows investigation of suspicious connections on a US federal agency’s firewall. CISA says the actor initially deployed LINE VIPER and subsequently used FIRESTARTER to maintain access. The agencies assess that compromise occurred before the agency’s response to the September 2025 emergency directive, but the precise initial exploitation date is unconfirmed. The report describes further LINE VIPER deployment in March 2026.
CISA assesses, but has not confirmed, that initial access involved CVE-2025-20333 or CVE-2025-20362. Those identifiers describe suspected entry routes; FIRESTARTER is the persistence mechanism under investigation. Presenting the entire sequence as a proven exploitation chain would exceed the evidence in the report.
The distinction changes the response objective. Patching addresses a vulnerable entry point, while compromise assessment asks what an intruder installed or accessed before the patch. Our recommendation is to track those as separate work items with separate closure evidence. This is especially important when a network appliance has already been updated and its current version no longer appears in an affected-version inventory.
Technical analysis
CISA describes FIRESTARTER as a Linux executable that provides remote access and control. The analysed sample interacts with LINA, the device’s network-processing engine, and supports loading additional actor-supplied code. The report describes copying the implant into memory, arranging callbacks for termination-related events and using files in reboot-persistent storage to restore execution. These are findings about the analysed sample, rather than evidence that every installation has identical filenames or identifiers. CISA analysis
The key operational property is survival across firmware updates and ordinary device reboots. The agencies distinguish this from a hard power disconnection. Their report says FIRESTARTER was present before patching and enabled renewed access later without re-exploitation. A routine restart, a firmware-version check and a compromise investigation therefore answer different questions.
The report also describes LINE VIPER establishing unauthorised virtual private network (VPN) sessions and access to device configuration material, including administrative credentials, certificates and private keys. These findings create a wider scoping problem than removal of one executable. Our recommendation is to investigate the trust material and downstream access available from the device, with credential and certificate decisions based on the organisation’s actual deployment.
The report does not attribute the actor to a named country or commercial tracking cluster. It refers to advanced persistent threat actors. This article retains that boundary: the malware name and the affected product are not sufficient to assign a sponsor or merge the case with another publicly reported firewall intrusion.
Impact assessment
The agencies’ assessment is that FIRESTARTER can preserve access on relevant Cisco devices running ASA or Firepower Threat Defense software. Their technical discussion should be read alongside the narrower observation: CISA had seen a successful implant in the wild on a Firepower device running ASA. A product appearing in the broader scope is a reason to assess applicability, not proof that every deployment is infected.
Our recommended impact assessment records three boundaries: the appliance itself, the identities and secrets it holds, and the networks or services reachable through it. Determine which of those were actually accessed, which were merely available and which cannot be resolved from the surviving evidence. Avoid translating theoretical access into an unsupported statement that all connected systems were compromised.
Availability also matters during recovery. A firewall may support remote access or connectivity for critical services. Before taking it out of service, identify the approved maintenance or failover procedure and the people authorised to execute it. Those operational arrangements should support the incident response plan without allowing convenience to become an indefinite reason to leave confirmed malicious access in place.
Indicators and forensic artefacts
These selected artefacts come from CISA’s sample analysis. They support forensic investigation; they are not a complete detection rule or a universal list of names used by the actor.
| Artefact | Reported significance | Investigation caveat |
|---|---|---|
/usr/bin/lina_cs |
Name of the analysed executable | CISA warns that filenames can change; the sample also deletes this file during its operation |
/opt/cisco/platform/logs/var/log/svc_samcore.log |
Location used to stage a copy during persistence handling | Treat as a sample-specific path and examine content and context |
/opt/cisco/config/platform/rmdb/CSP_MOUNT_LIST |
File modified as part of persistence | Compare with trusted device state through the supported forensic process |
CISA_261290_01 and CISA_261290_02 |
YARA rules supplied with the report | Apply the complete published rules to the specified evidence types |
Do not use the absence of one filename as evidence of a clean device. The report’s memory-focused detection guidance and filename caveat directly limit that conclusion. Conversely, a path name alone does not establish the presence of the implant; validate the file, memory evidence and associated behaviour.
Detection and hunting guidance
The primary guidance recommends examining a core dump or disk image with the supplied YARA rules. CISA identifies memory analysis as the principal detection method. It says conventional Sigma rules do not provide effective detection for this malware in standard monitoring platforms; that statement concerns this implant and should not be expanded into a claim that network or identity telemetry has no investigative value.
Our recommended evidence plan identifies the collector, the destination for sensitive diagnostic material and the record of collection time. Coordinate with the appropriate agency or Cisco support channel before changing device state. The report specifically warns that reboots, patches, configuration changes and hard power cycles can affect volatile evidence. Preserve the outputs required by the applicable instructions, rather than improvising a collection sequence on a production appliance.
Use other telemetry to scope the incident around the forensic finding. Review unexpected VPN sessions, use of inactive accounts, administrative actions and connections inconsistent with the device’s role. These are investigative questions grounded in the reported case, not a claim that each event is unique to FIRESTARTER. Preserve benign explanations and correlate the timing with the suspected compromise interval.
Incident response guidance
The report gives different instructions to different audiences. The following summary preserves those boundaries; the complete advisory remains the controlling operational reference.
| Organisation | Direction in the joint report |
|---|---|
| US federal civilian executive-branch agency | Collect and submit core dumps, report the submission to CISA, and take no further action until CISA provides guidance |
| Other US organisation | Collect evidence and apply the supplied rules; if compromise is confirmed, follow the report’s response and power-disconnection procedure and report the finding |
| UK organisation | Collect evidence, apply the rules and report a detection to the NCSC; await guidance before disconnecting power |
For the non-federal US procedure, CISA describes removing the still-powered device from every power source, including redundant supplies, leaving it fully disconnected for one minute and then reconnecting it. The report explicitly says that an ordinary shutdown or reboot is insufficient. This is not a blanket instruction for all readers to unplug a firewall immediately: evidence collection, confirmation and the relevant jurisdiction-specific direction come first. Response instructions
Our recommended recovery record includes the evidence result, the guidance received, the exact eradication action and the subsequent verification. Review potentially exposed administrative credentials, certificates and other trust material through the appropriate vendor and identity-management procedures. Confirm that required services return correctly and that suspicious access has ceased. A restored service proves availability; it does not by itself prove that all incident consequences have been resolved.
Threat intelligence context
The following ATT&CK references explain selected behaviours in the joint analysis. Preserve the report’s uncertainty about initial exploitation.
| Technique | Relationship to the case |
|---|---|
| T1190: Exploit Public-Facing Application | CISA’s assessed, unconfirmed initial-access route |
| T1055: Process Injection | The analysed implant modifies execution within the device’s processing environment |
| T1070.004: File Deletion | The sample removes files during its operation |
The report connects the current finding with activity preceding patching in September 2025 and renewed access in March 2026. That chronology explains why a retrospective hunt can be necessary on an updated device. It does not establish a universal dwell time or prove that every suspicious connection during that interval belonged to the same operator.
Mitigation recommendations
The agencies recommend maintaining security updates and prioritising known exploited vulnerabilities. They also state that the patches available at the time of the earlier emergency directive did not remove FIRESTARTER’s persistence. Apply both parts of that guidance: keep the software supported and current, and conduct the separate compromise assessment appropriate to the evidence. Mitigations
Our recommended preparation is to document how the organisation will obtain appliance evidence before an incident. Include the support contact, protected evidence storage, required authorisations and recovery constraints. Test that the response team can obtain the relevant logs and reach the network owner outside ordinary maintenance windows. Record which actions would destroy volatile evidence so that an urgent availability fix does not accidentally erase the investigation’s most useful material.
Include an explicit handover between network engineering and incident response. The handover should identify the collected evidence, the maintenance action still required and the person responsible for confirming the result. This avoids an appliance returning to normal service with a patch task completed but the associated compromise investigation still unresolved.
Outlook
The defensive lesson is a specific one: an appliance may need both vulnerability remediation and eradication of access established earlier. Our assessment is that recovery decisions will be stronger when they retain the distinction between confirmed findings, assessed entry routes and unresolved scope. A version number remains useful evidence about software state, but the joint FIRESTARTER analysis shows why it cannot be the only evidence used to close this incident.
