PEERSTITCH: A Memory-Only FortiGate Implant Built on the 2024 FortiManager Breach

PEERSTITCH: a memory-only FortiGate implant, built on the 2024 FortiManager breach

Palo Alto Networks Unit 42 published research on October 14, 2026 describing PEERSTITCH, a memory-resident implant for FortiGate firewalls. It was found during a September 2024 intrusion at a telecommunications managed service provider that began with CVE-2024-47575, the FortiManager "FortiJump" flaw. Unit 42 tracks the cluster as CL-STA-0954, also known as UNC5820.

Who is exposed

Anyone who manages FortiGates from a central FortiManager, and most of all managed service providers. Fortinet's advisory FG-IR-24-423 lists FortiManager 7.6, 7.4, 7.2, 7.0, 6.4 and 6.2 builds below the fixed releases, and FortiManager Cloud 7.4.1 to 7.4.4, 7.2.1 to 7.2.7 and 7.0.1 to 7.0.12 (6.4 must migrate). It also covers old FortiAnalyzer models (1000E/F, 2000E, 3000E/F/G, 3500E/F/G, 3700F/G, 3900E) that have fmg-status enable set and an interface with the fgfm service enabled. A FortiManager holds the configuration and the trust relationship for every device it manages, so one compromise reaches the whole fleet. Unit 42 put it this way: the cryptographic trust material "remains valid until it is rotated." The victim here was an unnamed telecom MSP, and Unit 42 did not examine its clients' networks, so what is confirmed is theft of configuration and credential material, not intrusion into client networks.

What is new

Fortinet and Mandiant disclosed CVE-2024-47575 in October 2024. Mandiant's October 24, 2024 write-up covered 50+ potentially compromised FortiManager devices and put the earliest exploitation at June 27, 2024. It also logged 45.32.41.202 on September 22, 2024, the same IP Unit 42 gives for the rogue localhost registration, so this intrusion sits inside the 2024 zero-day wave, a month before the October 23 advisory. Mandiant said it found no malware or backdoors on the FortiManager devices it examined. Fortinet's advisory said the same about low-level malware. The Unit 42 report adds the later stages of one intrusion: a privilege escalation on FortiGate, a never-before-described implant, and a command channel built on a legitimate Apache module. Those later stages are new public detail. The report was published two years after the intrusion it describes.

How the intrusion worked

Per Unit 42, the attackers exploited CVE-2024-47575 over the FMG-Access channel (TCP 541) and registered a rogue virtual FortiGate named localhost, serial FMG-VMTM23017412. That serial and the localhost device name also appear in Fortinet's own indicators for the flaw. They then pulled an archive containing running configurations for more than 500 managed FortiGates, the FortiManager SQLite databases, a serial and IP inventory, ciphertext credentials, and certificates with private keys.

After a long dwell period, the attackers pushed packet-capture configurations to downstream firewalls, aimed at cleartext HTTP, Telnet-style control ports, TFTP, RADIUS and LDAP. Unit 42 confirmed that administrative and SSL/VPN credentials in the stolen configurations could be recovered by brute force. It does not say how the attackers obtained them; it reports that they then opened SSL/VPN sessions with "legitimate credentials" from external staging hosts.

Root access through CVE-2025-61624

With admin access, the attackers used CVE-2025-61624 to reach root. Unit 42 describes a path traversal in the FortiOS CLI system.auto-script engine: the script object name is not sanitized, so a name such as ../../../../setup places the script body anywhere on the file system. Fortinet's advisory FG-IR-26-122 (April 14, 2026) rates it Medium, CVSS 6.0 (NVD's own score is 6.5), requires an authenticated admin with read-write permission, and marks it as known exploited. A virtual patch, FG-VD-59270.0day, is available in FMWP database update 25.120.

Affected and fixed versions per Fortinet:

The implant

Two years from the breach to the full picture.

The script fetched five files from attacker infrastructure into /data2/template/, including an ARM64 ELF injector named lldprx. PEERSTITCH is a one-shot ptrace injector written in C. It attaches to /bin/miglogd (logging) and /bin/iked (IKE/IPsec), maps a 16,384-byte anonymous read-write-execute region in each, and writes a 1,344-byte payload through /proc/<pid>/mem. The injector then deletes its own binary.

Inside the daemons, hook code watches data already passing through for two markers, 8550 and 169.254.0.1. When it finds one, it extracts a tag of up to 31 bytes and writes it directly into the other daemon's memory. When iked later handles a VPN session, its hook checks its buffer; if a matching tag is there, it takes an alternate return path that bypasses default security validation. This is how the implant communicates without sockets, listening ports or outbound connections. It also NOP-patches three static offsets in the daemon text and writes a 20-byte trampoline at base+0x135102C. These offsets are tied to specific builds, so treat them as indicators for the build Unit 42 analysed.

Apache mod_md as a reverse shell

Alongside PEERSTITCH, a separate auto-script wrote md-acme.conf (via ../../tmp/apache2/conf/md-acme.conf) for the FortiGate's Apache mod_md module through the same CVE-2025-61624 traversal. The reverse shell is a parallel command channel, not something the implant launches. They pointed the module at a rogue ACME server, mapped MDChallengeDns01 to /bin/node, and set MDRenewMode always. Each renewal challenge then ran Node.js with a command taken from the challenge's domain name field, which launched an SSH reverse shell and re-launched it on every poll. Afterwards they overwrote the config with a decoy string.

Anti-forensics included killing miglogd and syslogd, running diagnose debug crashlog clear, and deleting the rogue admin accounts, VPN groups and auto-script objects.

Management impersonation, and what is not confirmed

An admin account named FortiGateCloud pulled full configurations from managed firewalls over FGFM (TCP 541), though the victim had no FortiManager Cloud tenant. Unit 42 assesses with medium confidence that the attackers impersonated FortiManager. It says the evidence does not distinguish two routes: CVE-2024-26009 (FGFM authentication bypass using the FortiManager serial number; NVD, CVSS 8.1) or reuse of the stolen trust material. It says only that "it is possible" CVE-2024-26008 (FGFM connection reset; CVSS 5.3, Fortinet's score, NVD has none of its own) was used to knock the real FortiManager offline, and that the logs could not confirm it. Treat both as unconfirmed. Exposure: CVE-2024-26009 covers FortiOS 6.0 to 6.4.15, FortiProxy 7.0 to 7.4.2, FortiPAM up to 1.2.0 and FortiSwitchManager 7.0.0 to 7.0.3 and 7.2.0 to 7.2.3, and needs the FortiManager serial number, which this archive contained, so devices on old 6.x trains are exposed to the impersonation path. CVE-2024-26008 covers FortiOS 7.4.0 to 7.4.3 and before 7.2.7.

Unit 42 names CVE-2025-59718 and CVE-2025-59719 (FortiCloud SSO bypass) only to rule them out. It says those need FortiCloud enrollment, the firewalls had none, and only the account name overlapped.

Attribution

Unit 42's wording is limited to: "Aspects of the post-exploitation activity overlap with intrusions attributed to suspected nation-state actors." It does not name a country or group. In 2024 Mandiant said it lacked data to assess UNC5820's motivation or location. For another firewall case with a long undetected dwell, see our Palo Alto CVE-2026-0300 root-access story.

KEV status

Checked against the CISA KEV feed released October 15, 2026: CVE-2024-47575 is listed (added October 23, 2024). CVE-2025-61624, CVE-2024-26008 and CVE-2024-26009 were not listed, even though Fortinet marks CVE-2025-61624 as exploited.

What defenders should do

• Patch FortiManager to 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15 or 6.2.13 or above, and patch FortiManager Cloud to 7.4.5, 7.2.8 or 7.0.13 (6.4 must migrate), and any exposed FortiAnalyzer models above. Where patching lags, Fortinet's workarounds have version limits: fgfm-deny-unknown works only on 7.0.12+, 7.2.5+ and 7.4.3+ (not 7.6.0); local-in policies limiting TCP 541 need 7.2.0+; a custom FGFM CA needs 7.2.2+. FortiManager 6.2, 6.4 and 7.0.11 and below must upgrade first. Check the 2024 log indicators and the /tmp/.tm and /var/tmp/.tm files; Fortinet notes the log lines can also reflect a failed attempt on patched systems.
• Upgrade FortiOS and related products per the table above. FortiOS 7.2, 7.0 and 6.4 and FortiProxy 7.2 and 7.0 have no fix and must be migrated. (We covered another exploited Fortinet product in the FortiMail CVE-2026-104286 story and the earlier FortiVoice zero-day.)
• Assume that a FortiManager compromise exposed every managed device's credentials and certificates. Rotate admin, VPN and local passwords and the FGFM trust material, and restrict management-plane access.
• Hunt using Unit 42's four surfaces: rwxp anonymous 16,384-byte regions in miglogd and iked in /proc/<pid>/maps; the NOP patches at the listed offsets; cross-process /proc/<pid>/mem access; and Signal 11 entries in diagnose debug crashlog read. Because the attackers cleared crash logs and stopped logging, absence of evidence is weak.
• Review FortiOS configs for unexpected auto-script objects and admin accounts, and for ACME or mod_md configuration you did not create. Alert on FortiGateCloud admin sessions on devices with no FortiCloud enrollment.
• The hashes, network indicators and YARA rule are in the Unit 42 report; use those rather than copies.

Sources

• Unit 42: PEERSTITCH and CVE-2024-47575
• Fortinet PSIRT FG-IR-26-122 (CVE-2025-61624)
• Fortinet PSIRT FG-IR-24-423 (CVE-2024-47575)
• Fortinet PSIRT FG-IR-25-647 (CVE-2025-59718/59719)
• NVD CVE-2024-47575
• NVD CVE-2025-61624
• NVD CVE-2024-26008
• NVD CVE-2024-26009
• CISA Known Exploited Vulnerabilities feed
• Mandiant: FortiManager zero-day exploitation (CVE-2024-47575)