FortiManager breach exposed 500+ firewall configurations

Unit 42’s October 14 investigation describes an intrusion at a telecommunications managed service provider that began in September 2024. The attackers first exploited CVE-2024-47575 against one centralized FortiManager. From that appliance, they stole an archive with running configurations and databases for more than 500 managed FortiGate firewalls, along with inventories, network maps, credentials, certificates and private keys. (Unit 42 investigation)

The number describes firewalls whose data was in the archive, not 500 confirmed intrusions. Unit 42 investigated the provider’s environment but did not examine client networks. Its report confirms exposure of client firewall configurations and trust material; it does not establish compromise of every client network.

From stolen configurations to unauthorized access

The configurations contained encrypted administrative and SSL VPN passwords that the attackers were able to recover. Unit 42 says they used legitimate credentials to establish unauthorized SSL VPN sessions to perimeter firewalls and pushed packet-capture rules to multiple downstream FortiGate devices. The rules targeted unencrypted traffic and selected services, including authentication and directory traffic.

That makes the FortiManager compromise a management-plane incident with consequences beyond the appliance itself. Configuration files can contain the relationships, credentials and cryptographic material used to manage downstream devices. A successful patch of the manager does not revoke material already copied from it.

The two vulnerabilities belong to different stages

CVE-2024-47575 was the initial access flaw in this investigation. Fortinet describes it as an unauthenticated command-execution vulnerability in FortiManager’s FMG-Access management channel on TCP port 541. Unit 42 does not identify the version running on the compromised appliance.

For affected on-premises branches, Fortinet’s CVE record lists fixes in FortiManager 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15 and 6.2.13 or later, respectively. The affected FortiManager Cloud branches are fixed in 7.6.2, 7.4.5, 7.2.8 and 7.0.13 or later. Confirm the correct upgrade for the installed product and branch in Fortinet’s advisory.

Later in the intrusion, the attackers used a separate flaw, CVE-2025-61624, in FortiOS’s system.auto-script path handling. Fortinet says an authenticated administrator with at least read-write permissions could exploit the path traversal to write or delete arbitrary files. Unit 42 reports that the attackers used it to escalate from FortiOS administrative access to root and deploy PEERSTITCH. The report does not date this later exploitation, so it should not be collapsed into the September 2024 initial-access event.

Fortinet lists FortiOS 7.6.5, 7.4.10 and the forthcoming 8.0.0 line as fixed targets for CVE-2025-61624. Its current CVE record gives no fixed target for the affected 7.2, 7.0 and 6.4 branches; administrators on those lines should follow the current Fortinet advisory for supported upgrade guidance. The record rates the flaw CVSS 5.4, Medium.

CISA added CVE-2025-61624 to its Known Exploited Vulnerabilities catalog on October 16 and set an October 19 due date for agencies covered by Binding Operational Directive 26-04. That federal deadline does not create a general private-sector legal requirement. The catalog also calls for forensic triage; see the CISA KEV entry and the directive.

PEERSTITCH hides inside trusted processes

Unit 42 describes PEERSTITCH as an ARM64 implant that injects code into FortiOS’s miglogd logging daemon and iked VPN daemon. The implant leaves no persistent binary, opens no listening port and starts no independent outbound connection. Its hooks inspect traffic handled by those legitimate processes and share data through process memory. Those traits make an ordinary file scan or port check insufficient to rule it out.

The report separately describes attackers abusing Apache’s mod_md certificate-renewal module to establish a reverse shell. That is another part of the intrusion, not PEERSTITCH’s own network behavior.

What to review after a suspected compromise

Patch the vulnerable FortiManager and FortiOS branches using current vendor guidance, then treat credentials and trust material in any stolen configuration archive as exposed. Rotate affected administrator and VPN credentials, revoke and replace exposed certificates and private keys, and verify management trust relationships. Review configuration revisions for unexpected packet-capture rules, unauthorized VPN sessions and system.auto-script objects with path-traversal names. Preserve available logs and crash records; Unit 42 says the attackers stopped logging processes and cleared crash logs. Its report also gives memory-hunting guidance for the miglogd and iked processes.

The incident shows why response must cover both the central management system and the fleet it administers. Restoring the manager alone does not invalidate copies of the secrets and trust relationships that left it.