RansomHouse upgraded its ESXi encryptor with multi-layered, chunk-based encryption. See what changes—and how AI helps detect and stop it earlier.

RansomHouse’s New ESXi Encryption: How AI Fights Back
Ransomware isn’t “getting smarter” in the abstract—it’s getting more engineered. This week’s analysis of RansomHouse (run by the group many track as Jolly Scorpius) shows a concrete step forward: the encryptor used in their attacks, Mario, has upgraded from a simple linear encryption routine to a multi-layered, chunk-based approach designed to slow defenders down and make recovery harder.
Here’s why that matters for security teams: the upgrade isn’t only about stronger crypto. It’s about speed, scale, and operational chaos, especially in VMware ESXi environments where one hypervisor compromise can take down dozens or hundreds of virtual machines.
And it’s also a useful case study for something I strongly believe: AI is most valuable in ransomware defense before encryption starts—when the signals are weak, messy, and spread across identity, endpoint, network, and virtualization layers.
What changed in RansomHouse—and why ESXi is the main prize
RansomHouse is built for double extortion: steal data first, then encrypt to force urgency, then threaten to leak. That part isn’t new. What’s new is the operational maturity: the group has publicly listed at least 123 victims since December 2021, and they’ve disrupted sectors where downtime becomes headline news—healthcare, finance, transportation, government.
ESXi is the multiplier. Compromise a Windows file server and you may hurt a department. Compromise an ESXi host and you can cripple an entire line of business. VM disk and state files are the lifeblood of virtual infrastructure; encrypt those and you’ve effectively “turned off” operations.
RansomHouse affiliates are known to focus on ESXi because it supports:
- Maximum blast radius (many VMs per host)
- High-leverage data destruction (disk, memory, snapshot state)
- Backup disruption (targeting files often associated with recovery workflows)
For defenders, that means ransomware protection can’t stop at endpoints. You need visibility and response paths that include hypervisors, identity, and east-west movement.
The RansomHouse attack chain: four phases that defenders can actually interrupt
RansomHouse follows a pattern that’s familiar, but their tooling makes it efficient. The operation breaks down into four phases:
- Develop (operators build the service and tools)
- Infiltrate (affiliates gain access, move laterally)
- Exfiltrate & deploy (data theft + ransomware deployment)
- Extort (operators negotiate, threaten, leak)
What’s useful here is the separation of roles:
- Operators run the ransomware-as-a-service (RaaS): leak site, payments, negotiation infrastructure, tool development.
- Affiliates (attackers) do the intrusion work: initial access, privilege escalation, lateral movement, exfiltration, deployment.
This split is exactly why ransomware stays resilient. Even if you pressure one affiliate, the platform remains—and another affiliate can step in.
Where AI fits in this chain
AI isn’t a “decryptor.” It’s an early-warning and decision engine across phases 2 and 3, where humans struggle most:
- Too many weak signals across systems
- Too little time between “intrusion” and “encryption”
- Too many decisions that require correlation (identity + network + endpoint + virtualization)
If you’re only looking for ransomware at the moment files start flipping extensions, you’re late.
MrAgent + Mario: the modular ESXi ransomware toolkit
RansomHouse’s ESXi workflow is modular:
- MrAgent: the deployment/management tool installed on the hypervisor
- Mario: the encryptor executed on the hypervisor to encrypt VM-related files
MrAgent: why this tool is scarier than it looks
MrAgent is built for persistence and scale. It phones home to a command-and-control server and supports operational commands that make ransomware deployment repeatable.
Notable behaviors described in research include:
- Collecting host identifiers (
uname -a, NIC listing) - Pulling IP configuration (
esxcli ... ipv4 get) - Disabling the ESXi firewall (
esxcli network firewall set --enabled false) - Running continuous connectivity checks to C2 and executing instructions
The part that should bother you: this isn’t just “run ransomware.” It’s remote administration for hypervisor compromise.
A few example instruction types matter from a defense perspective:
Exec: starts deployment actions like changing root password, stopping vCenter agent processes, then encryptingRun: executes arbitrary commandsRemove: deletes content (rm -rf)Config: overwrites local configuration used for deployment
That’s a blueprint for automation. And automation is what makes ransomware outbreaks so hard to contain.
Mario: targets that maximize downtime and limit recovery
Mario targets virtualization and backup-adjacent file types commonly found in ESXi datastores, including:
vmdk(VM disks)vmem(memory)vmsn,vmsd(snapshot state/metadata)vswp(swap)ovf,ova(virtual appliance packaging)vbk,vbm(backup and metadata files)
It also drops a ransom note named How To Restore Your Files.txt into affected directories and renames encrypted files with extensions that include mario (such as .emario).
From an operational standpoint, the lesson is blunt: they’re not just encrypting production—they’re going after your ability to restore.
The encryption upgrade: from linear to multi-layered and harder to analyze
The upgraded Mario version is designed to complicate response and analysis, not just encrypt data.
Research comparing older and newer samples highlights four meaningful changes.
1) Two-stage encryption with two keys
The original Mario performed a simpler single-pass transformation.
The upgraded version introduces two-stage encryption using:
- a 32-byte primary key
- an 8-byte secondary key
That doesn’t automatically mean “unbreakable,” but it does mean:
- more complexity for reverse engineering
- fewer shortcuts for recovery tools
- more opportunity for implementation tricks that waste responder time
A practical takeaway: betting on “a decryptor will appear” is a bad business plan.
2) Smarter memory layout and buffer handling
Upgraded Mario reorganizes buffers and introduces explicit header handling for encrypted output. This tends to show up when developers are optimizing for speed, stability, and consistent output formats across different file sizes.
Defensive implication: faster, more reliable encryption reduces the window for containment once encryption begins.
3) Chunk processing with dynamic sizing (and sparse encryption)
This is the operational leap.
Older Mario processed files in fixed-size segments up to a threshold around 536,870,911 bytes.
Upgraded Mario uses:
- variable segment lengths
- a much larger size threshold (up to 8 GB)
- sparse encryption (encrypting selected blocks at offsets)
- progress reporting per chunk
Sparse encryption is common in modern ransomware because it’s a strong tradeoff:
- Encrypt less data → finish faster
- Finish faster → defenders have less time to respond
- Still break the VM → the victim is still down
4) More detailed output and telemetry (for the attacker)
Detailed per-file completion output helps affiliates troubleshoot at scale. When ransomware operators add more “operator-friendly” diagnostics, it usually signals they’re reducing friction for affiliates and increasing throughput.
Higher throughput is bad news for defenders.
Why this upgrade increases pressure on SOC teams (and how AI helps)
The Mario upgrade is a reminder that ransomware developers optimize for two things:
- Time-to-impact (how quickly they can cause downtime)
- Analyst friction (how hard they can make triage and reverse engineering)
So what should defenders optimize for? Time-to-detection and time-to-containment.
This is where AI-driven threat detection and automated response earn their budget.
AI is good at the messy middle: correlating weak signals
Ransomware incidents rarely start with “ransomware.” They start with small behaviors that look normal in isolation:
- a privileged login at an odd time
- lateral movement that mimics admin work
- suspicious compression + outbound transfer
- an ESXi firewall change that “could be maintenance”
AI (paired with good telemetry) can connect these dots faster than humans juggling dashboards.
Strong AI-assisted detections in ESXi-focused ransomware cases typically include correlation across:
- Identity and access: unusual root activity, password changes, privilege escalation
- Network: new outbound connections from hypervisor management networks, beacon-like traffic patterns
- Endpoint/host: execution of unexpected binaries on ESXi, process/service disruptions
- Data movement: large archive creation, atypical egress destinations, bursts of transfer
- Virtualization signals: changes to vCenter agents, datastore file churn patterns
Automated response matters because humans can’t click fast enough
If MrAgent can execute commands at machine speed, manual containment is a losing race.
Practical automated actions that reduce blast radius:
- Isolate suspicious hypervisors (network segmentation or microsegmentation)
- Disable compromised credentials quickly (especially privileged and service accounts)
- Block known bad egress destinations during suspected exfiltration
- Trigger snapshot/backup protection workflows (immutable storage, isolated backup networks)
- Open an incident with pre-built playbooks that assign tasks (identity, network, virtualization, legal/comms)
I’ve found that the best teams don’t automate everything. They automate the first 60 seconds—because that’s where the outcome often gets decided.
Defensive checklist: what to do this quarter if you run ESXi
If you want a plan that’s realistic before year-end close, focus on these controls.
Harden ESXi and its management plane
- Restrict ESXi management access to a dedicated admin network
- Require MFA for management tooling wherever possible
- Audit and reduce who can access hypervisors and vCenter
- Monitor for ESXi firewall disable events and treat them as high-signal
Treat exfiltration as the “point of no return” signal
Double extortion means encryption isn’t the only crisis.
- Detect bulk compression and unusual outbound transfers
- Baseline normal datastore access patterns
- Add high-confidence alerts for new outbound connections from hypervisor networks
Design backups for ransomware reality
- Use immutable backups and separate backup credentials
- Protect backup repositories from the same identity domain as production
- Regularly test restores of ESXi workloads (not just file restores)
Put AI where it counts: triage, correlation, and response
If your SOC is already overloaded, AI should reduce work, not create more.
- Use AI to correlate identity + network + virtualization events into one incident
- Use automated playbooks to contain suspected hypervisor compromise fast
- Use AI-assisted investigation summaries to speed decision-making during outages
A useful rule: if a detection requires three consoles and a spreadsheet, it won’t save you during ransomware.
What security leaders should take from the RansomHouse upgrade
The upgraded RansomHouse encryption is a signal of professionalization. Two-stage keys, dynamic chunking, and sparse encryption aren’t academic improvements—they’re built to shorten the defender’s response window.
If you’re planning 2026 security investments, prioritize the capabilities that reduce time-to-containment:
- Better telemetry from identity, network, endpoint, and virtualization layers
- AI-driven correlation that turns weak signals into a clear incident story
- Automated response that can isolate, disable, and block at machine speed
Ransomware groups will keep optimizing. The question is whether your detection and response loop is improving faster than theirs.