U.S. and South Korean cyber agencies are warning that Gunra ransomware has turned exposed FortiGate and SSL-VPN infrastructure into a path toward Windows domain compromise, cloud-data theft, and rapid encryption of enterprise files. The joint FBI, CISA, NSA, DC3, Secret Service, and Korean National Police Agency advisory published August 10 says Gunra has used known Fortinet authentication-bypass flaws, stolen VPN sessions, altered MFA processing, and common Windows administration tooling to reach Active Directory, VDI infrastructure, database servers, and NAS systems.

This is a Windows incident story even though Gunra now has Linux payloads. The Windows locker enumerates accessible drives from A through Z, selectively targets user data while leaving core system files intact, deletes Volume Shadow Copies through WMI, and encrypts files with the

.ENCRT

extension. The design preserves enough of the operating system to display ransom instructions and pressure an organization into negotiating, while making Windows-native recovery options far less useful.

The advisory’s most consequential finding is not the encryption routine. It is that Gunra’s documented access chain can compromise the systems organizations often trust to enforce remote access and MFA in the first place.

Infographic showing a breached Fortigate firewall enabling ransomware, lateral movement, and data exfiltration.Fortinet Edge Devices Are the Entry Point to Review First​

The agencies say Gunra actors have primarily gained initial access by exploiting internet-facing firewall and VPN appliances. They specifically identify CVE-2024-55591 and CVE-2025-24472, two Fortinet FortiOS and FortiProxy authentication-bypass vulnerabilities that were added to CISA’s Known Exploited Vulnerabilities catalog in 2025.

Fortinet’s own advisory says both issues affect FortiOS 7.0.0 through 7.0.16, FortiProxy 7.0.0 through 7.0.19, and FortiProxy 7.2.0 through 7.2.12. The fixed releases are FortiOS 7.0.17, FortiProxy 7.0.20, and FortiProxy 7.2.13 or later, respectively. CVE-2024-55591 concerns crafted requests to a Node.js WebSocket module; CVE-2025-24472 involves crafted Security Fabric proxy requests and, according to the current NVD description, requires knowledge of relevant device serial numbers and an enabled Security Fabric configuration.

Those version boundaries deserve an immediate configuration-management check rather than a generic “patch your VPN” ticket. An organization can have fully patched Windows endpoints and still hand an attacker administrative control of the remote-access boundary. Gunra’s reported use of a malicious

forticloud-sync

super-user account after exploiting Fortinet devices makes a second check just as important: review local Fortinet administrator accounts, scheduled tasks, configuration revisions, and remote-management logs for changes that survived a firmware upgrade.

The advisory also describes one Korean victim where the attackers obtained an SSL-VPN administrator account by using default credentials in an environment without account-lockout protection. That is a separate failure mode from an unpatched CVE. It means remote-access hardening needs to cover appliance administration accounts, not merely employee VPN users.

Fortinet had already reported active exploitation of these flaws when it issued its 2025 advisory. Gunra is therefore a reminder that known exploited does not mean historical. A vulnerable or weakly administered gateway can remain a usable initial-access broker long after the patch release and the initial news cycle.


Gunra’s MFA Bypass Targets the Systems Behind MFA​

The Korean police agency’s incident observations make Gunra more troubling than a conventional ransomware deployment. In one case, the intruders reportedly manipulated SSL-VPN traffic-control functionality to capture credentials and session information flowing to a VDI authentication portal. They then reused stolen session cookies to access the internal VDI environment as legitimate users.

The actors also allegedly modified authentication-processing files on the VDI portal server so that an attacker-chosen one-time password would be accepted. In practical terms, that creates a backdoor around MFA at the identity-verification layer. Users can continue receiving prompts, administrators can continue believing MFA is enforced, and the attackers can still authenticate with a value they planted.

This distinction changes how Windows and identity teams should scope an incident. Resetting user passwords, revoking Microsoft Entra ID refresh tokens, or requiring new MFA registration is necessary after suspected credential theft, but it will not remove an attacker-controlled exception inserted into a self-hosted authentication portal or a compromised VPN appliance. Responders need to inspect the authentication stack itself: appliance configuration exports, portal application files, privileged account changes, session stores, and the systems that issue or validate VDI access.

The advisory further says Gunra moved laterally from VDI into an Active Directory server, a VDI authentication web server, and virtual desktops assigned to IT personnel. It used Impacket’s

psexec.py

and

smbclient.py

for SMB-based movement, while

secretsdump.py

was used against domain controllers to obtain NTDS password hashes. Those hashes can support pass-the-hash or pass-the-ticket activity, turning a remote-access compromise into a domain-wide Windows problem.

The practical response is to treat a suspicious VPN administrator login or unexplained VDI session as a possible identity compromise, not merely an appliance event. Review Domain Controller replication and authentication telemetry, remote service creation, administrative-share access, PowerShell and command-line execution, and unexpected SMB activity from VDI pools. If logs are centrally collected, preserve them before containment; Gunra is documented clearing system and network access logs as well as command history.

OneDrive and SharePoint Are Part of the Extortion Surface​

Gunra’s ransomware operation follows the now-familiar double-extortion model: steal data first, encrypt second, then threaten to publish the stolen material. But the advisory includes a detail that Windows and Microsoft 365 administrators should not overlook: the FBI observed a malicious executable named

main.exe

used to exfiltrate data from Microsoft OneDrive and SharePoint.

The advisory does not describe the mechanism used by either observed

main.exe

sample to access those services, nor does it say whether the collection came through synced folders, browser sessions, application credentials, APIs, or tokens captured elsewhere in the intrusion. That gap matters. Blocking a listed malware hash is sensible, but it cannot substitute for investigating cloud audit trails and identity events surrounding the affected period.

Gunra’s leak-site previews have included directory listings from victims’ OneDrive and SharePoint environments, according to the agencies. The group was also observed creating compressed archives and sending data to Mega, with one incident involving up to tens of terabytes. For an organization with broad SharePoint permissions, inherited site access, or excessively capable service accounts, the cloud-data exposure may exceed what is visible on the first encrypted workstation.

Microsoft 365 defenders should preserve and review Unified Audit Log events for mass file access, download, sync, sharing-link changes, permission changes, suspicious OAuth consent, and unusual application activity. Look particularly at administrative and IT users whose VDI desktops may have contained browser sessions, mapped document libraries, credentials, or privileged access to collaboration sites. A quick inventory of OneDrive sync clients and SharePoint-connected service accounts is more valuable than assuming the ransomware event was limited to file servers.

The FBI says Gunra also collected internal email communications. That raises a second business consequence: even a recoverable Windows file estate does not erase notification, legal, contractual, or fraud risk from exfiltrated mailboxes and collaboration data.


The Windows Locker Is Built for Speed, Not Stealthy Remote Control​

CloudSEK reported in February that it infiltrated Gunra’s affiliate program and reviewed a configurable locker using multi-threaded ChaCha20 plus RSA-4096 encryption. CISA’s new advisory independently describes the same architecture, with the Windows payload using native

FindFirstFileW

and

FindNextFileW

calls to walk files and directories across every accessible drive letter.

The Windows encryptor excludes locations such as

C:\Windows

,

C:\Program Files

, and

C:\Program Files (x86)

, along with extensions needed by the operating system. That selective behavior is deliberate: a ransomware operator benefits when the victim’s Windows environment remains sufficiently functional for executives and administrators to read the ransom note, reach a Tor negotiation site, and assess the business disruption.

Gunra places a ransom note named

R3ADM3.txt

in affected directories and avoids encrypting its own note and files already ending in

.ENCRT

. There is one correction worth making to the government advisory: its technical narrative and multiple independent Gunra analyses identify

R3ADM3.txt

, but the MITRE impact table contains

R34DM3.txt

, with a numeral 4 in place of the letter A. Security teams should tune detections for the widely corroborated

R3ADM3.txt

filename while retaining the alternate spelling as a defensive search term in case the table’s typo has already made its way into rules or reports.

The ransomware binary reportedly has no observable DNS or HTTP activity while it encrypts. That means network-based security products may provide little warning at the precise moment files begin changing. Endpoint telemetry is the control that has to see the final act: high-volume file opens and rewrites,

.ENCRT

creation, ransom-note creation, shadow-copy deletion, and anomalous

wmic.exe

or

cmd.exe

execution.

The advisory gives a representative recovery-inhibition command that deletes shadow copies through WMI. Organizations should detect and block unauthorized shadow-copy deletion where operationally possible, but they should also assume that a local Windows backup strategy alone is insufficient. Gunra has been observed deleting data on backup infrastructure at both a primary data center and a disaster-recovery center.

Linux Recovery Research Does Not Apply to Windows Victims​

One unusual element of the advisory is potentially good news for a narrow set of victims. It says researchers identified a weakness in Gunra Linux ELF variants using the

.GNRA

extension: the encryption keys were generated with a predictable pseudorandom-number process seeded from the current time. Breakglass Intelligence first reported that flaw in March, and CISA now says responders may be able to reconstruct keys from file timestamps and recover Linux files without paying.

That finding should not be generalized to the Windows variant. The advisory does not claim a weakness in Gunra’s Windows encryption, does not provide a Windows decryptor, and continues to characterize the Windows payload as using ChaCha20 plus RSA-4096. A mixed Windows-Linux environment may therefore face two very different recovery situations after the same intrusion.

If Gunra is suspected before encryption begins, the agencies recommend isolating affected hosts, preserving relevant logs and ransom notes, identifying malicious and compromised accounts, and hunting for the actor’s tooling and access paths before applying eviction measures. If encryption has started, preserve samples of encrypted files and notes, avoid wiping systems that may contain forensic evidence, and confirm the platform and extension before making recovery decisions.

Gunra’s documented route from a Fortinet gateway to VDI, Active Directory, OneDrive, SharePoint, backup systems, and Windows file shares leaves little room for a siloed response. The immediate task is to establish whether the remote-access boundary, identity layer, cloud collaboration estate, and backup control plane were all touched—not simply whether a Windows endpoint now has

.ENCRT

files.