A stolen firewall configuration can outlive the breach that exposed it. In a newly published investigation, Unit 42 traced how attackers stole a telecom provider’s management archive, reused credentials and planted PEERSTITCH inside legitimate FortiGate processes. The archive held information about more than 500 managed firewalls; that is an exposure count, not confirmation that 500 customer networks were breached. [1]
The report was published on October 14, 2026. The intrusion began in September 2024, and the researchers examined the provider’s environment rather than its customers’ networks. Its practical lesson is current: patching a compromised management server does not invalidate the passwords, certificates and private keys already taken from it.
One rogue device opened the management archive
The entry point was FortiManager, the central platform used to manage the provider’s own and customer FortiGate firewalls. Attackers exploited CVE-2024-47575, also known as FortiJump, and registered a rogue virtual appliance named localhost. They then created and stole a configuration archive called .tm.
This was a map of trusted relationships: device serial numbers and public IP addresses, running configurations, management databases, routing information, credentials stored as reversible ciphertext, and cryptographic material. Unit 42 recovered administrative and SSL/VPN passwords from the stolen configurations. The attackers subsequently used legitimate credentials to open unauthorized VPN sessions into network-management segments.
That sequence explains why the older FortiJump vulnerability matters beyond the initial server compromise. Once the attacker holds usable identities, closing the original entry point and revoking those identities become separate jobs.
The implant moved into logging and VPN processes
After gaining administrative access, the attackers exploited a second flaw, CVE-2025-61624, to reach the underlying operating system. The weakness let a privileged user write outside the intended script directory. This crossed an important boundary: the FortiOS administrative interface is restricted, while its underlying services run with root privileges.
The PEERSTITCH injector targeted /bin/miglogd, the logging service, and /bin/iked, the VPN service. Instead of maintaining its own listening port or outbound connection, the injected code watched data already passing through those processes. A recognized marker could be passed directly into the other process’s memory; a matching VPN session then took a branch that bypassed normal security validation.
The distinction is subtle but useful for detection. 8550 and 169.254.0.1 were matching markers in inspected data, not instructions to hunt for a PEERSTITCH listener on port 8550. Ordinary-looking service traffic and familiar process names did not mean the code handling them was intact.
“Memory-resident” also does not mean the whole intrusion left no files. The delivery chain staged components on disk. Separately, the attackers abused Apache certificate-management functionality to create an outbound reverse-shell channel. The implant’s lack of new connections must not be generalized to every part of the attack.
An account the provider had never created
Another revealing clue was configuration downloads attributed to FortiGateCloud. The provider had no FortiManager Cloud tenant and had not provisioned that account on the affected devices. Unit 42 assessed management-platform impersonation with medium confidence. The evidence could not distinguish reuse of stolen trust material from a separate authentication-bypass path.
Defenders therefore need to compare apparent management identities with the deployment they actually operate. A plausible account label is less reassuring when there should be no corresponding service. In a different recent case, a modified Linux sudo command copied passwords while still doing its normal job; both investigations show why expected functionality alone cannot establish integrity.
Patch the software and replace the stolen trust
Fortinet’s current advisory lists FortiOS 7.6.5 and 7.4.10 as fixed releases for CVE-2025-61624. It directs affected 7.2, 7.0 and 6.4 branches to migrate to a fixed release. Administrators should use the vendor’s supported upgrade path for their model and release, and check FortiManager separately against the FortiJump advisory. [2]
For a suspected compromise, coordinate evidence collection before a reboot destroys volatile memory. Unit 42’s hunting leads include unexpected executable memory in the two daemons, cross-process memory writes, crash records, and script objects containing directory-traversal strings. These are specialist investigation leads, not a guaranteed clean bill when absent.
Fortinet’s FortiJump recovery guidance calls for reviewing managed-device activity and urgently changing credentials that may have been exfiltrated. Rebuild or recover the manager through the vendor’s documented process, review configuration integrity, and rotate exposed passwords, keys and certificates across the affected trust relationships. [3]
The important boundary is between a repaired appliance and a repaired identity system. PEERSTITCH made the first harder to inspect; the stolen management archive meant the second could remain compromised after the original flaw was patched.
References
- Daniel Gott and Shawn Westfall. “Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant.” Palo Alto Networks Unit 42, October 14, 2026. Investigation and hunting guidance.
- Fortinet PSIRT. “FG-IR-26-122,” CVE-2025-61624. Published April 14, 2026; accessed October 17, 2026. Affected versions and fixes.
- Fortinet PSIRT. “FG-IR-24-423,” CVE-2024-47575. Accessed October 17, 2026. FortiJump advisory and recovery.
