ForumsExploitsGamaredon Returns: Weaponizing CVE-2025-8088 in WinRAR for GammaWorm/GammaSteel

Gamaredon Returns: Weaponizing CVE-2025-8088 in WinRAR for GammaWorm/GammaSteel

CloudOps_Tyler 6/2/2026 USER

Just saw the latest Sekoia.io report regarding Gamaredon's renewed focus on Ukraine. They are actively exploiting CVE-2025-8088, a path traversal vulnerability in WinRAR, to push their custom toolset.

The attack chain is particularly interesting because of how they bridge the gap from an archive to execution. They weaponize the path traversal flaw to write an HTML Application payload (GammaPhish) directly to a location that triggers execution, or relies on user interaction. Once GammaPhish executes, it reaches out to retrieve the heavy hitters: GammaWorm (for propagation) and GammaSteel (for data theft).

Since HTML Applications are executed by mshta.exe, it's a massive red flag if WinRAR is the parent process. Standard users rarely, if ever, need to extract an archive that immediately spawns a script host.

I'm currently refining our detection logic. I've moved beyond just looking for the CVE signature and am focusing on the behavioral aspect of the dropper. Here is a PowerShell snippet I'm using to hunt for this parent-child relationship in our Security logs:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | 
Where-Object {$_.Message -match 'winrar' -and $_.Message -match 'mshta'} | 
Select-Object TimeCreated, Message

Given that Gamaredon is known for their speed and volume, I'm concerned about this spreading beyond the initial target region through supply chains or lateral movement.

How is everyone else handling archive filtering at the perimeter? Are you flat-out blocking .rar files or relying on sandbox detonation for this specific CVE?

BA
BackupBoss_Greg6/2/2026

Great find. We block .rar at the gateway for non-partners, but that’s not always feasible for everyone. For internal detection, I recommend looking for specific ParentProcessId correlation. In Sentinel, this KQL query works well:

DeviceProcessEvents
| where InitiatingProcessFileName =~ 'WinRAR.exe'
| where FileName in~ ('mshta.exe', 'powershell.exe', 'cmd.exe')
| project Timestamp, DeviceName, FileName, ProcessCommandLine

The GammaPhish HTA usually establishes a C2 connection immediately after extraction, so network telemetry is key.

BA
BackupBoss_Greg6/2/2026

We just pushed the WinRAR update via SCCM to address CVE-2025-8088. The hardest part was getting users to close the app so the installer could run.

Technically, the path traversal here works because WinRAR doesn't properly sanitize the filenames within the archive before extraction. If you can't patch immediately, disabling the 'associate' file types in Windows defaults might help reduce the surface area, though it won't stop a manual extraction.

AP
AppSec_Jordan6/3/2026

Since GammaPhish relies on an HTA, monitoring for mshta.exe spawning immediately after WinRAR is a high-fidelity tactic. If HTA usage is rare in your environment, consider blocking the executable via ASR rules or GPO. For those using Defender, this KQL query helps catch the correlation:

DeviceProcessEvents
| where FileName in~ ("WinRAR.exe", "mshta.exe")
| project Timestamp, DeviceName, FileName, InitiatingProcessFileName
| order by Timestamp asc

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created6/2/2026
Last Active6/3/2026
Replies3
Views24