Gunra did not find one MFA bug. It stacked three failures and only one of them is an identity-factor problem.
Per the joint CISA #StopRansomware advisory AA26-222A, Gunra ransomware affiliates (also tracked as Golden Community) stacked Fortinet FortiOS and FortiProxy authentication flaws, interception of live VDI credentials and session cookies on SSL-VPN paths, and server-side OTP verification tampering.
Phishing-proof MFA 2.0 does not patch those edge CVEs. It does not un-issue a stolen VDI cookie. It does retire the shared-secret OTP compare that made the portal backdoor possible.
What AA26-222A documents about Gunra access paths
According to AA26-222A, Gunra is ransomware-as-a-service aimed at government, critical infrastructure, and other organizations. Double extortion: encrypt, then threaten publication on a leak site. FBI reporting places first observation in April 2025, with lineage tied to leaked Conti source material. A Linux variant appeared later in 2025. As of January 2026 the group ran a formal RaaS affiliate program on dark web forums. The 10 August 2026 package from FBI, CISA, DC3, NSA, USSS, and KNPA is a campaign TTP advisory, not a named-org breach diary. No victim companies. No record counts. No ransom figures.
Initial access leaned on internet-facing Fortinet FortiOS and FortiProxy. Actors exploited authentication flaws tracked as CVE-2024-55591 and CVE-2025-24472 on specific versions. In some cases they also used default or weak VPN credentials on exposed gateways. With position on SSL-VPN traffic, they intercepted credentials and session cookies during corporate VDI portal logins and hijacked already-authenticated VDI sessions. Separately, they modified authentication-processing files on the corporate VDI authentication server so a fixed attacker-designated OTP value always succeeded. From those footholds: lateral movement, credential dumping, exfiltration including from Microsoft services, and ransomware across healthcare, finance, manufacturing, government, and utilities.
For the full attack-chain narrative, see the related post on legacymfa.sucks: Gunra Fortinet VPN, VDI cookie theft, and OTP backdoor TTPs.
Why OTP and session controls failed on Gunra VDI paths
Fortinet edge first. The dominant technique was an authentication flaw on the appliance itself. When the edge trust decision is broken, the workforce MFA challenge that would have run later is not the gate the attacker had to pass. Default or weak VPN passwords elsewhere are ordinary credential hygiene failures. Neither is a live OTP relay to a fake page. Patch lag, residual internet exposure, and treating a second factor as a substitute for fixed edge authentication are the problems. Stronger phone prompts do not close CVE-class edge flaws.
VDI session path next. Timing is everything. Affiliates intercepted live credentials and session cookies while legitimate users completed portal login, including whatever password-plus-OTP flow the portal used. AA26-222A maps this to stealing web session cookies and network sniffing style techniques. The session was already issued. Replaying a valid cookie does not present a fresh OTP. Shortening session lifetime may force the operator to re-steal sooner. It does not stop interception on a manipulable SSL-VPN path. Session binding, path integrity, anomaly handling for reused VDI sessions, and network controls own this phase. Calling it an MFA failure misreads the order of operations. Authentication had already succeeded.
The identity-specific persistence technique is different again. Affiliates modified authentication-processing files on the VDI authentication server so a fixed, attacker-chosen OTP always succeeded. After that change, the portal was no longer verifying the user's real authenticator app or hardware token. It was verifying whether the magic code was present. User-held OTP apps could not save the day. The comparison logic on the server had been rewritten. Every later login that presented the attacker-designated value looked like a successful MFA event to the broken portal.
| Phase | What was abused | Did a stronger OTP app help? |
|---|---|---|
| Fortinet edge | Auth CVEs; weak VPN creds in some cases | No. Challenge often never reached |
| VDI after login | Stolen session cookies on SSL-VPN path | No. Session already issued |
| VDI OTP verify | Server files rewritten for fixed success OTP | No. Server accepted attacker code |
| Post-foothold | Lateral move, dump, exfil, encrypt | No. Perimeter already broken |
Shared-secret second factors are brittle here because the server must compare a predictable string. If an attacker can edit that comparison path, cryptography in the user's pocket is irrelevant. That is not ordinary AiTM phishing and not push fatigue. It is host-level tampering of verification logic.
Where phishing-proof MFA 2.0 changes Gunra outcomes
It does not patch FortiOS or FortiProxy. It does not replace appliance hardening, internet-exposure reduction, or credential hygiene on VPN management planes. When the edge authentication decision is skipped via CVE, no workforce login factor is in the loop. Prevention for that phase is patching and shrinking attack surface, not a better phone ceremony.
It does not undo post-authentication cookie or token theft by itself. Once a legitimate VDI session exists and the cookie is stolen from the path, the problem is session handling, binding, monitoring, and network integrity. Do not sell a second factor as a cookie un-issuer. Revoke-and-detect remains residual hygiene for sessions path interception already captured.
Where it does matter is the narrow surface the OTP file rewrite exposed. Server-side "compare this OTP string" logic is a backdoorable shared secret. Move workforce VDI and VPN access to origin-bound, hardware-backed signatures and that always-accept-this-code verify path goes away. No central OTP seed database. No string-compare step to rewire into a permanent yes. The private key stays on the enrolled device. The server holds public material that is useless to flip into a fixed success code the way an OTP checker can be flipped.
Passkeys and FIDO2-style factors create a device-held key pair. The private key never leaves hardware. The signature is bound to the real origin of the enterprise identity provider, so a lookalike host cannot complete a useful ceremony. Industry language correctly calls that phishing-resistant at the login act. On a generic enterprise IdP that only accepts hardware-bound signatures, the server never stores a reusable OTP secret to rewrite into "always true." That is the mechanical contrast to Gunra's VDI OTP file mod: there is no attacker-chosen six-digit constant waiting in verification code.
Passkeys still harden authentication only unless enrollment and recovery are locked down the same way. AA26-222A does not describe helpdesk re-enrollment or recovery OTP abuse as the Gunra persistence path. The documented backdoor was server-side modification of OTP processing on the VDI auth host. The lifecycle lesson still applies. Phishing-resistant passkeys at login can sit beside phishable enrollment, email recovery codes, or OTP fallback on the same portal. Any remaining shared-secret verify path is another string-compare surface an operator with file write can bend. Phishing-proof MFA 2.0 means no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning, so you do not reintroduce an OTP checker that can be rewritten into a permanent yes. Pair that with integrity controls on the auth host. Crypto without host discipline is incomplete.
That claim has a hard ceiling. Phishing-proof login crypto does not survive unrestricted write access to the authentication host if attackers can replace entire trust stores, implant rogue configuration, or own the machine that decides access. File integrity monitoring, least privilege, change control, and treating the VDI auth server as a crown jewel remain mandatory. The honest win is shrinking the OTP-string backdoor class and forcing attackers toward harder host compromise, not magic immunity after full auth-server takeover.
Post-compromise lateral movement, credential dumping, exfiltration, and encryption are outside login MFA. Workforce authentication at the perimeter does not reverse established sessions or stop bulk data access after the identity story is already over.
| Control question | Edge CVE / weak VPN | Stolen VDI cookie | OTP verify rewrite |
|---|---|---|---|
| Phishing-proof MFA 2.0 | No substitute for patch | Does not un-issue cookie | Removes string-compare backdoor class |
| What actually closes it | Patch, exposure cut, hygiene | Bind, monitor, path integrity | Drop OTP verify; lock auth host |
Gunra's public story is ugly because it stacks failures org charts often budget separately. Network owns the firewall. Identity owns MFA enrollment. Desktop owns VDI. Affiliates chained pre-auth edge abuse, post-auth session theft, and auth-server file tampering into one RaaS pipeline. The useful prevention question is not whether a better push prompt would have saved everyone. It is which phase still had a transferable secret or a rewritable compare, and which phase never presented a factor at all.
If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.
FAQ
Would phishing-proof MFA have blocked Gunra's Fortinet initial access?
No. Phishing-proof MFA would not have blocked the Fortinet authentication path described for Gunra affiliates in AA26-222A. CVE-2024-55591 and CVE-2025-24472 broke the appliance's own authentication decision on affected FortiOS and FortiProxy versions, so the workforce MFA challenge was often never reached. Prevention for that phase is patching, reducing internet exposure, and fixing weak or default VPN credentials, not a stronger second factor on a ceremony that never ran.
Can device-bound MFA stop VDI session cookie theft like Gunra's SSL-VPN interception?
No. Device-bound MFA cannot by itself stop VDI session cookie theft after a legitimate login, which is how Gunra affiliates hijacked already-authenticated VDI sessions according to AA26-222A. The cookie was issued after authentication succeeded. Replaying it required no new factor. Defenders need session binding, shorter useful lifetime as hygiene only, monitoring for anomalous reuse, and integrity on the SSL-VPN path. Stronger OTP does not un-issue a stolen session.
Where does MFA 2.0 actually help against the Gunra VDI OTP backdoor?
MFA 2.0 helps on the Gunra VDI OTP backdoor by removing server-side shared-secret OTP verification that affiliates rewrote so a fixed attacker-chosen code always succeeded. Origin-bound, device-bound signatures have no "always accept this OTP string" compare step to flip. That does not mean any login technology survives full write access to the authentication server. File integrity monitoring, least privilege, and change control on the VDI auth host remain required alongside retiring OTP verify logic.
Is the Gunra OTP file change the same as AiTM phishing or push fatigue?
No. The Gunra OTP file change in AA26-222A is not AiTM phishing or push fatigue. Affiliates modified authentication-processing files on the corporate VDI authentication server so an attacker-designated OTP value always succeeded. That is server-side modification of the authentication process. User authenticator apps became irrelevant because the portal stopped checking the real second factor and started checking a backdoored rule.
Does AA26-222A give victim names or ransom amounts for Gunra?
No. The joint CISA, FBI, and partner advisory AA26-222A describes Gunra ransomware affiliate TTPs, sector targeting, and double-extortion behavior. It does not publish named victim organizations, affected record counts, or ransom payment figures in the public defender package.
