PEERSTITCH via FortiManager: Hunt and Evict Stealthy FortiOS Memory-Resident Firewall Access

The PEERSTITCH campaign matters because it targets the management plane, not just one firewall. According to the reporting summarized from Palo Alto Networks Unit 42, attackers compromised a telecom managed service provider's FortiManager appliance and used that trusted position to expose 500+ downstream firewalls, deploy a stealth implant, hide inside FortiOS memory, and preserve access across a prolonged intrusion that began in September 2024. Source: https://securityaffairs.com/201077/malware/peerstitch-malware-how-attackers-compromised-500-firewalls-through-fortimanager.html

No CVE identifier is provided in the source summary, and defenders should not invent one. Treat this as a present-day management-plane compromise pattern: FortiManager as the pivot, FortiOS as the persistence surface, and MSP scale as the force multiplier.

Introduction: Why This Is Urgent

If you operate FortiManager, especially in an MSP, telecom, retail, healthcare, or distributed enterprise model, assume that one management-node compromise can become a fleet compromise. The attacker goal described here is durable access with low forensic footprint: live in memory, blend into normal FortiOS operations, use trusted administrative flows, and avoid noisy endpoint artifacts.

The defensive priority is not only patching. It is proving whether FortiManager was used as a control channel, whether firewall configurations or admin objects changed outside approved work, whether any FortiGate shows unexplained memory-resident behavior, and whether credentials, API tokens, SNMP strings, certificates, and automation secrets need rotation across the entire estate.

Technical Analysis

Affected products and platforms

Based on the provided summary, the affected control point is Fortinet FortiManager, with downstream impact to FortiGate firewalls running FortiOS managed by that appliance. The public summary does not list exact model numbers, firmware trains, or vulnerable versions. Scope should therefore include:

FortiManager appliances or VMs that can reach many FortiGate devices.
FortiGate/FortiOS firewalls managed through FortiManager, especially where one MSP template or administrator can push to hundreds of devices.
Administrative jump hosts, NMS servers, backup servers, and automation runners that store FortiManager credentials or API tokens.
Any environment where FortiManager administration, FortiGate administration, SSH, HTTPS, SNMP, or API services are reachable beyond a tightly controlled management VRF.

CVE and exploitation status

The news title and summary do not include a CVE, CVSS score, CISA KEV entry, or patch identifier. Do not anchor the response to a guessed CVE. The confirmed issue from the reporting is active tradecraft: compromise of FortiManager, exposure of 500+ firewalls, stealthy FortiOS memory residence, and detection evasion during a long-running intrusion. Treat exploitation as real and operational, not theoretical, while separately checking current Fortinet PSIRT advisories and CISA KEV for any newly linked identifiers.

Defender-focused attack chain

Establish access to the management plane: the likely crown jewel is FortiManager because it centralizes policy, device inventory, templates, revisions, credentials, and push capability.
Abuse trust: from FortiManager, administrative actions toward FortiGate devices can look expected, especially in MSP workflows with frequent changes.
Scale quietly: one compromised manager can touch hundreds of firewalls without tripping per-device anomaly thresholds.
Persist in FortiOS memory: an implant that lives in memory reduces disk artifacts and can survive casual log review, though reboots, firmware updates, and integrity verification become important.
Evade detection: activity may blend with normal diagnose commands, config synchronization, backup jobs, HA operations, and administrator sessions.
Maintain access: new admin users, API tokens, SSH keys, SNMP communities, certificates, scheduled tasks, scripts, or hidden configuration objects may provide fallback paths.

What makes this hard

Firewall telemetry is often forwarded but not behaviorally baselined. Many SOCs alert on failed logins and deny logs, yet miss the dangerous sequence: a valid FortiManager session, followed by config revision creation, admin object changes, policy package installs, diagnostic command use, and an unusual spread of device touches in a short window. The signal is correlation across identity, change management, network device logs, and firmware integrity.

Detection & Response

Start with containment scoping: identify every FortiManager, its administrative source networks, every FortiGate it manages, all admins/API clients, all automation systems, and all configuration revisions since September 2024 unless your exposure window is provably shorter. Preserve volatile evidence before rebooting suspected FortiOS devices: active sessions, process lists, crashinfo, log buffers, config checksums, firmware version, HA state, routing tables, and connected management sessions.

The following detections are intentionally behavior-based. Tune field names to your pipeline; Fortinet syslog, CEF, and SNMP telemetry vary by deployment.

YAML

---
title: FortiManager Originated Mass Firewall Administration
description: Detects a FortiManager or management host touching an abnormal number of FortiGate devices or generating concentrated admin/config activity, consistent with management-plane abuse.
references:
  - https://attack.mitre.org/techniques/T1078/
  - https://attack.mitre.org/techniques/T1021/
author: Security Arsenal
date: 2026/01/15
status: experimental
tags:
  - attack.lateral_movement
  - attack.valid_accounts
logsource:
  product: fortinet
  service: syslog
detection:
  selection:
    msg|contains:
      - 'FortiManager'
      - 'config system'
      - 'execute restore'
      - 'diagnose'
      - 'admin'
  condition: selection
falsepositives:
  - Legitimate Fortinet administration during approved change windows
level: high
---
title: FortiOS Diagnostic And Memory-Oriented Command Abuse
description: Detects unusual use of FortiOS diagnostic, debug, hardware, sensor, or shell-adjacent commands that may precede memory-resident implant activity or anti-forensics.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1070/
author: Security Arsenal
date: 2026/01/15
status: experimental
tags:
  - attack.execution
  - attack.defense_evasion
logsource:
  product: fortinet
  service: syslog
detection:
  selection:
    msg|contains:
      - 'diagnose debug'
      - 'diagnose hardware'
      - 'diagnose sys'
      - 'diagnose firewall'
      - 'fnsysctl'
      - 'execute sensor'
      - 'execute tac report'
  condition: selection
falsepositives:
  - Fortinet TAC-directed troubleshooting
  - Approved maintenance with ticket reference
level: medium
---
title: Network Device Admin Or Credential Object Creation
description: Detects creation or modification of administrator, API, SNMP, SSH key, certificate, or automation objects on Fortinet infrastructure, a common persistence path after management-plane compromise.
references:
  - https://attack.mitre.org/techniques/T1136/
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/01/15
status: experimental
tags:
  - attack.persistence
  - attack.account_manipulation
logsource:
  product: fortinet
  service: syslog
detection:
  selection:
    msg|contains:
      - 'config system admin'
      - 'config system api-user'
      - 'config system snmp community'
      - 'ssh-public-key'
      - 'certificate'
      - 'trusthost'
      - 'accprofile'
  condition: selection
falsepositives:
  - New administrator onboarding
  - Automation with approved change record
level: high

KQL — Microsoft Sentinel / Defender

let lookback = 14d;
union isfuzzy=true (CommonSecurityLog | where TimeGenerated > ago(lookback)), (Syslog | where TimeGenerated > ago(lookback))
| where Computer has_any ('fortimanager','fortigate') or DeviceVendor has 'Fortinet' or ProcessName has_any ('fortinet','fgt','fmgr')
| extend Raw = coalesce(Message, SyslogMessage, '')
| where Raw has_any ('FortiManager','config system admin','config system api-user','diagnose debug','diagnose sys','execute restore','config system snmp','ssh-public-key','certificate')
| summarize Events=count(), DistinctTargets=dcount(DestinationHostName), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Sample=any(Raw) by SourceHostName, SourceIP, DestinationDevice, DeviceAction, DeviceEventClassID
| where Events > 25 or DistinctTargets > 10
| order by DistinctTargets desc, Events desc;

VQL — Velociraptor

-- Hunt administrator endpoints and automation hosts for Fortinet management tooling and saved firewall material
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)fortimanager|fortigate|fortios|fgt-|fmgr|diagnose debug|execute restore|config system admin'
   OR Name =~ '(?i)putty|plink|pscp|winscp|filezilla|ssh|scp|curl|wget|python|powershell|ansible'

Bash / Shell

# Authorized use only. Run from a Linux bastion against management networks and log archives you own or are approved to assess.
MGMT_NET=${MGMT_NET:-10.50.0.0/24}
LOGDIR=${LOGDIR:-/var/log/fortinet}
OUT=${OUT:-./forti_peerstitch_audit_$(date +%Y%m%d_%H%M%S)}
mkdir -p $OUT

# 1) Identify exposed Fortinet management services: SSH 22, HTTPS 443, FortiManager 541, alternate HTTPS 8443.
nmap -Pn -sS -p 22,443,541,8443 --open $MGMT_NET -oG $OUT/forti_mgmt_exposure.gnmap
awk '/Ports:/ && /open/ {print $2, $4, $5, $6, $7}' $OUT/forti_mgmt_exposure.gnmap > $OUT/exposed_hosts.txt

# 2) Search forwarded firewall/syslog archives for management-plane and diagnostic indicators.
zgrep -REi 'FortiManager|config system admin|config system api-user|config system snmp|ssh-public-key|diagnose debug|diagnose sys|execute restore|execute sensor|fnsysctl|certificate|trusthost' $LOGDIR > $OUT/indicator_hits.txt 2>/dev/null

# 3) Summarize high-spread sources and concentrate review on one source touching many destinations.
awk '{for(i=1;i<=NF;i++){if($i ~ /src=/){split($i,a,=);src=a[2]}; if($i ~ /dst=/){split($i,b,=);dst=b[2]}} if(src!=""&&dst!=""){print src, dst}}' $OUT/indicator_hits.txt | sort | uniq -c | sort -nr > $OUT/source_target_spread.txt

# 4) Produce a quick triage bundle for IR.
tar -czf $OUT.tgz $OUT && echo Evidence bundle: $OUT.tgz

Remediation

Isolate and preserve: restrict FortiManager to a dedicated management VRF; deny inbound Internet access to admin/API/SSH/HTTPS/SNMP; capture volatile data before reboot; snapshot VMs only after preserving RAM where your process supports it.
Rotate everything reachable from the trust domain: FortiManager admins, FortiGate local admins, API users/tokens, automation accounts, SSH keys, SNMPv3 credentials, RADIUS/TACACS+ secrets, LDAP binds, SAML/OIDC secrets, certificates, and any credentials stored in scripts or backups.
Patch and verify through official channels: review Fortinet PSIRT at https://www.fortiguard.com/psirt, FortiManager and FortiOS release notes, and current CISA KEV. Because this source provides no CVE, do not claim a specific fixed build in client communications unless Fortinet confirms it.
Rebuild high-confidence compromised nodes: for suspected FortiManager, prefer clean rebuild from known-good media/config rather than in-place cleanup. For suspected FortiOS persistence, reboot under controlled conditions, upgrade firmware, verify integrity, compare config checksums, and consider factory reset/re-image if root-level persistence cannot be excluded.
Diff the fleet: export configurations, normalize them, and compare against the last approved baseline. Look for new admins, changed trusthosts, added API users, modified SNMP, new certificates, policy package installs outside tickets, HA changes, static routes, VPN portals, and remote logging tampering.
Harden the control plane: enforce phishing-resistant MFA for admin access, role-based profiles, per-admin accounts, no shared MSP accounts, trusthost ACLs, certificate-based API auth where possible, disabled unused services, secure SNMPv3 only, separate backup credentials, and immutable off-device logging.
Change-window analytics: alert when FortiManager or automation touches more devices than baseline, creates admin objects, runs diagnostic commands, installs policy packages, or disables log forwarding. Require ticket ID in change metadata where feasible.
Hunt beyond Fortinet: check admin jump hosts, CI/CD runners, backup repositories, password vault logs, IdP sign-ins, and EDR telemetry for the operator path into FortiManager.
Notify and coordinate: for MSPs, map downstream customer impact, preserve evidence per tenant, align disclosure obligations, and engage IR support early if firmware or memory integrity cannot be verified.

Practical 72-Hour Action Plan

Hour 0-4: block external management-plane access, inventory FortiManager/FortiGate estate, freeze changes, start evidence preservation.
Hour 4-24: run the hunts above, enumerate admins/API/tokens/keys, identify high-spread sources, and review all config revisions since the suspected intrusion window.
Hour 24-48: rotate credentials in dependency order, isolate or rebuild suspect FortiManager, patch after forensic capture, and validate firmware integrity on priority firewalls.
Hour 48-72: implement detections, restore clean configurations, document customer impact, and brief leadership on residual risk and reboot/re-image decisions.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub