palmiq Speak to an expert

FortiGate Compromise Audit Checklist: Rogue Admins

6 min read

A FortiGate compromise audit checklist for finding rogue admin accounts, config drift and burned credentials after a critical edge advisory.

Closeup of rows of tiny round white electrical connectors and long thin blue wires in data center

If you run a FortiGate or a VPN concentrator at the edge of your network, the honest question after a critical advisory is not “did we patch?” It is “what happened on this device while the vulnerability existed?” A FortiGate compromise audit checklist answers that second question. Patching closes the door. It does not evict anyone who already walked through it.

That distinction has been on display since late 2025, and the pattern documented by incident responders is specific enough to hunt for. Here is what to look for, in what order, and what to rotate when you find it.

Does patching FortiOS remove an attacker’s rogue admin account?

No. A firmware update fixes the vulnerability; it does not undo what an attacker did with it.

SentinelOne’s DFIR team reports that in FortiGate edge intrusions it investigated in early 2026, attackers established persistence that survives a firmware update — most notably new local administrator accounts created directly on the appliance. The same reporting describes attackers running the device’s full-configuration command to extract the config file, and, in a February 2026 incident, that file contained encrypted LDAP service account credentials. SentinelOne reports the actor later authenticated to Active Directory using clear-text credentials associated with the fortidcagent service account.

Timing makes this worse. In one incident SentinelOne investigated, the compromise likely began in late November 2025 and went undetected through February 2026 — roughly three months. An organization that patched in December and stopped there would still have had a resident in February.

None of this is a knock on Fortinet. Fortinet’s PSIRT disclosed the underlying flaws quickly, and internet-facing edge appliances from multiple vendors have shown up in CISA’s Known Exploited Vulnerabilities catalog over the years. Fast, public disclosure is what makes a retrospective audit possible in the first place.

What actually happened with CVE-2025-59718?

Fortinet’s PSIRT disclosed CVE-2025-59718 and CVE-2025-59719 on December 9, 2025, per Beazley Security’s advisory — critical authentication bypass flaws affecting FortiOS, FortiProxy, FortiSwitchManager and FortiWeb when FortiCloud single sign-on is enabled. Cyber Security News reports both are rated CVSS 9.8 and stem from improper verification of a cryptographic signature (CWE-347), letting an unauthenticated attacker send a crafted SAML message and gain administrative access.

Read that last part again: MFA on the admin portal would not have helped. The front door was bypassed, not guessed.

CISA confirmed active exploitation, and eSentire notes federal agencies were ordered to mitigate by December 23, 2025. Those deadlines bind federal civilian agencies, not your business. But KEV is a free, credible prioritization input if you don’t have a formal vulnerability management program.

It also didn’t end with one patch cycle. Rapid7 reports that on January 27, 2026 Fortinet disclosed CVE-2026-24858, a critical unauthenticated cloud-SSO authentication bypass affecting FortiAnalyzer, FortiManager, FortiOS and FortiProxy — confirmed as net-new rather than a patch bypass, and observed under active zero-day exploitation. Because Fortinet deployed a fix in its cloud environment, no client-side patch was required. That’s good news going forward and no information at all about what happened before.

Two more for your tracking list. The Hacker News reports CISA added CVE-2026-21643, an SQL injection flaw in FortiClient EMS rated CVSS 9.1, to KEV in April 2026. CISA added CVE-2025-68686, a FortiOS information-exposure flaw, on July 27, 2026; Cyber Security News notes federal mitigation was required by August 10, 2026 under Binding Operational Directive 26-04.

Verify current CVE identifiers, dates and affected-version lists against Fortinet’s PSIRT and the KEV catalog before you act. Edge advisories move fast, and a stale list is worse than no list.

How do I check a FortiGate for unauthorized admin accounts?

Enumerate every account and compare it to a written list of named humans who should have access. Do not scan the list for something that “looks suspicious.”

That matters because of naming discipline. Cyber Security News, reporting on the same research, describes a late January 2026 incident in which the attacker’s new local administrator account was named ssl-admin — chosen to blend into a plausible naming convention. In that incident, within 10 minutes of creating the account, the attacker was logging into multiple internal servers using domain administrator credentials.

So: every local and remote admin account, every admin profile, every trusted-host restriction. Then SSL-VPN users, groups, portals and realms, checked for additions. If you cannot tie an account to a person, treat it as unexplained until proven otherwise.

What is config drift on a firewall, and why does it matter?

Config drift is the accumulated difference between what your firewall does today and what you last deliberately approved. It matters because attacker changes hide inside it.

TechNadu’s coverage of the SentinelOne findings describes the actor using the rogue account to create firewall policies permitting traffic to traverse all zones — a change that looks unremarkable in a config file nobody diffs, and that quietly turns a perimeter device into a transit point.

Diff the running configuration against your last known-good revision and investigate every unexplained delta: new or overly broad policies, static routes, VIPs, admin API tokens, SSH keys, local certificates, automation stitches and scheduled scripts.

If you don’t have a known-good revision, that’s the real finding. A signed-off baseline plus a scheduled diff turns a forensic scramble into a short check.

Is FortiCloud SSO enabled by default on a FortiGate?

Fortinet states FortiCloud SSO login is disabled by default in factory settings. Arctic Wolf notes that when an administrator registers the device to FortiCare through the GUI, FortiCloud SSO is enabled on registration unless the admin explicitly disables “Allow administrative login using FortiCloud SSO.”

Most real-world devices are registered. So verify the current state rather than assuming it, and confirm who owns the linked FortiCloud/FortiCare account. SentinelOne reports attackers abused the cloud-SSO path by logging into a victim device using the attacker’s own FortiCloud account.

Do I need to rotate credentials if the config was extracted?

As a working rule, yes. If the configuration left the building, treat every secret inside it as burned.

Credentials in a FortiGate config are stored encrypted, and whether an attacker can decrypt them depends on circumstances. But SentinelOne’s reporting describes encrypted LDAP credentials being obtained and the associated service account later used in clear text — which is why “rotate everything” is the defensible default rather than a gamble on key strength.

Rotate: LDAP bind accounts, FSSO/fortidcagent service accounts, RADIUS secrets, IPsec pre-shared keys, SNMP communities, and any backup target credentials stored on the device.

What should I check outside the firewall?

Hunt outward into Active Directory. Ampcus Cyber, summarizing the SentinelOne investigations, reports attackers created rogue domain workstations, deployed remote management tooling, and attempted credential harvesting from domain controllers. TechNadu also notes abuse of the mS-DS-MachineAccountQuota attribute to join attacker-controlled machines to the domain.

So: look for unexpected computer objects, new members of privileged groups, and RMM installs nobody requested. Then check log forwarding and retention — a device that only logs locally can have its own evidence rotated away long before you go looking.

When should we run this audit, and when is it not enough?

Run it on triggers, not just after a confirmed breach: a KEV addition affecting your edge vendor, an IT provider transition, a staff departure, an acquisition, or a security questionnaire from an insurer or funder you can’t answer confidently. Privileged access review and configuration baselines show up on those questionnaires often — check your own policy language for what yours requires.

And be honest about limits. A configuration audit finds known persistence artifacts and reduces risk. It cannot prove an appliance is clean. Where evidence points to firmware- or filesystem-level persistence, the right call is professional incident response and, potentially, a rebuild from verified firmware.

palmiq is a Fortinet partner, and our 24/7 SOC treats edge audits as a scheduled exercise rather than an emergency. If you’re hardening or replacing an aging FortiGate, join our FortiGate Firewall Modernization webinar — it’s framed for healthcare, but the platform, baseline and admin-access material applies to any organization running Fortinet at the edge.

Want this handled for you?

We run managed IT, security and backup for organizations that would rather not read another article about it.

Speak to an expert

or call 703-336-9700