The disk looked clean. The management GUI still answered. Policies still loaded. Nothing on disk looked like malware. Unit 42 investigators had a compromised FortiGate on the table, and the dropped-binary hunt returned nothing you’d put in a ticket. Then they dumped ARM64 memory and found PEERSTITCH, a stealthy implant that never wrote itself to storage. Attackers had reached those boxes through CVE-2024-47575 on FortiManager, and the campaign landed on more than 500 firewalls. If your cybersecurity program still treats the edge appliance as a trusted sensor, you just inherited a fleet problem filesystem forensics will not see.

They Put the Implant Where Reboots Look Helpful

PEERSTITCH lives in RAM. That choice punishes every incident response playbook that starts with imaging the disk and grepping for hashes. You can snapshot firmware, hash partitions, and still miss the process stitching sessions through the box you bought for threat-protection. Disk integrity checks pass. The implant keeps working.

A reboot kills a memory-resident payload. It also destroys the only copy you had. Teams that recover a FortiGate by power-cycling it often watch command-and-control stop and close the ticket. They never captured the sample, never mapped the FortiManager path, and never asked how many other managed firewalls took the same push. You’ll hear that memory-only malware is less persistent. Persistence on 500 managed firewalls is the management plane. PEERSTITCH can die in RAM and return on the next push if FortiManager still belongs to someone else. Five hundred devices is a fleet incident. Treat it like one.

CVE-2024-47575 is the missing-authentication hole on FortiManager’s FGFM channel. Once an attacker talks to the controller like a valid peer, pushing an implant into managed FortiGates is an operations task. Your threat detection stack that watches north-south HTTP will classify a management-plane push as vendor protocol doing vendor things. That’s the point of hiding in the appliance. The sensor is the host.

The Mail Filter Wrote Files as Root

Same week, same architectural miss, different badge on the rack. Cisco said attackers are already exploiting a critical flaw in Secure Email Gateway. A sender with no login ships a crafted attachment through the appliance that exists to strip spam and malware. If the parser cooperates, they write files to the operating system and run commands as root.

The box that opens every attachment on behalf of the company can be convinced to open one for itself. Users never clicked. MFA never fired. Root still happened on the filter. Most mail architectures treat that gateway as an inspection layer. In production it’s a Unix host with a privileged parser facing unauthenticated internet mail.

Start with a span or tap in front of the appliance, then compare that traffic to what the box reported. A root-capable parser can rewrite what it claims to have seen. Treat mismatches as the incident. Stop inventorying security tools as if they sit outside the attack surface. A FortiGate hosting PEERSTITCH and a Cisco gateway writing as root are the same miss: you deployed a high-privilege, internet-facing interpreter and then staffed monitoring around the endpoints behind it. Cyber security budgets love the label on the bezel. Attackers love the parser.

Treat Every Cybersecurity Appliance Like an Untrusted Host

Monday morning, put FortiManager and every firewall it manages in scope for CVE-2024-47575. Pull the management plane onto a dedicated network that does not route from the internet, from user VLANs, or from the mail DMZ. Capture RAM before you reboot a suspected FortiGate. If the vendor gives you crash dumps, process lists, listening sockets, and FGFM peer tables, take all of them, then image the disk anyway. You want both, because PEERSTITCH already showed you which layer lies.

On the mail side, treat Cisco’s advisory as an emergency change. Patch the gateway, then hunt its own filesystem for unexpected files, new SUID binaries, modified startup scripts, and outbound connections that are not the vendor update channel. Rebuild from known-good firmware if the hunt is messy. A box that had unauthenticated root is a replacement, even if the vendor dashboard still shows green.

Lock admin paths to a jump host with MFA. Disable unused services. If you still expose SSH or HTTPS on these devices, you’ll soak brute-force attempts until someone gets lucky. Host-level ipban on the jump box is a useful backstop; IPBan Pro covers Windows jump hosts if that’s what you already run. Keep the management plane isolated either way.

Keep doing the dull work. Inventory appliances like servers: owner, firmware, config hash, last process baseline, management-plane peers. Alert on new FGFM or admin peers, config pushes outside a change window, and appliance-originated DNS or HTTP that is not the update CDN. Store configs on a system the live box cannot rewrite. Write an incident response runbook that names who pulls RAM, who calls the vendor, who revokes tunnels, and who rebuilds. Security hardening here means rebuilding from known-good firmware and a stored config you collected before the incident.

Defense in depth means a second mail path and a second network path that do not die with the compromised box. One gateway with root is a company-wide mail incident. One FortiManager with a hostile peer is every firewall you thought was watching.

Sources

• Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant
• Cisco Warns of Active Attacks Exploiting New Critical Secure Email Gateway Vulnerability