A fixed OTP value that the corporate VDI portal would always accept after someone rewrote the verification files is not a user approving a tired push prompt. According to the joint CISA #StopRansomware advisory AA26-222A, Gunra ransomware affiliates (also tracked with Golden Community branding) combined Fortinet FortiOS and FortiProxy authentication flaws, interception of live VDI credentials and session cookies on SSL-VPN paths, and server-side OTP verification tampering. Device-bound phishing-proof authentication does not patch edge CVEs or un-issue a stolen VDI cookie. It does retire the shared-secret OTP compare surface that made the persistent portal backdoor possible.
What AA26-222A documents about Gunra access paths
According to AA26-222A, Gunra is a ransomware-as-a-service used by affiliates against government, critical infrastructure, and other organizations. The actors use double extortion: encrypt data and threaten publication on a dedicated leak site if ransom is unpaid. 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 single named-org breach diary. It names no victim companies, record counts, or ransom figures.
Documented initial access leaned on internet-facing Fortinet FortiOS and FortiProxy appliances. 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 and related exposure problems on internet-facing VPN 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 came lateral movement, credential dumping, exfiltration including from Microsoft services, and ransomware deployment across sectors such as healthcare, finance, manufacturing, government, and utilities.
If you want the full attack-chain narrative for this campaign, read 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
On the Fortinet edge path, the dominant documented 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 in other cases are ordinary credential hygiene failures. Neither pattern is a relay of a live OTP to a fake page. Patch lag, residual internet exposure, and treating a second factor as a substitute for fixed edge authentication are the real problems. Stronger phone prompts do not close CVE-class edge authentication flaws.
On the VDI session path, 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 class of activity to stealing web session cookies and network sniffing style techniques. The session material 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 prevent interception on a manipulable SSL-VPN path. Session binding, path integrity, anomaly handling for reused VDI sessions, and network controls address 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. That maps to modifying the authentication process. After the 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 device-bound phishing-proof MFA 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. Prevention, not detection still matters as a design goal for login, but revoke-and-detect work remains residual hygiene for sessions that malware or path interception already captured. Do not sell a second factor as a cookie un-issuer.
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. Moving workforce VDI and VPN access to origin-bound, hardware-backed signatures removes that exact always-accept-this-code class of verify path. There is no central OTP seed database and 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 coverage 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 |
|---|---|---|---|
| Device-bound phishing-proof MFA | 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 |
Key Takeaways for Defenders
- Patch and reduce internet exposure on Fortinet FortiOS and FortiProxy versions affected by CVE-2024-55591 and CVE-2025-24472; do not treat workforce MFA as the edge patch.
- Eliminate default and weak VPN credentials and lock down VPN management and SSH exposure on internet-facing gateways.
- Assume SSL-VPN path compromise can yield VDI session cookies; bind sessions tightly, monitor anomalous VDI reuse, and harden the path so traffic cannot be quietly manipulated.
- Retire server-side OTP string verification on workforce VDI and VPN portals in favor of origin-bound, device-bound signatures that have no fixed-code compare step.
- Treat the VDI authentication server as crown-jewel infrastructure: integrity monitoring, least privilege, and change control on authentication-processing files.
Gunra’s public story is ugly because it stacks failures that 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.
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.
