Palo Alto Networks Unit 42 has documented a previously unreported memory-resident implant called PEERSTITCH running on Fortinet edge appliances, deployed by an activity cluster tracked as CL-STA-0954 (also known as UNC5820). Researchers Daniel Gott and Shawn Westfall found it during a prolonged intrusion against a telecommunications managed service provider that began in September 2024.
The implant is a 64-bit Linux ARM64 executable written in C, and it is built to be hard to find. It writes no persistent binary to disk, opens no listening ports, and starts no outbound connections of its own.
"Instead, it communicates through traffic generated by legitimate processes on the infected host, which makes the malware resistant to conventional endpoint and network detection," Unit 42 researchers said.
Edge appliances are a useful place to hide for exactly that reason. Your firewall and your management appliance sit outside EDR coverage, terminate your SSL/VPN sessions, and hold the credentials and cryptographic material that describe your internal network.
What PEERSTITCH achieves on those devices is specific. It patches the memory of two running FortiOS daemons, /bin/miglogd and /bin/iked, so that VPN sessions carrying a particular tag take an alternative execution path that skips default FortiOS security validations. In practical terms, an attacker-controlled session gets handled as a legitimate one.
Four CVEs appear in this chain. Initial access came through CVE-2024-47575, the critical FortiManager flaw known as FortiJump, which has been publicly known and exploited since late 2024. PEERSTITCH delivery relies on CVE-2025-61624 (CVSS 5.4), a path traversal issue in the command line interpreter of FortiOS, FortiPAM, FortiProxy, and FortiSwitchManager that Fortinet patched in April 2026. Unit 42 also raised CVE-2024-26008 and CVE-2024-26009 as possible, though unconfirmed, contributors, noting that exploiting them requires FortiGate Cloud or FortiCloud SSO enrollment that none of the affected firewalls had.
How the FortiOS Flaws Are Chained to Bypass VPN Session Checks
The intrusion starts on the management plane, not the firewall. The actors exploited CVE-2024-47575, the FortiManager flaw known as FortiJump, to compromise the appliance that centrally administers the victim's Fortinet estate (MITRE ATT&CK T1190, exploitation of a public-facing application).
From that single box they pulled an archive containing the FortiManager serial number and its management relationships to every enrolled device, running configuration files for more than 500 managed FortiGate firewalls spanning internal and client networks, central management SQLite databases, an inventory of more than 500 FortiGate serial numbers paired with their public IP addresses, internal topology maps, routing tables and interface configurations, plus ciphertext administrative, local and SSL/VPN credentials and encoded cryptographic trust material including public certificates and private keys. For a managed service provider, one compromised management appliance hands over the operating blueprint for every downstream customer network it touches.
That inventory drove the next phase. The actors used it for reconnaissance, established unauthorized FortiGate SSL/VPN sessions against perimeter firewalls, deployed backdoors, intercepted traffic, and impersonated the FortiManager platform itself to pull configurations from managed firewalls belonging to other hosts in the target network. Unit 42 notes this required working knowledge of FortiOS internals and FortiOS management protocols, and suspects (without confirming) that CVE-2024-26009 and CVE-2024-26008 may have been involved, though exploitation of those requires FortiGate Cloud/FortiCloud SSO enrollment that none of the affected firewalls had.
On the firewall, the actors chained CVE-2025-61624 (CVSS 5.4), a path traversal flaw in the command line interpreter shared by FortiOS, FortiPAM, FortiProxy and FortiSwitchManager. A privileged attacker passes crafted arguments to existing CLI commands and gains arbitrary file write or delete. Fortinet patched it in April 2026.
The staging auto-script pulls five components from 23.240.77[.]233:8085:
pM.js, a self-deleting environment preparation scripta.js, saved asindex.js, an Emscripten JavaScript runtime modulea.wasm, saved asindex.wasm, a compiled WebAssembly binary moduleb.js, saved asipssem.js, the deployment orchestratordd, saved aslldprx, the native ARM64 ELF injector
After an execution delay, ipssem.js launches lldprx. The injector locates the running processes for two core FortiOS daemons, /bin/miglogd (the logging daemon) and /bin/iked (the IKE/IPsec and VPN session daemon), enumerates their memory layout, attaches with ptrace, halts them using PTRACE_INTERRUPT, allocates executable memory, writes code into it and redirects execution through the injected code. That maps to T1055.008, ptrace-based process injection.
The hooks build a communication bridge between the two daemons inside process memory. The miglogd hook watches passing data for two markers: TCP port 8550 embedded within traffic data (there is no listening socket on that port) and the link-local IP 169.254.0.1 used for pattern matching. On a match, it passes the associated session token to the iked hook, which checks subsequent VPN sessions for that identifier. A tagged session takes an alternative execution path that bypasses default FortiOS security validations, so an attacker VPN session authenticates on terms the appliance would normally reject.
A second channel runs separately from the implant: the actors abused the native Apache mod_md module present on FortiGate firewalls to spawn an SSH-based reverse shell for command and control. Cleanup ran alongside, with syslog generation terminated, crash logs cleared, logging telemetry disrupted, and rogue administrator accounts and auto-script objects deleted automatically after execution (T1070, indicator removal). The implant is described as a one-shot injector leaving no disk artifacts, so the hooks live only in the memory of those two daemons.
What a Compromised Edge Appliance Means for the Organization
The hooked iked daemon gives an adversary an authenticated SSL/VPN session without ever presenting valid credentials. When a session carries the right tag, FortiOS takes an alternative execution path and skips its default security validations, so the connection looks like an ordinary remote user to everything downstream. Your conditional access policies, your VPN group mappings, and your MFA enforcement all sit behind a check that never runs for that session.
That changes what your logs are worth. Session records on the firewall describe a connection that was never validated, and the attackers in this intrusion also terminated syslog generation, cleared crash logs, and disrupted logging telemetry. If you later need to reconstruct who was on the network during a given week, the primary evidence source is both incomplete and actively manipulated by the party you are investigating.
Account-level evidence has the same problem. CL-STA-0954 configured rogue administrator accounts and auto-script objects to delete themselves automatically after execution, so a review of current admin users on the appliance returns a clean result while the activity has already happened. A clean account list is not evidence of a clean appliance.
If you run a managed service practice, the affected devices are not only yours. Client-facing firewalls administered from the same management plane fall inside the same incident, which means breach notification decisions, contractual security obligations, and client-side forensic work all land on you at once. The attackers in this case also used the native Apache mod_md module on FortiGate firewalls to spawn an SSH reverse shell, giving them a second command channel that is independent of the implant itself.
Regulated firms face a specific attestation problem. If you are required to demonstrate that remote network access is controlled, authenticated, and logged, a VPN daemon with a modified session-handling path breaks all three claims for the period of compromise. You cannot sign an access-control attestation for a window in which the validation code was patched in memory, and you may not be able to fix the boundaries of that window with any precision.
Then there is the practical forensics question. These are appliances with constrained logging, limited writable storage, and no supported path to pull a live memory image in place. The implant exists only in the address space of running processes, so a reboot removes the evidence and a running device keeps the attacker. Your investigator is choosing between preserving a compromised production firewall and losing the only artifact that proves what happened.
In practice, most organizations in this position cannot prove an appliance is clean and end up rebuilding it from known-good firmware with regenerated certificates and credentials. For a fleet of several hundred managed firewalls across internal and client networks, that is a staged replacement program with change windows, client coordination, and re-enrollment work, carried out while you are still unsure which devices were touched. Budget and schedule the rebuild as the likely outcome, because verification at this level is rarely achievable.
Patching, Hunting and Rebuild Actions for Fortinet Estates
Start with an inventory of every Fortinet appliance you own, including the ones a client or an acquired site manages, and confirm firmware against the fixed releases named in Fortinet's advisories for CVE-2025-61624, CVE-2024-47575, CVE-2024-26009 and CVE-2024-26008. Fortinet patched the path traversal in the FortiOS command line interpreter in April 2026, and the same flaw affects FortiPAM, FortiProxy and FortiSwitchManager, so a firewall-only patch sweep leaves gaps. Pull the fixed build string from the vendor advisory for your specific appliance generation rather than assuming a single version covers the estate.
While that inventory is running, take administrative and management interfaces off the public internet. CVE-2024-26008 and CVE-2024-26009 require the device to be enrolled in FortiGate Cloud or FortiCloud SSO, and Unit 42 confirmed none of the affected firewalls in this intrusion held that enrollment, so check your own enrollment state before deciding those two apply to you.
Hunting for the implant and its delivery chain
Search each appliance filesystem for the staged components: index.js, index.wasm, ipssem.js and lldprx, plus the self-deleting preparation script pM.js. Then check egress records for connections to 23.240.77[.]233:8085, the host the auto-script pulled all five components from.
Port scanning will not find this implant. The TCP port marker 8550 and the link-local address 169.254.0.1 appear inside traffic data as pattern-matching markers, so look for them in full packet capture rather than in a listening socket list. On the appliance itself, inspect the running /bin/miglogd and /bin/iked processes for unexpected executable memory regions and for evidence of ptrace attachment, since the injector halts both daemons with PTRACE_INTERRUPT before writing code into allocated memory.
Separately, audit the Apache mod_md module on FortiGate devices. The attackers used the native module to spawn an SSH-based reverse shell as a second command-and-control path independent of PEERSTITCH, so clearing the implant alone does not close that channel.
Reconciling sessions, credentials and configuration
Compare SSL/VPN session records against authentication events and treat any session without a matching authentication as a hunt lead. In environments Capstone manages, Adlumin correlates authentication telemetry across identity sources, which surfaces VPN sessions that never produced a corresponding login event. Rotate every administrative, local and SSL/VPN credential that transited the appliance, and reissue the certificates and private keys held in its trust store, because ciphertext credential material and encoded cryptographic trust material were both taken in this case.
Diff running configurations against a known-good baseline held off the device. Rogue administrator accounts and auto-script objects were deleted automatically after execution here, so an account that no longer exists may still have left a configuration change behind.
Rebuild and structural changes
Treat any appliance you suspect was touched as a rebuild from verified vendor firmware, with configuration restored from a validated baseline rather than from the device's own stored config. In-place cleanup is unreliable against an injector that leaves nothing on disk once it has patched process memory.
Two structural changes reduce repeat exposure. Put the management plane on a segmented network reachable only from administrative jump hosts, which limits the FortiManager impersonation technique used to pull configurations from downstream firewalls. Then forward appliance logs to an external collector in near real time, so telemetry survives on a system the attacker does not control.
Priorities for Fortinet Operators
The hardest part of this one to act on is that a patched appliance and a clean appliance are two different states. The April 2026 fix for the FortiOS path traversal closes the route the operators used to place the implant. It does nothing about an implant already resident in process memory on a device they reached before you patched.
So treat version checking and threat hunting as separate tasks with separate outcomes. Your patch report tells you which appliances can be re-entered the same way. It does not tell you whether a device is currently running hooked daemons, and you will not get that answer from a firmware query or a configuration diff. If your only evidence of health is a version string, you have confirmed one thing and assumed the other.
Scope matters as much as sequence here. The intrusion Unit 42 documented ran against a managed service provider, which means the boundary of the problem was never one organization's own perimeter. If you administer Fortinet appliances on behalf of clients, or you inherited a fleet through an acquisition, those devices belong in the same count as the ones in your own racks.
The single action worth doing first is a complete inventory of every Fortinet appliance you touch, with firmware and integrity verified on each one. Start with FortiManager and any FortiGate reachable from the internet, because those are the devices this activity cluster went after and the ones that carry trust relationships into everything downstream. Everything else you decide to do depends on knowing what you actually have and what state it is in.
