PEERSTITCH: How a FortiGate Compromise Reached 500+ Firewalls

A compromise of a centralized network-management appliance can have consequences far beyond the system initially breached. In a case investigated by Palo Alto Networks Unit 42, attackers used a FortiManager compromise to obtain configurations, credentials and cryptographic trust material associated with more than 500 managed FortiGate firewalls. The affected organization was a telecommunications managed service provider, meaning the stolen information also related to firewalls protecting client environments.

The investigation, which Unit 42 tracks as cluster CL-STA-0954, also uncovered PEERSTITCH, a previously described memory-resident ARM64 implant. Its design avoided conventional persistence and network indicators: it did not leave a persistent binary on disk, open a listening port or initiate its own outbound connection. Instead, it modified the memory of legitimate FortiOS processes and used traffic and inter-process memory access already available to those processes.

Unit 42’s report is significant for two reasons. First, it shows how a management plane can provide an attacker with a detailed map of an entire fleet. Second, it demonstrates why appliance investigations cannot rely only on disk collection, perimeter traffic monitoring or ordinary endpoint tooling.

From FortiManager access to fleet-wide exposure

According to Unit 42, the intrusion began in September 2024 with exploitation of CVE-2024-47575 against a centralized FortiManager appliance. The vulnerability permitted an unauthenticated remote attacker to execute commands through crafted requests sent to the FMG-Access management channel on TCP port 541.

During exploitation, the attackers registered a rogue virtual FortiGate device named localhost with the FortiManager. Unit 42 observed the registration arriving from 45.32.41[.]202, later changed to 198.199.122[.]22. The attackers then created and exfiltrated a configuration archive from the FortiManager filesystem.

The archive contained the appliance’s serial number and management relationships, running configurations for more than 500 FortiGate devices, central management databases, serial numbers and public IP addresses, routing and interface information, credentials, certificates and private keys. Unit 42 characterized this as exposure of configuration and credential material. Its investigators did not examine the client networks protected by those firewalls and did not report confirmed intrusion into those client networks.

This distinction matters. A stolen configuration can provide the means to reach or impersonate managed infrastructure, but it is not itself proof that every downstream environment was entered. Nevertheless, the material represented a high-value operational and cryptographic inventory.

Reconnaissance through trusted management relationships

After an extended dwell period, the attackers used the compromised management platform to push unauthorized packet-capture configurations to multiple downstream FortiGate devices. Unit 42 reported targeting unencrypted HTTP traffic and a set of TCP services associated with administration, licensing, control panels, paging, discovery and internal application telemetry.

The attackers later added capture rules targeting TFTP over UDP port 69, RADIUS authentication and accounting over UDP ports 1812 and 1813, and LDAP over TCP port 389. Unit 42 assessed that this activity could support credential interception, service discovery and network-perimeter mapping. The reported behavior demonstrates the danger of treating centralized administration as an implicitly trusted path: a single management-plane compromise enabled surveillance actions across multiple appliances.

Unit 42 also reported that credentials stored as reversible ciphertext in exfiltrated FortiGate configurations could be recovered by brute-forcing administrative and SSL/VPN passwords. Using legitimate credentials, the attackers established unauthorized SSL/VPN sessions to perimeter firewalls from 23.240.77[.]233 and 47.18.167[.]159. Those sessions provided authenticated access to internal network-management segments.

A second vulnerability enabled root-level access

Unit 42 observed exploitation of CVE-2025-61624 after the attackers obtained FortiOS administrative access. The vulnerability affected the FortiOS system.auto-script mechanism. By using traversal sequences in an auto-script object name, an authenticated administrator could write files outside the intended directory and execute the script with the privileges of the auto-script engine.

This was an important transition in the attack chain. A FortiOS administrator normally operates within a restricted management command-line environment and does not directly control the underlying filesystem or root-owned processes. The reported path-traversal behavior allowed the attackers to move from that administrative context to root-level execution on the appliance.

Unit 42 identified a traversal object named ../../../../setup used to launch the initial PEERSTITCH delivery process. The same vulnerability was also used to create a path associated with Apache’s ACME configuration, ../../tmp/apache2/conf/md-acme.conf.

How PEERSTITCH operates in memory

PEERSTITCH is a statically linked 64-bit Linux ARM64 executable written in C. Its role is not to remain as a conventional daemon. Instead, it performs a one-shot injection into two FortiOS processes: /bin/miglogd, the system and traffic logging daemon, and /bin/iked, the IKE/IPsec VPN service.

The delivery chain observed by Unit 42 involved an auto-script downloading five components into /data2/template/. The files included a preparation script, JavaScript and WebAssembly runtime components, an orchestration script and the native ARM64 injector named lldprx. The scripts launched the injector after a delay. Unit 42 reported that the injector subsequently removed its own binary from disk.

The injector searched /proc/ for the target daemons, read their memory maps, attached with ptrace, captured ARM64 register state and allocated a 16 KB anonymous memory region with read, write and execute permissions. It then wrote an injection payload into that region through the target process’s memory.

PEERSTITCH modified fixed code locations in both daemons and inserted a trampoline that redirected execution to the injected hook. Unit 42 reported that the implant also applied NOP-style patches at three static offsets to alter normal code paths and suppress selected security or validation behavior.

The implant’s communication design was particularly difficult to observe. It did not use a socket-based control channel. Hooks inside both daemons inspected data already passing through the processes for two markers: the string associated with TCP port 8550 and the link-local address 169.254.0.1. When a marker appeared, PEERSTITCH extracted a short session identifier and stored it in a circular buffer.

The hook then used /proc/<pid>/mem to write information into the corresponding buffer in the other daemon. When /bin/iked processed later VPN sessions, the injected code checked the shared buffer and could take an alternate execution path. This created a covert bridge between the logging and VPN processes without requiring a new listening service or a standalone network connection.

Apache ACME abuse supplied a separate command channel

Alongside PEERSTITCH, the attackers abused FortiGate’s native Apache mod_md module, which manages certificates through the ACME protocol. Unit 42 reported that a path-traversal auto-script created an ACME configuration pointing to attacker-controlled infrastructure.

The DNS-01 challenge handler was mapped to /bin/node. According to the report, attacker-controlled values retrieved during the certificate challenge caused Node.js to execute an SSH-based reverse-shell command. The configuration forced repeated renewal activity, which provided a continuing outbound command channel.

This activity should be distinguished from PEERSTITCH’s implant communications. PEERSTITCH operated through patched process memory and legitimate daemon traffic, while the Apache configuration supplied a separate mechanism for repeated outbound command execution. Both relied on native components and legitimate process contexts, complicating detection based solely on unfamiliar binaries.

Defense evasion and uncertainty around management impersonation

Unit 42 documented multiple anti-forensic actions. The attackers used killall -9 miglogd and killall -9 syslogd before running malicious auto-scripts, cleared crash logs, removed rogue administrator accounts, VPN groups and auto-script objects, and replaced the ACME configuration with a benign-looking comment. The injector also deleted itself and terminated the staging process.

Logs showed intermittent drops across the tunnel-management interface during malicious activity. Unit 42 assessed with medium confidence that the attackers deliberately degraded telemetry. The researchers noted that CVE-2024-26008 could have been involved, but available logs did not confirm that mechanism.

Unit 42 also assessed with medium confidence that the attackers impersonated FortiManager over the FortiGate-to-FortiManager protocol to obtain additional running configurations. The evidence did not establish whether this used CVE-2024-26009 or reused stolen trust material. Unit 42 excluded FortiCloud-related vulnerabilities from the intrusion because the affected devices were not enrolled in that service.

What organizations should do now

Organizations operating FortiManager or managing FortiGate fleets should treat a compromise of the central platform as a fleet-wide incident, not an isolated appliance event. The following actions are general defensive recommendations informed by the Unit 42 findings:

• Establish exposure and patch status. Review FortiManager and FortiOS systems for exposure to CVE-2024-47575 and CVE-2025-61624, and follow the vendor’s current remediation guidance.
• Assume stored trust material is compromised. If a management appliance may have been accessed, rotate administrative credentials, SSL/VPN credentials, certificates, private keys and other trust material held by the platform. Reassess management relationships with every downstream device.
• Review management-plane activity. Investigate unexpected device registrations, unfamiliar administrator identities, unusual TCP port 541 activity, unexplained management-session interruptions and configuration changes involving packet capture or auto-scripts.
• Inspect volatile state. Where authorized forensic capability exists, examine memory maps for anonymous 16 KB regions with read, write and execute permissions in /bin/miglogd and /bin/iked. Review daemon text integrity and cross-process access to /proc/<pid>/mem.
• Check crash and configuration history. Look for segmentation faults involving the named daemons, traversal strings in system.auto-script objects, unexpected files under Apache configuration paths and unexplained logging gaps.
• Hunt using reported indicators. Use the PEERSTITCH hashes, filenames and defanged network indicators from the Unit 42 report in appropriately controlled tooling. Do not treat absence of those indicators as proof of a clean system because the implant is memory-resident and the infrastructure may change.
• Segment and monitor administration. Restrict management interfaces to dedicated administrative paths, alert on unexpected external access and preserve independent telemetry so a compromised appliance cannot erase the only available logs.

Conclusion

The PEERSTITCH case shows how attackers can turn a centralized edge-management system into a platform for reconnaissance, credential use and downstream intrusion. The most important lesson is not limited to one implant or two vulnerabilities. When a management appliance holds fleet-wide configurations and cryptographic trust relationships, its compromise changes the security posture of every connected device.

Traditional disk-based malware searches are insufficient for an implant that patches legitimate processes, communicates through existing traffic and deletes its staging files. Defenders should combine configuration review, management-plane monitoring, independent logging and—when compromise is suspected—specialized volatile-memory analysis.

Sources

Technical findings and assessments in this analysis are based on Palo Alto Networks Unit 42’s report on PEERSTITCH.