Published: 2026-10-18
Categories: Threat Intelligence
PEERSTITCH: Memory-Resident Implant Hiding in FortiOS Daemons
Key Takeaways
Palo Alto Networks Unit 42 has described PEERSTITCH, a memory-resident ARM64 implant that its operators placed inside two legitimate FortiOS daemons, miglogd and iked, during an intrusion at a telecommunications managed service provider that began in September 2024 [1]. The implant is delivered through CVE-2025-61624, a path traversal flaw in the FortiOS command-line interpreter that Fortinet disclosed in April 2026 [2], although the intrusion began roughly 19 months before that disclosure and the sources do not explain the gap. Unit 42 reports that the implant leaves no persistent binary on disk, opens no listening ports, and initiates no outbound connections of its own. Attacker access instead rides on a separate certificate-renewal channel and legitimate-looking VPN sessions, so network and file-based detections of the implant itself have little to examine [1].
In CSA’s assessment, the upstream compromise is likely the more consequential element for defenders. Unit 42 attributes the initial access to exploitation of CVE-2024-47575 on a FortiManager appliance, which exposed configurations, credentials, and cryptographic trust material for more than 500 managed FortiGate firewalls [1]. The implant therefore appears to be a follow-on tool for maintaining access, and it does not appear to be the root of the problem. Organizations that rely on FortiManager as a central management plane should treat the exfiltrated material, and not only the implant, as the primary remediation concern.
Detection depends on host-level inspection of process memory, daemon integrity, and configuration revisions. Practical measures include patching, rotating certificates and credentials that a compromised manager could have held, restricting management-plane exposure, and checking the indicators Unit 42 published. Because the technique abuses vendor-trusted daemons, a clean reboot does not establish that a device was never compromised, and a reboot would also remove the in-memory evidence a responder needs.
Background
Unit 42 published its analysis in mid-October 2026, tracking the activity as CL-STA-0954, a cluster that Unit 42 notes overlaps with the Google-tracked designation UNC5820 [1][3]. The investigation concerned a telecommunications managed service provider whose FortiManager appliance was compromised in September 2024. The attackers registered a rogue virtual FortiGate device against the manager and used that registration to pull a large archive of managed-device data [1]. Both Unit 42 and The Hacker News describe the FortiManager as controlling more than 500 firewalls that protected internal and client infrastructure, and The Hacker News reports that configurations were stolen for firewalls across both [1][3]. Unit 42 does not report confirmed downstream intrusions into client networks, so readers should rely on the primary Unit 42 report for scope and treat secondary characterizations cautiously.
CVE-2024-47575, often called “FortiJump,” is a missing-authentication flaw in the FortiManager FGFM daemon that permits unauthenticated remote code execution [1]. CVE-2025-61624 is a distinct and later-disclosed weakness. Fortinet advisory FG-IR-26-122, published on April 14, 2026, describes a path traversal flaw (CWE-22) in the command-line interpreter of FortiOS, FortiPAM, FortiProxy, and FortiSwitchManager that lets a privileged attacker write or delete arbitrary files through crafted arguments to existing commands [2]. Fortinet rates it medium severity, and its advisory lists the flaw as known exploited [2]. Because exploitation requires privileges, in CSA’s assessment the medium score does not reflect its role in this intrusion: the attackers already held management-plane access, which turned a file-write primitive into code execution on the firewall.
The incident belongs to a recurring pattern in which security and remote-access appliances serve as long-lived footholds. CSA’s earlier analysis of three exploited FortiSandbox vulnerabilities noted that a trusted security appliance can become a network entry point, and its SonicWall SMA 1000 analysis described compromised edge devices used as durable beachheads rather than single-use entry points [4][5]. PEERSTITCH extends that pattern from the appliance’s exposed services to its internal process structure.
Security Analysis
Delivery and Injection
According to Unit 42, the attackers abused CVE-2025-61624 by pushing an auto-script object whose name used ../ sequences, which caused the device to write and run a setup script outside its intended directory [1]. That script retrieved several files from attacker infrastructure, including an ARM64 injector named lldprx, and the report indicates the injector removes itself from disk after it runs [1]. The injector searches /proc for the two target daemons, reads their memory maps, attaches with ptrace, and records register state. It then arranges for a 16 KB anonymous region with read, write, and execute permissions to be allocated inside each daemon, writes a payload of about 1,344 bytes into that region through /proc/<pid>/mem, and installs a short trampoline that redirects execution into it [1]. Unit 42 also reports that the injector overwrites instructions at three fixed offsets with no-operation instructions, which it assesses as suppressing tamper checks [1].
The Cross-Daemon Bridge
The design choice that gives PEERSTITCH its name is a covert communication path between the two daemons. Rather than opening a socket, the hooks in miglogd watch traffic the daemon already handles for specific markers, which Unit 42 identifies as TCP port 8550 and the address 169.254.0.1. They extract a short tag of up to 31 bytes, store it in a small circular buffer, and write it into the memory of the counterpart process through /proc/<pid>/mem [1]. When iked handles an IPsec or SSL VPN session carrying a matching tag, the hook branches around the security validations that would otherwise apply [1]. The effect is that a session the attacker has tagged can pass checks that other sessions must satisfy, and the signaling that makes this possible is an ordinary memory write between two trusted processes.
This approach has implications for how defenders should think about telemetry. Network monitoring sees only logging traffic and VPN traffic that both appear routine, and file integrity tooling sees no new binary. The behavior is visible mainly at the process level, in the form of anomalous memory permissions, cross-process memory writes, and altered code in daemons that vendors do not expect to change.
Command and Control and Use of Stolen Material
Unit 42 reports a separate remote-access channel that abuses Apache’s mod_md certificate management module. The attackers pointed the module at a rogue ACME server, mapped its DNS challenge handler to a local interpreter, and placed a shell command in the domain name field, with a renewal mode that causes the command to run repeatedly [1]. Using the exfiltrated configurations, credentials, and key material, the operators then established unauthorized SSL VPN sessions and impersonated FortiManager over the FGFM protocol to download further device configurations [1]. The report also describes anti-forensic steps, including terminating logging processes, clearing crash logs, and deleting temporary accounts and script objects after use [1]. Unit 42 describes the clearing of crash logs; CSA infers that this matters for responders because the crash log is one of the few places an unstable injection might leave evidence.
Indicators Unit 42 Provides
The report lists detection surfaces that can be checked without vendor tooling, summarized in the table below.
| Surface | What to check | Source |
|---|---|---|
| Process memory | Anonymous 16,384-byte rwxp regions in miglogd and iked memory maps |
[1] |
| Daemon integrity | Expected no-operation patch bytes at the three offsets Unit 42 publishes | [1] |
| Process activity | ptrace attachment and writes to /proc/<pid>/mem between daemons |
[1] |
| Crash logs | Signal 11 entries involving miglogd or iked |
[1] |
| Configuration revisions | system.auto-script objects containing ../ |
[1] |
| Network | Connections to 23.240.77.233, 47.18.167.159, 45.32.41.202, and 198.199.122.22 | [1] |
These indicators are specific to the sample Unit 42 analyzed, and operators could change offsets or addresses in later variants. Absence of a match therefore provides limited assurance, and the structural checks (anomalous executable regions, cross-process memory writes) are more durable than the specific values.
Limits of Current Knowledge
Several points remain unclear in the sources reviewed. Unit 42 describes a September 2024 intrusion and a flaw that Fortinet disclosed in April 2026, which implies the attackers either held the capability well before disclosure or used an equivalent technique earlier; the sources do not resolve this, and it should be treated as an open question. Public reporting does not give a count of implanted devices as opposed to devices whose configurations were stolen. The Hacker News reports that CISA added CVE-2025-61624 to its Known Exploited Vulnerabilities catalog on October 16, 2026, with a federal deadline of October 19, 2026 [3]; that claim is attributed to the trade outlet and should be checked directly against CISA’s catalog. Fortinet’s advisory also does not map the exploit to a specific FortiOS build in the reporting reviewed here, so exposure should be assessed against the advisory’s version table rather than assumed.
Recommendations
Immediate Actions
Organizations running FortiOS should compare their versions against advisory FG-IR-26-122 and upgrade to fixed releases. As of the advisory date these include FortiOS 7.6.5 and 7.4.10 or later for those branches, with older 7.2, 7.0, and 6.4 branches directed to migrate to a fixed release [2]. Fortinet also lists a virtual patch for FortiGate IPS through a database update as an interim mitigation [2]. Teams should also confirm that FortiManager is patched for CVE-2024-47575 and that FGFM and management interfaces are not reachable from the internet. Where a FortiManager appliance was exposed and unpatched at any time, defenders should assume that device configurations, administrator credentials, certificates, and private keys it held may be compromised and begin rotation.
Responders should then run the checks in the table above on a representative set of devices (for example, one or more from each firewall tier and customer environment the manager administers) before any restart, because a reboot clears injected memory. Capturing process memory maps and crash logs first preserves evidence. Reviewing configuration revision history for auto-script objects containing path traversal sequences is low cost and can be done centrally from the manager.
Short-Term Mitigations
Rotate VPN credentials, local administrator passwords, pre-shared keys, and certificates for any firewall whose configuration a compromised manager could have stored. Restrict administrative access to a dedicated management network and require source-address allowlists for the FGFM protocol and administrative interfaces. Forward device logs to an external collector so that local log suppression does not remove the record, and alert on unexpected SSL VPN sessions, new virtual device registrations on FortiManager, and unexpected ACME or certificate-renewal configuration changes. Managed service providers should additionally review whether a single manager holds secrets for many customers and communicate exposure to affected customers promptly.
Strategic Considerations
PEERSTITCH illustrates that integrity assurance for edge appliances cannot depend on file scanning alone. Organizations should ask vendors what runtime attestation, memory inspection, or integrity-measurement capability is available on their platforms and whether it can be exported to independent tooling. Management-plane architecture deserves the same scrutiny as the data plane: a central manager that aggregates credentials and trust material for hundreds of devices is a high-value target, and segmenting managers by customer or environment limits the blast radius of a single compromise. Procurement and risk programs should also account for the long gap between initial intrusion and public disclosure in this case, and plan for retrospective hunting when new indicators are published.
CSA Resource Alignment
CSA’s FortiSandbox Triple-CVE: Security Appliances as Network Entry Points is the closest prior work on the same vendor ecosystem [4]. It argues that appliances placed in a trusted position, such as a sandbox that issues verdicts for downstream controls, become especially valuable when compromised. The FortiManager compromise in this incident has the same property, since the manager holds the trust relationships for the devices it administers, and the guidance in that note on prompt patching of security-fabric components applies directly.
CSA’s SonicWall SMA Zero-Days: Edge Appliance Root Returns documents attackers using compromised remote-access appliances as durable beachheads, including harvesting credentials and session data to authenticate to internal systems without returning through the original entry point [5]. PEERSTITCH shows a comparable operational goal reached by different means, and the recommendation in that note to treat a compromised edge device’s stored secrets as exposed carries over to the exfiltrated FortiGate configurations.
For control mapping, the CSA AI Controls Matrix (AICM) v1.1 builds on the Cloud Controls Matrix (CCM) and incorporates AI security best practices [6]. Its inherited infrastructure and vulnerability management controls give organizations a basis for assessing patch timelines, management-plane segmentation, and logging requirements. Although PEERSTITCH is not an AI-specific threat, AICM is the controls framework CSA recommends as the default reference, and the same infrastructure controls apply to the network appliances that front AI workloads.
References
[1] Palo Alto Networks Unit 42. “Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant.” Unit 42, October 2026.
[2] Fortinet PSIRT. “Path Traversal Vulnerability in Fortinet Products (FG-IR-26-122, CVE-2025-61624).” Fortinet, April 14, 2026.
[3] The Hacker News. “PEERSTITCH Malware Deployed via FortiOS Flaw Bypasses Checks on Tagged VPN Sessions.” The Hacker News, October 2026.
[4] Cloud Security Alliance AI Safety Initiative. “FortiSandbox Triple-CVE: Security Appliances as Network Entry Points.” CSA, June 2026.
[5] Cloud Security Alliance AI Safety Initiative. “SonicWall SMA Zero-Days: Edge Appliance Root Returns.” CSA, July 2026.
[6] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” CSA, 2026.