The Archive Outlived the Patch: PEERSTITCH Hid in FortiGate Memory on Trust Stolen in 2024

2026-10-18 AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 14 October 2026, Palo Alto Networks Unit 42 published its analysis of PEERSTITCH, a memory-resident ARM64 implant living inside the logging and VPN daemons of FortiGate firewalls. Two days later, CISA added CVE-2025-61624 — the second-stage flaw the implant rode in on — to its Known Exploited Vulnerabilities catalog, with a federal remediation deadline of 19 October, this Monday. The score on that CVE is CVSS 3.1 6.5: medium. The campaign behind it ran for 25 months off a single stolen management archive covering more than 500 firewalls. That gap between the number and the damage is the story — and it starts not in 2026, but in September 2024, with a FortiManager breach whose patch did nothing to revoke what was taken.

The entry point was CVE-2024-47575, dubbed FortiJump: a missing-authentication flaw in FortiManager’s management channel, scored CVSS 3.1 9.8 with network access, no privileges and no user interaction. Both NVD fields we checked first-hand confirm the record is in Analyzed status with that 9.8 from two sources. The actor Unit 42 tracks as CL-STA-0954 (overlapping Mandiant’s UNC5820) used it against a telecommunications managed-service provider: register a rogue virtual FortiGate named localhost, then generate and steal a configuration archive. That archive was a map of trusted relationships — running configurations for every managed FortiGate, the central management databases, a flat inventory of serial numbers beside public IPs, topology and routing data, credentials stored as reversible ciphertext, and private keys and certificates. Unit 42 recovered administrative and SSL/VPN passwords from the stolen material. From there the actors opened unauthorized VPN sessions into network-management segments using legitimate credentials. Patching FortiJump closed the door; it did nothing about the keys copied on the way in. Closing the entry point and revoking the stolen identities were always two separate jobs, and only one of them got done.

A medium-severity traversal, aimed with stolen admin rights

CVE-2025-61624, read first-hand from NVD and the KEV catalog CSV, is an improper limitation of a pathname (CWE-22) in the FortiOS CLI auto-script engine: an authenticated administrator with at least read-write permissions can write or delete arbitrary files through crafted CLI commands. Fortinet’s own assessment is CVSS 3.1 6.0 (local attack vector); NVD’s is 6.5 (network vector, still requiring high privileges). The affected surface is broad — FortiOS 7.6.0 through 7.6.4, 7.4.0 through 7.4.9, and all of 7.2, 7.0 and 6.4, plus FortiPAM, FortiProxy and FortiSwitchManager lines — but the severity reads as routine hardening backlog. It entered KEV anyway, because severity scores the flaw in isolation and the campaign never attacked it in isolation. A path traversal that requires admin rights is uninteresting until the attacker already is the admin, holding passwords brute-forced out of a two-year-old backup. Defenders who triage by CVSS sorted this one below the fold; the actor sorted it by what it unlocked — root on every firewall whose credentials were in the archive.

The implant’s delivery shows what that unlocking bought. By naming an auto-script object with traversal sequences, the actors dropped a JavaScript loader outside the intended directory and executed it with root privileges. The loader fetched five files from attacker infrastructure — including an ARM64 injector staged on disk as lldprx — and the injector went after two running processes: /bin/miglogd, the logging service, and /bin/iked, the IKE/IPsec VPN service. The technique is process parasitization, not persistence in the file sense: enumerate /proc for the daemon PIDs, read base addresses from the memory maps, seize each process with ptrace, snapshot the ARM64 registers, map a 16,384-byte RWX region into each victim, write a 1,344-byte payload into it, and redirect execution through NOP and trampoline patches at fixed text-segment offsets. The two hooks then form a covert bridge — when either daemon handles data matching embedded markers (TCP port 8550 or the link-local address 169.254.0.1), session tokens are copied into a 16-slot ring buffer in the counterpart’s memory, and subsequent VPN sessions matching a buffered token take an alternate return path that skips FortiOS security validation. No file left behind by the implant itself, no listening socket, no connection of its own. File-integrity monitoring, port scans and flow analysis all see nothing, because there is nothing in their respective domains to see. Note the corollary the reporting stresses: 8550 is a marker, not a listener — hunting for a PEERSTITCH port 8550 listener misunderstands the mechanism.

Memory-resident is not traceless

The implant’s stealth deserves a precise boundary, because “no disk, no socket, no traffic” is easily over-read as “no evidence anywhere.” The reporting draws the line carefully: the delivery chain staged components on disk, and the actors kept a second, noisier persistence channel alongside the quiet one. They abused the native Apache mod_md certificate-management module, crafting a rogue ACME configuration that mapped DNS-01 challenge handling onto /bin/node so that certificate renewal executed Node.js with attacker-supplied parameters — the domain-name field carrying an injected shell command — and forced continuous polling so the resulting outbound reverse shell re-established itself on every renewal cycle. They also pushed packet captures to downstream firewalls from the compromised manager, targeting unencrypted HTTP, a block of TCP services around remote administration and telemetry, and later RADIUS, LDAP and TFTP for authentication sniffing. And the anti-forensics were methodical: logging daemons killed before malicious auto-scripts ran, crash logs cleared, rogue accounts and script objects rolled back automatically after deployment, the ACME configuration file overwritten with benign content. Memory-residence defeated the controls that look at rest and transit; the campaign still touched disk, process tables and logs at its edges, which is where the hunting leads live — unexpected executable memory in the two daemons, cross-process memory writes, crash records, and script objects containing traversal strings.

One detail deserves to travel beyond this incident. Investigators found configuration downloads attributed to a FortiGateCloud identity on devices whose provider had no cloud-management tenant and had never provisioned that account. Unit 42 assessed management-platform impersonation at medium confidence, explicitly unable to distinguish reuse of stolen trust material from a separate authentication-bypass path. The defensive lesson survives the uncertainty either way: compare apparent management identities against the deployment you actually operate. A plausible account label is evidence of nothing when no corresponding service should exist. Expected functionality proved nothing here twice over — the VPN sessions validated (by patched code taking the wrong branch), and the management downloads looked routine (from an account that should not have been there).

Why this one belongs on an AI-security front page

PEERSTITCH is not an AI vulnerability, and this site does not claim otherwise. It belongs here for the same reason the Ivanti, PAN-OS and BeyondTrust edge-appliance campaigns do: the infrastructure that AI-driven operations depend on — VPN identity, session validation, the management plane that automated runbooks and agentic operators authenticate against — was subverted underneath every check, for two years, using credentials stolen from the manager that was supposed to be the root of trust. An agent that verifies a VPN session, queries a firewall API, or pulls inventory from FortiManager inherits exactly the lies this implant told. The campaign also inverts the usual patching moral. The vulnerable software was patched — FortiJump has had a fix since 2024, and the current advisory names FortiOS 7.6.5 and 7.4.10 as the fixed releases for CVE-2025-61624, with older branches told to migrate. Patching is necessary and insufficient when the breach already converted code flaws into credential holdings: passwords, keys and certificates do not expire because the bug that leaked them got fixed. The remediation order that falls out of this — rebuild the manager through the vendor’s documented process, rotate every exposed secret at the targets that trusted them, and hunt memory and management-identity anomalies rather than files and ports — is the same order the ARMORY CASTLE and Ivanti responses converged on. The industry keeps relearning it one appliance at a time.

What to do

Meet the 19 October KEV deadline for CVE-2025-61624, then keep going past the patch. Upgrade FortiOS to a fixed release (7.6.5 / 7.4.10 per the vendor advisory; migrate 7.2, 7.0 and 6.4 lines to supported fixed releases), and cover FortiPAM, FortiProxy and FortiSwitchManager from the same advisory — but treat the upgrade as step one, not the cleanup.
Assume any FortiManager breached via FortiJump handed over its whole estate. If a manager was ever exposed to CVE-2024-47575 before patching, rotate administrative, VPN, RADIUS/LDAP and certificate trust material on every managed device — the archive contained all of it in recoverable form.
Hunt the edges, not the implant’s center. Look for unexpected executable memory in miglogd and iked, cross-process memory writes, crash records, auto-script objects with traversal strings, rogue ACME/mod_md configurations, and packet-capture policies you did not push. Coordinate evidence collection before rebooting, which destroys volatile memory.
Audit management identities against reality. List every account and tenant association (cloud management, API, admin) on each firewall and confirm each maps to a service you actually operate. An account that looks native but has no corresponding deployment is the finding.
Watch the staging infrastructure at the perimeter. Block and alert on the published indicators — including 45.32.41.202, 23.240.77.233 and 47.18.167.159 — particularly on egress paths for firewall management traffic, and review VPN session logs for logins from infrastructure you do not own.
Stop triaging chained flaws by single-CVE score. A CVSS 6.5 admin-only traversal became root-everywhere the moment it met stolen admin credentials. Score the chain your estate actually presents: privileged-interface flaws on devices whose management trust may be compromised belong at the top regardless of their base score.

Our verification was read-only and external. The CVE-2025-61624 description, CWE-22 weakness, both CVSS 3.1 scores (Fortinet 6.0, NVD 6.5), affected product ranges and Analyzed status, and the CVE-2024-47575 9.8 score and missing-authentication description were read first-hand from the NVD 2.0 API; the KEV listings for both CVEs — 16 October date-added, 19 October due date, CWE labels and vendor-advisory references — were read first-hand from CISA’s KEV catalog CSV, which records ransomware use as Unknown for both. The intrusion sequence, implant mechanics, file paths, command behavior, staging infrastructure and remediation guidance above are Unit 42’s published findings as carried in two detailed secondary write-ups read here in full; the Unit 42 page itself would not load from the build host, and Fortinet’s PSIRT advisory page returned a server error, so fixed-release details are reported via the cited secondary that references the advisory directly. We installed nothing, contacted no firewall, ran no exploit, and performed no credential recovery. Staging addresses appear as published indicators, consistent with standard threat-intelligence practice.

Sources: