Gunra Ransomware: Protect Credentials and Recovery Secrets During an Incident

A joint CISA, FBI, NSA, U.S. Secret Service, DC3 and South Korean police advisory on Gunra ransomware documents an identity and secret-handling problem as much as a malware problem. The actors exploited internet-facing devices, captured credentials and session information, dumped domain password hashes, decrypted stored server passwords, accessed OneDrive and SharePoint data, and then damaged recovery options before encryption.

The advisory, published on August 10, 2026, does not say that a secure transfer tool would have prevented these intrusions. A compromised administrator endpoint, authentication server or browser can expose material before or after encryption. It does show why incident teams should stop distributing new recovery secrets in the same email, chat and identity plane that may already be under attacker control.

The Gunra chain crosses several trust boundaries

Authorities observed initial access through known vulnerabilities in internet-facing FortiOS and FortiProxy systems, VPN access-control weaknesses, and default credentials on an SSL-VPN appliance without account lockout. From there, actors used stolen VDI session information, RDP and SMB to reach privileged systems and IT staff desktops.

Session cookies were reused to impersonate legitimate users.
Authentication files were modified so an attacker-selected OTP value succeeded.
secretsdump.py was used against domain controllers to obtain password hashes.
A symmetric key stolen from an access-control server decrypted stored enterprise-server passwords.
Business documents, databases, personal data and email were collected before encryption.

Resetting one password addresses only one item in that chain. Response must revoke sessions and tokens, verify the integrity of the authentication service, rotate privileged credentials from known-clean devices, and check whether recovery accounts or server-side secret stores were reached.

Do not build the recovery channel on the compromised channel

During a live incident, teams urgently exchange temporary administrator passwords, API tokens, cloud break-glass credentials, decryption material, backup access and forensic-upload links. The fastest reflex is often to paste them into the incident chat or email thread. If the attacker has email, collaboration, VDI or administrator sessions, that convenience can hand over the recovery path.

Move coordination to a pre-approved clean channel. Verify participants through a separate method and do not reuse a workspace whose sessions are in scope for compromise.
Issue short-lived, least-privilege secrets. A temporary token for one task and one system limits what a captured link can unlock.
Separate the message from the decryption capability. Avoid placing a ciphertext, key and explanation in one durable conversation history.
Require dual control for crown-jewel recovery. Threshold sharing or approval by two independently verified people reduces single-account failure.
Expire and rotate after use. Treat every incident credential as temporary and record its owner, recipient, purpose and revocation time without logging the secret itself.

One-time encrypted links reduce exposure, not endpoint risk

A one-time encrypted transfer can reduce plaintext left in mailboxes and chat logs, constrain the viewing window and make reuse harder. Browser-to-browser transfer can reduce server-side payload retention. Threshold sharing can require more than one custodian for a recovery secret. These are useful properties when the delivery path remains trustworthy.

They do not rescue a compromised browser, administrator workstation, malicious extension, stolen authenticated session or altered identity service. Before sending a new secret, establish a known-clean device and verify the recipient independently. After sending, rotate the credential as soon as its narrow task is complete.

Cloud file transfer belongs in the same threat model

The FBI observed Gunra targeting OneDrive and SharePoint and using archives and legitimate transfer services for exfiltration. One incident involved data volumes measured in tens of terabytes. Blocking a single tool name is therefore not a complete control: many of the utilities listed in the advisory are legitimate.

Baseline who may create large archives and from which systems.
Alert on unusual cloud-download, archive and outbound-transfer combinations.
Keep high-value recovery material out of broad collaboration libraries.
Apply separate identity, device and network controls to backup administration.
Preserve telemetry before removing tools that may be needed as evidence.

A practical incident-secret checklist

Declare which collaboration and identity systems are trusted, untrusted or unknown.
Use a clean device and an independently verified recipient for every new privileged secret.
Send only the minimum material needed for the current response action.
Set explicit expiry, single-use or recipient controls where the workflow supports them.
Record custody and purpose without copying the secret into the incident timeline.
Revoke the secret and active sessions, then verify that revocation took effect.
Test restoration with separately administered offline or immutable backup copies.