New VOID#GEIST Campaign: Batch Scripts as RAT Delivery Vectors?
Just saw the Securonix write-up on VOID#GEIST. It’s a multi-stage campaign relying on obfuscated batch scripts to deliver a nasty cocktail of RATs: XWorm, AsyncRAT, and Xeno RAT.
What stands out to me is the reliance on good old .bat files. While we spend so much time locking down Office macros and PowerShell, attackers are circling back to batch files because they often bypass initial heuristic filters. The obfuscation techniques used here are significant—variable expansion and character substitution—which makes static analysis difficult.
The second stage involves decrypting the payloads in memory before injection. If you are hunting for this, watch for cmd.exe spawning powershell.exe with specific argument patterns. Here is a KQL query I'm testing to catch the initial obfuscation attempts:
DeviceProcessEvents
| where InitiatingProcessFileName == "cmd.exe"
| where FileName == "powershell.exe"
| where ProcessCommandLine contains "-enc" or ProcessCommandLine contains "FromBase64String"
| project Timestamp, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine
Additionally, a basic Sigma rule to flag the batch execution chain could look like this:
title: Suspicious CMD spawning PowerShell with Encoded Command
status: experimental
logsource:
category: process_creation
product: windows
detection:
selection:
ParentImage|endswith: '\cmd.exe'
Image|endswith: '\powershell.exe'
CommandLine|contains:
- '-enc'
- '-encodedcommand'
condition: selection
Since the payloads are encrypted (AES/RSA variants depending on the RAT variant), signature-based detection might struggle until the payload is decrypted in memory.
Are you all seeing a resurgence of batch-based loaders in your environments, or is this isolated to specific sectors? How are you handling the whitelisting of legitimate admin scripts vs. these obfuscated droppers?
We've actually seen a slight uptick in .bat and .vbs droppers over the last quarter, likely as a response to tighter AMSI (Antimalware Scan Interface) logging on PowerShell. The obfuscation in VOID#GEIST is annoying, but the parent-child process relationship is usually the giveaway.
I'd recommend adding a watch for certutil.exe or bitsadmin.exe being spawned by cmd.exe as well, as the second stage often fetches the encrypted payload from a remote server before the PowerShell decode.
# Check for suspicious certutil usage in recent logs
grep -i "certutil" /var/log/syslog | grep "decode"
From a pentester's perspective, batch files are incredibly effective for 'Living off the Land' (LotL) because they are native and trusted. The attackers are using set variable substitution to hide the command line arguments.
If you are blue teaming, strictly blocking cmd.exe from spawning PowerShell in userland (via AppLocker or SRP) breaks this chain immediately. It's a high-impact control, but for environments plagued by these RATs, it's often worth the operational friction.
Good points on the evasion techniques. For rapid triage, I suggest running the script in a sandbox with @echo on prepended; this often reveals the decoded payloads before execution.
Since the obfuscation relies heavily on environment variables, you can automate the decoding phase locally without executing the malware. This Python snippet helps expand those variables instantly:
import os
print(os.path.expandvars("paste_obfuscated_string_here"))
It’s a quick win for extracting IOCs without manually calculating character offsets.
Solid points on the sandboxing. For static analysis, don't overlook using Findstr to isolate the heavy lifting parts. If you suspect Hex encoding in those variables, this quick Python snippet helps visualize the decoded strings without execution:
import re, binascii
content = open('script.bat', 'r').read()
hex_strings = re.findall(r'[0-9A-Fa-f]{20,}', content)
for h in hex_strings: print(binascii.unhexlify(h))
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access