Gunra Ransomware Rewired the Login Flow to Get Past MFA

Every quarterly board deck says the same thing about ransomware readiness: multi-factor authentication is the control that stops credential-based intrusions. It is the line item everyone can point to and call done. A joint advisory CISA published on August 10, 2026, with the FBI, the Department of Defense Cyber Crime Center, the NSA, the U.S. Secret Service, and South Korea's National Police Agency, describes a group that did not need to beat that control. On at least one victim's corporate VDI portal, the actors modified the authentication code itself so a specific attacker-controlled one-time password would clear multifactor authentication on command.

The advisory is AA26-222A, and the group is Gunra, a ransomware strain written in C/C++ and derived from leaked Conti source code that first appeared in April 2025. In early 2026, its operators expanded into a structured ransomware-as-a-service affiliate program advertised on underground forums, one that hands affiliates a management panel, a configurable cross-platform payload builder, and supporting documentation, the same franchise model LockBit and BlackCat popularized and that keeps producing new operators faster than any single takedown removes them. Gunra affiliates have compromised hospitals, financial institutions, utilities, and government facilities across the Americas, Europe, the Middle East, and Asia-Pacific, exfiltrating data before encryption in a double-extortion model documented in the FBI's companion CSA. If you run Fortinet FortiOS or FortiProxy SSL-VPN appliances reachable from the internet, or a VPN/VDI gateway where MFA enforcement lives in code your admins control rather than hardware you cannot reach over the network, this is not one to skim. If your Fortinet estate is already on the fixed builds and your MFA is bound to a hardware token the server cannot simply wave through, tonight's specific chain is not your fire drill, though the detection logic below still belongs on your list.

The myth: MFA on the VPN means you are covered

Most breach post-mortems treat MFA as a binary state, present or absent, and most vendor risk questionnaires do the same: one checkbox, one point of credit. Gunra's initial-access playbook treated MFA as what it actually is, a piece of software with a codebase, a deployment, and an admin interface, and therefore a target with its own attack surface. The advisory does not describe credential theft defeating a second factor. It describes the second factor's verification logic getting edited by someone who had already gained enough access to reach it. That distinction changes what "we have MFA" is actually worth as a control, and it is the reason this advisory earns more attention than a routine patch-and-move-on notice.

Compare that to the MFA-bypass techniques most defenders already train against. Adversary-in-the-middle phishing kits, Evilginx-style, still need the victim to complete a real authentication challenge; the attacker relays it and steals the resulting session token. SIM swaps and prompt bombing target the human holding the second factor, betting on fatigue or a captured phone number. Gunra's VDI-portal technique needs none of that. There is no phishing email to miss, no push notification for a suspicious user to decline, no session token to detect replaying from an unfamiliar IP. The validator itself says yes. That makes it far harder to catch with the controls most security-awareness budgets buy, and it is why the advisory treats it as worth a standalone callout rather than folding it into the generic "credential access" section.

How the affiliates got in: two Fortinet CVEs and a spare superuser account

The advisory's primary initial-access vector is exploitation of internet-facing firewall and VPN appliances, specifically CVE-2024-55591 and CVE-2025-24472, a pair of FortiOS and FortiProxy authentication-bypass flaws (CWE-288, improper authentication) that let an attacker create a persistent, hardcoded super-user account named forticloud-sync. CISA and its co-authors also flag SSH access-control weaknesses and default credentials on SSL-VPN appliances as secondary paths in, meaning the Fortinet chain is the headline vector, not the only one. Once an affiliate has that superuser foothold, the advisory describes them moving with tools most defenders already have signatures for on paper: Impacket's psexec.py, smbclient.py, and secretsdump.py for SMB-based lateral movement and NTDS extraction, Mimikatz for credential harvesting, and legitimate remote-access software, MobaXterm, AnyDesk, and Google Remote Desktop, to blend into normal admin traffic rather than trip an EDR alert built for obviously malicious binaries.

The MFA bypass: rewriting the check, not stealing the password

The detail that sets this campaign apart from a routine VPN-CVE ransomware story is narrower and worse than credential theft. On a compromised corporate VDI portal, Gunra affiliates modified the authentication processing itself, per AttackIQ's technical breakdown of the advisory, so that a specific attacker-controlled one-time password would pass validation regardless of what the legitimate user's authenticator app displayed. Mapped to MITRE ATT&CK, that is T1556, Modify Authentication Process, and it is a meaningfully different failure mode than the MFA-fatigue prompt-bombing or SIM-swap attacks most security-awareness training covers. Prompt bombing and SIM swaps target the human holding the second factor. This targets the server verifying it, which means user training, phishing-resistant push notifications, and even a hardware key that is bound to a software-side validator an attacker can edit do not automatically close the gap. The control that actually holds here is integrity monitoring on the authentication stack itself, treating your VPN and VDI portal's auth code the same way you would treat a production database schema: change-controlled, monitored, and alerting on any modification nobody on your team requested.

From that foothold to a ransom note in five to seven days

Once inside, Gunra affiliates followed a documented sequence rather than an improvised one. Lateral movement runs over SMB admin shares and RDP with stolen session data, using pass-the-hash and pass-the-ticket to avoid needing a fresh credential at every hop, and domain controllers get hit with secretsdump.py to pull the NTDS database wholesale. Before encryption, the actors deploy a custom executable the advisory names main.exe specifically to pull data out of Microsoft OneDrive and SharePoint, compress it with 7-Zip, WinRAR, or RClone, and move it out over the Mega file-sharing service or FileZilla FTP; one documented case moved tens of terabytes this way. Encryption itself uses a ChaCha20-plus-RSA-4096 scheme across a multi-threaded architecture fast enough to finish before most backup jobs would even notice the source volume changed, dropping the extensions .ENCRT and .CRYPT on Windows hosts and .GNRA on Linux ELF variants, alongside a ransom note named R3ADM3.txt in every touched directory with a Tor negotiation link and a client ID. Demands run into the tens of millions of dollars, with a five-to-seven day negotiation window before the data-leak site listing goes live.

Where to look before the encryption step, not after

• Off-hours privileged activity. The advisory's observed operational window for privileged actions clusters between 10 p.m. and 6 a.m. local time. An admin session or an NTDS pull inside that window on a system that normally sits idle is worth an immediate look, not a morning ticket.
• Shadow-copy deletion via WMIC or PowerShell. Gunra affiliates delete volume shadow copies before encrypting, using native WMI operations rather than a custom tool. Treat any shadow-copy deletion command as a high-severity event by default, full stop, regardless of who ran it.
• Unrecognized super-user accounts on Fortinet devices. Specifically hunt for forticloud-sync or any admin account your team did not provision. A hit means assume compromise, not just a missing patch.
• Archive-then-upload sequences. 7-Zip or WinRAR activity followed by an outbound connection to Mega or an FTP session to an unfamiliar host, especially against OneDrive- or SharePoint-synced folders, is the exfiltration stage in progress.

CISA's own guidance in the advisory leans on behavior detection over network egress monitoring for a reason: Gunra's traffic to Mega and over FTP does not look anomalous at the packet level, and the group has not needed a novel command-and-control channel when SSH tunneling over OpenSSH does the job. The signal is in what the process did, not where the bytes went.

# FortiGate CLI — confirm the build is patched and hunt for the persistent superuser
get system status
# Patched builds close CVE-2024-55591 / CVE-2025-24472 (CWE-288 auth bypass).
# Check every SSL-VPN-facing unit, not just the ones your CMDB has current.

diagnose sys admin list
# Look for any admin account nobody on your team created. "forticloud-sync"
# is the name CISA observed affiliates provisioning. A hit means assume
# compromise and start an incident, not a patch ticket.

# Windows — hunt shadow-copy deletion via WMIC/PowerShell outside business hours
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1; StartTime=(Get-Date).AddDays(-30)} |
  Where-Object { $_.Message -match 'wmic.*shadowcopy delete|vssadmin.*delete shadows|Get-WmiObject Win32_ShadowCopy' } |
  Select-Object TimeCreated,
    @{n='User'; e={$_.Properties[12].Value}},
    @{n='CommandLine'; e={$_.Properties[10].Value}} |
  Where-Object { $_.TimeCreated.Hour -ge 22 -or $_.TimeCreated.Hour -le 6 }

Patch CVE-2024-55591 and CVE-2025-24472, then hunt for forticloud-sync

The patch is the floor, not the fix. Update every internet-facing FortiOS and FortiProxy instance to a build past both CVEs today, and do it before the account audit, because a hunt on an unpatched device just tells you whether an attacker has come back yet. Then run the account audit anyway: pull the admin list on every Fortinet appliance, on every domain controller, and on the VDI portal itself, and treat any name nobody recognizes as an active incident. The lesson that outlasts this specific advisory is the one about MFA. A second factor is only as trustworthy as the code that checks it, and that code needs the same change control and monitoring you would put on anything else an attacker could edit to buy themselves a green checkmark.