CrowdStrike Threat Hunts for Shell Command Obfuscation on VMware ESX
CrowdStrike Threat Hunts for Shell Command Obfuscation on VMware ESX
VMware ESX systems are a recurring target in ransomware campaigns. Threat groups including SCATTERED SPIDER, BlackBasta, Royal (aka BlackSuit), Akira, and the ESX-focused ransomware as a service (RaaS) platform shinysp1d3r have demonstrated that once an adversary reaches the hypervisor layer, they can rapidly encrypt virtual machines, disable logging, and cripple an entire data center. Traditional detection approaches that search ESX shell logs for known malicious commands assume the adversary will type commands in cleartext. However, command obfuscation is well understood on Linux and Windows, with public tools like Bashfuscator and Invoke-Obfuscation making evasion accessible. 🚀
ESX runs a minimal BusyBox shell, not a full Bash environment, but our research demonstrates that obfuscation techniques not only survive ESX’s constraints but extend far beyond basic encoding into cryptographic ciphers, infrastructure-keyed payloads, and alternative encoding systems. CrowdStrike researchers systematically tested obfuscation techniques on an ESX environment, cataloged 21 distinct methods, and built regex-based CrowdStrike Query Language (CQL) detection patterns based on that research. All techniques were validated on ESX 7.0.3 build-20036589 running the VMware-provided BusyBox at /usr/lib/vmware/busybox/bin/busybox, which enables the awk GNU math extensions (xor, and, or).
The critical insight is that ESX shell logs capture commands during the parsing stage, before expansions occur. An obfuscated command, such as the following, executes identically to esxcli system syslog config get, but the log entry preserves the obfuscated form: $(printf "\x65\x73\x78\x63\x6c\x69") system syslog config get. Any detection strategy that searches for the keyword “esxcli” would miss this command entirely. This parsing-versus-execution gap is what makes obfuscation viable and what our detection strategy must account for. The research revealed that ESX’s BusyBox shell supports significantly more obfuscation capability than its minimal reputation suggests.
Among the most novel techniques we validated, invisible Unicode characters can be interleaved between the visible characters of a command string. The shell’s awk gsub() function strips them at runtime, leaving only the executable command – but the shell log preserves the full string including the invisible bytes, making the command unreadable to human analysts and invisible to keyword-based detection. This decodes to esxcli vm process list. The detection pattern awk.*BEGIN.*printf.*%c.*[0-9] (P9 in our CQL rule) catches the character generation, and awk\s+.*\|\s*(?:/bin/)?(sh|bash)\b (P14) catches the pipeline to shell execution. Our research also revealed that ESX’s awk implementation supports sufficient arithmetic and bitwise operations to implement genuine cryptographic encoding schemes.