Skip to main content

Hit by ransomware? Isolate affected systems now. Do not reboot or reformat.

SheMo Noransom舍末无勒

Ransomware family

Eclipse Ransomware Decryption & Data Recovery

  • Active
  • Medium
  • No public decryptor

Eclipse is a ransomware-as-a-service family that surfaced in August 2026. Its operators advertise coverage of Windows, Linux, NAS, VMware ESXi and Hyper-V with double extortion, but sample-level public research remains very limited.

First seen
2026-08
File extensions
No public information
Ransom notes
No public information
Affected platforms
Windows / Linux / VMware ESXi / Hyper-V / NAS storage

Public information on this family is limited. What follows is compiled from the small amount of verified material available, so please contact us for a sample assessment before you act on it.

Family profile

File extensions
No public information
Ransom notes
No public information
Contact patterns
  • Tor (.onion) leak infrastructure split into a posting site and a separate file site
  • An .onion negotiation or contact entry point given on the leak site and in the note
  • Session anonymous messenger account
  • Tox account
  • PGP-encrypted messages
  • Bitcoin and Monero payment addresses
Aliases / versions
Eclipse Ransomware、Eclipse RaaS
First seen
2026-08
Status
Active
Operational status
Newly emerged
Threat level
Medium
Affected platforms
  • Windows
  • Linux
  • VMware ESXi
  • Hyper-V
  • NAS storage
Tags
  • Emerging
  • Active
  • Ransomware-as-a-Service
  • Double extortion
  • Targets virtualization
  • Targets NAS
Decryptor
No public decryptor

No free public decryptor exists. Neither No More Ransom, security vendors nor law enforcement have released a tool for Eclipse, and there is no public record of leaked keys or an exploitable implementation flaw.

The operators claim ChaCha20 encryption with Kyber post-quantum key encapsulation. With a sound implementation there is no decryption path without the private key. Any tool claiming to decrypt Eclipse directly should first prove itself on your own samples in an isolated environment.

Latest activity

  1. Victim count reached eight across Singapore, the US, India and Italy - hospitality, travel media, financial software, manufacturing and pharma research. About half the domains appear in infostealer data.

    Sources
  2. The Eclipse Blog leak site went live and posted its first victim, Singapore maritime and oil-and-gas marketplace Moscord, with the attack estimated at 14 August 2026.

    Sources
  3. An actor using the handle EclipseSupport advertised Eclipse RaaS on criminal forums: a Rust Windows encryptor plus C++ builds for Linux, NAS, ESXi and Nutanix, using ChaCha20 with Kyber key wrapping.

    Sources

Overview

Eclipse became visible in August 2026: threat-intelligence trackers catalogued its leak site - a posting site and a separate file site, both on Tor, the former on an eclipse-prefixed address - around 11 August, with the first victims published in mid-August. An actor using the handle EclipseSupport was reported recruiting affiliates on criminal forums with a USD 300 entry fee, a 90/10 split for the first cases falling to 80/20 afterwards, and a minimum ransom target of USD 70,000.

As of 11 September 2026 the leak site had published around eight victims - trackers differ slightly on the count - across Singapore, the United States, India and Italy, spanning hospitality, travel media, financial software, engineering and manufacturing, pharmaceutical research and legal services. Trackers flag roughly half of those domains as correlating with infostealer credential data.

Public information is limited. No vendor has published a sample analysis; the extension, note filename and indicators are undocumented and the advertised capability unverified. Note also that "Eclipse" is a common word: unrelated security tools, projects and handles share the name, so confirm attribution against the leak site and contact details rather than the name alone.

How to identify it

No extension or note filename is publicly documented, so Eclipse cannot be identified from its extension. Only peripheral indicators are usable:

  • The organisation appears on the Eclipse Tor posting site, with sample data packs hosted on a separate file site.
  • The note points to an .onion negotiation address.
  • Contact channels combine Session, Tox and a PGP key - a combination recorded by several trackers.
  • Payment is requested in Bitcoin and Monero.

Preserve the original note and three to five encrypted samples; let analysts compare headers, trailers, stride and embedded strings before attributing.

Infection vectors

Verifiable intrusion detail is scarce:

  • Stolen credentials. About half the victim domains appear in infostealer datasets, pointing to reused VPN, RDP and SaaS credentials.
  • Affiliate model. Under RaaS, tradecraft is per affiliate, so two Eclipse cases may share no initial access vector.
  • Operator claims. Automated lateral movement, defence evasion and targeted service termination - none independently corroborated.

Defensive priority falls on MFA at every remote entry point, remediating exposed credentials, and tighter control of domain administrator accounts.

Encryption behavior

All of the below comes from the operators' advertisement and has not been confirmed by independent analysis. On-site measurement is authoritative:

  • Algorithms. ChaCha20 for file content, keys distributed via Kyber post-quantum key encapsulation.
  • Code and platforms. A Rust Windows payload; C++ builds for Linux, NAS, ESXi and Nutanix.
  • Virtualisation and backup. Claimed routines for encrypting Hyper-V virtual machines and disabling Veeam backups.
  • Encryption modes. Configurable speed and stealth profiles, normally implying an intermittent-encryption option.
  • Double extortion. Exfiltration before encryption, with leak-site publishing in the affiliate panel.

Four things must be measured on site: shadow copies, database and backup agent services, which virtual-disk regions were overwritten and at what stride, and NAS snapshots - they decide the recovery route.

Assess before you act

Recoverability assessment

We do not pay ransoms and do not negotiate. Our work is technical recovery, impact assessment and attribution; for a family this new, recoverability is measured case by case.

1) Public decryptor. None, so this layer is skipped.

2) Repair space under intermittent encryption. If partial encryption is confirmed, database files (MDF/LDF, DBF, ibd), virtual disks (vmdk/vhdx) and mail stores may retain large untouched regions, allowing page-level extraction and logical rebuilds, with the yield depending on which structures were hit.

3) Backups, snapshots and shadow copies. Offline and offsite backups, NAS, SAN and hypervisor snapshots and cloud version history usually give the highest recovery ratio. Because Eclipse advertises anti-Veeam capability, backup usability must be tested.

4) Unencrypted copies and log replay. Recycle bins, endpoint caches, BI staging databases and transaction logs support point-in-time reconstruction.

5) Low-level carving. If the encryptor writes new ciphertext and deletes the original, source data may survive in unallocated clusters; all writes must stop immediately.

6) The exfiltration side. Even with every file restored, the scope of stolen data, notification obligations and credential rotation remain. We commit to a verifiable assessment and a bounded scope, never to a promised outcome.

Our response plan

Hit by Eclipse ransomware? What to do

  1. Containment and forensic preservation

    Isolate affected hosts, ESXi and Hyper-V servers and NAS units from production networks and storage paths, and do not reboot or power off. Image the domain controller, backup server and hypervisor management hosts first, export VPN, edge-device and Active Directory logs, and keep the original note plus three to five encrypted samples.

  2. Attribution and encryption analysis

    With no public extension or note signature, Eclipse can only be confirmed by sample comparison. The analysis measures the encryption mode (full or intermittent), the overwrite stride, header and trailer markers, and what was done to shadow copies, snapshots and backup services. Its conclusions govern everything that follows.

  3. Recoverability and exposure assessment

    Inventory which backups, storage snapshots and hypervisor snapshots are genuinely usable, and run sample repairs on the critical databases and VMs. In parallel, reconstruct the timing, channel and volume of exfiltration from logs and traffic records. The output is a written assessment: route per system, expected recovery ranges, timelines and notification guidance.

  4. Recovery execution and verification

    All work happens on images or copies with originals kept read-only. Restore in business priority order: identity and domain controllers, then core databases, then file and mail systems. For ESXi and Hyper-V, repair virtual disk structures and mount them to extract data rather than overwriting the original datastores. Verify integrity and run business-side checks after each batch.

  5. Attribution, hardening and handover

    Reconstruct the full kill chain, focusing on infostealer-leaked credentials and remote entry points without MFA. Remove persistence, rogue accounts and scheduled tasks; reset credentials domain-wide and enforce MFA on VPN; segment the hypervisor management network; rebuild backups to a 3-2-1 design with immutable copies. Close with an incident report and a handover checklist.

Risk warning

What not to do

  • Do not reboot or power off affected hosts and hypervisors - losing memory-resident key material, processes and connections destroys both evidence and any potential recovery path.
  • Do not trust any tool or service claiming to decrypt Eclipse directly. No public decryptor exists, and tools of unknown origin frequently cause a second round of damage.
  • Do not delete the ransom note or encrypted samples, and do not rush to clean up 'virus files' - they are the only basis for confirming the family and analysing the encryption mode.
  • Do not reattach backup media or backup servers to the network before verifying them; this operation publicly advertises the ability to disable Veeam backups.
  • Do not format, reinstall, rebuild RAID arrays or storage pools, or reinitialise ESXi datastores - that removes any chance of low-level carving.
  • Do not contact the .onion address in the note or pay the ransom; payment produces neither a reliably working key nor any assurance that the stolen data stays private.

Emergency response

Data already encrypted? Stop and let an engineer look first

We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.

Related scenarios

Related industries

Similar families

FAQ

Eclipse Frequently asked questions

  • Can Eclipse ransomware be decrypted?

    There is no free public decryptor and no known implementation flaw or leaked keys. The realistic routes are backups and snapshots, database and virtual-disk repair where intermittent encryption left intact regions, unencrypted copies with log replay, and low-level carving. How much is recoverable can only be scoped after examining your actual samples.

  • What extension and ransom note filename does Eclipse use?

    As of September 2026 public threat intelligence documents no extension or note filename for Eclipse, and no vendor has published a sample analysis. You therefore cannot attribute Eclipse from the extension - several extensions circulating online belong to other families. Preserve the original note and encrypted samples and have analysts confirm from file structure.

  • Does Eclipse encrypt ESXi, Hyper-V and NAS?

    The operators advertise C++ encryptors for Linux, NAS, VMware ESXi and Nutanix plus dedicated Hyper-V routines. These claims are unverified, but defensively they should be treated as real: keep hypervisor and NAS management interfaces off the public internet, segment the management network, and keep immutable snapshot and backup copies.

  • Does the claimed post-quantum encryption make recovery harder?

    It makes no practical difference to incident response. Whether keys are wrapped with RSA or Kyber, a sound implementation cannot be reversed without the private key; post-quantum design only addresses future quantum attacks. What actually determines the outcome is the encryption mode, whether backups and snapshots survived, and how quickly the response began.

  • Should Chinese organisations be concerned about Eclipse?

    Victims listed so far concentrate in Singapore, the United States, India and Italy, with no public record of a mainland China organisation being named. But the family recruits affiliates through RaaS and leans heavily on stolen credentials - the same weaknesses common in Chinese manufacturing, pharmaceutical and logistics firms. Overseas subsidiaries and cross-border branches sit inside its reach.