VMware ESX servers sit near the top of a ransomware crew's wish list, because an attacker who reaches the hypervisor can encrypt every virtual machine running on it at once, switch off logging, and take a data center down in one move. New research published on 7 August 2026 by CrowdStrike's Erez Goldberg shows that the defenders watching those servers may not even be able to read what an intruder typed.
Goldberg's team systematically tested command obfuscation on a live ESX host. Obfuscation here means writing a command in a scrambled form that the shell quietly reassembles at the moment it runs, so what gets logged and what gets executed are not the same text. CrowdStrike validated 21 distinct working techniques and turned them into regular expression detection patterns in CrowdStrike Query Language (CQL).
Why keyword searches miss it
Most ESX threat hunting today comes down to searching shell logs for known bad commands, which assumes an attacker types those commands in plain sight. The research points at a gap in how ESX records activity: the shell log captures a command at the parsing stage, before the shell expands it. A command written as $(printf "\x65\x73\x78\x63\x6c\x69") system syslog config get executes exactly as esxcli system syslog config get, but the log preserves the scrambled version. A hunt for the string esxcli returns nothing.
One of the fully encoded examples CrowdStrike published decodes to a command that resets the host's syslog destination, which is to say it can stop an ESX host forwarding its logs anywhere at all.
What works on a BusyBox shell
ESX does not run a full Bash environment. It ships a stripped down BusyBox, which is widely assumed to be too thin for this sort of trickery. The research found the opposite. All techniques were validated on ESX 7.0.3 build 20036589 using the BusyBox that VMware itself supplies, whose awk build supports bitwise operations (xor, and, or). The 21 techniques fall into six families:
- Escape sequence encoding. Characters written as octal or hexadecimal codes and rebuilt at runtime with printf or echo. Whole command lines, arguments included, can be encoded this way, leaving no readable text in the log.
- Character generation and string juggling. awk or Python building letters from their ASCII numbers, commands stored backwards and reversed by sed or od, and, quietest of all, commands assembled character by character out of ordinary environment variables such as TERM and SHELL. That last one carries no encoding and no suspicious syntax at all.
- Invisible Unicode injection. Zero width characters slipped between every visible letter and stripped at runtime by awk. CrowdStrike notes the trick is polymorphic: the pool of invisible characters an attacker can draw on runs to more than 131,000 codepoints once the Private Use Areas are included, so no two attempts need look alike.
- Cryptographic encoding. The team found ESX's awk capable of real cipher schemes, including XOR against a fixed key, a Fibonacci sequence used as a keystream, an affine cipher, and a chained scheme modelled on cipher block chaining in which one corrupted character wrecks everything after it.
- Infrastructure keyed payloads. The most awkward family for defenders. These derive the decoding key from the target host itself, its ESX build number or the length of its hostname, so the payload only unlocks on that specific machine. Others gate execution on live conditions, running only when the firewall is enabled and more than five virtual machines are present.
- Filesystem and log steganography. A payload written to a VMFS volume as an octal encoded file, bracketed by fake vmkernel log entries so the whole sequence reads like a routine storage check, then removed after it runs.
How worried to be
None of this is a vulnerability in ESX, and CrowdStrike does not report catching these techniques in a real intrusion. What the work establishes is capability: the assumption that a minimal hypervisor shell is too poor an environment for serious evasion does not hold. That matters because the groups CrowdStrike names as recurring ESX threats, among them Scattered Spider, Black Basta, Royal (also known as BlackSuit) and Akira, plus an ESX focused ransomware as a service platform called shinysp1d3r, already operate at the hypervisor layer. IntelFusions reported in July on a new ransomware family built specifically for Windows and ESXi.
What you should do
Stop treating keyword matching over ESX shell telemetry as detection. Hunt for the shape of obfuscation rather than the command: awk generating characters from numbers, awk piping its output into a shell, and bitwise operations inside awk are all high signal on a hypervisor that should mostly be seeing routine administrative work. CrowdStrike has published its CQL patterns for deployment as correlation rules in Falcon Next-Gen SIEM, and they are worth translating into whatever platform holds your ESX logs. Alert separately on any change to syslog forwarding, since silencing the logs is the natural first move once obfuscation is in play. The full write up, with every technique and detection pattern, is in CrowdStrike's original report.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.