FortiManager CVE-2024-47575 and the PEERSTITCH FortiGate Implant: Testing Edge Exposure and Proving Impact

TL;DR

CVE-2024-47575 is a missing-authentication flaw in FortiManager's FGFM daemon that let attackers register rogue FortiGate devices and pull managed configuration files, credentials included. Unit 42's PEERSTITCH research shows the follow-on: a memory-resident ARM64 implant on more than 500 FortiGate firewalls, with nothing written to disk for a file-based scan to find. Patching FortiManager closes one door; it neither evicts an implant from firewall memory nor invalidates credentials that were already stolen. Test the FGFM path for reachability, diff the FortiManager device inventory against your asset list, and check the firewalls for processes and sockets you cannot explain. The proof of impact is an unknown device registration plus a live process on a firewall — not an open port.

What this is

CVE-2024-47575 is a missing-authentication flaw in the FortiManager fgfmd daemon, the service behind the FortiGate-to-FortiManager management protocol (FGFM) on TCP 541. An attacker who could reach that port could register a device FortiManager did not know about, and from there retrieve configuration data belonging to managed devices.

PEERSTITCH is the firewall-side payload Unit 42 documented on top of that access: ARM64 code that runs in FortiGate memory instead of from the filesystem. No dropped binary to hash, no file path to sweep, no on-disk persistence to find during triage.

Treat these as two findings. The manager-side flaw is an access-control failure you patch. The firewall-side implant is live adversary presence you hunt and evict.

Why it matters

• Anyone running FortiManager is in the blast radius, and so is every firewall that manager touches.
• The configuration files FortiManager holds are not inert. They carry admin credential material, pre-shared keys, LDAP and RADIUS bind accounts, API tokens, and the tunnel data that lets a device be re-onboarded. One successful config pull is a fleet-wide credential exposure.
• Unit 42's intrusion covered more than 500 firewalls. Assume that scale if your FGFM path was ever reachable from an untrusted network.
• The failure mode is quiet: patch, close the port, declare victory, and leave the attacker's credentials and in-memory tooling in place.

How it works

Three stages, each one testable.

1. Initial access at the manager. fgfmd processes FGFM registration traffic. Without authentication enforced on that path, a manager will accept a device presented by an attacker. Fortinet's advisory FG-IR-24-423 is the authoritative source for the affected build matrix and the fixed release for your branch — check it against the device, not against a summary someone forwarded.
2. Configuration collection. A registered device has a two-way data path. Attackers used it to retrieve stored configuration files from managed FortiGates, which contain secrets in reusable form. This is where a FortiManager problem becomes a credential problem.
3. Firewall-side deployment. With those credentials the attacker logs into a FortiGate directly and stages PEERSTITCH in memory.

Validation — run only against infrastructure you are authorized to test — answers three questions with evidence: can anything outside my management network reach TCP 541? Does this build predate the fixed release for its branch? Does the device inventory hold serials my asset database cannot name? A yes to any of those is a hypothesis, not a conclusion.

Detection and response

Collect on both sides of the FGFM relationship.

On FortiManager:

• The managed-device list and the unknown/unregistered-device view, diffed against your asset inventory. An unmatched serial is the highest-value indicator in this incident.
• fgfmd debug output (diagnose debug application fgfmd -1) during a registration window, showing which source IPs attempt to peer.
• Administrative audit logs and the source IPs of FGFM connections.
• Which interfaces and networks can reach TCP 541 on each manager.

On each FortiGate:

• Build version via get system status, compared to the advisory matrix.
• Running processes and open sockets. A memory-resident implant shows up here and nowhere else.
• Outbound connections from management interfaces to destinations the firewall has no reason to contact.
• Admin logins from new source IPs using existing credentials — the fingerprint of credential reuse after a config pull.

Retention caveat. FGFM events roll out of local buffers quickly. If forwarding is not configured, the registration evidence may already be gone.

What to do

1. Scope the FGFM attack surface. Scan authorized IP ranges for TCP 541 and record every FortiManager that answers and on which interface. Assume management-plane exposure until proven otherwise.
2. Verify the build against FG-IR-24-423. Not "are we on the latest branch" but "is this device on or above the fixed release for its branch." Check the CVE against the KEV catalog at the same time.
3. Reconcile the device inventory. Export the device list and the unknown-device list, diff serials against your asset records, and open a ticket for every unmatched entry.
4. Read the FGFM and admin logs. Look for registration attempts from outside your management ranges and for firewall admin logins from addresses your team does not use.
5. Inspect the firewalls for in-memory tooling. List processes and sockets against the expected FortiOS set. If you need evidence, capture memory before rebooting — a reboot removes the implant and the proof it was there.
6. Rotate everything the configuration exposed. FortiGate admin credentials, IPsec/IKE pre-shared keys, LDAP and RADIUS bind accounts, API tokens, SNMP communities, and tunnel credentials. Rotation is a precondition for eviction.
7. Constrain FGFM. Use a local-in policy or an upstream ACL so only known management networks reach TCP 541, alongside Fortinet's documented workarounds in the advisory.
8. Retest and keep the artifacts. Re-scan the port, re-export the device list, and attach before/after to the finding. A closed port on a rescan is not evidence the implant is gone.

Where this fits in a program

An open management port is a signal. A serial in the device list you cannot name, a config pull with a timestamp, and a live socket on a firewall are findings — artifacts a second person can verify. Exposure programs live or die on that distinction, because queues fill with signals and decisions get made on findings. Trusteed keeps attack surface, investigation, and evidence validation as separate steps, so a scanner hit does not ship as an alarm.

FAQ

Does patching FortiManager remove PEERSTITCH from my firewalls? No. The patch closes the manager-side flaw. The implant lives in FortiGate memory, and credentials taken from stolen configurations stay valid until rotated. Patch, rotate, then hunt.

Is CVE-2024-47575 still worth testing? Yes. Unpatched FortiManager builds remain in service, and exfiltrated credential material does not expire on its own. Until you can show both a patch record and a rotation record, the finding is open.

How do I know a rogue FortiGate registered? The managed-device list, the unknown-device view, and FGFM logs showing a source IP outside your management networks. The strongest artifact is a serial you cannot match to an asset record.

Will a file or endpoint scan find the implant? No. It is memory-resident, so file-based IOC sweeps come back clean. Detection depends on process and socket inspection on the firewall plus network telemetry.

Can I just reboot the firewalls? A reboot clears memory-resident code and interrupts the implant, but it also destroys the evidence and does nothing about the stolen credentials. Capture memory, rotate, then reboot as controlled recovery.

Sources

• Unit 42, "Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant" — https://unit42.paloaltonetworks.com/fortimanager-cve-2024-47575-peerstitch-malware/
• Fortinet PSIRT advisory FG-IR-24-423 (CVE-2024-47575) — https://www.fortiguard.com/psirt/FG-IR-24-423
• NVD, CVE-2024-47575 — https://nvd.nist.gov/vuln/detail/CVE-2024-47575
• CISA Known Exploited Vulnerabilities catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Trusteed vulnerability intelligence — https://trusteed.io