FortiGate Under Fire: How Attackers Compromise Firewalls and Take Over Entire Networks

Since late 2024, one of the most aggressive attack campaigns against perimeter infrastructure that the security industry has ever seen has been underway. At the center: FortiGate next-generation firewalls from Fortinet. Within 15 months, at least five critical vulnerabilities were actively exploited, over 600 devices in 55 countries were compromised, and attackers developed techniques that maintain access even after patching. This article reconstructs the timeline, analyzes the attack chain in detail, and shows what lessons organizations should draw from it.

The Timeline: 15 Months of Escalating Attacks

The Attack Chain in Detail: From Firewall Exploit to Domain Takeover

A DFIR report published by SentinelOne in March 2026 documents two real incidents that show the full scope of the threat. The attack chain follows a clear pattern:

Phase 1: Initial access and persistence

The attackers exploit one of the vulnerabilities listed above to gain unauthenticated super-admin privileges on the FortiGate. They then create local admin accounts with inconspicuous names such as support, ssl-admin, audit or backup. In addition, new firewall policies are created that permit unrestricted traffic between all zones, effectively disabling the firewall.

Phase 2: Credential theft, the key problem

This is the most critical point in the entire chain: FortiOS stores credentials in configuration files using reversible encryption. The attackers export the configuration via the show full-configuration command and decrypt the LDAP service account credentials contained in it.

In the documented cases, the fortidcagent account was specifically compromised, a service account used for the integration between FortiGate and Active Directory that typically holds broad AD read privileges.

Phase 3: Active Directory takeover

With the decrypted credentials, the attackers authenticate against Active Directory. In the first documented incident, they abused the AD attribute mS-DS-MachineAccountQuota to join their own workstations to the domain. The rogue workstations carried generic names such as WIN-X8WRBOSK0OF.

In the second incident it went even faster: only 10 minutes after creating the backdoor account on the firewall, the attackers already had domain administrator privileges.

Phase 4: Remote access tools and malware

For persistent access independent of the firewall, the attackers deployed two legitimate remote management tools:

• arrow_rightPulseway - hosted on Google Cloud Storage (storage.googleapis[.]com/apply-main/)
• arrow_rightMeshAgent - hidden via the registry key SystemComponent=1 so it does not appear in the software list

In addition, a Java-based malware using DLL sideloading was deployed, distributed via AWS S3 and establishing beacon connections to the C2 domains ndibstersoft[.]com and neremedysoft[.]com.

Phase 5: NTDS.dit exfiltration, game over

The ultimate goal: the NTDS.dit database of the primary domain controller. This file contains all password hashes of every domain user. The attackers:

1. Created a Volume Shadow Copy via WMIC
2. Extracted NTDS.dit and the SYSTEM registry hive
3. Compressed the files with makecab
4. Exfiltrated them over port 443 to 172.67.196[.]232 (8 minutes of connection time)
5. Deleted the compressed files after exfiltration

Who Is Behind the Attacks?

SentinelOne assesses the actors as financially motivated Initial Access Brokers (IABs), specialized criminals who break into high-value targets and then resell the access to ransomware operators. The differing approaches in the two documented incidents point to at least two separate operator groups.

In parallel, the AWS security team documented a separate campaign by a Russian-speaking, AI-augmented actor who compromised over 600 FortiGate devices in 55 countries between January and February 2026, in this case via exposed management ports and weak single-factor authentication.

The Logging Problem: Why the Firewall Alone Doesn't See Enough

A recurring pattern across the documented incidents: the logging on the FortiGate devices was not sufficient for a complete forensic analysis. In many cases, the exact time of the initial compromise could not be determined.

Fortinet has since published specific log IDs that organizations should actively monitor:

In addition, the following event IDs should be monitored on the Windows side:

Immediate Measures for Affected Organizations