A stolen FortiManager archive helped attackers reach managed FortiGates; a memory-only implant linked logging and VPN processes. Check revisions and rotate trust material.2026-10-17T22:38:31.720Z5 min2026networkthreats
5 min read
Read format

Attackers Hid PEERSTITCH in Fortinet Firewalls After Manager Breach

A stolen FortiManager archive helped attackers reach managed FortiGates; a memory-only implant linked logging and VPN processes. Check revisions and rotate trust material.

By Justin Howe
An enterprise firewall in a telecom rack, its two internal processor modules joined by a thin copper-colored bridge.

A FortiManager break-in gave attackers running configurations and cryptographic material for more than 500 managed FortiGate firewalls. In a telecommunications provider intrusion investigated by Palo Alto Networks Unit 42, the attackers later installed PEERSTITCH on selected firewalls: a memory-resident implant that moved data between the logging and VPN daemons. The firewalls served both the provider and its clients. Unit 42 published the investigation on October 14, bringing the older intrusion back into focus for teams that manage other organizations’ edge devices.

The first breach used Fortinet’s CVE-2024-47575 FortiManager flaw. The attacker registered a rogue virtual FortiGate named localhost, serial FMG-VMTM23017412, then extracted a .tm archive. Unit 42 found more than 500 firewall configurations, device serial numbers and public IP addresses, reversible encrypted passwords, certificates and private keys inside. It examined the provider’s environment, so client operators should scope exposed configuration and trust material with the provider before assessing their own networks.

A stolen manager reached firewalls

FortiManager normally speaks to its managed firewalls over FGFM on TCP 541. Once the attackers held the archive, Unit 42 observed unauthorized SSL/VPN sessions using recovered credentials, followed by packet-capture settings pushed to downstream firewalls. The capture targeted cleartext HTTP and later TFTP 69/UDP, RADIUS 1812/UDP and 1813/UDP, and LDAP 389/TCP. The attackers could now inspect cleartext traffic through managed perimeter devices.

In another phase, FGFM traffic from external infrastructure preceded an unprovisioned FortiGateCloud account downloading running configurations from multiple managed devices. Unit 42 assesses with medium confidence that the attackers impersonated FortiManager, either by reusing stolen trust material or by exploiting CVE-2024-26009. Unit 42 could not distinguish between those two paths in this intrusion. The affected firewalls had no FortiCloud SSO enrollment, which rules out the separate FortiCloud SSO issues discussed in the research.

PEERSTITCH hid inside two daemons

With FortiOS administrator access, the attackers exploited the authenticated CLI path traversal CVE-2025-61624 to write outside the intended auto-script directory. Unit 42 traced a system.auto-script traversal object named ../../../../setup to a loader and the ARM64 PEERSTITCH injector. Fortinet marks the flaw as known exploited; its CNA record also lists FortiProxy, FortiPAM and FortiSwitchManager as affected products. The PEERSTITCH deployment Unit 42 observed was on FortiGate firewalls.

The injector attached to /bin/miglogd, the logging daemon, and /bin/iked, the VPN negotiation daemon. It placed hooks in anonymous executable memory and wrote session tags directly between those processes through /proc/<pid>/mem. The hooks looked for the 8550 traffic marker and 169.254.0.1 link-local marker; a matching tag in the VPN process changed a return path and bypassed normal security validation. Unit 42 puts the hiding trick plainly: “PEERSTITCH leaves no persistent binary on disk, opens no listening ports and initiates no outbound network connections.” The visible traffic came from legitimate appliance processes.

Attackers also abused Apache mod_md certificate renewal for a separate outbound reverse-shell channel. They stopped miglogd and syslogd, cleared crash logs with diagnose debug crashlog clear, removed rogue accounts and auto-scripts, and replaced the suspicious md-acme.conf content. Unit 42 assesses with medium confidence that intermittent management-tunnel drops were deliberate telemetry disruption. A quiet current configuration deserves a look at older revisions and collected logs.

Hunt revisions and process memory

Start with the central FortiManager: compare its installed version against the Fortinet CNA fixes for CVE-2024-47575: 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15 and 6.2.13, depending on branch. Limit access to FGFM 541/TCP from approved management endpoints. Look for the rogue serial FMG-VMTM23017412, archive .tm, and registration from 45.32.41[.]202 or 198.199.122[.]22; correlate downstream SSL/VPN logins from 23.240.77[.]233 and 47.18.167[.]159 with provider change records. Search other management registrations and VPN sessions from the same periods; these addresses identify the activity Unit 42 observed in this intrusion.

On managed FortiGates, compare configuration revisions for system.auto-script objects with ../../ in the name, especially ../../../../setup and ../../tmp/apache2/conf/md-acme.conf. Review diagnose debug crashlog read for Signal 11 involving miglogd, iked or syslogd and for a cleared crash-log interval. Where incident-response access permits memory inspection, Unit 42 recommends checking /proc/<pid>/maps for anonymous 16,384-byte rwxp mappings in miglogd and iked; cross-process writes to /proc/<pid>/mem are another signal. The PEERSTITCH injector hash is b9fb0b27ddd59b58d3ae53c7227298a3e0de1e6f868b9429ae21533bb9cd1e70. Its staging filenames include lldprx, pM.js, index.js, index.wasm and ipssem.js. Unit 42 also gives hashes for the PEERSTITCH components:

  • Bootstrap header: 829b1cd270b30565739a478441833f49f10a49bd06f0d18cc96c8ae4a0431f11
  • Core hook block: bd064244dad748cf2a44074bee56f5bfab4a2b18ee944b75d1b3febd4c1fe02a
  • Preparation script: 9c4c4436ff5cdf0d6d68f5108031cbf3708a095cde4ef8c09316af7a7110437e
  • Deployment orchestrator: fc1b10c58057ef9f1f9a1e2a3d4a1c89f43b0ead451398c70ed7a6e0312b36ee
  • JavaScript runtime: f84eea718526706afdf2d1a2774fab76ecb11c18fb61995a37be8249c5e379ab
  • WebAssembly module: b7ae166fd49a7ecfe6322a80b8aa56d6aa0825d8f5d106dab2e4fb7d14ce15a8
  • Runtime shared-secret artifact: 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92

Retain volatile memory before restarting a suspect firewall.

Patch access and replace secrets

Fortinet’s advisory fixes the CLI traversal for FortiOS 7.6 at 7.6.5 and for 7.4 at 7.4.10; its 7.2, 7.0 and 6.4 branches require migration to a fixed release. The advisory also covers FortiProxy, FortiPAM and FortiSwitchManager; inventory those products separately using its product-specific matrix. Fortinet lists a virtual patch, FG-VD-59270.0day, in FMWP database update 25.120. A firewall with matching intrusion artifacts needs incident response even after its FortiOS release is fixed.

If a FortiManager archive was stolen, rotate the administrative and SSL/VPN credentials and replace the certificate and private-key material it held for managed devices; reestablish FGFM trust with those firewalls. Tell client owners which device configurations were in the archive so they can change exposed secrets on their side. Check the next managed-device registrations, configuration pulls and VPN sessions against the authorized inventory, and verify the new trust material is what each managed firewall uses. A patched manager can still carry yesterday’s stolen credentials into tomorrow’s session.

Primary sources

Continue reading

Article figurePinch or double-tap to zoom, then drag to pan.