Analysis: VOID#GEIST's Modular RAT Delivery (XWorm, AsyncRAT, Xeno)
Just caught the Securonix write-up on the new VOID#GEIST campaign. It’s a classic example of "living off the land" taken to the next level with heavy obfuscation.
The attack chain starts with a malicious batch script, but what’s interesting is the second-stage loader. Securonix noticed that the initial obfuscated batch file acts as a dropper for a heavily encrypted payload, which then unpacks one of three distinct RATs: XWorm, AsyncRAT, or Xeno RAT. This modularity suggests the actors are testing which payload yields the best persistence in different environments.
The batch scripts themselves are a mess of variable obfuscation, often using standard Windows binaries to proxy the execution. For detection, relying on static signatures for the batch file is going to be a cat-and-mouse game. I’ve put together a quick Sigma rule to catch the process lineage, specifically looking for cmd.exe spawning powershell.exe with encoded commands, which is the primary vector here.
title: VOID#GEIST Suspicious PowerShell Encoded Command
description: Detects cmd.exe spawning powershell with encoded arguments, a common VOID#GEIST behavior
status: experimental
references:
- https://thehackernews.com/2026/03/multi-stage-voidgeist-malware.html
date: 2026/03/10
author: SecurityArsenalUser
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: '\cmd.exe'
Image|endswith: '\powershell.exe'
CommandLine|contains: '-e'
CommandLine|matches: '[a-zA-Z0-9+/]{500,}'
condition: selection
falsepositives:
- Administrative scripts
level: high
Has anyone started seeing IOCs for the Xeno RAT variant specifically? I'm curious if they are using the default C2 ports or if they've shifted to custom port binding to blend in with traffic.
We caught a variant of this last week. The batch files were using mshta.exe to pull down the second stage instead of direct PowerShell calls, likely to bypass AMSI triggers. We ended up blocking all mshta execution for non-admin users via GPO, which stopped the payload delivery immediately. Definitely recommend checking your Sysmon logs for cmd.exe parenting mshta.exe.
Good catch on the encoded command length. I've been analyzing the XWorm dropper used in this campaign, and it specifically uses a custom XOR key for the string obfuscation. If you're doing memory scanning, look for the pattern \x00\x50\x00\x57 which seems to be consistent across the unpacked headers in this specific VOID#GEIST iteration.
The modularity is the scary part. AsyncRAT and XWorm are commodity malware, but Xeno is getting much more sophisticated with its AV evasion. We've deployed a simple PowerShell logging policy to catch the EncodedCommand activity:
Set-PSRemoting -SkipNetworkProfileCheck -Force
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; ID=4104} | Where-Object {$_.Message -match 'EncodedCommand'}
It generates noise, but it's caught several stagers attempting to load in memory.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access