PEERSTITCH Shows How a FortiManager Breach Can Reach Hundreds of Firewalls

A single FortiManager compromise gave attackers a path to sensitive data associated with more than 500 FortiGate firewalls—and, later, access to parts of the managed network. The September 2024 intrusion against a telecommunications provider shows why a centralized edge management appliance can carry risks far beyond its own network: it holds the credentials, cryptographic material and device relationships that connect an organization to many firewalls.

Unit 42 tracked the activity as CL-STA-0954, also known as UNC5820. Its investigation covered the provider’s environment, not the networks protected by clients’ firewalls. The researchers report exposure of configuration and credential material, but did not confirm that attackers entered those client networks. They also found a previously undocumented FortiOS implant, PEERSTITCH, built to operate in memory and blend its communications into activity from legitimate system processes.

One management appliance exposed data on hundreds of devices

The intrusion began with exploitation of CVE-2024-47575, a flaw that allowed unauthenticated command execution through crafted requests to FortiManager’s FMG-Access management channel on TCP port 541. External parties have called the vulnerability FortiJump. The attackers registered a rogue Virtual FortiGate appliance called localhost, with serial number FMG-VMTM23017412. They then generated and removed an archive named .tm.

The archive contained running configurations, cryptographic trust material and database files linked to more than 500 managed FortiGate devices. Those firewalls served both the provider’s infrastructure and its clients. The information gave the attackers a view of device relationships and network structure, as well as credentials stored in a reversible encrypted format. Unit 42 says it recovered administrative and SSL/VPN passwords by brute-forcing the values in the stolen configuration files.

After an extended period in the environment, the intruders used the compromised management appliance to push unauthorized packet-capture rules to downstream firewalls. The rules targeted unencrypted HTTP traffic and 11 services running on different TCP ports, with the aim of intercepting communications and mapping network boundaries. Additional capture rules were later placed on core perimeter firewalls.

The stolen credentials also enabled unauthorized SSL/VPN sessions to perimeter devices from external infrastructure at 23.240.77[.]233 and 47.18.167[.]159. Those sessions provided authenticated access to internal network-management segments. The sequence illustrates the value of management data in an intrusion: it can turn a breach of one central appliance into a route toward devices and networks that the appliance manages.

FortiOS path traversal delivered a memory-only implant

From authenticated FortiOS administrative access, the attackers exploited CVE-2025-61624 to gain root-level file access on the firewall. FortiOS administrators, including accounts with the super_admin role, normally operate through a restricted management interface without shell access or direct control of system files and processes. The flaw sits in the FortiOS CLI’s system.auto-script engine: it fails to sanitize an auto-script object name containing path traversal sequences. As a result, an authenticated administrator can read or write files outside the intended directory, and the script runs with the engine’s privileges.

The attackers used the name ../../../../setup to place an initial-stage loader. PEERSTITCH is a 64-bit ARM64 Linux executable written in C and statically linked against glibc. It acts as a one-shot injector that patches the memory of two FortiOS daemons. The implant leaves no persistent binary on disk, opens no listening port and does not initiate its own outbound connection. Instead, it sets up a covert communication bridge between /bin/miglogd and /bin/iked, using traffic produced by those processes.

That design complicates detection based on file scans or network connection monitoring. The loader was staged through the auto-script mechanism, which downloaded five files from an external server into /data2/template/. After a delay, ipssem.js launched lldprx with a sequence of arguments that included JavaScript and WebAssembly components. Unit 42 describes lldprx as performing a single-pass execution sequence before the implant operates within the target processes.

PEERSTITCH also alters execution directly in process memory. It writes NOP instructions at three static offsets to suppress selected daemon routines, then installs a 20-byte trampoline at base + 0x135102C. That trampoline redirects execution to a read, write and execute hook buffer of 16 KB. The specific ARM64 instruction used for the NOP patch is 0xAA0003E0, which corresponds to MOV X0, X0.

A second path used Apache’s certificate workflow

Alongside PEERSTITCH, the attackers repurposed FortiGate’s Apache mod_md module, which manages certificates using the ACME protocol. They used another auto-script object to write ../../tmp/apache2/conf/md-acme.conf, then configured the module to interact with an ACME server under their control.

Unit 42’s analysis of the module’s state and log files describes a chain from certificate validation to command execution. The account state redirected ACME directory requests to the attackers’ server, while the pending order file pointed authorization and finalization requests there as well. The module’s MDChallengeDns01 handler was mapped to /bin/node. When Apache initiated a DNS-01 validation challenge, Node.js ran with parameters supplied through the remote request. A debug log showed shell commands placed in the challenge’s domain-name field, including an SSH command that established a reverse shell.

Setting MDRenewMode always caused Apache to repeatedly initiate renewal challenges. With the challenge handler bound to Node.js, this created a recurring execution path for the injected command. It gave the attackers an outbound shell channel that could persist alongside the memory-resident implant.

Stolen trust material enabled management impersonation

FortiGate-to-FortiManager communication uses TCP port 541 and relies on cryptographic trust material checked against appliance serial numbers. The stolen archive included that material, serial numbers and management relationships for downstream devices. Unit 42 observed external FGFM activity followed by an account named FortiGateCloud downloading complete running configurations from multiple firewalls. The provider did not use a FortiManager Cloud tenant, and the account had not been provisioned on the affected devices.

Researchers assess with medium confidence that the attackers impersonated the management platform over FGFM. They describe two possible methods but say the available evidence does not establish which one was used. One possibility is that attackers forced the legitimate FortiManager session to end using CVE-2024-26008, which could fit intermittent drops in the tunnel management interface that investigators observed.

Unit 42 considered other vulnerabilities associated with misuse of the FortiGateCloud account name, but excluded them from this intrusion’s scope. Those issues require enrollment in FortiGate Cloud or FortiCloud SSO, which the affected firewalls did not have. Investigators found reuse of the account name, but not the exploitation artifacts associated with those vulnerabilities.

What defenders should take from the intrusion

The investigation describes extensive efforts to remove forensic traces. PEERSTITCH adds a particular challenge because it runs in memory, leaves no persistent implant file and uses existing processes for network activity. Defenders will need to look beyond disk artifacts and listening ports, using specialized hunting methods such as examining process memory, daemon behavior and unusual FortiOS auto-script objects. Unit 42 also lists file names, SHA-256 hashes, network indicators and a YARA rule in its full report; those details can support searches in environments where the relevant telemetry is available.

A breach can expose shared trust material and credentials even when investigators have not confirmed entry into every downstream network. Patching the appliance alone does not invalidate copied certificates or passwords. Defenders should assess and rotate credentials and cryptographic material tied to a compromised management platform, while reviewing management access and downstream device configurations for unauthorized changes.

The case also shows how attackers can combine several mechanisms: an exposed management interface, credential recovery, impersonation of device-management traffic, an auto-script path traversal flaw and abuse of a certificate workflow. PEERSTITCH’s in-memory design raises the bar for endpoint and network monitoring, but its deployment still depends on access to FortiOS administrative functions. That makes management-plane access, script configuration and trust-material rotation practical areas to examine as organizations investigate similar exposures.

Unit 42 says Palo Alto Networks shared the findings with Cyber Threat Alliance members. Organizations that suspect a compromise can contact the Unit 42 Incident Response team. The key operational question after a management appliance breach is how far its credentials and trust relationships extend—and whether those links have been reset.