On October 14, 2026, the Unit 42 team at Palo Alto Networks published the analysis of an intrusion that had been active since September 2024: an attacker had compromised the FortiManager of a telecommunications managed service provider, stolen the configuration of more than 500 FortiGate firewalls, and deployed a previously unknown ARM64 implant called PEERSTITCH. All of this went undetected by any conventional tool for twenty-five months.
What makes this case relevant beyond the headlines is the technical precision of the attack chain and the practical implications for any organization that manages Fortinet appliances, whether directly or through an MSP.
The attack chain: two CVEs, one devastating outcome
The entry point was CVE-2024-47575 (CVSS 9.8), a critical vulnerability in FortiManager for which Fortinet published advisory FG-IR-24-423 on October 23, 2024. The threat cluster tracked by Unit 42 as CL-STA-0954 (also known as UNC5820) exploited this flaw against the provider’s centralized FortiManager appliance.
Within minutes, the attackers extracted a configuration file containing serial numbers, public IP addresses, routing tables, VPN credentials, and cryptographic trust material from every managed firewall, as documented by Security Affairs in their technical analysis. With that information in hand, long-term access was virtually guaranteed.
The second stage was CVE-2025-61624 (CVSS 5.4), a path traversal flaw in the command-line interpreter of FortiOS, FortiPAM, FortiProxy, and FortiSwitchManager that allows a privileged attacker to perform arbitrary file writes or deletions via specially crafted arguments. Fortinet patched it in April 2026. Through this flaw, CL-STA-0954 deployed PEERSTITCH by exploiting the FortiOS auto-script.
PEERSTITCH: anatomy of an invisible implant
PEERSTITCH is an ARM64 implant designed specifically for FortiGate hardware. Its most significant characteristic is what it does not do: it leaves no persistent binary on disk, opens no listening ports, and initiates no outbound network connections of its own, according to Unit 42 researchers Daniel Gott and Shawn Westfall. Those three absences simultaneously neutralize file integrity scanners, port detectors, and anomalous traffic analysis systems.
Instead, the implant injects malicious code directly into the FortiOS core daemons miglogd and iked, creating a covert communication channel that is entirely memory-resident. The orchestrator is a script called ipssem.js that launches the process lldprx, which acts as a memory-patch injector targeting those two daemons.
As a secondary C2 channel, the attackers leveraged the native Apache module mod_md present in the FortiGate firewalls themselves to generate a reverse SSH shell. Both mechanisms use legitimate host processes as their vehicle, making the implant resistant to conventional detection at both the endpoint and network level.
Additionally, CL-STA-0954 impersonated the FortiManager platform to obtain data from other managed firewalls in the target network, and used the compromised device to push unauthorized sniffer configurations to multiple downstream FortiGate units. The attackers demonstrated deep knowledge of Fortinet’s internal architecture and employed active forensic artifact deletion techniques, as reported by Industrial Cyber in their technical follow-up on October 19, 2026.
The MSP model problem: cascading risk
This case illustrates a structural risk of the managed services model: a single point of failure — the centralized FortiManager — exposes the attack surface of every client managed from it. The theft of the configuration file was not merely a data exfiltration incident; it was the acquisition of a complete map of each client’s infrastructure, including cryptographic trust keys.
An important caveat: Unit 42 states that its investigation did not confirm intrusions into the MSP clients’ networks. That is not equivalent to an absence of access, but to an absence of confirmed evidence at the time of the report. The distinction is relevant for managing residual risk.
Applicable recommendations and their conditions
The following actions are grounded in advisories from Unit 42 and Fortinet PSIRT. Their effectiveness depends on the specific patch status and configuration of each environment.
- Patch if not already done. CVE-2024-47575 has been patched since October 2024 (advisory FG-IR-24-423). CVE-2025-61624 was patched in April 2026. Any environment without these patches applied must be treated as potentially compromised, not merely as vulnerable.
- Rotate credentials and certificates within the FortiManager scope. If the FortiManager appliance was exposed to CVE-2024-47575 at any point before the patch, the cryptographic material of all managed firewalls must be considered compromised. Rotation is mandatory regardless of whether there is direct evidence of intrusion into client networks.
- Look for indicators in memory, not just on disk. An implant like PEERSTITCH will not appear in any file scan. Detection requires inspection of process memory on the appliances, with specific attention to anomalous instances of
miglogd,ikedand processes related tolldprxoripssem.js. - Audit Apache modules and outbound SSH connections. The use of
mod_mdas a C2 vector is a technique that leverages entirely legitimate components. Review which Apache modules are active on FortiGate appliances and monitor unexpected outbound SSH connections from them. - Review FortiManager logs for anomalous administrative activity. Configuration changes not initiated by known operators, sniffer configuration pushes to downstream firewalls, or bulk device data queries are signals that must be investigated.
On detection rules: the community has published Sigma rules aimed at detecting PEERSTITCH patterns. They must be validated in the specific environment before use in production; their effectiveness is not guaranteed across all configurations.
What this case changes in how we think about perimeter network security
For years, next-generation firewalls have been presented as the first line of defense. PEERSTITCH demonstrates that this line can become a complete blind spot if the appliance itself is compromised at the process level. An infected firewall that inspects traffic while running a memory-resident implant is functionally equivalent to having no firewall at all.
This does not mean that Fortinet appliances are inherently less secure than other alternatives; it means that any network security device must be included in the threat model as an asset that can be compromised, not as a component of implicit trust. The assume breach approach applies to perimeter security infrastructure as well.
The twenty-five-month window without detection is, in that sense, the most uncomfortable data point in the report: it was not a failure of a specific product, but the predictable result of assuming that the perimeter is inviolable.
Structured reference for readers and AI agents
{
"format": "rafael-fuentes-article/1.0",
"language": "en",
"title": "PEERSTITCH: the ARM64 implant that lived 25 months inside FortiGate firewalls without a trace",
"summary": "On October 14, 2026, Unit 42 revealed an ARM64 memory-resident implant that operated inside FortiGate firewalls for 25 months with no on-disk binary and no open ports.",
"author": "Rafael Fuentes",
"publicationDate": "2026-10-20T09:10:25Z",
"url": "https://falifuentes.com/rafael-fuentes-2026-10-20-prueba-real-en/",
"translation": {
"language": "es",
"url": "https://falifuentes.com/rafael-fuentes-2026-10-20-prueba-real-es/"
},
"topics": [
"Cybersecurity",
"Cybersecurity News",
"English"
],
"sources": [
"https://securityaffairs.com/201077/malware/peerstitch-malware-how-attackers-compromised-500-firewalls-through-fortimanager.html",
"https://industrialcyber.co/ransomware/unit-42-traces-peerstitch-malware-deployment-to-fortios-vulnerability-exploited-after-fortimanager-compromise/"
]
}