FortiGate Firewalls Breached via FortiCloud SSO, Attackers Steal Full Configuration Files and Plant Rogue Admins

Opening

If your FortiGate management plane is reachable from the internet and FortiCloud SSO is enabled, assume you are in the blast radius of a campaign that is optimized for speed, persistence, and intelligence gathering. Incident responders have observed attackers logging in via SSO, exporting the entire firewall configuration, and creating new administrative users in a matter of seconds. That combination matters because a firewall configuration is not just "settings" but a blueprint of how your network is segmented, where remote access is permitted, and which identities and integrations are trusted. In practical terms, a stolen config can turn a one-time appliance compromise into a longer intrusion sequence that targets VPN access, privileged accounts, and internal routing decisions.

This is not a noisy smash-and-grab that immediately detonates ransomware. It is closer to an operator building a reusable foothold and collecting the kind of information that makes later attacks cheaper and more reliable. The uncertainty around the initial access path is what should push this issue to the top of your queue. When defenders cannot confidently map a campaign to a single patched CVE, the safest assumption is that multiple paths may be in play, including patch bypasses, incomplete fixes, or alternate abuse of exposed management workflows.

What happened: automated FortiGate intrusions and config theft

The activity was observed beginning January 15, 2026 and presents as a tightly sequenced chain of actions on the firewall itself. The pattern defenders are reporting is consistent: an SSO-based administrative login appears first, followed immediately by a configuration export, followed by administrative user creation intended to persist access. The timing is a key detail because it suggests automation rather than manual operator activity. When the same few events occur within seconds, across multiple devices, it usually indicates a scripted workflow designed to scale quickly against large populations of internet-reachable appliances.

From an operational security standpoint, the attacker behavior is also telling. Exporting the system configuration early is a high-value step because it lets the adversary "learn the environment" without deploying malware or probing internal services yet. Creating secondary admin accounts immediately afterwards is a classic persistence move: even if the initial access vector is closed later, a newly created privileged account may remain valid unless the organization performs explicit account review and credential rotation. In other words, patching alone can become a false finish line if your response process does not also validate local admin inventories, VPN user lists, and authentication logs.

The campaign also appears to reuse the same naming conventions and infrastructure across intrusions. Researchers have highlighted specific suspicious accounts and a small set of source IP addresses associated with the SSO logins and subsequent config downloads. That concentration is helpful for hunting and blocking, but it is not a guarantee of safety. Once tradecraft proves effective, it is common for other operators to copy the workflow, rotate infrastructure, and vary usernames. Defenders should treat the listed indicators as an initial filter, not the full definition of risk.

The likely entry point: FortiCloud SSO, SAML flows, and why "unknown" is the scary word

At the center of this activity is FortiCloud SSO, a feature that can allow administrative login to FortiGate devices via a Fortinet-controlled identity flow. In the observed intrusions, attackers are abusing SSO to authenticate and then operate through the management interface. The most important nuance is that the initial access details are not fully confirmed. That uncertainty has two implications: first, defenders cannot reliably determine whether a single patch level closes the door; second, organizations may be exposed even if they believe they followed standard patch guidance.

This campaign follows earlier warnings tied to critical authentication bypass issues in Fortinet's SSO implementations, where crafted SAML messages could be used to bypass expected authentication checks when FortiCloud SSO is enabled. In a clean world, defenders would patch, validate, and move on. The complication here is that multiple administrators have reported suspicious SSO logins even on systems they believe to be fully patched, and responders have stated they cannot yet confirm whether the current campaign is fully covered by the prior fixes. That is exactly the window attackers like: defenders split their attention between "is it fixed?" and "is it misconfiguration?", while the adversary uses speed to harvest configurations and establish persistence.

There is another operational twist that increases exposure in real environments. FortiCloud SSO may be disabled by default in factory settings, but it can become enabled during common administrative workflows, such as device registration with vendor support services through the GUI, unless a specific option is explicitly turned off. This is not a condemnation of any one team's competence. It is a reminder that default states do not always survive real production setups, and a feature that seems unused during deployment can become active months later during support registration or routine management changes. For risk management, this means your configuration baselines need to be continuously validated, not just checked once during rollout.

Why stolen firewall configs are so dangerous in the real world

Security teams often underestimate how much "secret material" accumulates in network appliance configurations over time. Even when passwords are hashed, the configuration can still be weaponized. A hash is not a neutral artifact; it is an offline cracking opportunity, and adversaries know that many organizations still tolerate weak password hygiene on infrastructure accounts. Beyond credentials, the config typically reveals network topology and intent: which subnets exist, what NAT rules expose internal services, which VPN portals are active, and which policies permit traffic between sensitive zones. That is reconnaissance with perfect fidelity, gathered without scanning your internal network.

The second-order effect is equally important. A stolen config helps attackers select the path of least resistance for follow-on access. If the configuration reveals that a management interface is reachable from specific external ranges, or that a VPN user group maps to privileged network segments, the attacker can tailor their next steps precisely. If the configuration shows where logging is forwarded, which SIEM collectors exist, and which authentication sources are in use, the adversary can also optimize evasion. In high-maturity environments, these details do not instantly cause compromise. But they materially reduce the time and cost for a capable attacker to design a reliable intrusion plan.

Finally, persistence created on the firewall itself is operationally painful because many organizations treat network appliances differently from endpoints. They may not have continuous EDR-like telemetry, and they may rely on periodic configuration reviews rather than continuous identity monitoring. An attacker that creates an extra admin user or adds VPN access for a new account can maintain access in plain sight if the organization does not routinely baseline local accounts and configuration changes. This is why the response playbook needs to include a "configuration integrity" phase, not just patching and IOC blocking.

Detection and threat hunting: what defenders should look for today

Effective hunting for this campaign starts with the management plane logs. The observed chain typically includes an administrative login via SSO, followed by a configuration file export via the GUI, followed by creation of one or more additional administrative accounts. The sequence matters as much as any single event. An SSO login is not automatically malicious, and a configuration export might be legitimate during troubleshooting, but a rapid cluster of these events in seconds is a strong signal for automation.

From a practical SOC workflow perspective, the best initial filter is to identify administrative logins that explicitly indicate an SSO method and correlate them with subsequent "download" events for system configuration. From there, pivot to audit trails that show new admin objects being added, privilege profiles assigned, or VPN access toggled for newly created accounts. Even if you cannot match the exact suspicious usernames seen in public reporting, the behavioral chain remains a strong detection strategy because it models what the attacker needs to do: obtain admin-level control, export intelligence, then retain access.

You should also treat this as an opportunity to validate your exposure assumptions. Confirm which FortiGate devices have internet-reachable management interfaces and from where. Confirm whether FortiCloud SSO administrative login is enabled anywhere, including devices that were registered for support long after deployment. Review admin user inventories for generic names that were not part of your provisioning standards, and validate whether any accounts were created recently without a change ticket. Because the initial access method is still uncertain, your detection posture should not assume that one patch line or one mitigation fully closes the risk until Fortinet provides definitive guidance and you have verified it in your environment.

How to respond: containment, hardening, and credential hygiene that survives the "unknown"

The immediate containment step recommended by responders is to disable FortiCloud SSO administrative login if it is enabled in your environment, at least until the vendor publishes clear remediation that definitively addresses the observed abuse. This is a defensive tradeoff. Disabling SSO may impact administrative convenience, but it reduces exposure to a class of attacks that is currently being actively leveraged for unauthorized access and configuration theft. If you cannot disable it globally due to operational constraints, prioritize doing so on any device where the management interface is reachable from untrusted networks.

Patching still matters, but it must be paired with post-compromise hygiene. If your firewall configuration has likely been exfiltrated, assume that any credentials stored or represented in that config are now at elevated risk, including hashed credentials that might be cracked offline. That means rotating administrative passwords, reviewing API keys or integration credentials if present, and validating VPN user access and group membership. It also means checking for newly created admin accounts and removing them, and then verifying that no additional persistence mechanisms were established through configuration changes. Treat the firewall as an identity-bearing system, not just a packet filter.

Longer-term hardening should focus on reducing attack surface and increasing configuration integrity. Restrict management access to trusted internal networks or controlled jump hosts. Enforce strong authentication for administrative access, including MFA where supported, and ensure administrative workflows are logged centrally and monitored for anomalies. Implement configuration change monitoring with clear alerting when admin accounts are created, privilege levels are modified, or configuration exports occur. The goal is not only to block the current indicators, but to build a control plane that makes future automation visible and expensive for attackers.

Closing

FortiGate devices sit at a uniquely sensitive junction: they mediate trust boundaries, remote access, and network segmentation decisions, so a fast compromise of the management plane can cascade into broader exposure even without malware deployment. The current campaign is a reminder that identity features on appliances can become the weakest link when they are internet reachable and not continuously monitored. Until Fortinet provides definitive clarity on the initial access path and confirms durable fixes, the safest defensive posture is to disable FortiCloud SSO admin login where possible, aggressively hunt for SSO-driven config exports and unexpected admin creation, and rotate credentials with the assumption that exported configurations are intelligence gold for attackers. Organizations that treat firewall configurations as protected assets, not routine artifacts, will be best positioned to reduce both immediate risk and the likelihood of follow-on intrusions.