A Backdoor Named forticloud-sync: Inside the Gunra Ransomware Advisory and Two Fortinet CVEs From Early 2025

On 10 August 2026, six agencies put their names on the same document: CISA, the FBI, NSA, the DoD Cyber Crime Center, the U.S. Secret Service, and South Korea’s National Police Agency. The advisory is AA26-222A, part of the #StopRansomware series, and its subject is a double-extortion group called Gunra. Nothing about that is unusual on its own — joint ransomware advisories aren’t rare. What makes this one worth a full read is what’s actually inside it: two Fortinet CVEs that are both well over a year old, a persistent backdoor account with a name that sounds like legitimate telemetry, and an MFA bypass that doesn’t trip a single alert on the identity provider that’s supposed to be watching for exactly this.

None of what follows requires reproducing an attack to be useful. The advisory itself, and the technical write-ups that followed it, already lay out the mechanism in enough detail to understand what happened and what to check for. That’s the point of this post.

Who Gunra is

Gunra first appeared in April 2025 as a double-extortion ransomware variant built on source code leaked from Conti back in 2022 — the same leak that’s quietly seeded a good portion of the ransomware landscape since. By January 2026 it had grown into a structured ransomware-as-a-service operation, branded “Golden Community,” running a Tor-based leak site and actively recruiting affiliates and initial access brokers on dark web forums. The targeting is broad: healthcare, financial services, manufacturing, transportation, government, academia, and utilities, with CloudSEK’s research pointing to Brazil and South Korea as the most-hit countries, followed by Canada and Japan. Negotiation happens over a Tor portal or qTox, victims are given five to seven days before data starts appearing on the leak site, and demands have reportedly run into the tens of millions of dollars.

None of that is what makes this advisory worth writing about. What’s interesting is how Gunra gets in, and what it does once it’s there.

Two Fortinet CVEs, both over a year old

The advisory names two initial access vulnerabilities, both authentication bypasses in FortiOS and FortiProxy, both classified under CWE-288 — authentication bypass using an alternate path or channel. That classification is doing a lot of work: neither of these is a case of guessing a password or exploiting a memory-corruption bug. Both are cases where a device has more than one road into administrative access, and one of those roads doesn’t actually check who’s driving.

CVE-2024-55591 sits in FortiOS and FortiProxy’s Node.js websocket module. Fortinet’s own advisory (FG-IR-24-535) describes it as letting a remote, unauthenticated attacker obtain super-admin privileges through crafted requests to that module. It carries a CVSS v3.1 score of 9.8, was disclosed on 14 January 2025, and — this is the detail that should sting a little — was already being actively exploited as a zero-day from November 2024, weeks before the patch existed. It’s since been used by multiple ransomware operations beyond Gunra, including Qilin and LockBit-affiliated actors, which is a pattern worth noticing on its own: one authentication bypass, reused across an entire ecosystem of ransomware brands, over more than a year.

CVE-2025-24472 is a different road to the same destination. It lives in Fortinet’s Security Fabric — the mechanism, covered in NSE4 Part 2, that lets FortiGate devices exchange information and coordinate operations across an organization’s fleet. That coordination happens over its own internal channel, separate from the ordinary admin GUI login, on the reasonable-sounding assumption that traffic arriving from another Fortinet device in the Fabric is already trusted. CVE-2025-24472 breaks that assumption: a crafted CSF (Fabric) proxy request can win super-admin privileges on a downstream device, provided the attacker already knows the upstream and downstream devices’ serial numbers and the Security Fabric is enabled between them. Published 11 February 2025, one month after the first CVE, at CVSS v2 10.0 / v3 8.1.

Both are in CISA’s Known Exploited Vulnerabilities catalog. Both have had patches available since early 2025. The advisory isn’t describing a fresh zero-day; it’s describing two well-documented, well-patched bugs that are still working, more than eighteen months later, because enough internet-facing FortiGate and FortiProxy devices out there haven’t been patched, or were compromised before they were.

The account that names itself after something legitimate

Here’s the detail worth actually checking your own devices for: on both paths, the advisory documents Gunra actors using the access to create a persistent local super-admin account named forticloud-sync, with a hardcoded password baked in by the actor. It’s a well-chosen name — it reads like a piece of legitimate Fortinet cloud-integration plumbing, the kind of account an administrator might glance past in a user list without a second thought. That’s the entire point of naming it that way. If you administer FortiGate or FortiProxy appliances, this is a five-minute check worth doing today: pull the local admin account list and confirm you recognize every entry, particularly anything that looks like it belongs to Fortinet’s own infrastructure rather than your organization’s. This site has now covered three separate Fortinet trust-boundary failures this month alone — FortiManager’s FGFM certificate reuse, FortiWeb’s RADIUS wildcard bypass, and FortiBleed’s credential harvest — and a persistent backdoor account is exactly the kind of durable foothold all of them were ultimately used to plant.

The MFA bypass that leaves no trace at the identity provider

This is the part of the advisory that’s genuinely different from the usual “phished the MFA code” story, and it’s worth slowing down for. The advisory describes two distinct techniques Gunra used to get past multi-factor authentication on corporate VPN and virtual desktop infrastructure (VDI):

The first is closer to what you’d expect: once inside an SSL-VPN appliance, the actors used its own traffic-inspection capability against its owners, harvesting employee credentials and session cookies as they authenticated to the organization’s VDI portal, then replaying those sessions to skip the login step entirely — MITRE ATT&CK T1550, pass-the-cookie by another name.

The second technique is the one worth genuinely understanding. Rather than stealing a valid session, Gunra actors modified the authentication-processing files on the VDI authentication portal server itself, so that one specific, attacker-chosen one-time-password value would always be accepted as valid — for anyone, indefinitely, until someone found and reverted the change. This is MITRE ATT&CK T1556.006, Modify Authentication Process: Multi-Factor Authentication, and the mechanism matters because of what it does to detection. A stolen session cookie or a phished OTP still shows up as an authentication event at the identity provider — a login, from a location or device that might look wrong on closer inspection. This doesn’t. The IdP, the authenticator app, and every log downstream of the authentication decision see a completely normal, successful MFA challenge and response, because as far as that layer is concerned, it was. The forgery happens one layer below, inside the logic that decides whether the OTP was correct in the first place. If your MFA monitoring lives entirely in your identity provider’s dashboard, this technique is invisible to it by design. The place to catch it is file integrity monitoring on the authentication portal server itself, and a baseline of what “normal” looks like for those specific files.

From backdoor to domain, with tools this site has already covered

Once past authentication, Gunra’s post-exploitation toolkit reads like a highlight reel of legitimate admin and red-team software repurposed wholesale: Impacket’s secretsdump.py for NTDS and LSA credential extraction (the exact mechanics are in Impacket Part 7), psexec.py and smbclient.py for lateral movement over SMB (see Impacket Part 6), Mimikatz for credential harvesting, and Sliver as a C2 framework alongside legitimate remote-access tools like AnyDesk and Google Remote Desktop that blend into normal IT traffic. For exfiltration, the advisory describes data being pulled from OneDrive and SharePoint, archived with 7-Zip or WinRAR, and shipped out over Rclone to Mega or plain FTP via FileZilla — nothing exotic, all tools that show up in a hundred legitimate IT workflows, which is exactly why this stage of an intrusion is so easy to miss on egress monitoring alone.

One incident detail from the broader reporting on this campaign is worth sitting with regardless of which ransomware group is involved, because it’s an architecture lesson, not a Gunra-specific one. At one victim organization, the actors used stolen VDI credentials to reach a central access-control server over SSH and extract its master encryption key — the key that decrypted stored passwords for every enterprise server the organization ran, including both its primary and disaster-recovery data centers. The two sites were geographically separate but shared the same credential root, so once that one key was gone, both backup copies were reachable and both got deleted before the encryptor ever ran. Geographic redundancy protects against a data center burning down. It does nothing against a compromised credential that both sites happen to trust equally. The only backup architecture that actually survives this scenario is one where the recovery copy sits in a genuinely separate trust domain — different credentials, ideally a different account or organization entirely — not just a different building.

What actually gets encrypted, and the one honest silver lining

The ransomware payload itself uses ChaCha20 for bulk file encryption with RSA-4096 protecting the ChaCha20 keys, runs multi-threaded, and — a small mercy for anyone trying to keep a business limping along during an incident — deliberately skips C:\Windows, C:\Program Files, and C:\Program Files (x86) so the operating system itself keeps booting. Encrypted files pick up a .ENCRT, .CRYPT, or .GNRA extension depending on the build, and every affected directory gets a ransom note named R3ADM3.txt with a client ID and negotiation instructions.

There’s a genuine exception to all of this, and it only applies to the Linux variant. Researchers at Breakglass Intelligence found that Gunra’s Linux ELF encryptor seeds its random number generator with srand(time(NULL)) — the current Unix timestamp — before generating the ChaCha20 key and nonce using musl libc’s rand(), a linear congruential generator that was never intended to be cryptographically secure. Seeding a key generator with the current time collapses what should be an astronomically large keyspace down to roughly one candidate seed per second of encryption. For an encryption run lasting an hour, that’s on the order of 3,600 seeds to try — brute-forceable in minutes once you know roughly when the encryption started, which file timestamps and system logs will usually tell you. The important caveat, stated plainly by every source covering it: this applies only to the Linux .GNRA variant. The Windows build uses Windows’ CryptGenRandom(), a proper cryptographically secure generator, and is not affected by this flaw in any way. If you’re dealing with a Linux Gunra infection, the advisory’s practical advice is to preserve the encrypted files and their timestamps exactly as they are and get a specialist involved before paying anything. If it’s Windows, this shortcut doesn’t exist, and the advice reverts to the usual: contact law enforcement, restore from backup, and — per the section above — hope that backup didn’t share a trust domain with everything else.

What to actually check

The patches for both CVEs have existed since early 2025, so the first action is the obvious one: confirm every internet-facing FortiOS and FortiProxy device is on a fixed release, and treat any that aren’t as though they’re already compromised rather than merely exposed. Past that, audit local admin accounts on every FortiGate and FortiProxy device for anything resembling forticloud-sync or another account nobody can immediately account for. Extend file integrity monitoring to the VDI or SSO authentication portal itself, not just the identity provider’s own logs, since that’s the layer this particular MFA bypass operates beneath. Enforce least privilege and MFA on every administrative and remote-access account regardless — it didn’t stop this particular technique, but it stops plenty of others, and the advisory itself still lists it as a core mitigation. And build backup architecture around the assumption that any credential trusted by production is eventually going to be a credential an attacker has, which means recovery copies belong in a trust domain production access can’t reach, not just a second building.

The advisory closes with a detection note worth repeating verbatim in spirit: the encryption stage itself generates almost no useful network signal, so the things actually worth watching for are behavioral — wmic.exe shadowcopy delete or equivalent shadow-copy destruction, and a disproportionate share of administrative activity clustering between 10 p.m. and 6 a.m., when most legitimate admin work isn’t happening. Detect on behavior, not egress, because by the time there’s anything to see on egress, the backups are usually already gone.