Skip to main content

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

SheMo Noransom舍末无勒

Ransomware family

Crysis / Dharma Ransomware Decryption & Data Recovery

  • Active
  • High
  • Some versions decryptable

Crysis (CrySiS) and its successor Dharma have been active since 2016, breaking in through brute-forced RDP and spawning many variants including .cezar, .arena, .bip, .combo and .java. Early versions have free decryptors; the .cezar family from 2017 onward does not.

First seen
2016-02
File extensions
.cezar .arena .bip
Ransom notes
info.hta
Affected platforms
Windows / Databases

Family profile

File extensions
  • .cezar
  • .arena
  • .bip
  • .combo
  • .java
  • .dharma
  • .wallet
  • .harma
  • .adobe
  • .bkp
Ransom notes
  • info.hta
  • FILES ENCRYPTED.txt
  • README.txt
  • Info.hta
Contact patterns
  • Disposable mailboxes (primary and backup, free encrypted-mail domains)
  • Attacker mailbox embedded directly in the filename
  • IM account as a fallback in some variants
Aliases / versions
CrySiS、Dharma、Cezar 家族、Wallet / Arena / Bip / Combo / Java 变种
First seen
2016-02
Status
Active
Threat level
High
Affected platforms
  • Windows
  • Databases
Tags
  • Prevalent in China
  • Ransomware-as-a-Service
  • RDP brute force
  • Targets databases
  • Legacy family
  • Active
Decryptor
Some versions decryptable

Decryptability for Crysis/Dharma depends entirely on the variant's era.

Decryptable: between 2016 and 2017 several batches of master keys were released publicly, so Kaspersky's RakhniDecryptor supports Crysis generations 2 and 3 and some early Dharma variants (.dharma, .wallet, .onion, .zzzzz and similar), and No More Ransom carries the corresponding entry. ESET also published tools for early versions.

Not decryptable: the .cezar family that appeared from 2017 onward — including .arena, .bip, .combo, .java, .harma and many others — has no public decryptor, and it accounts for the overwhelming majority of current Chinese cases.

The workflow is therefore: determine the variant's era from the extension and notes; for early variants, trial-decrypt with RakhniDecryptor on read-only copies; for the .cezar family, go straight to backup restoration and repair assessment rather than spending time on decryptors.

Sources

Latest activity

  1. 360's Aug 2026 report: Crysis still leads devices seeking help with its decryption utility, yet the month's top infections were Weaxor (65.74%), BrzCrypt and LockBit, and no Crysis suffix made the active keyword list.

    Sources

  2. Solar's H1 2026 report covers 375 domestic incidents; among the 114 with a confirmed entry point, management-software flaws, database access and weak server/remote-ops passwords totalled 81.1% — still Crysis's core vector.

    Sources

Overview

Crysis (also written CrySiS) appeared in early 2016 and spawned the Dharma branch later that year; the two are now commonly grouped as the Crysis/Dharma family. It was among the first families to industrialise brute-forced RDP, essentially defining the "expose 3389, brute-force, deploy by hand" chain that still dominates Chinese server ransomware. The later Phobos family closely resembles it in note style and operating model and is widely regarded as its continuation.

Its decryption history is what makes it unusual. Between late 2016 and 2017 several batches of Crysis master keys were published, and vendors built free decryptors from them; Kaspersky's RakhniDecryptor still supports Crysis generations 2 and 3 and some early Dharma variants. From 2017 onward, however, the operators changed their key scheme and introduced the .cezar family, and every variant since has been undecryptable. 360's July and August 2026 monthly reports still show Crysis first by the number of devices seeking help through its decryption utility, while new monthly infections are now dominated by Weaxor, BrzCrypt and Sorry, and Crysis-lineage suffixes no longer appear on the active-keyword list — a combination that reflects a large installed base of victims, many of them hitting the undecryptable .cezar variants.

How to identify it

The filename pattern is the key to identification: originalname.originalext.id-8 hex chars.[attacker email].suffix — for example data.xlsx.id-A1B2C3D4.[xxx@example.com].bip.

Common extensions split in two: early and potentially decryptable — .dharma, .wallet, .onion, .zzzzz, .crysis; and the .cezar family, which is not decryptable — .cezar, .arena, .bip, .combo, .java, .harma, .adobe, .bkp and a long, growing list.

Ransom notes: the classic marker is info.hta, launched automatically through an autorun entry once encryption completes, with FILES ENCRYPTED.txt on the desktop and README.txt in some variants.

Distinguishing similar families (this decides whether a free tool exists): Crysis/Dharma uses .id-8 hex chars.[email].suffix with info.hta and FILES ENCRYPTED.txt; Phobos uses .id[8 chars-4 digits].[email].suffix with info.txt and info.hta; Makop uses .[8-char ID].[email].suffix with readme-warning.txt; GlobeImposter uses themed suffixes (4444/666) with how_to_back_files.html.

Infection vectors

Brute-forced RDP is the signature Crysis/Dharma entry point, unchanged since 2016. A typical chain: scan the internet for hosts with port 3389 open; brute-force built-in accounts such as administrator, or simply log in with leaked credentials purchased on underground markets; uninstall or disable security software and create a backdoor administrator account; distribute the payload to other internal servers through shared folders, mapped drives or remote desktop; terminate database, mail and backup services and delete shadow copies; then encrypt, drop info.hta and FILES ENCRYPTED.txt, and set an autorun entry so the note pops up at every logon.

Other documented vectors include phishing attachments, more common in early versions, and distribution disguised as legitimate software installers. The reason for its prevalence in China is identical to Phobos: many smaller companies map 3389 straight to the internet with a simple, long-unchanged administrator password; the application, database and backups share one host; and the network is unsegmented. This chain has run for nearly a decade and still works.

Encryption behavior

Crysis/Dharma encrypts file contents with AES and protects the symmetric key with RSA. Versions before 2017 are decryptable because of their key-scheme design and the master-key leaks; the .cezar family from 2017 onward changed the scheme so each host's key material is protected by the attacker's private key, eliminating any general decryption path.

Encryption and destructive behaviour: it terminates database (SQL Server, MySQL, Oracle), mail and backup-agent services before encrypting; encrypts local disks, mapped network drives and reachable SMB shares, so NAS devices and file servers are commonly caught; deletes volume shadow copies and restore points via vssadmin and similar methods; explicitly targets database and backup files (.mdf, .ldf, .bak, .dbf, .ibd); and sets a registry autorun entry so info.hta pops up at every logon.

On large-file handling: variants span nearly a decade with substantial implementation differences and public sources give no consistent answer, so testing is required — take .mdf, .dbf and .ibd files and large archives, analyse the distribution and stride of encrypted blocks, determine whether encryption is partial or full, and only then judge repair feasibility. Platforms are primarily Windows.

Assess before you act

Recoverability assessment

The first step in Crysis/Dharma recovery is determining the variant's era, which decides whether a free decryption path exists.

1. Free decryptors (early variants only) The master keys released in 2016 and 2017 make some versions decryptable. Kaspersky's RakhniDecryptor supports Crysis generations 2 and 3 and early Dharma variants such as .dharma, .wallet, .onion and .zzzzz, with a corresponding entry on No More Ransom; ESET also published tools for early versions. Method: trial-decrypt samples of different sizes and types on read-only copies, counting success only when the output opens correctly. If the extension belongs to the .cezar family (.cezar, .arena, .bip, .combo, .java, .harma), there is no public decryptor — and that covers the overwhelming majority of current Chinese cases.

2. Backups, snapshots and shadow copies The primary realistic path. The family deletes shadow copies and encrypts backups within reach, but hands-on deployment and limited dwell time often leave gaps: standalone backup servers outside the same credential scope, offline media and tape, NAS-native snapshots, cloud object-storage version history with object lock, and hypervisor snapshots.

3. Structure-level repair of databases and large files (verify first) Where large files are only partially encrypted, page-level damage mapping, system-table and allocation repair and table-level extraction are possible, with transaction logs and upstream documents replayed to close the delta. Where encryption is full the path is closed, and we say so.

We do not pay ransoms, do not negotiate for clients, and never promise that every file can be decrypted or restored.

Our response plan

Hit by Crysis / Dharma ransomware? What to do

  1. Step 1: Containment and evidence preservation

    Immediately remove public 3389 mapping on affected servers, block SMB and RDP between them and the rest of the network, and disable the brute-forced account together with every suspicious new administrator account. Crysis/Dharma operators routinely leave backdoor accounts and registry autorun entries that must be removed before recovery.

    Evidence to preserve: security log 4625/4624 records (source IP, success time and account of the brute force), account and group changes, registry autorun entries, scheduled task and service inventories, records of security software being uninstalled, the original info.hta and FILES ENCRYPTED.txt notes, encrypted samples of varying type and size, and matching unencrypted originals wherever possible (needed both for decryptor trials and for repair comparison).

    Do not reinstall, do not reformat, and do not run any decryption or recovery tool against original disks.

  2. Step 2: Determine the variant era and test decryption feasibility

    This is the highest-value step in a Crysis/Dharma case, because early variants genuinely are decryptable.

    Evidence used: whether the extension belongs to the early sequence (.dharma, .wallet, .onion, .zzzzz) or the .cezar family (.cezar, .arena, .bip, .combo, .java, .harma); whether filenames follow .id-8 hex chars.[email].suffix; whether the notes are info.hta plus FILES ENCRYPTED.txt; and marker structures in encrypted files together with payload characteristics. Separate it clearly from Phobos, Makop and GlobeImposter.

    If it is an early variant, immediately take samples of varying size and type and trial-decrypt them on read-only copies with Kaspersky RakhniDecryptor or equivalent, validating that the output is usable. If it is the .cezar family, skip decryptors and go straight to encryption analysis: whether encryption is partial or full, the block stride, and where damaged structures sit, to feed the repair feasibility assessment.

  3. Step 3: Recoverability assessment and recovery planning

    Bucket by path with a time and coverage estimate for each:

    • Decryption viable: the scope where trial decryption succeeded on early variants and the runtime for bulk execution.
    • Backup available: verify the recovery point and integrity of standalone backup machines, offline media, NAS snapshots, cloud version history and hypervisor snapshots, confirming they were outside the same credential scope.
    • Repair required: sample .mdf/.ldf, .dbf, .ibd and large business files; give table-level coverage estimates where encryption is partial and state honestly where it is full.
    • Side-channel reconstruction: inventory report exports, reconciliation data, email attachments and paper vouchers, and assess the reconstructable time range.
    • Unaffected hosts: verify host by host which can serve as a baseline.
    • Confirmed unrecoverable: listed explicitly so the business can plan re-entry.

    The plan specifies delivery sequence and per-batch verification, and recommends which systems to restore first to resume operations quickly.

  4. Step 4: Recovery execution

    Execution happens in a clean environment where backdoor accounts, autorun entries and residual payloads have been removed, working throughout on read-only images and copies.

    • Decryption (where applicable): run in batches against early-variant files, validating openability and integrity after each batch.
    • Backup restoration: validate backup integrity and screen for embedded payloads in isolation first, then restore in priority batches.
    • Database repair: where encryption is confirmed partial, map page-level damage in SQL Server, repair system tables and allocation structures and extract table by table; for Oracle, combine datafile header repair with archive-log application; for MySQL, process .ibd files individually and rebuild the dictionary.
    • Delta reconstruction: replay unaffected transaction logs, archive logs and upstream transaction feeds.
    • Files and NAS: restore in batches by department priority.
    • Side-channel reload: import reconstructed reports and reconciliation data back into the system by business period.

    Each batch ships with verification records: record-count reconciliation, sampled key document checks and application functionality tests. The recovery environment joins production only once confirmed clean.

  5. Step 5: Attribution, hardening and sign-off

    The investigation report states: brute-force source IPs and timeline (or whether the operator simply logged in with purchased credentials), which account succeeded, an inventory of backdoor accounts and autorun entries, which hosts the manual deployment reached, and why backups failed.

    Verifiable hardening checklist:

    • Remove all public 3389 mappings and route remote access through VPN or a zero-trust gateway with enforced multi-factor authentication.
    • Rename built-in administrator accounts and give them strong passwords, clean up contractor and legacy accounts, and enable lockout policies.
    • Segment servers to limit internal RDP and SMB reachability.
    • Rebuild the backup architecture on offline/off-site plus immutable storage, with backup media physically separated from production servers, the backup system using separate credentials, and regular real restore drills.
    • Separate databases from application servers and keep database ports off the internet.
    • Deploy EDR with a closed alert loop for failed logons, account creation, security-software removal and bulk file renaming.

    The engagement closes with an incident report and a hardening sign-off checklist.

Risk warning

What not to do

  • Do not run RakhniDecryptor or similar tools directly against original disks. Image read-only first, trial-decrypt on copies, validate the output, and only then process in bulk.
  • Do not assume free decryption simply because the name says "Dharma". Only pre-2017 early variants are decryptable; .cezar, .arena, .bip, .combo, .java and the rest of the .cezar family have no public decryptor.
  • Do not reconnect to the network before backdoor accounts and registry autorun entries are removed. The attacker's channel is still open and re-encryption during recovery is a real risk.
  • Do not delete info.hta, FILES ENCRYPTED.txt or encrypted samples; they are required inputs for determining the variant era and testing decryption feasibility.
  • Do not reinstall the OS or reformat affected volumes, and do not rebuild partitions for a "thorough clean-up" — that destroys both forensic evidence and the fragment-recovery option.
  • Do not email the addresses in the note to pay or negotiate on your own; payment guarantees no working decryptor and does nothing about 3389 still being exposed.

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.

+86 15639272850See contact details

Related scenarios

Related industries

Similar families

FAQ

Crysis / Dharma Frequently asked questions

  • Can .bip / .combo / .java / .arena files be decrypted for free?

    No. These extensions all belong to the Crysis/Dharma .cezar family, introduced after the operators changed their key scheme in 2017, and no free public decryptor exists for them.

    What can be decrypted for free are the earlier versions: the master keys published in 2016 and 2017 allow Kaspersky's RakhniDecryptor to handle Crysis generations 2 and 3 and early Dharma variants such as .dharma, .wallet, .onion and .zzzzz, with a corresponding entry on No More Ransom.

    Determining the variant era is therefore the first priority. If it is confirmed as .cezar family, shift effort immediately to realistic paths: inventory standalone backups and offline media, check NAS and hypervisor snapshots, run repair feasibility tests on database files, and map untouched hosts and side-channel copies.

  • How do we tell decryptable early Dharma from the undecryptable .cezar family?

    Mainly by the extension, supported by the notes and the timeline.

    Decryptable early extensions: .dharma, .wallet, .onion, .zzzzz, .crysis — mostly infections from 2016 to 2017. The .cezar family (undecryptable): .cezar, .arena, .bip, .combo, .java, .harma, .adobe, .bkp and many more, appearing from 2017 onward.

    Both share the same filename pattern (originalname.id-8 hex chars.[email].suffix) and the same info.hta plus FILES ENCRYPTED.txt notes, so neither distinguishes them — the extension itself does.

    The final answer comes from a trial: copy encrypted samples of varying size and type onto read-only copies, run Kaspersky RakhniDecryptor against them, and count it decryptable only when the output opens correctly in the business application. Never run the tool directly on original disks.

  • Filenames became .id-XXXXXXXX.[email].suffix — which family is this?

    That is the classic Crysis/Dharma pattern: original filename, then .id-, an 8-character hexadecimal ID, .[attacker email], and the variant suffix. Together with info.hta (which pops up at logon) and FILES ENCRYPTED.txt on the desktop, it is effectively confirmation.

    Two similar families need separating:

    • Phobos uses .id[8 chars-4 digits].[email].suffix — the ID is bracketed and carries four extra digits — with info.txt plus info.hta notes.
    • Makop uses .[8-char ID].[email].suffix — bracketed but without the id- prefix — with a readme-warning.txt note.

    The distinction is not cosmetic: Phobos has an official free decryptor released by Japan's National Police Agency in 2025, Crysis/Dharma is decryptable only in early variants, and Makop has nothing at all. Misidentifying the family means the wrong tool and a wasted response window.

  • A ransom page pops up at every logon — what should we do?

    That is the registry autorun entry Crysis/Dharma set, running info.hta. Note that the pop-up is only the note display program: closing it does not restore data, and deleting it does not lose any — but do not rush to clean it up before forensics is complete.

    The correct order: keep one copy of info.hta as evidence (variant identification needs it), then remove the autorun entry and residual payloads after imaging and evidence collection. Check for other persistence at the same time: attacker-created administrator accounts, scheduled tasks, services and remote-access tools. Anything missed makes re-encryption during recovery likely.

    One more caution: the pop-up usually offers to decrypt a few small files for free. Do not use important files for that, and do not open a channel with the attacker on that basis — we do not negotiate for clients and do not recommend organisations make contact themselves.

  • Should we pay the Crysis/Dharma ransom?

    We do not pay ransoms, do not negotiate for clients, and advise against paying independently. The family has run for nearly a decade with affiliates of widely varying competence; victims have received no decryptor, a defective one, or one that caused further damage to large files. Payment also marks the organisation as willing to pay and creates compliance and legal exposure from sending funds to an overseas criminal operation.

    The better use of the first 24 to 72 hours is fourfold: complete containment and remove backdoors so there is no second wave; determine the variant era and trial-decrypt early variants, which may resolve the case outright; inventory every potentially surviving backup and snapshot; and run sample-based repair feasibility on the database files.

    In most Crysis/Dharma cases, the combined coverage of early-variant decryption, backups, structural repair and side-channel copies is far more controllable than betting on a decryptor.

Sources

External links are provided for reference only. The content is published by third parties and does not represent our position.

Updated