The FIRESTARTER backdoor is a reminder that patching vulnerable Cisco edge devices is only half the battle: if attackers implant persistence before remediation, they can survive firmware updates and return later without re-exploiting the original flaw. CISA and the U.K. NCSC say the malware was found during a forensic investigation on a Cisco Firepower device running ASA software, where it worked alongside LINE VIPER to maintain access after initial compromise. The result is a much nastier problem for defenders than a simple intrusion: a post-patching foothold living inside infrastructure many teams assume is already “fixed.”
CISA’s April 23, 2026 Malware Analysis Report lands in a very specific and uncomfortable moment for defenders. It ties FIRESTARTER to a broader campaign against publicly accessible Cisco Firepower and Secure Firewall devices running ASA or FTD software, and it explicitly says the sample analyzed by CISA functioned as a backdoor with persistence features. That matters because the report is not describing a theoretical implant or an abstract proof of concept; it is describing live tradecraft recovered from a real investigation.
The report also connects the malware to earlier exploitation activity involving CVE-2025-20333 and CVE-2025-20362, which CISA says likely provided the initial access path into the device. In other words, the compromise likely began as a perimeter-device intrusion and then evolved into a long-term occupation. CISA’s assessment is that the actors first used LINE VIPER as a post-exploitation implant, then used FIRESTARTER as the persistence mechanism that survived remediative actions and allowed later re-entry.
That sequencing is the core of the story. Modern defenders are accustomed to thinking in terms of “patch, reboot, verify,” but FIRESTARTER is built to frustrate exactly that workflow. CISA says the malware persists through firmware updates and reboots unless the device is subjected to a hard power cycle, which means ordinary remediation can leave the implant intact. The implication is grim but clear: if you do not understand the persistence layer, you may simply be preserving the attacker’s foothold while believing the problem has been solved.
The advisory is also notable because it applies to both government and non-government organizations. CISA is using the report to support its updated Emergency Directive 25-03, but the guidance is not limited to federal civilian executive branch agencies. For the broader market, the report is a warning that edge-device incidents can be both stealthy and stubborn, especially when the attacker has already reached the part of the network where trust is highest and visibility is lowest.
The report’s emphasis on core dumps, memory analysis, and device-level forensics also signals how difficult this class of incident is to handle. You are not chasing a file on a laptop; you are hunting embedded state inside a security appliance that may have been trusted for months. That changes both the response playbook and the operational risk calculus.
Once inside, the actors reportedly used LINE VIPER to establish illegitimate VPN sessions that bypassed VPN authentication policies. CISA says those sessions were associated with user accounts that existed but were no longer active, which is a familiar but dangerous trick: dead accounts often linger long enough to become useful to attackers, especially when administrators assume they no longer matter. The report also says LINE VIPER exposed configuration elements, administrative credentials, certificates, and private keys.
This is a strong reminder that valid accounts are often the least glamorous part of a compromise and one of the most dangerous. Attackers do not always need fresh exploits when old accounts, residual trust, and exposed services are already enough to move. In practical terms, identity cleanup is a security control, not an administrative nicety.
The malware’s persistence model is unusually elegant in a malicious sense. FIRESTARTER installs signal handlers so it can react to termination-related signals such as SIGTERM, SIGINT, SIGQUIT, SIGABRT, SIGHUP, and SIGTSTP. When it gets those signals, it triggers a callback that writes a copy of itself to a reboot-persistent location and reconstructs the boot-time script needed to relaunch it.
This is a particularly sharp example of living off the device. The malware is not trying to look like a flashy dropper or a noisy agent; it is trying to look like a normal Cisco component long enough to survive the cleanup cycle. That blend of masquerading and reboot persistence is exactly why security appliances are so dangerous when compromised.
That process is not random. It is a deliberate attempt to understand and alter internal program structure rather than just inject a generic payload. Once it finds the right location, the malware installs a hook that allows arbitrary shell code supplied by the actors to execute inside the target process. That makes the implant much more flexible, because the attacker can use the same foothold to deploy follow-on tooling or modify behavior on demand.
CISA also says the injected shellcode lands in the code section of
This is a notable level of operational discipline. Rather than spraying broadly and hoping for persistence, the malware waits for the right environment before fully activating its next stage. That reduces noise and may help the actors avoid detonating their own tooling on the wrong device. It also suggests that the attackers understand the Cisco platform well enough to embed environment-specific guardrails.
For defenders, this means the question is not only “is the box patched?” but also “was it ever compromised in a way that survives the patch?” That is a much harder question, and it is why core dumps and memory analysis are central to the response plan.
The reason is straightforward. FIRESTARTER does not announce itself with conventional log evidence, and CISA explicitly says Sigma rules are not effective because the malware does not generate observable log events or standard behavioral anomalies. That is a sobering statement for teams that rely heavily on centralized logging to identify compromise. If the platform is compromised at the memory layer, the logs may be too clean to help.
That caution is more than procedural caution. It reflects the fact that a rushed response can erase the very clues needed to determine whether the device is merely exposed or actually implanted. In a case like this, what you do first can matter as much as what you do last.
One of the most interesting things about the rules is what they reveal about the malware’s operational habits. They key off paths such as Cisco configuration and log locations, runlevel references, and process-map behavior. That tells defenders the implant is closely aligned with the target platform’s internals, which again reinforces the point that this is not a commodity malware sample that could be dropped anywhere and expected to work.
That distinction matters for resource planning. A well-run hunt may use YARA to prioritize which core dumps or disk images deserve deeper inspection, but the deeper question—whether the device has been used as a covert persistence platform—still requires forensics. The best outcome is to use YARA to narrow the search, not to declare victory.
That is a striking recommendation because it underscores how deeply the persistence mechanism is embedded. A reboot is not enough. A software patch is not enough. CISA is effectively saying that in some cases the only reliable way to strip the implant is to remove all power sources, including redundant power, wait, and then reconnect. That is a very different mental model than routine network remediation.
For agencies running critical perimeter infrastructure, that creates an operational tension. You want to preserve service availability, but you also need to eliminate a backdoor that could re-open the network at any time. The tradeoff is ugly, and that is precisely why this kind of incident needs staged response coordination rather than improvisation.
That caution is important because it reflects the risk of taking action too early or in the wrong order. In many environments, an instinctive reboot or immediate isolation may seem sensible, but it can also destroy evidence or leave the persistence mechanism intact. The better approach is disciplined containment, artifact collection, and coordinated remediation.
Still, the lesson is the same. A security device with persistent backdoor characteristics should be treated like a compromised crown-jewel system, not like a disposable edge box. That is a mindset shift many teams still struggle to make until after the breach.
One of the report’s sharpest observations is that patching available at the time of ED 25-03 did not specifically remove FIRESTARTER, even though it mitigated the original vulnerabilities. That means remediation cannot stop at “install the update.” A patched device may still be contaminated, and defenders need a separate validation step to prove the backdoor is gone.
The recommendation to modernize administrative access with TACACS+ over TLS 1.3 is especially interesting because it signals a shift toward protecting the management plane itself. That is the right direction. If attackers are exploiting device administration paths, then securing the administrative channel becomes part of the remediation, not a separate best-practice project for later.
Another important watchpoint is whether follow-on reporting reveals more about the original intrusion chain. If additional samples, indicators, or forensic cases surface, defenders may get a clearer picture of whether FIRESTARTER is a one-off implant or part of a more systematic Cisco edge-device playbook. Either way, the lesson is already visible: once attackers reach the management plane, the cleanup problem becomes much harder than the breach itself.
Source: CISA FIRESTARTER Backdoor | CISA
Overview
CISA’s April 23, 2026 Malware Analysis Report lands in a very specific and uncomfortable moment for defenders. It ties FIRESTARTER to a broader campaign against publicly accessible Cisco Firepower and Secure Firewall devices running ASA or FTD software, and it explicitly says the sample analyzed by CISA functioned as a backdoor with persistence features. That matters because the report is not describing a theoretical implant or an abstract proof of concept; it is describing live tradecraft recovered from a real investigation.The report also connects the malware to earlier exploitation activity involving CVE-2025-20333 and CVE-2025-20362, which CISA says likely provided the initial access path into the device. In other words, the compromise likely began as a perimeter-device intrusion and then evolved into a long-term occupation. CISA’s assessment is that the actors first used LINE VIPER as a post-exploitation implant, then used FIRESTARTER as the persistence mechanism that survived remediative actions and allowed later re-entry.
That sequencing is the core of the story. Modern defenders are accustomed to thinking in terms of “patch, reboot, verify,” but FIRESTARTER is built to frustrate exactly that workflow. CISA says the malware persists through firmware updates and reboots unless the device is subjected to a hard power cycle, which means ordinary remediation can leave the implant intact. The implication is grim but clear: if you do not understand the persistence layer, you may simply be preserving the attacker’s foothold while believing the problem has been solved.
The advisory is also notable because it applies to both government and non-government organizations. CISA is using the report to support its updated Emergency Directive 25-03, but the guidance is not limited to federal civilian executive branch agencies. For the broader market, the report is a warning that edge-device incidents can be both stealthy and stubborn, especially when the attacker has already reached the part of the network where trust is highest and visibility is lowest.
Why this case is different
What makes FIRESTARTER especially important is that it is not just “malware on a firewall.” It is malware designed to survive on a device that many teams consider operationally stable and rarely touch unless something is already broken. That kind of persistence makes the incident feel less like an endpoint compromise and more like a compromised control plane.The report’s emphasis on core dumps, memory analysis, and device-level forensics also signals how difficult this class of incident is to handle. You are not chasing a file on a laptop; you are hunting embedded state inside a security appliance that may have been trusted for months. That changes both the response playbook and the operational risk calculus.
- The malware was found on a Cisco Firepower device running ASA software.
- CISA says it can persist through reboots and firmware updates.
- The implant can re-establish command-and-control channels after remediation.
- The campaign is tied to earlier Cisco exploitation activity.
The Initial Compromise Story
CISA assesses, but does not fully confirm, that the actors obtained initial access by exploiting CVE-2025-20333 and/or CVE-2025-20362 in Cisco ASA firmware. The agency places the compromise in early September 2025, before the affected agency had implemented the relevant patches. That timeline matters because it shows how fast an edge-device compromise can age into a persistence problem if defenders do not validate whether the attacker did anything beyond the initial intrusion.Once inside, the actors reportedly used LINE VIPER to establish illegitimate VPN sessions that bypassed VPN authentication policies. CISA says those sessions were associated with user accounts that existed but were no longer active, which is a familiar but dangerous trick: dead accounts often linger long enough to become useful to attackers, especially when administrators assume they no longer matter. The report also says LINE VIPER exposed configuration elements, administrative credentials, certificates, and private keys.
The role of stale identity
That detail about former-employee accounts is not cosmetic. It shows how edge-device compromise and identity hygiene converge into the same incident. If an attacker can combine a perimeter foothold with stale credentials or stale accounts, the device may be treated as legitimate infrastructure while actually serving hostile sessions.This is a strong reminder that valid accounts are often the least glamorous part of a compromise and one of the most dangerous. Attackers do not always need fresh exploits when old accounts, residual trust, and exposed services are already enough to move. In practical terms, identity cleanup is a security control, not an administrative nicety.
- The compromise likely began before patching.
- LINE VIPER was used for unauthorized VPN access.
- The access involved accounts that should no longer have been active.
- Configuration secrets were exposed after initial entry.
What FIRESTARTER Actually Does
CISA describes FIRESTARTER as a Linux ELF designed to run on Cisco Firepower and Secure Firewall devices, serving as a command-and-control channel for remote access and control. The sample obtained by CISA was named lina_cs, though the agency cautions that filenames can be changed easily. That may sound mundane, but it matters because it means defenders should care more about behavior and memory artifacts than the filename alone.The malware’s persistence model is unusually elegant in a malicious sense. FIRESTARTER installs signal handlers so it can react to termination-related signals such as SIGTERM, SIGINT, SIGQUIT, SIGABRT, SIGHUP, and SIGTSTP. When it gets those signals, it triggers a callback that writes a copy of itself to a reboot-persistent location and reconstructs the boot-time script needed to relaunch it.
Persistence by design
That architecture gives FIRESTARTER a built-in survival instinct. If the process is interrupted in a normal way, it responds by copying itself into a location that survives reboots and then restoring its launch path. The report says it stages itself in/opt/cisco/platform/logs/var/log/svc_samcore.log, then moves that payload into /usr/bin/lina_cs, makes it executable, and runs it in the background.This is a particularly sharp example of living off the device. The malware is not trying to look like a flashy dropper or a noisy agent; it is trying to look like a normal Cisco component long enough to survive the cleanup cycle. That blend of masquerading and reboot persistence is exactly why security appliances are so dangerous when compromised.
Key behaviors at a glance
- Registers signal handlers to survive termination attempts.
- Copies itself into a reboot-persistent directory.
- Rewrites boot-time behavior so the malware relaunches automatically.
- Deletes staging artifacts to reduce forensic visibility.
Memory Manipulation and Hooking
One of the most technically interesting parts of the report is FIRESTARTER’s memory scanning behavior. CISA says the malware enumerates LINA’s virtual memory map to find the writable data segment associated with the main process, then parses that memory to locate the XML Handler element table. The malware appears to use a custom algorithm to locate handler pointers tied to a specific sequence of element IDs.That process is not random. It is a deliberate attempt to understand and alter internal program structure rather than just inject a generic payload. Once it finds the right location, the malware installs a hook that allows arbitrary shell code supplied by the actors to execute inside the target process. That makes the implant much more flexible, because the attacker can use the same foothold to deploy follow-on tooling or modify behavior on demand.
Why the hook matters
The report says the malware attempts to install a hook within LINA, the device’s core engine for network processing and security functions. That is the real prize. If you can influence the core engine, you are no longer merely sitting on the perimeter; you are inside the logic that controls how traffic is parsed and handled.CISA also says the injected shellcode lands in the code section of
libstdc++.so, which is a classic sign of process injection. The practical significance is that the implant is not just writing files; it is altering execution flow inside a sensitive process. That is a much harder threat to detect with ordinary host logs, especially when the device is already expected to run complex networking code.- LINA’s memory map is actively parsed by the malware.
- A hook is installed to run attacker-supplied shell code.
- Shellcode is injected into a shared library’s text region.
- The malware relies on process internals, not just filesystem artifacts.
Victim Identification and Stage Loading
CISA says FIRESTARTER includes a victim-identification routine that checks for a hard-coded 8-byte ASCII string unique to the installation, along with a victim-specific 8-byte ID embedded in the shellcode. Only when both values match does the next stage load into LINA’s memory and become executable. That implies the implant is not merely opportunistic malware; it is tailored to a specific target or family of targets.This is a notable level of operational discipline. Rather than spraying broadly and hoping for persistence, the malware waits for the right environment before fully activating its next stage. That reduces noise and may help the actors avoid detonating their own tooling on the wrong device. It also suggests that the attackers understand the Cisco platform well enough to embed environment-specific guardrails.
Comparison to broader bootkit behavior
CISA says FIRESTARTER closely mirrors the RayInitiator Cisco ASA bootkit stage 3 deploy path. That comparison is important because it places FIRESTARTER in a lineage of sophisticated Cisco-device tradecraft rather than in the category of random opportunistic malware. The deeper lesson is that the same operational patterns tend to recur: device compromise, durable staging, internal hooking, and selective activation.For defenders, this means the question is not only “is the box patched?” but also “was it ever compromised in a way that survives the patch?” That is a much harder question, and it is why core dumps and memory analysis are central to the response plan.
- The malware fingerprints the victim before loading the next stage.
- It appears to target a specific installation context.
- CISA compares the behavior to RayInitiator’s stage-3 path.
- The next stage is only activated after successful verification.
Detection and Forensics
CISA is unusually blunt about the best detection path here: memory analysis. The agency says U.S. FCEB agencies must collect core dumps from affected devices and submit them to CISA’s Malware Next Generation platform, which can analyze the core dumps for the presence and behavior of thelina_cs binary. That makes the detection workflow materially different from standard endpoint or SIEM triage.The reason is straightforward. FIRESTARTER does not announce itself with conventional log evidence, and CISA explicitly says Sigma rules are not effective because the malware does not generate observable log events or standard behavioral anomalies. That is a sobering statement for teams that rely heavily on centralized logging to identify compromise. If the platform is compromised at the memory layer, the logs may be too clean to help.
Why core dumps are central
The report recommends runningshow checkheaps and show tech-support detail, saving the output off-device, and then generating a core dump. That sequence is designed to preserve volatile evidence before it disappears, which is crucial because the malware is explicitly built to survive or clean up after itself. The guidance also warns against hard power cycles or other changes before coordination with CISA.That caution is more than procedural caution. It reflects the fact that a rushed response can erase the very clues needed to determine whether the device is merely exposed or actually implanted. In a case like this, what you do first can matter as much as what you do last.
- Core dumps are the primary detection artifact.
- Normal log-based detection is weak or ineffective.
- CISA wants output preserved before any disruptive action.
- Memory analysis is favored over conventional SIEM hunting.
The YARA Rules and What They Signal
CISA published YARA rules to help organizations detect FIRESTARTER against either disk images or core dumps. The rules focus on strings and shellcode fragments associated with the injector and its in-memory behavior, rather than on generic indicators that would be easy for an attacker to change. That choice is practical because filename changes and basic packaging changes would otherwise make static detection brittle.One of the most interesting things about the rules is what they reveal about the malware’s operational habits. They key off paths such as Cisco configuration and log locations, runlevel references, and process-map behavior. That tells defenders the implant is closely aligned with the target platform’s internals, which again reinforces the point that this is not a commodity malware sample that could be dropped anywhere and expected to work.
Why YARA helps, but only partially
The YARA rules are a useful hunting tool, but they are not a magic bullet. CISA itself says the primary detection method remains memory analysis, and that makes sense because the malware is built to blur the boundary between file system, process memory, and startup behavior. YARA can flag evidence; it cannot substitute for a full incident response.That distinction matters for resource planning. A well-run hunt may use YARA to prioritize which core dumps or disk images deserve deeper inspection, but the deeper question—whether the device has been used as a covert persistence platform—still requires forensics. The best outcome is to use YARA to narrow the search, not to declare victory.
- The rules are meant for disk images and core dumps.
- They target platform-specific strings and shellcode traits.
- They are hunting tools, not a complete response.
- CISA still prefers memory analysis as the primary method.
Response Guidance for Federal Agencies
For U.S. FCEB agencies, the report is unusually prescriptive. CISA wants agencies to collect and submit core dumps to the Malware Next Generation platform, immediately report the submission to CISA’s 24/7 Operations Center, and take no additional action until CISA provides further guidance. The agency even warns that if compromise is confirmed, it may instruct the organization to physically unplug the device from power.That is a striking recommendation because it underscores how deeply the persistence mechanism is embedded. A reboot is not enough. A software patch is not enough. CISA is effectively saying that in some cases the only reliable way to strip the implant is to remove all power sources, including redundant power, wait, and then reconnect. That is a very different mental model than routine network remediation.
The power-cycle reality
The report is explicit that merely powering the device off or rebooting it is insufficient for removal. The device must be fully disconnected from power for one minute before being reconnected and allowed to reboot. That is a useful but uncomfortable detail because it reveals how stubborn the persistence can be once it is established inside the appliance.For agencies running critical perimeter infrastructure, that creates an operational tension. You want to preserve service availability, but you also need to eliminate a backdoor that could re-open the network at any time. The tradeoff is ugly, and that is precisely why this kind of incident needs staged response coordination rather than improvisation.
- Submit core dumps through CISA’s MNG platform.
- Report immediately to the 24/7 Operations Center.
- Wait for direction before taking further steps.
- Physical power removal may be required to eliminate persistence.
Guidance for Other Organizations
CISA and the NCSC extend the same basic response philosophy to other U.S. and U.K. organizations, though without the federal directive structure. The agencies recommend using the YARA rules against disk images or core dumps, reporting findings, and beginning incident response if compromise is confirmed. They also warn organizations not to unplug affected devices unless instructed to do so by CISA or the NCSC.That caution is important because it reflects the risk of taking action too early or in the wrong order. In many environments, an instinctive reboot or immediate isolation may seem sensible, but it can also destroy evidence or leave the persistence mechanism intact. The better approach is disciplined containment, artifact collection, and coordinated remediation.
Enterprise versus government impact
For the federal sector, the issue is compliance-backed and time-sensitive. For enterprises, hospitals, utilities, and service providers, the issue is more operational but just as serious: a compromised firewall can be the hidden bridge between internal trust and external exposure. The most important difference is that private-sector organizations may need to build the response path themselves, whereas FCEB agencies are being routed through a more prescriptive federal process.Still, the lesson is the same. A security device with persistent backdoor characteristics should be treated like a compromised crown-jewel system, not like a disposable edge box. That is a mindset shift many teams still struggle to make until after the breach.
- Use YARA against core dumps and disk images.
- Report confirmed findings to the appropriate national authority.
- Avoid unsupervised power cycling or unplugging.
- Treat the event as a full incident, not a simple malware removal task.
Mitigations and Hardening
CISA and the NCSC recommend broad hardening measures that go beyond the immediate incident. They stress patching, inventorying edge devices, monitoring privileged accounts, applying least privilege, rotating passwords regularly, and modernizing administrative access with TACACS+ over TLS 1.3. That mix is important because FIRESTARTER is only one part of the risk picture; the broader environment that allowed the compromise is equally relevant.One of the report’s sharpest observations is that patching available at the time of ED 25-03 did not specifically remove FIRESTARTER, even though it mitigated the original vulnerabilities. That means remediation cannot stop at “install the update.” A patched device may still be contaminated, and defenders need a separate validation step to prove the backdoor is gone.
Hardening priorities that actually matter
Inventory is the first practical control here. If you do not know where your Cisco edge devices are, whether they are exposed, or who manages them, you will not be able to determine the blast radius quickly enough. From there, credential review, account cleanup, and segmentation become the controls that reduce future compromise risk rather than simply reacting to the current one.The recommendation to modernize administrative access with TACACS+ over TLS 1.3 is especially interesting because it signals a shift toward protecting the management plane itself. That is the right direction. If attackers are exploiting device administration paths, then securing the administrative channel becomes part of the remediation, not a separate best-practice project for later.
Sequential response checklist
- Identify all Cisco Firepower and Secure Firewall devices, especially those exposed to the public internet.
- Collect core dumps and preserve related device output before changing the device state.
- Run the supplied YARA rules against core dumps or disk images.
- Report findings to CISA or the NCSC immediately.
- Follow agency guidance before powering devices down or disconnecting them.
- Keep systems fully patched.
- Inventory all edge devices.
- Review elevated accounts and service accounts.
- Restrict permissions to the minimum necessary.
- Rotate credentials regularly.
- Improve administrative channel encryption.
Strengths and Opportunities
The most encouraging part of the report is that CISA and the NCSC have paired a threat analysis with concrete artifacts, guidance, and hunting logic. That gives defenders something to work with immediately, rather than forcing them to reverse-engineer the problem from scratch. It also shows a mature recognition that persistence on network devices needs a different response model than commodity endpoint malware.- CISA provides YARA rules for practical hunting.
- The report explains the persistence mechanism clearly.
- The federal response is already integrated with ED 25-03.
- Memory analysis guidance is specific and actionable.
- The report helps teams distinguish initial access from persistence.
- The mitigations emphasize both technology and identity hygiene.
- The report is useful for both U.S. and U.K. organizations.
Risks and Concerns
The biggest concern is that many organizations still treat firewall and security appliances as black boxes that are “safe once patched.” FIRESTARTER directly undermines that assumption by surviving remediation in ways ordinary tooling may not catch. The fact that CISA considers power removal potentially necessary is a strong hint that the implant can outlast the standard incident-response script.- Patching may not remove the backdoor.
- Logs may be insufficient to detect compromise.
- Older or inactive accounts can be reused by attackers.
- Network edge devices can be trusted too broadly.
- Powering off is not the same as fully disconnecting power.
- Incident response may require physical access and downtime.
- Organizations without core-dump workflows may miss the implant entirely.
Looking Ahead
The next question is how many organizations can actually verify whether they were touched by the same campaign. Because FIRESTARTER hides in memory and in device-specific persistence paths, the answer will depend on whether defenders can collect the right artifacts before they vanish. That means the real test of this advisory will not just be whether people read it, but whether they can operationalize it quickly.Another important watchpoint is whether follow-on reporting reveals more about the original intrusion chain. If additional samples, indicators, or forensic cases surface, defenders may get a clearer picture of whether FIRESTARTER is a one-off implant or part of a more systematic Cisco edge-device playbook. Either way, the lesson is already visible: once attackers reach the management plane, the cleanup problem becomes much harder than the breach itself.
What to watch next
- Additional forensic reports tied to Cisco Firepower or ASA/FTD compromises.
- More guidance on when physical power removal is required.
- Wider adoption of core-dump collection in enterprise response playbooks.
- Further Cisco or CISA indicators that refine detection.
- Evidence that the same persistence concept appears in other edge-device families.
Source: CISA FIRESTARTER Backdoor | CISA
