--- schema: 1 kind: research title: "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" headline: "ESXi's minimal shell is expressive enough to hide commands, and its logging captures the parsing stage rather than the result" summary: > CrowdStrike systematically tested command obfuscation against a live ESXi host and catalogued 21 working techniques across six classes, validated on ESX 7.0.3 with the VMware-provided BusyBox. The load-bearing finding for defenders is a logging property rather than a vulnerability: ESXi shell logs capture commands during parsing, before expansions occur, so a substitution-based command is recorded in its obfuscated form and any detection keyed on a literal string such as esxcli misses it entirely. The obfuscation capability comes largely from awk rather than the shell itself. ESXi is where ransomware operators go to encrypt an estate at once, which is what makes a blind spot in its command telemetry expensive. discovered_at: "2026-08-10T04:45:00Z" event_date: "2026-08-07" run_id: 2026-08-10T0411Z-intel priority: notable immediate_action: null tags: [ransomware, cloud, vulnerabilities] regions: [global, europe] sectors: [public-sector, healthcare, energy, finance, technology] entities: [actor:akira, actor:scattered-spider] techniques: [T1027, T1059.004, T1140] affected_products: ["VMware ESXi"] cves: [] sources: - url: "https://www.crowdstrike.com/en-us/blog/crowdstrike-hunts-for-shell-command-obfuscation-vmware-esx/" publisher: "CrowdStrike" date: "2026-08-07" role: primary closed_sources: [] evidence: - quote: "The critical insight is that ESX shell logs capture commands during the parsing stage, before expansions occur." publisher: "CrowdStrike" - quote: "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)." publisher: "CrowdStrike" - quote: "Any detection strategy that searches for the keyword \"esxcli\" would miss this command entirely." publisher: "CrowdStrike" verification: single-source sourcing_note: > Single originating research publication; no second party has reproduced or corroborated the catalogue. The findings are reproducible in principle — the source names the exact build and shell binary it validated against — but reproduction is not corroboration, so credibility stays at 2. confidence: high update_of: null references: [] deep_dive: false deep_dive_category: null org_triage: null classification: reliability: B credibility: 2 watchlist_hit: false actions: [] migrated_from: null --- 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](https://www.crowdstrike.com/en-us/blog/crowdstrike-hunts-for-shell-command-obfuscation-vmware-esx/)). 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. **Defender takeaway:** treat ESXi shell logs as recording intent-as-typed rather than effect, and rebuild any hypervisor detection that currently matches literal administrative command strings. Interactive shell access to ESXi should be rare and change-controlled enough that structural anomalies in the command log are worth alerting on outright, which is the practical way to close a gap that no single string match can.