CrowdStrike catalogues 21 working command-obfuscation techniques inside VMware ESXi's BusyBox ash shell — and shell logs record the command before expansion, so the logged string is not what ran

CrowdStrike has published a systematic test of command obfuscation inside VMware ESXi's shell, catalogued as 21 distinct working techniques across six classes and validated against a named build — "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" (CrowdStrike, 2026-08-07). The motivation is that the hypervisor layer is where ransomware operations end: CrowdStrike names Scattered Spider and Akira among the groups that have demonstrated that reaching it allows an adversary to encrypt virtual machines, disable logging and cripple a data centre at once.

Two findings carry the operational weight. The first is that the assumption behind ignoring this shell is wrong — BusyBox's minimal footprint does not mean minimal capability, because it keeps POSIX compliance for command substitution, variable expansion, escape-sequence interpretation and quoting, and the bundled awk brings string manipulation, arithmetic, bitwise operations and its own command-execution facility. The obfuscation engine, in other words, is a coreutils applet rather than the shell, which is precisely why hardening and monitoring approaches designed for a full Linux server shell do not transfer.

The second finding is the one that changes detection engineering, and it is a property of the platform's own telemetry: "ESX shell logs capture commands during the parsing stage, before expansions occur." The logged string is therefore the obfuscated form, not the command that executed. CrowdStrike states the consequence plainly for the concrete case — "Any detection strategy that searches for the keyword 'esxcli' would miss this command entirely." Any rule, hunt query or SIEM correlation built on literal administrative command names against ESXi shell telemetry inherits this gap, regardless of vendor.

Detection, telemetry class first. The usable signal is the ESXi shell command log itself, but keyed on structure rather than on command names: substitution and expansion syntax, escape-sequence density, arithmetic or bitwise construction of strings, and invocations of the shell's text-processing applet in positions where an administrator would type a command name. CrowdStrike calibrated false-positive risk against real production activity and lists what normal looks like — service restarts, vendor hardware tools, backup scripts, certificate renewal, NTP restarts, configuration greps — none of which resemble any of the six classes. Triage: administrators legitimately use quoting and variables in ESXi shell one-liners, so their presence alone is not the signal; the discriminator is obfuscation that serves no readability or scripting purpose — a command name assembled from fragments or computed arithmetically, when typing it directly would have been shorter.