FortiGate attacks are giving intruders a fast path into enterprise networks

Threat actors are exploiting FortiGate firewalls in a fresh wave of intrusions that let them break into enterprise networks, steal service account credentials, and move deeper into internal systems. SentinelOne says its DFIR team investigated multiple cases in early 2026 where attackers compromised FortiGate Next-Generation Firewalls, then used the devices as a foothold for lateral movement.

The pattern matters because the firewall was not just the entry point. In both incidents described by SentinelOne, attackers used access to the FortiGate appliance to export configuration files, recover embedded credentials, and pivot into Active Directory and other internal systems. SentinelOne says each intrusion was stopped during the lateral movement stage, before the attackers fully reached their end goals.

The activity lines up with several recently disclosed Fortinet flaws. SentinelOne tied the wave to CVE-2025-59718, CVE-2025-59719, and CVE-2026-24858, while Fortinet has separately confirmed active exploitation involving FortiCloud SSO-related authentication bypass issues. CISA also issued guidance on the ongoing exploitation and added CVE-2026-24858 to its Known Exploited Vulnerabilities catalog.

What attackers are doing after they get in

SentinelOne says a compromised FortiGate device can expose far more than perimeter access. Once inside, the attacker can run show full-configuration to export the full appliance config, which often contains encrypted LDAP or Active Directory service account credentials and useful network topology information. Because FortiOS uses reversible encryption for these config files, the credentials can be recovered and reused.

That gives the attacker a shortcut into the internal network. Instead of spending time hunting for domain credentials elsewhere, they can pull them directly from the device meant to protect the edge. This is why FortiGate compromise can quickly turn into an identity and lateral movement problem, not just a firewall problem.

SentinelOne also says not every actor used a sophisticated exploit chain. Some intrusions may have involved known vulnerabilities, while others likely relied on weak credentials on exposed FortiGate instances. That lowers the technical barrier and broadens the pool of attackers who can try the same playbook.

The Fortinet flaws linked to the attack wave

CVE	What it does	Public status
CVE-2025-59718	SAML/FortiCloud SSO bypass path that can allow unauthorized admin access on affected devices	Fortinet disclosed and patched; active exploitation discussed publicly
CVE-2025-59719	Related SSO cryptographic verification issue affecting similar products and flows	Fortinet disclosed and patched
CVE-2026-24858	FortiCloud SSO authentication bypass that can let attackers log into victim devices using their own FortiCloud account	Fortinet confirmed in-the-wild abuse; CISA issued alert and KEV action

Source: SentinelOne, Fortinet, and CISA.

Fortinet says CVE-2026-24858 affected devices with FortiCloud SSO enabled and that the feature is not enabled by default at factory settings. The company temporarily disabled FortiCloud SSO on January 26, 2026, then restored it on January 27 in a way that blocked vulnerable devices from using the feature until they upgraded.

Incident 1: rogue domain workstations and password spraying

In the first case described by SentinelOne, the compromise likely started in late November 2025 and stayed undetected until February 2026. After gaining access to the appliance, the actor created a local FortiGate admin account named support and added four permissive firewall rules that allowed traffic across all zones. SentinelOne says that low-volume activity followed for weeks, which fits the pattern of an initial access broker maintaining foothold access before handing it off or using it later.

In February, the attacker appears to have extracted and decrypted the config file, then authenticated to Active Directory with the fortidcagent service account from IP address 193.24.211[.]61. The actor then abused mS-DS-MachineAccountQuota to join two rogue systems, WIN-X8WRBOSK0OF and WIN-YRSXLEONJY2, to the victim domain. SentinelOne says network scanning and password spraying later triggered alerts and stopped the intrusion before it moved further.

Incident 2: RMM tools, hidden persistence, and NTDS theft

In the second incident, SentinelOne says the attacker created a FortiGate local admin account named ssl-admin and within about 10 minutes began logging into internal servers with built-in Domain Administrator credentials likely recovered from the exported FortiGate config. The actor staged tools in C:\ProgramData\USOShared, then deployed Pulseway and MeshAgent from attacker-controlled Google Cloud Storage and AWS S3 locations.

SentinelOne says the attacker hid MeshAgent by setting SystemComponent=1 in the Windows Registry, then used DLL side-loading with Java-named DLLs to beacon to attacker-controlled domains. The actor later created a Volume Shadow Copy of the primary domain controller, extracted NTDS.dit and the SYSTEM hive with makecab, and exfiltrated the compressed files. That is a serious escalation because NTDS.dit can expose domain credential material if the attacker gets the files out successfully.

Why this campaign stands out

These cases show why a compromised edge appliance is so dangerous. A FortiGate firewall often sits close to identity systems, VPN workflows, and privileged admin paths. Once the attacker turns that device into a backdoor, the rest of the network becomes much easier to map and abuse. That conclusion follows directly from SentinelOne’s description of the config exports, service account theft, and domain pivoting.

The report also highlights a defensive blind spot. SentinelOne says insufficient FortiGate log retention made it hard to determine the precise initial access vector in these incidents. If organizations do not keep enough firewall logs, they may discover the intrusion only after the attacker has already reached Active Directory or deployed persistence inside the network.

What defenders should do now

• Apply Fortinet patches for CVE-2025-59718, CVE-2025-59719, and CVE-2026-24858 immediately.
• Review FortiGate admin accounts for suspicious names such as support, ssl-admin, helpdesk, backup, secadmin, or similar unexpected entries. Fortinet and SentinelOne both call this out as a useful detection step.
• Search FortiGate logs for successful SSO admin logins and config downloads, especially Log ID 0100032001 and 0100032095. SentinelOne and Fortinet both reference these as strong indicators.
• Rotate LDAP, AD, and other service account credentials tied to the FortiGate appliance after any suspected compromise.
• Increase FortiGate log retention to at least 14 days, with 60 to 90 days preferred, and forward logs into a SIEM.
• Audit mS-DS-MachineAccountQuota so ordinary accounts cannot quietly join rogue workstations to the domain.
• Monitor adjacent servers with EDR because the appliance itself cannot host standard endpoint tools.

Key signs of compromise

Indicator type	Examples reported
Suspicious FortiGate admin accounts	support, ssl-admin, audit, backup, secadmin
Suspicious SSO user accounts	[email protected], [email protected], and others listed by Fortinet
Suspicious behavior	Config file download, new permissive firewall rules, rogue domain joins, password spraying
Follow-on tooling	Pulseway, MeshAgent, PsExec, SoftPerfect Network Scanner
Suspicious infrastructure	FortiCloud SSO abuse, cloud-hosted RMM delivery, exfiltration after NTDS collection

Source: SentinelOne and Fortinet.

FAQ