Gunra ransomware beats MFA by backdooring the login server, not the user. Patching Fortinet won't evict it.

Multi-factor authentication did not fail here because someone approved a rogue push. It failed because the attacker rewrote the server that checks the codes. A ransomware crew tracked as Gunra reached a corporate virtual-desktop portal, edited its login logic, and set one one-time password value that would always validate. After that, MFA stayed switched on. Every sign-in looked clean. The dashboard stayed green. And the operators came and went through the front door.

That is the detail worth sitting with in the joint advisory published on August 11. On that date, the FBI, CISA, and the Korean National Police Agency jointly issued #StopRansomware advisory AA26-222a on Gunra, a double-extortion operation that researchers believe was built on leaked Conti source code and has since rebranded as "Golden Community." According to reporting on the advisory, the group has hit at least 51 organizations since it emerged in April 2025, concentrated in healthcare, financial services, government, critical manufacturing, and transportation, with ransoms in most documented cases above ten million dollars.

The way in was familiar. Gunra broke in through two Fortinet authentication-bypass bugs left exposed at the network edge. One, CVE-2024-55591, sits in FortiOS; the other, CVE-2025-24472, spans FortiOS and FortiProxy. Fortinet shipped fixes for both long before this campaign began. But the advisory describes a second, quieter enabler that matters more. In at least one victim, the operators reached an SSL-VPN administrator account that still used default credentials with no lockout policy, as detailed coverage of the advisory notes. The edge flaw got them to the appliance. The unrotated default account is what let them start rewriting how authentication worked.

Why your MFA dashboard lies after an attack like this

A server-side one-time-password backdoor is invisible to the telemetry most teams use to catch account takeover. When the login server itself is told to accept a fixed code, the sessions it produces are recorded as successful, MFA-satisfied logins. There is no failed-push storm, no impossible-travel flag, no brute-force pattern. The compromise hides inside "normal."

So detection has to move down a layer, to the integrity of the authentication path itself. Three things are worth hunting. First, file changes on the authentication modules of a virtual-desktop, single-sign-on, or VPN portal that no change ticket explains. Second, repeated successful logins that all present the same one-time password or the same token. Third, administrator sign-ins clustered in the overnight window the advisory flags, roughly 10 at night through 6 in the morning, with logs wiped afterward. None of those show up on an MFA coverage report. All of them surface in file-integrity monitoring and raw authentication logs, if you keep them.

Patching Fortinet is necessary. It will not evict them.

This is the part the wire coverage understates, and it is a pattern we keep returning to: closing the hole an intruder came through does nothing about the persistence they left behind. We made the same argument about FortiBleed session theft and about why a patch is rarely the finish line. Gunra makes it concrete. By the time you upgrade past CVE-2024-55591 and CVE-2025-24472, the operators may already hold a tampered login server, domain credentials dumped with secretsdump, stolen VPN session cookies, and, in at least one case the advisory cites, a symmetric key lifted from an access-control server that let them decrypt stored enterprise passwords in bulk. The patch closes a door they are no longer standing in.

Eviction means treating the authentication layer as compromised. Restore the portal's login logic from a known-good build rather than trusting it. Rotate every credential the intruder could have touched, starting with that default admin account and any secret store Gunra could reach. Revoke active sessions and tokens. And rebuild, do not clean, the servers that held the modified files. The alternative is the outcome we traced when a session-persistence flaw went unaddressed and turned into a ransomware deployment weeks later.

Linux victims should check timestamps before paying

Gunra's Windows locker uses ChaCha20 and RSA-4096, appends .ENCRT, and drops a note named R3ADM3.txt. That is sound cryptography, and there is no shortcut. The Linux variant is a different story. The agencies note that its keys come from a pseudorandom generator seeded from the system clock, which means they can sometimes be reconstructed from the encrypted files' own timestamps. Those files carry the .GNRA extension. If a Linux host is hit, that is a concrete reason to attempt recovery before anyone discusses payment, because the advisory's own guidance is that these keys may be rebuildable without the operator's help. Ransomware crypto is broken often enough that decryption should be the first move, not the last resort.

The short list for anyone running Fortinet edge and a VDI portal

• Upgrade internet-facing FortiOS and FortiProxy to a fixed release for CVE-2024-55591 and CVE-2025-24472, and confirm no appliance still exposes an admin interface to the internet.
• Find and kill default or shared credentials on every VPN and remote-access admin account, and enforce lockout. This campaign's real pivot was an admin account nobody had rotated.
• Put file-integrity monitoring on the authentication modules of your virtual-desktop, single-sign-on, and VPN portals, and alert on any change without a matching ticket.
• Hunt authentication logs for repeated success on a single one-time password or token, and for off-hours admin logins, then correlate against gaps where logs were deleted.
• Keep offline, immutable backups in a separate location. Exfiltration and encryption here move fast, and the extortion window is five to seven days.
• If a Linux host is encrypted and files end in .GNRA, attempt timestamp-based key reconstruction before considering payment.

The uncomfortable lesson is that "MFA is enabled" has quietly stopped being an answer to "are these logins trustworthy." When an attacker can reach the server that adjudicates the second factor, the second factor becomes theater. The control you actually need is integrity monitoring on the systems that make authentication decisions, plus an incident-response assumption, baked in from the start, that a firewall flaw is where an intrusion begins and almost never where it ends.