Palo Alto Networks Unit 42 published research on October 14 describing PEERSTITCH, a memory-resident implant used against FortiGate firewalls by a cluster it tracks as CL-STA-0954 (overlapping with UNC5820). The intrusion started in September 2024 at a telecommunications managed service provider and chained two Fortinet flaws: the FortiManager “FortiJump” bug (CVE-2024-47575) for initial access and fleet-wide credential theft, and a FortiOS CLI path traversal (CVE-2025-61624) for root on individual firewalls. The write-up is the first public look at what the actor did after FortiJump, and it matters because the end state is a firewall that skips its own VPN security checks for attacker-tagged sessions.

Caveat: the primary Unit 42 report and Fortinet advisory were not reachable from our publishing environment, so details below come from Unit 42’s findings as reported by secondary coverage. Verify version numbers, scores and hashes against the vendor sources before acting.

Attack chain

  1. FortiManager compromise (CVE-2024-47575). The actor exploited FortiJump on a FortiManager managing the provider’s fleet. From there they reportedly pulled configuration files, keys and credentials for more than 500 FortiGate devices (one figure not corroborated across every outlet).
  2. Recovered credentials into VPN. Using stolen credentials, the attackers opened VPN sessions into perimeter firewalls rather than exploiting them from the outside.
  3. Root via CVE-2025-61624. An authenticated administrator can supply traversal sequences in an auto-script object name, writing files outside the intended directory. Fortinet published the advisory in April 2026; it is scored medium (reported as CVSS 5.4), but in this chain it is the step that delivers code execution as root.
  4. Implant deployment. A deployment script launches an executable that locates two FortiOS processes, miglogd (logging) and iked (IKE/IPsec VPN), and injects PEERSTITCH into them.

What PEERSTITCH does

The implant leaves no persistent binary on disk, opens no listening ports and makes no outbound connections of its own. It communicates by riding traffic of legitimate processes. The core trick: a session identifier is handed to iked, which then looks for that tag in later VPN sessions. When the tag is present, iked takes an alternate execution path that bypasses the default FortiOS security validation. In effect, the attacker gets a covert, authenticated-looking channel through the firewall’s own VPN daemon. Injecting into miglogd also positions the implant to interfere with logging, which Unit 42 lists as a detection signal (unexplained logging interruptions).

Impact

Anyone running FortiGate behind a FortiManager that was exposed to FortiJump during 2024 should consider management-plane secrets burned. Because the implant is fileless, it does not survive a reboot, but the stolen credentials, certificates and keys do. Reinfection is straightforward for an actor that still holds them. Fortinet-managed fleets at MSPs and telecoms are the obvious targets, since one FortiManager compromise yields credentials for every downstream customer.

Unit 42 did not disclose the FortiManager/FortiOS versions in the victim environment, the FortiGate models affected, or how many devices were actually implanted.

Detection

Reported hunting guidance from the report:

  • Inspect memory maps of miglogd and iked for anonymous 16 KB regions with read-write-execute permissions.
  • Look for cross-process memory writes and ptrace use on FortiOS daemons.
  • Review auto-scripts for path traversal in object names.
  • Check for rogue FortiGate registrations on FortiManager, unexpected .tm archives and unauthorized sniffer policies.
  • Alert on gaps in logging that do not match restarts.
  • Two SHA-256 hashes were published for the injector and the memory-mapping bootstrap; pull the full values from the Unit 42 IoC list.

Mitigation

  • Patch CVE-2025-61624. Reported fixed releases are FortiOS 7.4.10 and 7.6.5. The 7.2, 7.0 and 6.4 branches are affected; plan a migration to a fixed branch rather than waiting for backports.
  • Rotate everything. Patching does not invalidate stolen trust. Rotate admin credentials, VPN credentials, certificates, pre-shared keys and any secrets held in FortiManager-managed configs.
  • Harden management. Restrict FortiManager and FortiGate management interfaces to dedicated networks, limit FGFM (TCP 541) to known peers, and block unknown device registrations.
  • Confirm FortiJump remediation. Verify FortiManager is on a fixed build and review it for the indicators above.
  • Hunt, then rebuild. Because the implant is memory-only, a clean reboot is not evidence of a clean device; if indicators are present, treat the firewall and its config as compromised.

References