Why a Firewall Manager Compromise Exposes Every Device

A firewall manager compromise exposes every device it manages because the manager holds each firewall's full configuration, its administrator and VPN credentials, its certificates and private keys, and a trusted channel to push changes. An attacker who controls the manager can read all of that and act on every firewall at once. Patching the manager closes the entry point, but stolen secrets stay valid until you rotate them.

Why does a firewall manager compromise reach every device?

Central managers exist to hold the master copy of every firewall's configuration and to push changes without logging in to each box. That convenience means whoever controls the manager inherits the same reach.

In the intrusion behind FortiOS CVE-2025-61624 and the PEERSTITCH implant, Unit 42 found that attackers exploited the FortiManager flaw CVE-2024-47575, registered a rogue virtual FortiGate, and pulled an archive covering more than 500 managed firewalls. The archive held running configurations, topology, encrypted administrator and SSL VPN credentials, and certificates with private keys. Unit 42 says the credentials could be recovered by brute force.

What does a firewall manager store?

A firewall manager stores everything needed to rebuild or control each managed device. The exact contents vary by vendor, but expect most of the following:

• Full running configurations for every device, including policies, routes, NAT rules and interface settings.
• Administrator credentials, often encrypted with keys the attacker can attack offline once they have the file.
• VPN secrets: pre-shared keys, local VPN user accounts and group definitions.
• Directory and authentication bind accounts used for LDAP or RADIUS lookups.
• Certificates and private keys for SSL inspection, VPN portals and device identity.
• An asset inventory with serial numbers, public IP addresses and site names.
• Trust relationships that let the manager log in to or push to devices without further authentication.

For an MSP, that list covers every client network the MSP manages.

What can an attacker do with that data?

With configurations and credentials in hand, the attacker no longer needs a vulnerability on each firewall. They can log in as a legitimate admin or VPN user, read policies to plan lateral movement, and push changes that look like normal management activity.

Unit 42 described all of these in the PEERSTITCH case. The actor logged in to downstream firewalls over SSL VPN with recovered credentials, pushed packet-capture rules aimed at unencrypted protocols, and impersonated the manager to pull configurations from other firewalls. They then used a Medium-rated CLI bug to move from admin to root and install a memory-only implant, a technique covered in what memory-resident malware on a network appliance is.

Why doesn't patching the manager end the incident?

Patching removes the way in, but it does nothing about what was already taken. Stolen credentials, keys and certificates keep working until they are changed, and any accounts or scripts planted on managed devices keep running.

Unit 42 made the same point: trust material taken from a management platform remains valid until it is rotated. The pattern is the same one we described for VPN gateways in why patching your VPN gateway does not evict the attacker already inside.

How should you plan the response?

Treat a manager compromise as a fleet-wide incident from the first hour. A workable order:

1. Contain the manager. Cut its internet exposure, preserve its logs and disk for investigation, and stop it pushing changes until you trust it.
2. Rebuild or restore the manager from known-good media and a configuration backup taken before the earliest suspected access.
3. Audit every managed device. Look for unknown admin accounts, VPN groups, automation scripts, packet-capture rules and log setting changes. Check configuration history for objects that were created and deleted. Look for unexplained silences, as described in how to detect firewall logging gaps.
4. Rotate secrets after devices are trusted: admin passwords, VPN pre-shared keys and local VPN users, LDAP and RADIUS bind accounts, API tokens, and every certificate and private key the manager held. Rotating on a device that still carries an implant hands the attacker the new secrets.
5. Revoke and reissue certificates rather than only replacing them, so stolen copies fail validation.
6. Notify downstream customers if you are an MSP. Their networks were in the same archive.

How do you reduce the blast radius before it happens?

You can keep the convenience of central management while limiting what one compromise yields:

• Keep the manager off the internet. Restrict its management and device-registration ports to the networks that need them, and put admin access behind a jump host.
• Split large fleets. Separate managers or administrative domains per client or region mean one breach does not expose everything.
• Use unique secrets per device. Shared admin passwords or VPN keys across sites turn one recovered secret into hundreds of logins.
• Prefer short-lived and centrally revocable credentials, such as certificates from your own CA with short lifetimes, over static keys that live in configuration files.
• Back up configurations to a separate system and diff them on a schedule, so unauthorized changes are visible even if the manager's own logs are wiped.
• Patch the manager first. It is a tier-0 system and belongs at the front of your patch queue, with the same urgency as your domain controllers.

A firewall manager is a single place that knows every secret your perimeter holds. Plan, protect and monitor it on that basis.