INSITO 1.0.0 — open-source recovery for the Rhysida ESXi locker

Today we are shipping INSITO as free, open-source software — MIT licensed, single static binary. If the Rhysida family’s ESXi build hit your datastores, you can recover your files today: no ransom, no attacker keys, no build environment, and no internet connection. The source is on GitHub; you can compile it, audit it, fork it. It builds on the researchers who cracked this family first — cited at the end — and we built the piece everyone was missing.

Why this tool exists

Rhysida is the ransomware family that encrypts VMware datastores in place and drops a CriticalBreachDetected note. When it appeared in 2023, the practical answer was the ransom note. Public decryption coverage stopped at the family’s early Windows builds — industry recovery guidance has carried the caveat that newer builds and, in particular, its Linux/ESXi variant were not covered. A datastore full of .rhysida files on a production cluster is one of the highest-stakes scenes in incident response, and until now its practical story ended with “no public option”. We changed that this week, and we are shipping the tool for free.

INSITO is what we would want in the hands of a responder at 3 a.m.: copy one static binary to the ESXi shell (or any Linux, BusyBox included), point it at the datastore, and let it work. It has restored files byte-for-byte on a live datastore — the video below is from that recovery.

The flaw, and the gap we closed

The flaw. Every Rhysida-encrypted file ends with a trailer holding the file’s AES-256 key and IV, wrapped with RSA-4096. Unwrapping is supposed to demand the attacker’s private key. But the wrap’s randomness is drawn from a stream seeded with nothing but the wall clock — a 32-bit second counter. The Kookmin/KISA team proved for the Windows builds that the generator’s internal state can be regenerated from that seed and used to re-derive per-file keys and even the order of encryption. Recovering the family’s output is therefore about finding one 32-bit second, not about breaking RSA.

The gap. The ESXi locker is a different animal. It links glibc, whose rand() follows the TYPE_3 additive-feedback algorithm — a different state machine, different byte consumption, nothing like the MSVCRT LCG the Windows papers deal with. Its ChaCha20 stream is consumed in a different layout (key wrap, IV wrap, sequential blocks), and its target is a datastore, not a file share: thousands of files, ESXi’s BusyBox userland, no package manager, no room for tooling. None of the published tooling covered this build.

What INSITO adds. A from-scratch model of the ESXi locker’s PRNG and wrap construction, verified byte-for-byte in the lab; a trailer-replay oracle that needs nothing but the encrypted files; an automatic hardware-scaled clock search (every core, memory-guarded) so that even with no external knowledge the tool finds its own anchor; and a single static, BusyBox-compatible binary that runs where the incident is. The engine is one readable C file.

What ships in 1.0.0

• Single static binary — x86-64 Linux/ESXi, ~1.4 MB, zero dependencies — scp it and run it under BusyBox. A CI-built release with SHA256SUMS accompanies every tag.
• One-time consent, no nags — A short MIT notice on first run; you type accept once. Consent is recorded in a validated local record; every later run stays silent. Scripts use --accept-license.
• Automatic clock search — Timestamps intact: the sweep is anchored for you. No anchor: hardware-scaled automatic fallback over the last 30 days (configurable).
• Reported, verifiable results — Every run writes a text + JSON recovery report (clock window, hit, per-file SHA-256). Encrypted originals are opened read-only and never modified.
• Fully offline — No telemetry, no fetching, no keys sent anywhere. The crypto library is vendored in the repo; builds are reproducible with two commands.
• Tested like a product — A deterministic synthetic-corpus suite verifies the recovery engine byte-for-byte in CI, plus CodeQL, secret scanning and ASan/UBSan builds.

Watch it work

Four files encrypted by the real locker on a datastore; one command; 4/4 restored and verified by SHA-256.

Faster recovery: a guide for defenders

Be honest about the constraint: the tool is fastest where the ransomware ran. Every step you take offline makes the search harder — because the sweep anchor is the clock, and offline copies can lose their best clue (the files’ own timestamps). Here is how IR teams get tier-topping speed:

• Tier 0 — run it there (fastest) — If you can reach the host, run INSITO on it, against the datastore. Clock and timestamps are true where you stand; the sweep is minutes. Prefer read-only mounts; originals are never modified either way.
• Tier 1 — offline, timestamps preserved — Plain cp/scp reset modification times and cost you the anchor. Copy with rsync -aH, tar cpzf or scp -p — then the offline run is exactly as fast as on the live system.
• Tier 2 — offline, bring the clock — On the victim’s ESXi shell run date +%s and carry the epoch back with you; then ./insito --datastore /lab/enc --clock 1735689600. Near tier-0 speed. Good alternative anchors: vmkernel/hostd log timestamps, your IR timeline.
• Tier 3 — blind, but scaled — No anchor at all: the tool auto-escalates to a full-core search over the last 30 days. Bound it with --lookback <days> the moment anyone produces a window — a 7-day lookback on a 32-core box is minutes, the 30-day default is a long compute.

Practical truth: --clock and timestamp-preserving copies are the difference between minutes and days. See the repository README’s Recovery speed & constraints section for the full playbook — the same tier table lives there.

Get it, build it, verify it

• download — release binary + SHA256SUMS: https://github.com/ionsec/insito/releases/download/v1.0.0/insito-1.0.0-static (source: github.com/ionsec/insito)
• verify — sha256sum -c SHA256SUMS — the write-up binary is fa0402e646c671478ca387c71f597a27fcf49a5cc1e0782bccc9a092afb659f5
• build — make vendor && make — LibTomCrypt and LibTomMath ship in-tree; nothing else is required
• preview — ./insito --scan /vmfs/volumes/<name> — a dry-run that writes nothing
• recover — ./insito --datastore /vmfs/volumes/<name> — confirms, restores, reports (scripted: add --accept-license --yes)
• if nothing matches — keep it running: the automatic offline search uses your cores and stops the moment it hits; --lookback, --window and --threads are there if you want control

Offline, audited, honest

Recovery tools are only as trustworthy as their behavior when you are not looking. INSITO’s answers: the entire engine is a single readable C file; the sweep never touches your network; the originals open read-only; every write is a new file in a rhysida_recovered directory. There is no account, no license server, no usage ping. One-time consent is stored locally, and you can inspect it with insito --license-status and delete it with rm.

Where this came from: the recovery oracle needs nothing but the encrypted files themselves — no plaintext, no victim keys, no attacker infrastructure. Its approach extends the PRNG-state regeneration published by the Kookmin/KISA team (see the References below) to a build of the family their tooling did not reach. A companion technical write-up, with reproductions and recorded runs, is available on ionsec.io/resources.

License, responsible use, and the team

INSITO is released under the MIT license (c) 2026 IONSEC.IO. Use it only on systems you own or are explicitly authorized to recover. Recovery is best-effort — always keep the encrypted originals until restored copies are verified (the tool reads them read-only, never touches them). Unlawful use is prohibited and not condoned; you alone are responsible for your use.

We go past the visible threat and unravel the entire chain — how they got in, what they touched, and what would let them back. Containment is not the finish line.

• emergency incident response — 24/7 intake, assured four-hour response, memory capture, attack-chain reconstruction and guided recovery
• tier-3 as a service — senior reverse engineers, threat hunters and forensic analysts on demand for your SOC or MSSP
• cyber preparedness — visibility, playbooks and rehearsals front-loaded before the breach
• ransomprotect — early-chain ransomware and wiper detection where OS defenses fall short

4 hours assured response · +100k hours of research and DFIR expertise · ~85% MTTR reduction · 6 open-source DFIR tools published. Research and tooling, free to read: ionsec.io/tooling · Emergency intake: [email protected] · ionsec.io

References

• [1] G. Kim, S. Kang, S. Baek, K. Kim, J. Kim — A Method for Decrypting Data Infected with Rhysida Ransomware, arXiv:2402.06440, Feb 2024. https://arxiv.org/abs/2402.06440
• [2] G. Kim, S. Kang, S. Baek, K. Kim, J. Kim — How to decrypt files encrypted by Rhysida ransomware without the attacker’s private key, Computers & Security, 2025. https://www.sciencedirect.com/science/article/abs/pii/S016740482500029X
• [3] KISA — Rhysida ransomware cryptographic function analysis report, January 2024. https://seed.kisa.or.kr
• [4] Kookmin University DF&C lab — Rhysida recovery tool for the Windows builds, developed with KISA, 2024. https://dfnc.kookmin.ac.kr
• [5] ProvenData — Rhysida Ransomware: Attack Chain, IOCs and Recovery Options. https://www.provendata.com/blog/rhysida-ransomware

LibTomCrypt and LibTomMath are vendored at their own licenses.