PeerStitch implant hid in FortiGate after FortiJump breach
Unit 42 details PeerStitch, a memory-resident FortiOS implant deployed in a telecom intrusion via CVE-2024-47575 and CVE-2025-61624. One FortiManager exposed 500+ managed firewalls.
Palo Alto Networks' Unit 42 has published an analysis of PeerStitch, a stealthy FortiOS implant it found inside a telecommunications provider's network after an intrusion that began in September 2024. The attacker reached a central FortiManager, pulled a configuration archive covering more than 500 managed FortiGate firewalls, and then planted an implant designed to leave almost no trace. The primary source is the Unit 42 report, published October 14.
What the bugs are
- CVE-2024-47575 — the missing-authentication RCE in FortiManager that Mandiant tracked as FortiJump, patched in October 2024. It gave initial access to the central FortiManager, from which the attacker registered a rogue virtual FortiGate and exfiltrated running configs, cryptographic material, and database files for the managed fleet.
- CVE-2025-61624 — a path-traversal flaw in FortiOS, FortiPAM, FortiProxy, and FortiSwitchManager, patched April 2026, used to deploy the implant. CISA has added it to the Known Exploited Vulnerabilities catalog.
What PeerStitch does
PeerStitch is ARM64 malware written in C and resident entirely in memory — Unit 42 describes it as a "one-shot process memory patching injector." It targets the central-management, traffic-logging, and IKE/IPsec VPN daemons in FortiOS, opening a covert bridge between them. It writes no persistent binary to disk, opens no listening ports, and makes no outbound connections of its own; instead it rides traffic from legitimate processes, impersonating FortiManager in FortiGate-to-FortiManager (FGFM) communication to issue commands. The operators also cleaned up behind themselves — stopping syslog generation, clearing crash logs, and deleting rogue administrator accounts and auto-script objects.
Attribution
Unit 42 attributes the activity to a cluster it tracks as CL-STA-0954, which it says overlaps with UNC5820 — the group Mandiant previously tied to FortiJump exploitation — and describes as a suspected state-sponsored actor. Treat that as attribution-by-overlap, not a confirmed identity. Unit 42 also notes it did not examine the provider's customer networks, so the 500+ figure is the count of firewalls whose configs were exposed, not proof that each was compromised.
Action checklist
- Patch both CVEs if you have not: FortiManager against CVE-2024-47575, and FortiOS/FortiPAM/FortiProxy/FortiSwitchManager against CVE-2025-61624.
- Assume config exposure on any FortiManager that was unpatched for FortiJump: rotate device credentials, pre-shared keys, and certificates pulled from managed FortiGates.
- Hunt in volatile memory, not just on disk — PeerStitch leaves no file artifact. Unit 42 recommends live-memory investigation.
- Audit FGFM trust and admin/auto-script objects for rogue virtual FortiGates and accounts, and check for gaps in syslog and crash-log continuity.
Context
Fortinet management-plane bugs keep turning into fleet-wide exposure: FortiJump let one compromised FortiManager leak an entire managed estate in 2024, and this year's FortiBleed credential dump and the FortiSandbox KEV additions showed the same pattern — the device that administers everything is the one worth the most to an attacker. A memory-only implant that speaks the management protocol is the logical next step.