Habla con un experto
PreciosNoticiasHabla con un experto
Volver a la sala de prensa
Amenazas

PEERSTITCH: Memory-Only Implant Hijacks FortiOS VPN Handling

A suspected advanced actor breached a telecom MSP via FortiManager, stole configs for 500+ FortiGates, then planted PEERSTITCH — a diskless implant that lets tagged VPN sessions skip FortiOS security checks.

4T4Tify Team4Tify
Oct 16, 2026·6 min de lectura
PEERSTITCH: Memory-Only Implant Hijacks FortiOS VPN Handling

PEERSTITCH: Memory-Only Implant Hijacks FortiOS VPN Handling

A suspected advanced threat actor has been caught running a new, memory-resident ARM64 implant on Fortinet FortiGate firewalls. Dubbed PEERSTITCH by Palo Alto Networks Unit 42, the malware leaves no file on disk, opens no port and makes no outbound connection of its own — instead it quietly rewires how the firewall's own VPN daemon treats specially tagged sessions.

What happened

Unit 42 uncovered the activity while investigating a long-running intrusion at a telecommunications managed service provider. The cluster is tracked as CL-STA-0954 (also known as UNC5820). As reported, the chain unfolded like this:

  • Initial access through FortiManager. The attackers exploited FortiJump (CVE-2024-47575), a critical FortiManager flaw, to take over the central management appliance.
  • Bulk theft of the management estate. From FortiManager they took running configurations for more than 500 managed FortiGate firewalls (internal and client networks), device serials paired with public IPs, central-management SQLite databases, topology and routing data, encrypted admin/local/SSL-VPN credentials, and certificates plus private keys.
  • Pivot to the edge. With that material they mapped the network, set up unauthorized SSL-VPN sessions, intercepted traffic, planted backdoors, and abused CVE-2025-61624 — a FortiOS CLI path-traversal flaw (CVSS 5.4, patched by Fortinet in April 2026) — to escalate privileges and deploy PEERSTITCH.
  • A second C2 channel. Separately, the actor abused FortiGate's built-in Apache mod_md module to spawn an SSH-based reverse shell, and impersonated FortiManager to pull data from other managed firewalls.

Unit 42 also flagged CVE-2024-26008 and CVE-2024-26009 as possible additional vectors, but stressed this is not confirmed — those bugs require FortiCloud SSO enrollment, which none of the affected firewalls had.

How PEERSTITCH works

An auto-script fetches five staged components (two JavaScript files, an Emscripten runtime, a WebAssembly module and a native ARM64 injector) from attacker infrastructure, stages them under /data2/template/, and then:

  1. The injector (lldprx) attaches to the miglogd and iked daemons via ptrace, pauses them, allocates a small executable buffer and plants a hook in each.
  2. The two hooks talk to each other through /proc/<pid>/mem, forming a covert in-memory bridge between two legitimate FortiOS processes.
  3. miglogd watches passing data for a marker (TCP port value 8550 embedded in traffic and the link-local address 169.254.0.1), then hands the matching session identifier to iked.
  4. When a VPN session carries that tag, iked takes an alternate code path that skips normal FortiOS security validation.
  5. The injector then deletes every staged file and exits.

On top of that, the operators killed syslog generation, cleared crash logs, disrupted telemetry and auto-deleted their rogue admin accounts and auto-scripts.

Why it matters

  • One management box, hundreds of firewalls. Compromising FortiManager handed the attacker the keys to an entire managed fleet, including downstream customer networks — a textbook MSP supply-chain risk.
  • Built to dodge EDR and NDR. No binary on disk, no listener, no beacon: classic file-, port- and flow-based detection has little to catch.
  • Stolen secrets outlive the patch. Once configs, credentials and private keys are exfiltrated, patching alone does not evict the attacker.

What to do

  1. Patch FortiManager and FortiOS — confirm fixes for CVE-2024-47575 and CVE-2025-61624 (and FortiPAM, FortiProxy, FortiSwitchManager where used).
  2. Take management off the internet. Keep FortiManager and FortiGate admin interfaces (including FGFM) reachable only from a dedicated management network.
  3. Assume secrets from a compromised FortiManager are burned. Rotate admin, local and SSL-VPN credentials, re-issue certificates and private keys, and review every device it managed.
  4. Hunt on the devices themselves. Look for unknown auto-scripts, short-lived admin accounts, files under /data2/template/, unexpected mod_md activity, and gaps or sudden silence in syslog and crash logs. Fortinet's integrity checks and a reboot/re-image are more reliable than log review for memory-only implants.
  5. Watch VPN behaviour, not just files. Baseline SSL-VPN/IKE sessions and alert on logins from unusual sources or sessions that bypass expected MFA/posture checks.
  6. Block reported infrastructure — e.g. 23.240.77[.]233:8085 — while recognising that IOCs change quickly.
  7. MSPs: segment tenants. One management plane should not be a single key to every client.

Need an outside view of how exposed your edge devices and management interfaces are? The 4Tify team can run an authorized assessment of your perimeter.

Credit: this report is based on research published by Palo Alto Networks Unit 42 and originally reported by The Hacker News (Ravie Lakshmanan, 16 Oct 2026). This article is 4Tify's own summary and analysis.

COMPARTIR