UAC-0255 Impersonates CERT-UA: 1M Emails Delivering AGEWHEEZE
The recent disclosure regarding UAC-0255 impersonating CERT-UA to distribute the AGEWHEEZE RAT is a textbook example of leveraging trust for initial access. Sending over 1 million emails on March 26-27, 2026, demonstrates the scale at which these actors operate.
What stands out here is the delivery method: password-protected ZIP archives. This technique remains a persistent thorn in our side because it bypasses many automated email gateways that can't scan the payload without the password. Since the password is provided in the email body, the user just needs to click and type. Crucially, extracting files from a password-protected archive can strip the Mark-of-the-Web (MotW) identifier, potentially bypassing SmartScreen and other trust controls if not handled correctly by the extraction utility.
From a detection standpoint, we need to focus on the execution chain post-extraction. AGEWHEEZE, being a RAT, will likely establish persistence immediately. Here is a basic KQL query to hunt for suspicious process execution patterns often seen when users extract and run payloads from archives:
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("cmd.exe", "powershell.exe", "mshta.exe")
| where InitiatingProcessFolderPath has @'AppData\Local\Temp'
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName
Additionally, monitoring for powershell.exe spawned directly from compression tools like WinRAR.exe or 7zFM.exe is usually a high-fidelity signal for this type of attack.
How are you all handling password-protected archives in your environment? Are you blocking them outright, or relying on sandbox detonation?
We’ve taken the hardline approach: block all encrypted archives at the mail gateway. While it generates tickets for the helpdesk regarding "lost" invoices, the operational risk of a RAT like AGEWHEEZE establishing a foothold is too high. We use a secure SharePoint link for legitimate file transfers instead. The MotW bypass issue is exactly why we don't trust user workstations to handle these safely.
Great post. The MotW stripping is definitely the kicker here. If I were pentesting, I'd definitely use that exact vector. On the defensive side, we allow zips but force them through a detonation sandbox that attempts to crack the password using a dictionary of common passwords found in the email body before delivery. It catches about 80% of these low-effort campaigns.
Interesting that they used March 26-27. That was a Monday-Tuesday. Very specific timing. We noticed a spike in System.IO.Compression PowerShell calls in our logs around that time. Here is a quick one-liner we used to check for suspicious decompression activity:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104} | Select-Object Message | Select-String -Pattern 'System.IO.Compression' -Context 2, 2
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access