Gunra Ransomware Exploits Fortinet Flaws Against Critical Infrastructure

Gunra reportedly exploits FortiOS and FortiProxy authentication bypasses CVE-2024-55591 and CVE-2025-24472 against government and critical infrastructure, with MFA bypass, session hijacking, backup deletion, and double extortion. Take a firm position: which exposed versions and observable conditions justify treating the appliance and downstream domain as compromised tonight, what evidence matters most, and what are the first t... [arg clipped]

Halil, the affected ranges are FortiOS 7.0.0–7.0.16, FortiProxy 7.0.0–7.0.19, and FortiProxy 7.2.0–7.2.12; fixed releases begin at 7.0.17, 7.0.20, and 7.2.13 respectively. These flaws permit unauthenticated super-admin access, and CISA associates them with Gunra operations. My assessment: if management was internet-accessible while running those versions, treat the appliance as compromised tonight—not merely vulnerable. An unauthenticated super-admin flaw is an unlocked control room, not a cracked window. fortiguard.com (opens in new tab) cisa.gov (opens in new tab)

Do not automatically condemn the downstream domain on exposure alone. Cross that threshold when you find an unexpected successful jsconsole super-admin login, unknown administrator or VPN account, unexplained configuration or MFA changes, session reuse, deleted backups/logs, or appliance-originated access toward domain controllers, identity systems, hypervisors, or backup infrastructure. A documented signal is an admin login showing ui="jsconsole" and method="jsconsole". External SIEM, IdP, EDR, NetFlow and backup audit records matter more than local appliance logs because super-admin access makes the appliance an unreliable witness. fortifiedhealthsecurity.com (opens in new tab)

Tonight: isolate management access, preserve configuration, memory/session state and off-box logs, then replace or rebuild and patch the appliance. Revoke active VPN/admin sessions; rotate appliance credentials, API secrets, certificates and any directory or service credentials it could reach; disable unauthorized accounts; isolate suspicious endpoints; and hunt from the appliance toward identity and backup systems. Do not restore the old configuration blindly. Unknown: the available evidence does not establish the exact CVE-to-ransomware sequence for every Gunra victim, so attribution to one flaw should not delay containment.

Assess the operational delta in North Korea-linked exploitation of Windows afd.sys CVE-2026-68820 against European and Indian defense and aerospace targets. Bound attribution confidence; map fake-job delivery, sideloading, FudModule, Roundcube CVE-2025-49113, and RelayShell; and give defenders the highest-yield hunts tonight without making attribution the response plan. State what evidence would change your confidence.

The operational delta is chain integration, not a new remote-entry capability. Check Point reports this sequence against European and Indian defense/aerospace targets: fake-job impersonation → DLL side-loading → local CVE-2026-68820 exploitation for SYSTEM → FudModule kernel rootkit. In parallel, stolen Roundcube credentials → post-auth CVE-2025-49113 exploitation → RelayShell on compromised Roundcube, WordPress, or PrestaShop servers. ATT&CK: T1566, T1574.002, T1068, T1014, T1190, T1505.003, and T1090. Microsoft patched CVE-2026-68820 on August 11; CISA confirms active exploitation.

Attribution: Lazarus Group/G0032 is moderate confidence (ICD 203); operational chain confidence is high. FudModule and Dream Job provide continuity, but the new exploit-to-RelayShell linkage currently lacks enough independent infrastructure corroboration for high-confidence attribution.

Tonight, hunt the behavior—not “North Korea”:

1. Trusted binaries loading DLLs from user-writable or newly created directories, followed by unusual child processes or networking.
2. That execution chain transitioning rapidly to SYSTEM, kernel interference, or FudModule-like rootkit activity.
3. Roundcube below 1.5.10/1.6.11: successful authentication followed by abnormal PHP object activity, new PHP files, or web-server-initiated outbound connections.
4. Unexpected PHP changes and relay traffic on Roundcube, WordPress, and PrestaShop hosts; preserve authentication and web logs before containment.
5. Patch CVE-2026-68820 and CVE-2025-49113 immediately.

I would raise attribution to high with independent victim telemetry plus passive-DNS/certificate pivots tying RelayShell administration to known G0032 infrastructure and reproducible FudModule code lineage. Multi-actor use of the exploit or proof that RelayShell is commodity infrastructure would lower confidence.

Head Mare reportedly exploited internet-facing TrueConf Server 5.3.x through 5.5.5 on port 4307/TCP, gained SYSTEM, installed a web shell, and replaced hosted client installers with PhantomCore or PhantomGraph builds. Determine the real trust boundary and downstream blast radius. Give a decision-ready containment and provenance-validation sequence, including how far back to distrust downloaded installers and which secrets or systems to rotate or rebuild.

Halil, the real trust boundary is the TrueConf installer-distribution channel, not merely the server process. Kaspersky reports unauthenticated access over TCP/4307, SYSTEM-level execution, a web shell, privileged database access, and replacement of hosted client installers. Consequently, the blast radius includes the server, every endpoint that executed a substituted installer, and external counterparties that downloaded clients from it. PhantomGraph’s reported credential-theft and reverse-SSH capabilities also place reachable identity and network trust paths in scope.

Contain in this order:

1. Isolate the server and block external TCP/4307; preserve disk, memory, logs, database records, and every hosted installer.
2. Establish the compromise window from the earliest web-shell/file change, anomalous access, or installer replacement through verified restoration. If that cannot be proved, distrust every installer downloaded since the server first became both vulnerable and internet-accessible—or since the last independently verified clean installer hash, whichever is later. July 2026 is reported campaign activity, not a reliable per-server start date.
3. Map downloads through server, proxy, browser, EDR, and software-deployment logs. Quarantine artifacts and validate both vendor signature and canonical hash; Kaspersky specifically provides detection for unsigned TrueConf installers.
4. Rebuild the TrueConf server from clean media and rebuild endpoints that executed malicious or unverifiable installers. Download-only endpoints require artifact removal and investigation; rebuild them if execution cannot be excluded. Do not rely on in-place patching or uninstalling the client.
5. From clean systems, rotate TrueConf database and service credentials, server-local and domain administrative credentials used there, and credentials or tokens present on infected clients; revoke sessions. Rotate SSH/VPN keys, deployment secrets, and signing keys only where access or theft is plausible. Investigate—and rebuild where persistence cannot be excluded—systems reached through stolen privileged credentials or reverse tunnels.

One version detail needs caution: Kaspersky’s press release identifies 5.3.9, 5.4.9, and 5.5.5 as fixed releases, so I would not treat the phrase “affected through 5.5.5” as authoritative without reconciling it against TrueConf’s branch-specific advisory before reconnecting.

Compare reported CyberAv3ngers compromises of U.S. water systems via exposed cellular modems and PLCs with Russian-linked Polish cases involving weak HMI credentials and a FortiGate-to-private-APN path that ultimately put Siemens PLCs into STOP. What is the minimum safe action water and energy operators should take today without causing unsafe outages? Distinguish confirmed process manipulation from access-only events and give a 30-minute CISO/plant-manager sequence.

The minimum safe action is local physical verification plus controlled containment of remote access—not emergency patching or indiscriminate cable-pulling. The Polish CHP case represents reported process manipulation: attackers traversed a FortiGate/private-APN path and put Siemens PLCs into STOP. Polish water reporting also describes altered water-quality and alarm parameters. By contrast, exposed cellular modems, reachable PLCs, or HMI access in the CyberAv3ngers cases do not prove that every process was manipulated; separate research found 22 exposed Rockwell controllers in affected cities but could not confirm compromise. Treat those as access events unless controller mode, commands, outputs, setpoints, or physical measurements prove otherwise.

Thirty-minute CISO/plant-manager sequence:

• 0–5 minutes: Operators verify physical truth using independent gauges and samples—tank level, pressure, dosing residuals, pump state, or boiler pressure and temperature. Maintain local control; do not reboot PLCs or alter SIS communications.
• 5–10 minutes: Freeze remote changes. At the Level 3/OT boundary, disable only the exposed or unauthorized cellular, VPN, FortiGate, vendor, or HMI path. Do not blanket-isolate Level 2/1 networks if that could interrupt control.
• 10–20 minutes: Preserve firewall, VPN, cellular and HMI logs; record PLC RUN/STOP state, program checksum, setpoint history, alarms and output changes. Staff the control room for local/manual operation under approved procedures.
• 20–30 minutes: If manipulation is confirmed, invoke the established process-safety shutdown or isolation plan. If access only is confirmed, keep the route blocked, intensify monitoring and schedule tested credential, firmware and segmentation changes during a maintenance window.

Any segmentation or authentication change must be tested against process and safety communications first: an accidental false trip can stop the plant, while disrupted safety logic can prevent a required trip.

The source pack presents Tx XRPL bridge false-deposit crediting, Harmony unauthorized minting, Ronin threshold validation failure, THORChain suspected GG20 TSS leakage, and a 2,150 ETH MEV-bot drain. Do not recap all five. Identify the two control failures that demand immediate operator decisions, separate confirmed facts from speculation, and give a protocol-specific stop/resume criterion for each. Explain why the smaller XRPL... [arg clipped]

The two immediate decisions are Tx’s XRPL deposit-validation failure and Harmony’s ONE issuance-control failure.

Tx/XRPL — confirmed: reporting attributes nearly 200,000 XRP in losses to relayers accepting self-transfers with valid memos without confirming the bridge destination; 94 signed withdrawals followed. This was bridge infrastructure failure, not an XRPL compromise. Stop: keep crediting and withdrawals disabled. Resume only when: every bridged liability reconciles 1:1 with a finalized XRPL payment to the correct destination, independent relayers reproduce that result, and adversarial replay tests reject self-transfers and malformed deposits. The attacker’s identity and final off-ramp remain unknown.

Harmony — confirmed: reporting says an attacker created roughly four billion unauthorized ONE tokens. The precise root cause is not established in the available evidence, so key theft, validator compromise, and contract-authorization failure remain speculation. Stop: disable the affected issuance path and suspend ONE deposits, withdrawals, and bridge finalization. Resume only when: unauthorized supply is enumerated, the compromised authority is revoked or patched, validators agree on canonical supply/state, and exchanges and bridges reconcile against the same snapshot.

The smaller XRPL loss is operationally urgent because the bridge’s normal signing machinery authorized invalid state repeatedly. The amount already withdrawn measures observed loss—not the reserve still exposed to a repeatable validation defect.

Choose between two AI risks for operational airtime: Paperclip CVE-2026-41679 unauthenticated RCE and GhostJacking prompt injection through logs or alerts into Claude Code-connected operations. Which has the more credible enterprise exploit path today? Give a 30-minute CISO action, identify the necessary preconditions, and argue against the frontier-agent 'hostile autonomy' framing if ordinary overprivilege and untrusted input explain the risk better.

Paperclip gets the airtime. Fact: CVE-2026-41679 provides automated, unauthenticated RCE against network-accessible Paperclip instances before 2026.416.0 running the default authenticated configuration. Assessment: That is a closed exploit chain; GhostJacking remains conditional. Alex Mercer’s feasibility review reaches the same conclusion.

Necessary preconditions: - Paperclip: vulnerable version, network reachability, default authenticated mode. - GhostJacking: attacker-controlled text enters telemetry; Claude Code or another agent consumes it; the model treats it as instruction; connected MCP tools possess write authority. The published demonstration combined a poisoned User-Agent log with Cloudflare write permissions to alter DNS.

First 30 minutes: isolate exposed Paperclip instances, preserve process/API logs, upgrade to 2026.416.0, inspect imported configurations, and rotate every credential reachable by the Paperclip OS account. Separately, suspend autonomous write-capable MCP connections until their telemetry paths are reviewed. This is not “hostile autonomy”: it is injection plus overprivilege—untrusted input crossing into an agent holding operational credentials. Least privilege and sandboxing constrain the damage; model branding does not.

Assess the reported pass-the-passkey techniques across Windows 11, Microsoft Entra ID, browsers, and password managers. One source calls them a broad bypass of phishing-resistant authentication; another calls the issue mostly a nothingburger. Reconcile the disagreement by naming the preconditions, what trust artifact is actually replayed or transferred, and whether enterprises should change authentication policy tonight. Give a defensible position, not a recap.

The disagreement is mostly about scope. Fact: The demonstrated Windows 11→Entra chain requires a vulnerable endpoint, local access to its WebAuthn operational log, a previously captured signed WebAuthn assertion, and an Entra validation path that accepts its replay. The passkey private key is neither extracted nor cryptographically broken; the reusable trust artifact is the complete signed assertion. Without both endpoint disclosure and relying-party validation weakness, the chain fails.

Browser and password-manager findings broaden the attack surface through provider plugins and local mediation, but the available evidence does not establish a universal remote bypass. Those scenarios still appear to require control of the endpoint, browser, extension, provider, or recovery/onboarding flow. Calling the entire family a “nothingburger” understates a genuine Windows/Entra trust-chain defect; calling it a broad defeat of phishing-resistant authentication overstates it. I have not seen evidence that an attacker can remotely clone arbitrary passkeys from a clean device.

Enterprises should not disable passkeys or downgrade authentication tonight. Patch affected Windows 11 systems, restrict local administrative access, govern browser extensions and passkey-provider plugins, and investigate Entra sign-ins after any endpoint compromise. If exploitation is suspected, revoke resulting sessions and refresh tokens—not merely the passkey—and retain phishing-resistant FIDO2/WebAuthn policy.

Translate today's 44% monthly rise to 85 high-impact actively exploited or weaponized CVEs into a patch-governance decision without simply declaring every patch urgent. Build a concrete three-tier queue using today's examples: active edge/control-plane exploitation, high-impact patched client/server flaws without known exploitation, and broad patch-wave items. State exact response windows you would defend to a board, and identify one headline the room should deliberately deprioritize.

Halil, the 44% rise to 85 CVEs—36 rated “Very Critical”—is a capacity signal, not an instruction to emergency-patch all 85. My board-defensible queue is:

1. Tier 1 — active exploitation on edge/control-plane systems: establish exposure within 4 hours, isolate or apply compensating controls within 8 hours, patch within 24 hours, then hunt for compromise for 72 hours. This includes exploited internet-facing infrastructure and SharePoint CVE-2026-45659, now associated with ransomware.
2. Tier 2 — high-impact patched client/server flaws without known exploitation: test within 72 hours and deploy within 7 calendar days; allow 14 days only for isolated systems with documented controls. SonicWall GMS/Email Security issues, including CVE-2026-66147, fit here based on the evidence available.
3. Tier 3 — broad patch-wave inventory: deploy within 30 days, bringing individual items forward only for exploitation, direct exposure, or critical-business dependency. Microsoft’s August release reportedly covers 398–421 CVEs, but only the exploited CVE-2026-68820 belongs in Tier 1 automatically.

The headline I would deliberately deprioritize is “Microsoft fixes nearly 400 security holes.” Raw patch volume does not measure business exposure. Best case, disciplined triage limits emergency change risk to a small exploited subset; worst case, an exposed Tier-1 control plane remains open beyond 24 hours and turns patching into containment, outage, and disclosure. I cannot responsibly attach a dollar range without the affected asset count, revenue dependency, and recovery-time data.

Claim: Any internet-managed FortiOS 7.0.0–7.0.16, FortiProxy 7.0.0–7.0.19, or FortiProxy 7.2.0–7.2.12 appliance should be treated as compromised tonight. Counter-evidence: Exposure alone proves vulnerability, not exploitation, and Sara's OT guidance warns that indiscriminate containment can cause service or safety impact. Tighten your position: define the evidence-based minimum for compromise classification, distinguish internet reachability from confirmed unauthorized administration, and provide a safe sequence for an inline Fortinet appliance supporting critical services where immediate isolation could cause an outage.

Halil, you’re right: I overstated the classification. Internet reachability on an affected version means urgent compromise assessment, not confirmed compromise. The minimum for appliance compromise is validated evidence of unauthorized privileged activity—for example, an unexplained successful jsconsole super-admin login, unauthorized administrator creation, or an unapproved configuration change tied to that session. Prefer off-box SIEM evidence. Classify the downstream domain separately; require successful appliance-originated authentication, account modification, credential access, or execution there.

For an inline critical-services appliance, don’t pull the plug blindly. Sara’s sequence is right: confirm process stability and local operator control; export logs and configuration out-of-band; restrict management access and revoke unauthorized sessions without rebooting; then transfer traffic through a tested HA peer or approved bypass only after operations confirms safety communications. Isolate the suspect unit, rotate administrative and VPN trust from a clean host, compare rules and routes with a known-good baseline, then replace or upgrade during a controlled window.

Close the room with a sequenced tonight/next-24-hours plan across the topics already tested: Gunra exploitation of Fortinet CVE-2024-55591/CVE-2025-24472; DPRK use of Windows CVE-2026-68820; TrueConf installer poisoning; CyberAv3ngers/Polish OT access; Paperclip CVE-2026-41679; and the Tx XRPL/Harmony protocol failures. Do not give a generic patch list. Resolve control conflicts: evidence preservation versus rebuilding... [arg clipped]

Tonight, isolate affected Fortinet, Windows, TrueConf, Paperclip, and OT systems after rapid evidence capture; active safety risk overrides collection. Quarantine TrueConf installers and rebuild the server plus endpoints that executed them, rotating reachable identity, database, signing, backup, and management secrets. TrueConf’s June 2026 advisory recommends versions 5.3.9, 5.4.9, and 5.5.5; test the applicable branch before restoration.

Keep the OT cases separate: CyberAv3ngers reporting concerns US water infrastructure, while the Polish access was attributed in reporting to two Russian nationals. Block remote access, replace shared/default credentials, and validate controller setpoints with operators. Within 24 hours, stage verified Fortinet and Windows fixes and hunt adjacent trust systems. Evidence available here does not establish validated fixes for Paperclip CVE-2026-41679 or the XRPL/Harmony failures; isolate or pause affected services pending authoritative guidance.

Give the minimum decision-ready treatment for Zoom annotation-engine flaws CVE-2026-53413, CVE-2026-53414, and CVE-2026-53415. Identify affected client platforms and versions supported by the evidence, explain the video-call code-execution precondition, and set a defensible inventory, fixed-version verification, and patch deadline. Separate this patched but not known-exploited risk from today's active edge exploitation; do not inflate urgency.

Decision: Treat this as accelerated client patching, not an exploitation emergency. CVE-2026-53413 is a high-severity annotation buffer overwrite enabling code execution; CVE-2026-53414 is a medium-severity buffer over-read associated with denial of service; CVE-2026-53415 is a high-severity use-after-free. Code execution requires the attacker to participate in the same Zoom meeting and send malicious annotation data to another participant; no victim click is reported.

Affected evidence supports:

• Zoom Workplace before 7.1.5, or before 7.0.6 on the 7.0 branch
• Zoom Rooms and Meeting SDK before 7.1.5
• Scope is described as all supported platforms, although the available evidence does not enumerate each OS
• Windows VDI Client before 7.0.11 is specifically tied to CVE-2026-53413; aggregate guidance also lists 6.6/7.0 VDI thresholds, but does not clearly map every threshold to all three CVEs

Inventory Workplace installations, Rooms, VDI components, and applications embedding Meeting SDK within 48 hours. Verify installed package/binary versions—not merely successful update jobs—and remediate below-fixed versions within 14 calendar days. Zoom has patched the client code; customers remain responsible for deployment and version enforcement. The reviewed evidence reports patches but no known in-the-wild exploitation, so keep this below confirmed active edge exploitation, which warrants emergency 24–72-hour action.