Gunra patched the MFA validator and left the dashboards green
The line in the August 10 joint advisory that sent me to check our own portals has nothing to do with a CVE. In at least one victim network, Gunra operators edited the authentication processing files on a corporate VDI portal server so that one specific one-time password, a value they chose, validated every time it was entered. MFA stayed switched on and kept reporting itself as enforced, so every login they made afterward looked like a user with a working token.
Who Gunra is
Gunra is a financially motivated ransomware-as-a-service crew built on the leaked Conti source code, first observed in April 2025, running double extortion against healthcare, financial services, government and utilities across four continents. The affiliate program opened on dark web forums in January 2026 with a management panel, a configurable builder and cross-platform lockers, and the FBI has observed a rebrand under the alias Golden Community. No MITRE ATT&CK group ID has been assigned yet, so track them by technique. What put them on the board is advisory AA26-222A, published August 10, 2026 by six agencies including the FBI and CISA, the first joint United States and South Korea advisory on this actor.
The backdoor sits in the validator, not in an account
Every MFA deployment has one place where the decision actually gets made: some code on some server recomputes the expected value from an account's shared secret, compares it to what the user submitted, and returns a boolean. Enrollment records, push notifications and conditional access policies are scaffolding around that comparison, which is trusted absolutely because it runs on hardware you own.
Gunra took the appliance in front of the portal with a Fortinet authentication bypass, or in one case with default credentials on an exposed SSL-VPN box, then edited the files that perform the comparison. The validator now accepts a second answer: real time-based codes still work, and beside them sits a constant the operators picked, which validates for as long as that file stays in place.
What it defeats. MFA rests on the assumption that an attacker cannot produce the second factor, and on a quieter assumption that the verifier is honest. Almost nobody monitors the second one. Your identity provider logs a successful second factor because one was returned, the authenticator app never fires because no push was requested, and no event shows MFA disabled, because nothing was disabled. A SOC watching for MFA fatigue sees a clean quarter while an operator signs in nightly.
How new this is, precisely. Not new as a technique. MITRE ATT&CK has carried T1556, Modify Authentication Process for years, and sub-technique T1556.006 covers modifying or disabling MFA. What is new is the target class and who is doing it. Documented cases under that technique cluster around identity provider configuration, attacker-registered devices and hybrid identity trust, all of which change the policy governing MFA. Gunra changed neither policy nor configuration: they edited application code on an on-premises virtual desktop portal, left the control switched on so it kept reporting healthy, and did it as routine persistence inside a ransomware playbook. A six-agency advisory documenting a RaaS crew working that way is the part I have not seen before, and I claim no more than that.
The two flaws that put them next to the portal
Both are CWE-288 authentication bypasses that hand an unauthenticated attacker super-admin on the appliance, and both sit in the CISA Known Exploited Vulnerabilities catalog.
| CVE | Affected versions | How Gunra uses it | KEV | Source |
|---|---|---|---|---|
| CVE-2024-55591 CVSS 9.6 |
FortiOS 7.0.0 to 7.0.16; FortiProxy 7.0.0 to 7.0.19 and 7.2.0 to 7.2.12 | Crafted requests to the Node.js websocket module grant super-admin with no credentials, then operators plant randomly named accounts. | Listed January 2025 | AA26-222A, FG-IR-24-535 |
| CVE-2025-24472 CVSS 8.1 |
FortiOS and FortiProxy with Security Fabric enabled | Forged Cluster Synchronization Framework proxy requests grant super-admin on a downstream device, the fallback once the websocket route closes. | Listed February 11, 2025 | AA26-222A, The Hacker News |
What a CVSS-sorted queue gets wrong
A 9.6 and an 8.1 both land high enough that nobody calls them ignored, so the failure is not that they sink down the list. Take two FortiGates, both running 7.0.14, both scored 9.6. One terminates a warehouse tunnel, the other fronts the VDI portal four thousand clinical staff authenticate through every morning, and a severity queue calls them the same finding even though only one puts an operator next to an authentication server.
Worse, the highest consequence action in the whole intrusion, the edit to the portal's authentication files, has no CVE and no scanner signature, so it never enters a severity queue at all.
How TRIS ranks these findings
TRIS is the Threat and Risk Intelligence Scoring engine inside CVEasy AI, and it scores a finding against the asset it sits on. Three layers carry most of the weight here.
Exploitation status. Both CVEs are KEV listed and named in AA26-222A as actively used against real victims, which is confirmed in-the-wild abuse rather than a published proof of concept. TRIS keeps those states apart: a PoC says a flaw is reachable, an advisory like this says somebody is already through the door.
Exposure. Whether the appliance answers from the open internet or only from a management VLAN moves this finding further than any other single input.
Downstream trust. An edge device fronting an authentication portal, a VDI farm and a flat network with domain controller reachability inherits the blast radius of all of it. A segmented tunnel endpoint does not.
Run the same CVE-2024-55591 finding through those layers on two assets and you get two answers. The internet-facing FortiGate fronting the VDI portal lands in the top band, ACT, this week, while the same version on a segmented appliance lands several bands lower and waits for the maintenance window. Both answers are correct.
What to run this week
Audit Fortinet accounts. The advisory names a persistent malicious super-user account, forticloud-sync, created with a hard-coded password through scheduled task abuse on vulnerable FortiOS firewalls, and SafeBreach flags that name as a high-value hunt target. Check every appliance for it, review the admin list and every SSL-VPN user group for accounts nobody recognizes, and read the automation stitches that would recreate one after you delete it.
Baseline the portal authentication files. Hash the authentication directory on every VDI and VPN portal server against the vendor build; on Linux, rpm -V or dpkg --verify is a fast first pass. Any write to that directory outside a change window is an incident, so put file integrity monitoring on it.
Hunt the rest of the chain. Gunra works deliberately between 10:00 p.m. and 6:00 a.m., so baseline privileged logons in that window and give it its own detection logic. Alert on DCSync from any account that is not a domain controller, on service creation over SMB matching Impacket patterns, and on vssadmin delete shadows, bcdedit recovery changes and bulk wevtutil log clearing. Watch for 7-Zip or WinRAR activity on a file server followed by an Rclone transfer to Mega, and sweep shares and NAS volumes for the .ENCRT, .CRYPT and .GNRA extensions and for R3ADM3.txt notes. The advisory ships its IOCs in STIX, so load them into your SIEM.
Fix, mitigate, rotate
Patch. One upgrade closes both flaws: FortiOS to 7.0.17 or later, FortiProxy to 7.0.20 or 7.2.13 or later. Until that window opens, take SSL-VPN and the administrative interfaces off the public internet, restrict management to a trusted source-address list, and enforce account lockout on every portal, since one intrusion began with default credentials rather than an exploit.
Rebuild a tampered portal. Restore from vendor media, because editing the file back is not remediation when you have no idea what else was touched.
Rotate. Appliance administrative credentials and API keys, every local SSL-VPN account, the TOTP seeds for every account that authenticated through a tampered portal, and the domain accounts behind them. If NTDS was dumped, krbtgt goes on the list, twice.
Protect recovery. Gunra deletes volume shadow copies before detonating, so you want offline, immutable backups an administrative account cannot reach.
One note if you run Linux. AhnLab's ASEC team found that the ELF locker generates its ChaCha20 key material with a time-seeded standard library random number generator, which collapses the key space far enough that encrypted files can often be recovered by analysis instead of payment. That path depends on file timestamps, so preserve them and image the host first.
Where this shows up in CVEasy AI
CVEasy AI, the number one local-first CTEM platform, ingests the sources this post cites, the KEV catalog and joint advisories like AA26-222A, then runs them through TRIS against your own inventory on your own hardware, so the FortiGate in front of your VDI portal and the one behind a jump host come back with different answers. BASzy, our attack simulation engine, replays this kill chain in authorized engagements so you learn whether that path is reachable before somebody else does.
Sources: CISA AA26-222A, Fortinet FG-IR-24-535, MITRE ATT&CK T1556.006, AhnLab ASEC, SafeBreach, Infosecurity Magazine, The Hacker News