Abstract operational timeline showing a narrow intervention window before ransomware encryption.

Gunra Before Encryption: Detect the Ransomware Handoff

The first alert in this composite scenario is almost insultingly small: a privileged account appears on a VPN appliance at 02:14, then authenticates from an address the company has never used. Nothing crashes. No beacon starts chattering. The overnight analyst sees a successful administrative action, not an exploit.

By breakfast, that interpretation is wrong.

A remote-access tool has appeared on an internal server. Archive creation is rising. The backup team has a failed job in both the primary and disaster-recovery environments. Hours later, database servers and NAS volumes are encrypted. The ransom note is the loudest event in the incident, but it is also the least useful detection point.

That sequence matters because the August 10, 2026 joint advisory AA26-222A describes Gunra as an affiliate-driven operation rather than a single, uniform intrusion set. Static indicators will age. The durable defensive problem is recognizing the operational handoff from an internet-facing identity compromise to interactive access, collection, recovery impairment, and finally an offline encryptor.

The intrusion begins with an identity that looks valid

The FBI observed Gunra affiliates exploiting known vulnerabilities in FortiGate firewall and SSL-VPN appliances, including CVE-2024-55591 and CVE-2025-24472, as well as exposed or default credentials and missing account-lockout controls. In observed exploitation of the Fortinet flaws, attackers could create a persistent superuser named forticloud-sync.

The important word is persistent. A patched gateway is not necessarily a clean gateway. This is the same post-compromise problem examined in the FortiOS symlink patch-bypass analysis: remediation must account for attacker-created state, not only the vulnerable code path.

An operator who lands on a perimeter appliance does not need to make noise immediately. The useful questions are quieter: Which authentication material can be reused? Which administrative interface is monitored poorly? Does the appliance provide a route into management networks? Can a new account blend into vendor-managed identities?

For defenders, the corresponding detection unit is not “malicious IP.” It is a state transition:

new privileged appliance identity
  + first-seen source or impossible administrative path
  + remote-service activity into an internal management segment
  = high-confidence investigation candidate

Inventorying appliance-local accounts should therefore produce events, not quarterly spreadsheets. Alert on privileged account creation, privilege changes, unexpected configuration exports, disabled logging, and authentication from sources outside approved administration paths. Preserve those logs off-device. Gunra actors have been observed deleting system and network access logs; a gateway that holds the only copy of its own evidence is a convenient crime scene.

The locker is the last component, not the campaign

Once inside, Gunra affiliates have used legitimate and dual-use tools: OpenSSH, AnyDesk, Google Remote Desktop, MobaXterm, Impacket, Mimikatz, 7-Zip, Rclone, FileZilla, and Microsoft Visual Studio Code. None is sufficient attribution. Together, in the wrong sequence and identity context, they describe an operator.

The practical chain looks like this:

  1. Gain or manufacture a privileged identity on an exposed appliance.
  2. Establish durable remote access and tunnels using familiar administrative protocols.
  3. Discover internal systems and collect credentials.
  4. Stage and exfiltrate sensitive data.
  5. Impair logging and recovery infrastructure.
  6. Deploy a self-contained encryptor to high-value systems.

The actors reportedly favor late-night and early-morning activity, roughly 22:00 to 06:00. Time is not proof, but it changes the baseline. An interactive RDP or SSH session from a VPN appliance into a backup console at 03:00 deserves a different prior probability than the same connection during an approved maintenance window.

Gunra ransomware attack chain from VPN compromise through remote access, exfiltration, backup destruction, and offline encryption.
Gunra’s durable detection surface is the transition between stages, not a single tool or hash.

The tool list also exposes a common detection failure: products are evaluated individually. AnyDesk may be approved. Rclone may support cloud migrations. 7-Zip is everywhere. The useful signal is cross-domain correlation: a newly observed privileged account launches remote access, enumerates file shares, creates unusually large archives, transfers them to an unapproved destination, then touches backup administration.

That is an incident graph, not a hash feed.

Offline encryption removes the network safety net

CloudSEK’s February 2026 analysis found that Gunra’s Windows locker embeds the material it needs to operate without command-and-control connectivity. It uses per-file ChaCha20 encryption and protects key material with an embedded RSA-4096 public key. The analyzed implementation recursively enumerated accessible drive letters and selectively excluded system paths and extensions so the host would remain usable enough to display the extortion instructions.

This design changes containment assumptions. Blocking egress after payload execution may stop additional theft, but it does not stop an encryptor that already carries its keying material and target logic. Network controls buy less time at the final stage than they do during staging and exfiltration.

On Windows, high-value behavioral detections include:

  • a new or uncommon process rapidly opening and rewriting files across multiple volumes;
  • WMI or command-shell activity deleting volume shadow copies;
  • concurrent file renaming to a novel extension and ransom-note creation across directories;
  • privileged access to database, NAS, and backup systems from a host that does not normally administer them;
  • security tooling or logs disabled shortly before high-rate filesystem changes.

A safe lab validation can test the correlation without running ransomware. On an isolated Windows VM containing disposable files, use a benign script to rename copies in a test directory while a separate administrative test invokes a harmless WMI inventory query. Confirm that telemetry preserves process ancestry, user identity, command line, target volume, and event ordering. Do *not* delete shadow copies or touch production backup APIs. The objective is to validate data coverage and correlation latency, not imitate destructive impact.

Linux changes both the speed and the recovery question

Gunra’s Linux branch deserves separate handling. Trend Micro reported in July 2025 that the variant accepted operator-controlled paths, extension filters, partial-encryption settings, block-device targeting, and up to 100 encryption threads. That flexibility is operationally significant on virtualization hosts, NAS platforms, and application servers: an affiliate can trade completeness for speed and target only data with maximum outage leverage.

In March 2026, Breakglass Intelligence identified a cryptographic flaw in analyzed Linux ELF builds. Instead of a cryptographically secure generator, those samples used musl-libc rand() seeded with Unix time for per-file ChaCha20 material. A bounded timestamp window can make seed recovery practical.

That finding is valuable, but narrow:

  • it applies to the affected Linux variant and sample lineage;
  • it does not make the Windows implementation recoverable;
  • operators can rebuild or replace the flawed generator;
  • recovery depends on preserving encrypted files, original timestamps, ransom notes, logs, and the relevant binary.

If an affected Linux incident is suspected, do not “clean up” the evidence before evaluating recovery. Isolate systems, preserve metadata, acquire the executable and encrypted samples, and work from forensic copies. The decryptor decision belongs after variant confirmation, not after a filename match. This is where the broader public-decryptor recovery workflow becomes operationally useful: identify precisely, preserve first, validate tooling offline, then recover.

Backup deletion is a pre-encryption emergency

The most consequential fact in AA26-222A may not be a malware API. In one observed intrusion, Gunra actors deleted backup and archived data from infrastructure at both the primary data center and the disaster-recovery center, before and after ransomware deployment.

If one identity plane can administer production, the backup repository, and the DR copy, “two locations” is geography, not resilience.

Treat these events as imminent-impact signals:

  • retention or immutability policies weakened;
  • backup catalogs, snapshots, or archives deleted in bulk;
  • backup agents disabled across multiple hosts;
  • a production-domain administrator accesses backup control planes for the first time;
  • simultaneous destructive actions affect primary and DR repositories;
  • restore tests or integrity checks are suppressed during an active incident.

Controls should force a different trust path: separate administrative identities, phishing-resistant MFA, dedicated management workstations, repository-level immutability, delayed deletion where supported, dual authorization for destructive changes, and telemetry exported to a system the backup administrator cannot erase. “Offline” must be verified by a restore exercise under loss-of-domain conditions.

Build detections around transitions

A defensible Gunra program does not require perfect family attribution. It requires detections positioned before the encryptor:

*Perimeter to identity.* Alert on new appliance superusers, first-seen administrative sources, configuration tampering, and unexpected identities such as forticloud-sync. Hunt historical configuration and authentication records after patching.

*Identity to remote access.* Correlate appliance sessions with inbound RDP, SMB, SSH, and newly installed remote-management software. Enforce allowlists for management paths rather than only destination ports.

*Remote access to collection.* Detect unusual archive volume, Rclone/FileZilla transfers, large outbound flows, and file-share enumeration under recently privileged accounts. Baseline by identity and host role.

*Collection to recovery impairment.* Escalate any backup-policy change, snapshot deletion, log clearing, or endpoint-control disablement during the same identity session. These should page an incident responder, not create a low-priority ticket.

*Impairment to encryption.* Use EDR and filesystem telemetry for rapid multi-volume rewrites, extension changes, ransom-note fan-out, and shadow-copy deletion. Isolate affected hosts and revoke the initiating identities while preserving evidence.

The sequence is more resilient than an IOC-only strategy because affiliates change infrastructure, builders, and tooling. Their operational dependencies remain: they need access, credentials, time, data movement, recovery impairment, and execution on valuable assets.

Strategic takeaways

Gunra is dangerous less because its components are exotic than because its affiliate model packages them into a repeatable business process. The defender’s advantage sits in the joins between stages.

A VPN appliance creating a privileged account is an identity event. A remote-access binary appearing afterward is a continuity event. Archive creation and outbound transfer are collection events. Backup deletion is an impact precursor. Encryption confirms what the preceding telemetry already said.

Measure the program against that chronology. Can the SOC connect appliance, identity, endpoint, network, and backup evidence quickly enough to interrupt the chain? Can responders revoke access without destroying the artifacts needed to evaluate Linux recovery? Can the organization restore when the domain and the primary backup administrators are assumed compromised?

If the first enterprise-wide alert is the ransom note, the detection stack observed the incident. It did not defend the organization.

💜 Enjoyed this content? Support the blog with USDT (TRC20):

TX7obcjHQbDUXb4mGqoASEu1QFTKT2CFGG

View support page

Paulo Rigonato

Security Engineer | Red Team | Pentest

Offensive security specialist with experience in assessments, pentesting, and Red Team operations. He works in enterprise cybersecurity and continues to share knowledge through this blog.

Certifications: OSCP | eWPTXv2 | ITILv4

💻 GitHub 🔗 LinkedIn

Similar Posts