FortiGate Intrusions Are Blowing Up AD. Here's What SentinelOne Found.

If you're running FortiGate NGFWs with AD integration, stop what you're doing and read this.

SentinelOne's DFIR team published their investigation notes Monday on two separate FortiGate intrusions from early 2026. Both started the same way — a compromised appliance — and both ended badly. One gave attackers 3 months of quiet access before anyone noticed. The other went from firewall pop to domain controller in 10 minutes.

Three CVEs are in active play:

• CVE-2025-59718 — FortiOS SSO fails to validate cryptographic signatures. Craft a token, get unauthenticated admin access.
• CVE-2025-59719 — Same class of flaw, same SSO mechanism, patched in the same cycle.
• CVE-2026-24858 — If you have FortiCloud SSO enabled, attackers can log into your device using *their own FortiCloud account*. Patched by Fortinet in late January.

If you haven't applied patches for all three, you're exposed.

The Part Nobody Talks About: Reversible Encryption

Here's what makes FortiGate compromises particularly damaging. Once an attacker runs `show full-configuration`, they get the device's config file. That file contains your LDAP service account credentials — the ones your FortiGate uses to talk to Active Directory.

Those credentials are encrypted. With reversible encryption. Which attackers decrypt.

So a firewall compromise isn't just a firewall compromise. It's a set of AD credentials sitting in a file that attackers can take their time with offline. In both incidents SentinelOne investigated, that's exactly what happened.

Incident 1: Three Months of Quiet

The first compromise started around late November 2025. Attackers created a local admin account named `support` on the FortiGate, built four firewall policies allowing unrestricted access across all zones (source: all, destination: all), then went quiet.

For two months, minimal traffic trickled through those policies. That pattern is textbook initial access broker (IAB) — establish the foothold, park it, sell it. Whoever bought in showed up in February 2026 with the decrypted LDAP credentials from the FortiGate config.

They used the `fortidcagent` service account to authenticate to AD from IP `193.24.211[.]61` — a host that Validin records show has consistently had RDP open with workstation ID WIN-1J7L3SQSTMS. From there, they used the default `mS-DS-MachineAccountQuota` setting (which lets standard accounts join up to 10 machines to the domain) to enroll two rogue workstations: `WIN-X8WRBOSK0OF` and `WIN-YRSXLEONJY2`.

Security alerts triggered during the subsequent network scanning and password spraying. That stopped them. They didn't get further. But they were in the environment for three months before anyone detected it.

Incident 2: Ten Minutes to NTDS

The second case is faster and worse. Attackers hit a FortiGate, created a local admin account named `ssl-admin`, extracted and decrypted the config, and got Domain Administrator credentials.

Within 10 minutes of creating that FortiGate account, they were logging into servers across the environment via RDP using the built-in Domain Admin account — sourced from the FortiGate VPN IP range.

From there: staged files in `C:\ProgramData\USOShared`, downloaded Pulseway and MeshAgent RMM tools (hosted on attacker-controlled Google Cloud Storage and AWS S3 URLs), hid MeshAgent from Programs and Features using `SystemComponent=1` in the registry, created scheduled tasks named `JavaMainUpdate` and `MeshUserTask`, and deployed a DLL side-loading payload that mimicked legitimate Java DLLs.

The payload beaconed to `ndibstersoft[.]com` and `neremedysoft[.]com` on port 443.

They then created a Volume Shadow Copy of the primary domain controller, extracted `NTDS.dit` and the SYSTEM registry hive using `makecab`, and uploaded both during an 8-minute Cloudflare-routed connection. Then they deleted the local copies.

Every domain credential, offline. In under an hour.

What You Need to Check Right Now

On FortiGate:

• Look for Log ID `0100032001` (successful SSO login) — flag anything unexpected
• Look for Log ID `0100032095` (config file downloaded) — if this fired outside a maintenance window, assume compromise
• Look for Log ID `0100044547` (object configured) filtering on `cfgpath="system.admin"` or `cfgpath="user.local"` — that's your rogue admin account creation
• Check local admin accounts for anything named `support` or `ssl-admin`

In Active Directory:

• Windows Event ID 4741 — computer account creation. Check if Subject: Security ID matches your FortiGate LDAP service account.
• Look for computer objects with no SPNs and `mS-DS-CreatorSID` pointing to the FortiGate bind account
• Set `mS-DS-MachineAccountQuota` to 0 unless you have a specific reason to allow standard accounts to join machines

IOCs to block:

• `193.24.211[.]61`
• `185.156.73[.]62`
• `185.242.246[.]127`
• `ndibstersoft[.]com`
• `neremedysoft[.]com`
• `fastdlvrss[.]s3[.]us-east-1[.]amazonaws[.]com`

The Log Retention Problem

Both investigations were hampered by the same thing: insufficient log retention on the FortiGate appliances. SentinelOne couldn't reconstruct how the attackers got initial access because the logs weren't there.

Minimum 14 days on the appliance. Better: stream everything to a SIEM immediately, where attackers can't delete it after they're in. 60–90 days retention in the SIEM lets you do proper forensic reconstruction.

If you're not shipping FortiGate logs to a SIEM today, the next intrusion will look exactly like these two — and you'll be doing forensics blind.

Patch, Rotate, Audit

1. Patch CVE-2025-59718, CVE-2025-59719, CVE-2026-24858 — all three.
2. Rotate every service account credential stored in FortiGate configs. Assume they've been extracted.
3. Audit AD for rogue computer objects. Check creator SID, missing SPNs, creation timestamps.
4. Set `mS-DS-MachineAccountQuota` to 0.
5. Get logs off the appliance and into a SIEM.

The attacker in Incident 2 went from firewall to NTDS in 10 minutes. Your patch window is a lot shorter than you think.

*CybrPulse tracked 9 critical-severity security events in week 11 of 2026, with FortiGate intrusions comprising the highest-priority operational threat for enterprise defenders this week. Source: SentinelOne DFIR, published March 10, 2026.*