A fixed OTP value that the corporate VDI portal would always accept. Session cookies pulled from live SSL-VPN traffic while users logged into virtual desktops. Fortinet edge appliances opened with authentication flaws so the MFA prompt never appeared. According to the joint CISA #StopRansomware advisory AA26-222A, that combination is how Gunra ransomware affiliates (also tracked with the Golden Community branding) reached workforce VPN and VDI paths, then moved to credential dumping, data theft including from Microsoft services, encryption, and double extortion via a dedicated leak site.
This is campaign-level tradecraft observed across sectors such as healthcare, finance, manufacturing, government, and utilities. The advisory does not name individual victim companies or publish record counts or ransom figures. It still gives defenders a clear map of where workforce identity controls actually sat in the path, and where they never got a vote.
How Fortinet edge flaws never reached an MFA challenge
Initial access in the documented Gunra affiliate activity leaned hard on internet-facing Fortinet FortiOS and FortiProxy appliances. According to AA26-222A, actors exploited authentication flaws tracked as CVE-2024-55591 and CVE-2025-24472 on specific product versions. When the appliance’s own authentication decision is broken, the login ceremony that would have enforced a second factor is not the gate the attacker has to pass. The edge trust decision is already broken.
In some cases, affiliates also used default or weak VPN credentials and related exposure problems on internet-facing VPN gateways, including credential exposure and weak SSH access control. That path is ordinary bad hygiene: password-only or weakly protected remote access still exists in the wild, and it still works when nobody rotated factory defaults or locked down management planes.
Neither path is “MFA got outsmarted in a relay.” On the CVE path, the MFA challenge is simply not in the loop. Patch lag, residual internet exposure, and treating a second factor as a substitute for fixed edge authentication are the failures that matter. Gunra’s first foothold story is appliance and VPN perimeter failure first, identity ceremony second.
FBI reporting places Gunra’s first observation in April 2025, with code lineage tied to leaked Conti source material and a Tor-hosted data leak site. A Linux variant showed up later in 2025. As of January 2026 the group was running a formal RaaS affiliate model on dark web forums under the Golden Community alias. The August 10, 2026 multi-agency advisory (FBI, CISA, DC3, NSA, USSS, and KNPA) is the public TTP package, not a single-org breach diary.
How SSL-VPN position turned into stolen VDI sessions
Once affiliates could influence SSL-VPN traffic, they intercepted live credentials and session cookies during corporate VDI portal logins. AA26-222A maps this to stealing web session cookies and network sniffing style activity. The important identity detail is timing: the legitimate user had already completed authentication, including whatever OTP or password-plus-OTP flow the portal used. The attacker then reused the issued session material and rode an already-authenticated VDI session.
That is post-authentication abuse. No second factor is waiting on the next click when the cookie or session token is already valid in the attacker’s hands. Shortening session lifetime might annoy the operator into re-stealing sooner. It does not prevent the interception itself. Detecting odd VDI session reuse, binding sessions more tightly to client context, and hardening the VPN path so traffic cannot be quietly manipulated are the controls that address this phase. Blaming “weak MFA” for a stolen live session misreads the order of operations.
From that foothold the rest of the intrusion looks like classic post-compromise work: lateral movement, credential dumping, exfiltration, and ransomware deployment. Double extortion meant data left the environment before encryption, with publication threatened on the group’s leak site if payment failed. Workforce login MFA does not reverse host compromise or stop bulk data access after the perimeter identity story is already over.
How a rewritten OTP check became a permanent backdoor
The most identity-specific technique in the advisory is not a fake login page. Affiliates modified authentication-processing files on the corporate VDI authentication server so a fixed, attacker-chosen OTP value always succeeded. MITRE maps that class of activity to modifying the authentication process. After that change, the portal’s OTP check was no longer verifying the user’s real authenticator app or hardware token. It was verifying whether the attacker-supplied magic code was present.
User-held OTP apps could not save the day. The verification logic on the server had been rewritten. Every subsequent login that used the attacker-designated code looked like a successful MFA event to the broken portal. That is a durable backdoor on the auth host, not a one-time code relay and not push fatigue.
| Control surface | What Gunra affiliates did | Why the user factor failed |
|---|---|---|
| Fortinet edge / SSL-VPN | Edge auth CVEs; weak or default VPN creds in some cases | MFA challenge often never reached |
| VDI session after login | Intercepted cookies/credentials on SSL-VPN path | Session already issued; no fresh MFA |
| VDI OTP verification | Rewrote server files for a fixed success OTP | Server accepted attacker code, not user OTP |
OTP and other shared-secret second factors are especially brittle here because the server must compare a predictable string. If an attacker can edit that comparison path, the cryptography in the user’s pocket is irrelevant. Hardware-bound, origin-bound signatures shrink that exact “always accept this string” class of backdoor because there is no server-side OTP blob to rewire into a permanent yes. That still does not mean any login technology survives full write access to the authentication server. File integrity monitoring, least privilege, change control, and treating the VDI auth host like the crown jewel it is remain mandatory. Identity crypto does not replace host integrity.
Honest scorecard for this campaign:
- Edge CVE and weak VPN password paths: fix and harden the appliance and exposure. Do not market a stronger phone prompt as the patch.
- Stolen VDI session cookies after a real login: session binding, monitoring, and network path integrity. Stronger OTP does not un-issue a cookie.
- Server-side OTP always-succeed backdoor: retire backdoorable shared-secret verify logic on workforce VDI and VPN portals, and lock down who can change auth code on that host.
- Ransomware, exfil, lateral movement after the foothold: containment and recovery problems, not a second login prompt.
Gunra’s public story is ugly because it stacks failures that security programs often budget separately. Network teams own Fortinet patching. Identity teams own MFA enrollment. Desktop teams own VDI. Affiliates did not respect the org chart. They chained pre-auth edge abuse, post-auth session theft, and auth-server file tampering into one RaaS pipeline.
If you want the prevention-side read on where workforce device-bound MFA actually changes this picture, and where it does not, see where workforce MFA actually helps on Gunra-style VDI OTP and session abuse.
FAQ
Did Gunra affiliates face MFA on Fortinet VPN paths?
Gunra affiliates often never faced the MFA challenge on Fortinet paths described in AA26-222A. They exploited authentication flaws (CVE-2024-55591 and CVE-2025-24472) on FortiOS and FortiProxy, and in some cases used default or weak VPN credentials. When the edge authentication decision is skipped or reduced to a weak password, the second factor on a later portal is not what failed first.
How did Gunra steal VDI sessions without a new MFA prompt?
According to CISA advisory AA26-222A, Gunra affiliates intercepted credentials and session cookies during corporate VDI portal logins by manipulating SSL-VPN traffic. Those sessions were already authenticated. Replaying a valid session cookie does not trigger a fresh OTP or push. The failure is post-login session handling and path integrity, not a user mistyping a code.
What made the VDI OTP MFA useless after the server change?
Gunra affiliates modified authentication-processing files on the VDI authentication server so a fixed attacker-chosen OTP always succeeded. After that change, legitimate user authenticator apps could not stop attacker logins that presented the magic value. The portal was no longer checking the user’s real second factor. It was checking a backdoored rule on the server.
Does AA26-222A name victims or ransom amounts for Gunra?
No. The joint CISA, FBI, and partner advisory AA26-222A describes campaign TTPs and sector targeting for Gunra ransomware affiliates. It does not publish named victim organizations, record counts, or ransom payment figures in the public package summarized for defenders.
Would stronger push or OTP MFA have stopped this whole chain?
No single OTP or push upgrade would have stopped the full Gunra chain in AA26-222A. Fortinet edge CVE paths never presented the challenge. Stolen VDI session cookies required no new factor. The server-side OTP rewrite made user-held OTP irrelevant after the auth host was altered. Patching and exposing less edge surface, protecting sessions after login, removing backdoorable OTP verify logic, and hardening the VDI auth server each address different phases. Treating phone MFA as a universal fix for edge CVEs and cookie theft is how this class of campaign keeps working.
