Your FortiGate Has Been Giving Away Your Active Directory
Three CVEs. Two incidents. One consistent outcome: attackers walked from the firewall straight into domain controllers.
SentinelOne's DFIR team just published what they found investigating multiple FortiGate intrusions in early 2026, and it's a blueprint for how edge device compromise turns into full AD takeover. If you run FortiGate — especially with SSO or FortiCloud integration — you need to stop reading this in a tab and actually act on it.
What the Attackers Used
Three vulnerabilities were in active play across these investigations:
CVE-2025-59718 and CVE-2025-59719 — Both hit Fortinet's SSO mechanisms by skipping cryptographic signature validation. An attacker sends a crafted SSO token and gets unauthenticated administrative access. No password required. Fortinet disclosed these through December 2025.
CVE-2026-24858 — Patched by Fortinet in late January, this one allowed an attacker to log into FortiGate devices using their *own* FortiCloud account on a victim's device with FortiCloud SSO enabled. Not a brute-force issue. Just a logic flaw that handed over the device.
Once in, the path is straightforward: run `show full-configuration`, export the config file, decrypt it. FortiOS uses reversible encryption on those config files. That means embedded service account credentials — your LDAP bind accounts, your AD integration credentials — are recoverable in plaintext.
Incident 1: The Slow Burn
This compromise started in late November 2025 and ran undetected until February 2026 — roughly three months.
The attacker created a local admin account named `support` on the FortiGate device, added four overly permissive firewall policies, then went quiet. Minimal traffic through those policies while they waited. SentinelOne's assessment: initial access broker behavior. Establish the foothold, confirm it works, sell it.
In February, whoever bought the access extracted the config, decrypted the LDAP credentials from the `fortidcagent` service account, and authenticated into Active Directory from IP `193.24.211[.]61`. They then exploited 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`.
That IP address consistently exposes RDP and a machine ID of `WIN-1J7L3SQSTMS`. It's an attacker-controlled pivot host and should be blocked.
The noise of password spraying and network scanning (SoftPerfect Network Scanner artifacts were recovered) eventually triggered alerts and stopped lateral movement before it progressed further. But they had 3 months of access before anyone noticed.
Why didn't they catch it sooner? Insufficient log retention. The FortiGate appliance didn't have enough logs saved to reconstruct exactly when or how the initial access happened.
Incident 2: Ten Minutes to Domain Controller
This one's faster. Discovered in late January, the attacker created a local admin account named `ssl-admin`, extracted the AD configuration, and within 10 minutes was logged into multiple servers using the built-in Domain Administrator account via the FortiGate VPN IP range.
The sequence that followed:
- RMM deployment — Pulseway downloaded from a Google Cloud Storage bucket (`storage.googleapis[.]com/apply-main/windows_agent_x64[.]msi`). MeshAgent pulled separately, then hidden from Programs and Features using the `SystemComponent=1` registry key.
- Malware staging — PowerShell downloaded `paswr.zip` from `fastdlvrss[.]s3[.]us-east-1[.]amazonaws[.]com`. The payload used DLL side-loading with malicious files named to match legitimate Java components. Payloads beaconed to `ndibstersoft[.]com` and `neremedysoft[.]com`.
- NTDS exfiltration — The attacker created a Volume Shadow Copy of the primary domain controller, extracted `NTDS.dit` and the SYSTEM registry hive using `makecab`, then connected to `172.67.196[.]232` (Cloudflare-fronted) for 8 minutes. Files were deleted after. The entire AD credential database was gone.
What You Should Do Right Now
Patch first. All three CVEs need to be addressed: CVE-2025-59718, CVE-2025-59719, CVE-2026-24858. If you haven't done it already, you're behind.
Audit your FortiGate for rogue accounts. Look for local admin accounts named `support` or `ssl-admin`. Check your firewall policies for anything with source: all / destination: all that wasn't explicitly approved.
Rotate service account credentials. Assume that if your FortiGate has ever been accessible from the internet and hasn't been patched, the LDAP credentials in your config may already be in someone's hands.
Set `mS-DS-MachineAccountQuota` to 0. There is no good reason for standard user accounts to be joining machines to your domain. Pull that right now.
Check AD for rogue computer objects. Look for computer accounts where `mS-DS-CreatorSID` maps back to a FortiGate service account and where SPNs are absent. Those are indicators.
FortiGate log retention. Both incidents were hampered by insufficient logs. Minimum 14 days locally, 60-90 days if you're streaming to a SIEM. Stream all logs to a SIEM — attackers can delete local logs, but they can't delete what's already centralized.
Detection log IDs to watch:
- `0100032001` — SSO login
- `0100032095` — Config file download
- `0100044547` — Local admin account creation
- Windows Event 4741 — Computer account creation in AD
- Windows Event 5136 — Directory service attribute changes
IOCs
IPs: `193.24.211[.]61`, `185.156.73[.]62`, `185.242.246[.]127`
C2 domains: `ndibstersoft[.]com`, `neremedysoft[.]com`
Malware staging: `fastdlvrss[.]s3[.]us-east-1[.]amazonaws[.]com/paswr.zip`
RMM delivery: `storage.googleapis[.]com/apply-main/windows_agent_x64[.]msi`
Edge devices are high-value, they sit on the internet, and most organizations have no EDR visibility into them. That combination isn't changing. These attacks will keep coming. The defenders who patch fast, rotate credentials, and stream logs to a SIEM are the ones who contain this before the NTDS walks out the door.
