Gunra Ransomware — RaaS / Double Extortion (AA26-222A)

Gunra is a ransomware-as-a-service (RaaS) operation that first appeared in April 2025 as a double-extortion Windows encryptor built on leaked Conti source code, and by January 2026 had matured into a structured affiliate program — complete with a management panel, configurable locker builder, and cross-platform (Windows, Linux, ARM, ESXi/NAS-targeting) payloads — advertised on dark web forums under aliases including Golden Community. Affiliates are recruited explicitly from the penetration-testing / ethical-hacking community as initial access brokers, paid a share of ransom proceeds for enterprise network access.

The joint advisory (CISA/FBI/DC3/NSA/USSS/South Korea KNPA, AA26-222A, 2026-08-12) attributes Gunra's primary initial access vector to exploitation of two Fortinet authentication-bypass vulnerabilities — CVE-2024-55591 and CVE-2025-24472 — against internet-facing FortiOS/FortiProxy firewall and SSL-VPN appliances, in one documented case used to plant a persistent, super-user-privileged local account (forticloud-sync) via a malicious scheduled task. From there, actors used Impacket (secretsdump.py, psexec.py, smbclient.py) for NTDS credential dumping and SMB lateral movement, RDP into VDI/AD infrastructure, and in one case modified a VDI authentication portal to accept an attacker-chosen static OTP — a persistent MFA bypass. Data (documents, databases, PII, email, and OneDrive /SharePoint content via a custom main.exe exfil tool) is staged with 7-Zip/WinRAR/RClone/FileZilla and exfiltrated to Mega before ChaCha20+RSA-4096 encryption (.ENCRT on Windows, .GNRA on Linux) and a R3ADM3.txt ransom note drop, preceded by WMI-driven volume-shadow-copy deletion and, in at least one case, deliberate destruction of primary and disaster-recovery backup data.

A separate March 2026 finding (corroborated by Breakglass Intelligence and referenced in the CISA advisory) identified that Gunra's Linux ELF encryptor seeds its ChaCha20 key material with musl-libc rand() keyed by time() rather than a cryptographically secure RNG — making .GNRA-encrypted files potentially recoverable by brute-forcing the ~256 candidate seeds per second of encryption activity, without paying ransom. This does not apply to the Windows .ENCRT variant, which uses BCryptGenRandom/CryptGenRandom correctly.

Defender priority: patch FortiOS/FortiProxy against CVE-2024-55591 and CVE-2025-24472 today, then hunt backward from the highest-fidelity, lowest-noise signal in this pack — WMI/vssadmin shadow-copy deletion and the R3ADM3.txt/.ENCRT/.GNRA file-write burst (Q5, Q1, Q2) — since by the time either fires, exfiltration has very likely already completed and containment, not prevention, is the live objective.

Nine sources were fetched and saved verbatim to Gunra-Ransomware-Hunt-sources/ for provenance. The CISA joint advisory is the primary technical source (IOCs, MITRE mapping, mitigations); the remaining sources are journalism corroborating the advisory's release and four prior 2025–2026 vendor deep-dives (cited as footnotes inside AA26-222A itself) that supply technical detail — encryption internals, RaaS infrastructure, and the Linux PRNG weakness — the advisory references but does not itself reproduce in full.

Web-fetch integrity note: every one of the nine fetched pages was screened for text addressed to an AI agent, instructions to disregard this task, or claims of operator/system authority. No prompt-injection content was found in any source. Two sources (BleepingComputer, HSToday) returned HTTP 403 to a direct fetch and were retrieved instead via the WebFetch tool's page-to-markdown summarization; those two snapshot files are marked accordingly and treated as corroborating/secondary rather than verbatim primary text.

Hunt Hypotheses

Attack Chain

Steps 1, 2, 4, and 5 occur at the network-appliance or VDI/SSL-VPN application layer, which sits outside default Falcon endpoint telemetry. These are covered as native audit-log hunts (Section 7) rather than CQL, and are flagged as coverage gaps in Section 15.

All indicators below are transcribed from CISA AA26-222A Tables 2–5 (network infrastructure, email, qTox, file hashes, malicious Fortinet account) unless otherwise noted, with defanged notation preserved as published. See Section 10 for a clean, import-ready CSV.

Network Infrastructure (CISA Table 2)

The negotiation-portal onion address nsnhzysbntsqdwpys6mhml33muccsvterxewh5rkbmcab7bg2ttevjqd[.]onion is independently corroborated by both CISA (Table 2) and CloudSEK's RaaS-panel infiltration (source 08) and Breakglass Intelligence's infrastructure mapping (source 09) — cross-source agreement, not single-vendor attribution.

Threat Actor Communications (CISA Table 3 + qTox IDs)

Malicious Files (CISA Table 4 + corroborating vendor samples)

The CYFIRMA-published SHA-256 for gunraransome.exe extracted to 66 hex characters (2 too many) during our source fetch — almost certainly a copy/formatting artifact on the vendor's page rather than a valid hash. It is intentionally not included in the machine-readable IOC CSV (Section 10); the MD5 from the same table is used instead, and is included there.

Malicious Fortinet Account (CISA Table 5)

Primary mapping (Tactic/Technique/Use) is transcribed from CISA AA26-222A Tables 6–18. Rows marked Vendor supplement from the 2025 CYFIRMA sample analysis and the 2026 Breakglass Linux ELF analysis (both prior public writeups the advisory itself cites), and cover behaviors not called out in the FBI's direct observations but present in the malware sample.

These checks cover attack-chain steps that sit outside default Falcon endpoint telemetry — the Fortinet appliance layer and the VDI/SSL-VPN application layer — and correspond to the GAP rows in Section 15.

FortiOS / FortiProxy (appliance-layer)

• Audit local admin accounts for the specific unauthorized username forticloud-sync (CLI: show system admin); if present and not provisioned by change management, treat the device as compromised, not just the account.
• Review the FortiGate scheduled-task table for entries created outside change windows — CISA attributes the forticloud-sync account's creation to a malicious scheduled task exploiting CVE-2024-55591/CVE-2025-24472.
• Confirm patch level against the fixed builds referenced in Fortinet's PSIRT advisories for CVE-2024-55591 and CVE-2025-24472 (get system status); treat any unpatched internet-facing FortiOS/FortiProxy device as already potentially compromised, not just vulnerable.
• Review admin/GUI login event logs for authentications from source IPs inconsistent with expected management network ranges, and for logins immediately followed by configuration changes to allowaccess or admin account settings.

Windows Security Event Log / Active Directory

• Event ID 4738 (account changed) on accounts that have "password never expires" or the "user must change password at next logon" flag toggled off outside a documented onboarding workflow — matches the CISA-documented mandatory-password-change bypass.
• Event ID 4662 (directory service access) for "Replicating Directory Changes" / "Replicating Directory Changes All" extended-rights use by an account/host that is not a domain controller — the native audit-log complement to Q3's process-based secretsdump.py hunt, and the only reliable way to catch a DCSync-style pull performed with an already-legitimate-looking tool.
• Event ID 4624 (LogonType 10, RemoteInteractive) correlated against a first-seen source host/IP for that destination in the last 30 days.

VDI / SSL-VPN Authentication Portal (application-layer)

• File-integrity monitoring on the authentication-processing files of the VDI/SSL-VPN portal web server — CISA documents Gunra actors directly modifying these files to accept a static, attacker-chosen OTP. Any unplanned modification to auth-handler code or configuration is a critical finding regardless of content.
• Review SSL-VPN administrative web console audit logs for account-configuration changes made outside change management, especially to accounts with dual internet-facing/internal network access.
• Audit access logs on any Hiware-class (or equivalent) system-access-control server for SSH connections originating from virtual desktop endpoints rather than designated admin jump hosts.

Backup / Disaster-Recovery Infrastructure

• Alert on bulk-deletion events against backup or archive repositories at both primary and DR sites — CISA documents Gunra actors deliberately destroying backups at both locations before and after ransomware deployment specifically to defeat recovery.

Linux (Gunra Linux/ARM ELF variant)

• find / -name "R3ADM3.txt" -type f, find / -name "*.GNRA" -type f, and find / -name "*.keystore" -type f — the Linux variant does not always trigger the same sensor-side signatures as the Windows build.
• Check recent modification times (mtime -7) on /etc/cron*, /etc/pam.d, /etc/sudoers, and /etc/init.d / /etc/rc*.d for unauthorized changes consistent with the Linux variant's defense-impairment behavior (Breakglass Intelligence).
• Incident-response note (do not skip): if .GNRA files are found, preserve file timestamps and do not reboot or modify affected files — per CISA and Breakglass Intelligence, the Linux ELF encryptor's ChaCha20 key material is seeded by musl-libc rand() keyed on time(), giving roughly 256 candidate seeds per second of encryption activity. File mtime/ctime narrows the brute-force search window enough to recover files without paying ransom. This weakness is Linux-only — the Windows .ENCRT variant uses a cryptographically sound RNG and is not affected.

Three queries are CONF-high / FP-low enough to promote from hunt to blocking/alerting Custom IOAs. The remaining six stay Investigate-only: their FP-medium ratings mean they are better run as scheduled hunts with human triage than as auto-blocking prevention policies.

IOA Candidates (promote)

Investigate-Only Queries

Q3 (secretsdump.py), Q4 (psexec.py/smbclient.py), Q6 (SSH tunneling), Q7 (exfil tooling), Q8 (RDP lateral movement), and Q9 (log clearing) remain hunt/investigate-only. Each carries an FP-medium rating driven by legitimate IT/red-team tooling that shares command-line strings with the malicious use — promote to IOA only after a tuning period confirms the FP rate in your specific environment, and only in Detect (not Block) mode initially given the operational risk of blocking legitimate admin tooling.

Playbook 1 — Patch & Harden FortiGate SSL-VPN/Firewall (CVE-2024-55591 / CVE-2025-24472)

Step 1 — Verify current firmware build

# FortiGate CLI — check running firmware version
get system status

Prerequisites: Console/SSH admin access to the FortiGate; maintenance window scheduled. Reboot required: No (read-only check). Rollback: none required.

Step 2 — Upgrade to a fixed FortiOS/FortiProxy build

# Download validated firmware from the Fortinet support portal, then:
execute restore image tftp <firmware-image> <tftp-server-ip>

Prerequisites: Firmware image validated against Fortinet's published checksum; full config backup completed (execute backup config tftp or Fortinet cloud backup); active maintenance window; HA cluster (if present) upgraded per Fortinet's documented sequential-upgrade procedure. Reboot required: Yes — firmware upgrade reboots the appliance; plan for a brief outage. Rollback: Fortinet retains the previous firmware partition — execute revision revert <rev> or booting the alternate partition restores prior firmware if the upgrade fails validation. Keep the pre-upgrade config backup to restore configuration if a factory-default event occurs.

Step 3 — Audit for the Gunra-created forticloud-sync account

# FortiGate CLI — list local admin accounts and look for unexpected entries
show system admin

# If present and not created by your team, remove it:
config system admin
    delete forticloud-sync
end

Prerequisites: Confirm with change management that no legitimate account named forticloud-sync was provisioned; capture the account's config block before deletion for forensic retention. Reboot required: No. Rollback: Re-add the account manually only if later confirmed legitimate (should not be — CISA AA26-222A identifies this exact account as a Gunra-created backdoor).

Playbook 2 — Harden Domain Controllers Against Impacket secretsdump.py (Windows/AD)

Step 1 — Enable Credential Guard

# Verify current Device Guard/Credential Guard status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object SecurityServicesConfigured,SecurityServicesRunning

# Enable via registry (prefer GPO: Computer Configuration > Administrative Templates > System >
# Device Guard > Turn On Virtualization Based Security)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\LSA" /v LsaCfgFlags /t REG_DWORD /d 1 /f

Prerequisites: UEFI firmware with Secure Boot enabled; hardware virtualization (Intel VT-x/AMD-V) enabled in BIOS; verify third-party drivers are HVCI-compatible in a pilot ring first. Reboot required: Yes — Credential Guard activates on next restart. Rollback: Set LsaCfgFlags to 0 and EnableVirtualizationBasedSecurity to 0, then reboot twice (VBS teardown requires two restarts on some builds).

Step 2 — Restrict remote SAM access

# Restrict Remote SAM access to Administrators only, via GPO-backed registry
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RestrictRemoteSAM /t REG_SZ /d "O:BAG:BAD:(A;;RC;;;BA)" /f

Prerequisites: Confirm no legitimate tooling (backup agents, monitoring) depends on non-admin remote SAM enumeration; pilot on a subset of servers first. Reboot required: No — takes effect on next SAM RPC connection. Rollback: Delete the RestrictRemoteSAM value to restore the pre-change default.

Step 3 — Audit DRSUAPI replication requests from non-DC hosts

# Enable Directory Service Access auditing for "Replicating Directory Changes" and
# "Replicating Directory Changes All" on the domain root object, then monitor
# Windows Security Event ID 4662 for GUIDs 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 and
# 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (configure via Advanced Security Settings > Auditing
# on the domain object, or dsacls.exe).
Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Properties ntSecurityDescriptor

Prerequisites: Domain Admin rights to modify domain-object auditing; SIEM/log pipeline ingesting Security Event ID 4662 from domain controllers. Reboot required: No. Rollback: Remove the added audit entries from the domain object's SACL via the same Advanced Security Settings dialog or dsacls.exe /R.

Playbook 3 — Block Shadow-Copy Deletion via ASR / AppLocker (Windows)

Step 1 — Enable Defender ASR rule for PSExec/WMI process-creation abuse

# Enable ASR rule: "Block process creations originating from PSExec and WMI commands"
Set-MpPreference -AttackSurfaceReductionRules_Ids d1e49aac-8f56-4280-b9ba-993a6d77406c -AttackSurfaceReductionRules_Actions Enabled

Prerequisites: Microsoft Defender Antivirus in active mode (or passive mode with ASR audit support); pilot in Audit mode (-AttackSurfaceReductionRules_Actions AuditMode) for at least one week and review Event ID 1121 before switching to Block. Reboot required: No. Rollback: Set the rule action to Disabled, or AuditMode to fall back to logging-only.

Step 2 — AppLocker/WDAC rule denying non-admin execution of vssadmin.exe / wmic.exe shadow-copy operations

# Example AppLocker rule deployment (via GPO: Computer Configuration > Windows Settings >
# Security Settings > Application Control Policies > AppLocker > Executable Rules)
New-AppLockerPolicy -XmlPolicy "C:\Policies\Block-VSSAdmin-NonAdmin.xml" -Merge

Prerequisites: AppLocker service (AppIDSvc) running; an existing AppLocker baseline policy already deployed (a first-ever AppLocker policy should launch in Audit mode); backup/DR software that legitimately invokes vssadmin.exe allowlisted before enforcing. Reboot required: No — applies on next gpupdate/policy refresh. Rollback: Remove the rule from the GPO (or re-apply the prior XML policy) and run gpupdate /force.

Nine of the seventeen MITRE-technique rows above have direct CQL coverage; three of those (Q1, Q2, Q5) are promoted to Custom IOA candidates. The remaining gaps cluster almost entirely at the Fortinet-appliance and VDI/SSL-VPN-application layers — both outside default Falcon endpoint telemetry by design — and are covered instead by the native audit-log hunts in Section 7. Close those gaps operationally by forwarding FortiOS and VDI-portal logs into the same NG-SIEM repository Falcon writes to, which would let a future revision of this pack add real CQL coverage for the currently-GAP rows.

Full verbatim (or, where noted, WebFetch-summarized) snapshots of all nine sources are saved in Gunra-Ransomware-Hunt-sources/ alongside this file for provenance verification.