Gunra Defeated Multi-Factor Authentication by Editing the Authentication Server

WASHINGTON, 15 AUG 2026 — Six agencies, including South Korea's National Police Agency, published a joint advisory on Gunra ransomware on 10 August. Buried in it is a detail worth more than the rest of the document: the operators defeated multi-factor authentication by editing the authentication server.

Not by phishing a code. Not by stealing a session. They altered the files on a virtual desktop authentication portal so that one specific one-time password, chosen by them, always succeeds.

Who published it, and why that matters

The advisory carries the FBI, CISA, the Department of Defense Cyber Crime Center, the National Security Agency, the United States Secret Service and the Republic of Korea's National Police Agency.

Six-agency advisories with a foreign police force attached are not routine. The Korean presence means victims or infrastructure are in that jurisdiction, bringing the threat into our region rather than near it. The named victim geography runs across the Americas, Europe, the Middle East, Africa and Asia-Pacific.

What Gunra is

It is derived from Conti source code leaked in 2022, which is a reminder that a code leak does not expire. Four years on, that codebase is still producing working criminal tooling under new management, now sold as a service with a management panel, a configurable builder and cross-platform payloads. The group also operates under the name Golden Community.

Targets include healthcare, financial services, manufacturing, transport, utilities, academia and government. One victim had tens of terabytes exfiltrated.

The way in is a firewall you did not patch

Initial access is unglamorous and entirely preventable. The advisory names two FortiOS authentication-bypass flaws, CVE-2024-55591 and CVE-2025-24472, both long since patched by the vendor.

The operators use them to create accounts on the firewall itself. The account name to search for, forticloud-sync, is chosen to look like a legitimate service integration and is meant to survive a casual review of the user list.

Credential exposure and weak SSH access controls on VPN gateways round out the entry routes. Every one of these is a perimeter appliance, which is the same lesson this week's Cisco advisory carried: the device your architecture treats as the boundary is an ordinary application, and it is where the intrusions start.

The authentication backdoor

This is the part that should change what you check tomorrow.

Most thinking about multi-factor authentication assumes the attack targets the user through a phished code, a fatigue-prompted approval, or a swapped SIM. The corresponding defences — user training, number matching, hardware tokens — follow that same assumption.

Gunra went after the verifier instead. By modifying files on the authentication portal, the operators arranged for a chosen code to be accepted permanently. Every control built around the user still functions perfectly, and none of them helps, because the verifier has been subverted to approve the attacker's code.

It is a durable form of persistence. It survives password resets. It generates no failed-login pattern. And it will not appear in any review that examines user behaviour rather than the integrity of the authentication system itself.

The practical question for a defender is uncomfortably simple. When did you last verify that your authentication portal's files match what the vendor shipped? For most organisations the honest answer is never, because it is not a question the tooling prompts you to ask.

What "as a service" changes for a defender

Gunra became a ransomware-as-a-service operation in January, and that detail changes how its indicators should be treated.

Under an affiliate model the payload is shared but the intrusion is not. Different affiliates buy the builder and bring their own access, their own tooling and their own working hours, so two Gunra incidents can look almost nothing alike up to the moment of encryption. The file extension is stable; the route in is whatever that affiliate happened to have.

The practical consequence is that indicators tied to the encryption stage age well and indicators tied to the intrusion age badly. Hunting for the forticloud-sync account is worth doing today and may be worthless in a month, because it belongs to a particular affiliate's habit rather than to the malware. Detections built on behaviour — unexpected accounts on a firewall, shadow copies deleted through WMI, authentication files that no longer match the vendor's — keep working across affiliates in a way a list of names does not.

The mistake that gives Linux victims their files back

There is one piece of good news, though it is specific to the Linux builds.

The Linux builds, which write files with a .GNRA extension, generate encryption keys using a weak pseudorandom number generator seeded with the current time. This is a textbook cryptographic error. A predictable seed makes the key recoverable.

Recovery is possible without paying, provided file timestamps and system logs have been preserved. That proviso is doing real work. The instinct after an incident is to clean up, and cleaning up destroys the timing evidence the recovery depends on.

The operational instruction is narrow and worth following before you need it. If Linux systems are encrypted with .GNRA files, preserve timestamps and logs, and do not pay while that recovery path is open. The Windows payloads carry no equivalent weakness.

What to check this week

The advisory's mitigation list is long. Four items are worth doing regardless of whether you think Gunra is aimed at you.

Patch CVE-2024-55591 and CVE-2025-24472 on anything internet-facing, and confirm rather than assume. Search domain controllers and firewalls for unfamiliar accounts, with forticloud-sync as the specific string. Verify the integrity of your authentication portal against vendor-supplied files. And alert on shadow-copy deletion driven through WMI as a high-severity event, because that is the step immediately before encryption and one of the last moments intervention is still possible.

The advisory also suggests alerting on privileged activity between 10 at night and 6 in the morning. That advice is sound in principle and needs local calibration. In an organisation with staff across several time zones — which describes most regional businesses of any size — off-hours administration is normal rather than suspicious.

What we could not establish

Which organisations were hit, in which countries, or how the 51-victim figure is counted — whether it reflects confirmed intrusions, leak-site postings, or both. Leak-site counts routinely overstate, because operators list victims who did not pay regardless of how much was actually taken.

Also unestablished: whether any organisations in Southeast Asia are among the victims, the ransom demands and payment rates, whether the Korean involvement stems from victims or from infrastructure, how many affiliates operate the service, and whether the Linux cryptographic flaw has since been corrected in newer builds.

What to watch

Whether the Linux weakness gets fixed. It is a small change for the operators and it closes the only free route out, so the recovery window should be treated as temporary.

Whether authentication-server tampering shows up in other campaigns. A technique that defeats every user-side control while leaving no failed-login trail is valuable enough to be copied, and this advisory has now documented it publicly.

And whether the Fortinet flaws keep appearing as entry points. Both were patched long ago, so every future intrusion through them is a statement about patching practice rather than about the vendor.