One compromised management box was enough. Attackers who broke into a single Fortinet FortiManager appliance at a telecommunications managed service provider walked away with the running configurations, credentials and cryptographic keys for more than 500 FortiGate firewalls, some protecting the provider's own network and others protecting its clients, according to research from Palo Alto Networks' Unit 42 by Daniel Gott and Shawn Westfall.
The intrusion itself took place in September 2024. The report, published on October 14, 2026, details what came next: traffic sniffing, VPN logins with cracked passwords, and a previously undocumented memory-only implant Unit 42 calls PEERSTITCH. The researchers track the activity as CL-STA-0954 (also known as UNC5820) and say parts of the post-exploitation tradecraft overlap with intrusions attributed to suspected nation-state actors.
One appliance held the keys to 500 firewalls
Initial access came through CVE-2024-47575, the FortiManager flaw known as FortiJump, which lets an unauthenticated remote attacker run commands through the FMG-Access management channel on TCP port 541. The attackers registered a rogue virtual FortiGate named "localhost" (serial FMG-VMTM23017412), then exfiltrated an archive holding every managed device's configuration, the management databases, firewall serial numbers with public IP addresses, network topology, ciphertext admin and SSL VPN credentials, and certificates with private keys.
Unit 42 is careful about scope: for the client networks, what was exposed was configuration and credential material, not a confirmed intrusion.
From stolen configs to live VPN sessions
After an extended dwell period, the attackers used the FortiManager to push packet-capture rules to downstream firewalls, aimed at cleartext HTTP, RADIUS, LDAP and TFTP traffic. The credentials in the stolen configurations were stored in reversible form, and Unit 42 confirmed they could be recovered by brute force. The attackers then logged in over SSL VPN with those legitimate accounts.
To get beneath the restricted FortiOS admin interface, they exploited CVE-2025-61624, a path traversal in the FortiOS auto-script engine that lets an authenticated administrator read and write files as root. That is how PEERSTITCH arrived.
An implant that never opens a port
PEERSTITCH is an ARM64 Linux injector written in C. It attaches to two FortiOS daemons, the logging service miglogd and the VPN service iked, plants code in a 16 KB memory region inside each, and deletes its own binary. It opens no listening ports and makes no outbound connections. Instead it watches traffic already flowing through those processes for marker strings, passes tokens between the daemons by writing into each other's memory, and lets iked bypass default FortiOS security validations for tagged VPN sessions.
The attackers also abused the firewall's Apache mod_md certificate module, pointing it at their own ACME server so that forced certificate renewals kept relaunching an SSH reverse shell. They covered their tracks by killing logging daemons, clearing crash logs and deleting rogue accounts soon after use. Unit 42 assesses with medium confidence that the crew also impersonated the FortiManager to pull more firewall configurations.
Patch FortiJump, then assume the configs are gone
Organizations running FortiManager and FortiOS should confirm they are patched against CVE-2024-47575 and CVE-2025-61624 using Fortinet's own advisories. Because the stolen archive held recoverable passwords and private keys, a FortiManager that was ever exposed means the credentials and certificates on every firewall it managed should be treated as compromised too. Unit 42's hunting guidance for PEERSTITCH includes:
- Check the memory maps of miglogd and iked for anonymous 16,384-byte regions with rwxp permissions.
- Review FortiOS configuration revisions for system.auto-script objects whose names contain "../../".
- Query the crash log for segmentation faults involving miglogd, iked or syslogd.
Infrastructure named in the report includes 45[.]32[.]41[.]202, 198[.]199[.]122[.]22, 23[.]240[.]77[.]233 (which served payloads from hxxp://23[.]240[.]77[.]233:8085/) and 47[.]18[.]167[.]159.
Edge devices keep proving a comfortable place to hide, as the return of a Russian implant on Cisco firewalls showed. This case adds a sharper lesson, one worth weighing against every Fortinet patch cycle: a central manager is where a network keeps its trust, and whoever owns it inherits all of it.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.