After a Firewall Breach, Assume Every Stored Credential Is Compromised
A firewall stores VPN keys, SSL-VPN logins, LDAP binds, and wireless secrets. After a compromise, treat all of them as burned and rotate on a plan.
When a firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. or VPN appliance is compromised, the instinct is to patch it, reboot it, and move on. That instinct is wrong, and the PivotC2 campaign against Fortinet's CVE-2025-25249 shows why. The malware's entire purpose was to read the device's configuration and decrypt every secret stored inside it. By the time you notice the intrusion, the attacker already holds the keys. Recovery is not about cleaning one box; it is about rotating everything that box knew.
What a Firewall Actually Stores
A modern edge appliance is a vault of reusable credentials. Walk through what a typical FortiGate configuration holds, all of it exploited in this campaign:
- **IPsec VPN pre-shared keys**, which authenticate site-to-site tunnels to partners and branches.
- **SSL-VPN user credentials and session material** for remote workforce access.
- **LDAP or Active Directory bind accounts** the firewall uses to authenticate users, often with standing read access to the directory.
- **Wireless pre-shared keys** for corporate and guest networks.
- **Local administrator accounts**, including any shared between devices.
These are stored encrypted, but the encryptionEncryption🛡️The process of converting data into a coded format that can only be read with the correct decryption key. protects against a stolen backup file, not against code running on the device. PivotC2 decrypted them in place using a hardcoded key and a device-specific key it read from the appliance's own filesystem. Once the implant ran as the daemon, the encryption bought nothing.
Why Rotation Beats Cleanup
The credentials on a firewall are dangerous precisely because they are shared and reused. A bind account is trusted by the directory. A pre-shared key is trusted by the peer on the other end of the tunnel. Rotating the firewall's own admin password does nothing to those relationships. If the attacker exported an LDAP bind credential, they can query or authenticate against your directory from anywhere, and no amount of firewall patching closes that door.
This is the blast-radius mindset applied to secrets. The question is not "is the firewall clean now" but "what did the firewall's stored credentials let an attacker reach." In the two confirmed intrusions SOCRadar documented, the answer was: the internal network, remote desktop, browser-stored passwords, and Exchange mailbox data. The appliance was the pivot, not the prize. The same logic drives Why a Compromised Firewall Manager Exposes Your Entire Network, which extends it from one firewall to the console that manages many.
Build the Rotation Plan Before You Need It
Credential rotation under incident pressure goes badly if you improvise it, because rotating a pre-shared key or a bind account can break production. Plan it in advance.
**Inventory the secrets each appliance holds.** Maintain a list of every credential class stored on each device and, for each, the systems and peers that trust it. This is the map you will follow at 2 a.m.
**Define rotation order and coordination.** Some secrets you can rotate unilaterally. Others, like site-to-site pre-shared keys, require the peer to change at the same moment or the tunnel drops. Know which partner contact to call and how long it takes.
**Stage the mechanics.** Pre-write the procedures to reset local admin accounts, reissue SSL-VPN credentials, force a directory password reset for any exposed bind account, and rotate wireless keys with the least disruptive rollout you can manage.
**Decide your device-recovery stance.** A confirmed-compromised appliance should be rebuilt from clean firmwareFirmware🏠Permanent software programmed into a device's hardware that controls its basic functions. and a known-good configuration, not merely patched, because implants can persist across a reboot. The rebuild workflow itself is covered in How to Rebuild a Compromised VPN Appliance.
Tie It to Detection
Rotation is triggered by a finding, so it depends on knowing you were hit. Keep the appliance's own indicators handy: for this campaign, sessions to the C2 addresses SOCRadar published and the on-device stager file were the tells. But because attackers on these devices favor the built-in tools, plan to hunt for behavior, not just known bad addresses, as described in How a Heap OverflowHeap Overflow🛡️A memory-corruption bug where a program writes more data into a heap allocation than it was sized to hold, spilling into adjacent memory. When the overwritten neighbor is the allocator's own bookkeeping, an attacker can steer it toward code execution. in a Network Daemon Becomes Code Execution and in the broader detection guidance for security appliances.
The uncomfortable rule is simple. If an internet-facing appliance was vulnerable and reachable during an exploitation window, and it stored credentials, treat those credentials as compromised even without proof of exfiltration. Rotating secrets you did not strictly need to is cheap. Leaving a live bind account or a known pre-shared key in an attacker's hands is how a firewall incident becomes a domain incident.