Case study
Crysis/Dharma encrypts an insurance agency's OA and file servers
Brute-forced RDP let a Crysis/Dharma .cezar-family variant encrypt an insurance agency's OA and file servers, hitting scanned contracts and customer records. Attachments came back from NAS snapshots, mailboxes and local copies, with the OA database rolled back from an off-site backup.
- Industry
- Financial Services Ransomware Response and Recovery
- Family
- Crysis / Dharma
- Scenario
- OA Encrypted
- Handled
- 2025-12
This case study is composed from typical scenarios to illustrate our approach and the recovery paths involved. It does not describe a specific customer incident; real cases involving customer data are published only with authorization.
约 93%
Contract and customer records recovered
约 18 小时
OA workflow rollback window
4 个工作日
Core office systems back online
0
Ransom paid
Incident background
The client is a wealth management and insurance agency of roughly two hundred staff. Its OA system carries contract approvals, seal usage, customer follow-up and HR workflows; scanned contracts, policy paperwork and customer files sit on one Windows file server, with a NAS as secondary storage and a backup agent pushing a copy of the OA database to an off-site branch machine room in the early hours of each day.
To give field agents and two branch offices access, operations had mapped port 3389 on both the OA and file servers straight to the internet. Administrators still used the built-in account name with a password unchanged for years, and no lockout policy was in place.
The incident began late on a Friday night in December. When duty staff logged in on Saturday morning, an info.hta ransom page popped up automatically, FILES ENCRYPTED.txt sat on the desktop, and filenames had been rewritten as originalname.originalext.id-8 hex chars.[attacker email].bip, the note giving a primary and a backup anonymous mailbox. The OA application directory, attachment store, database files and file server shares were all affected, and the NAS shares reachable through mapped drives were encrypted too; shadow copies had been deleted and the backup agent stopped before encryption ran.
Before calling us the client had rebooted once and tried a downloaded decryption tool against the original disks.
What we did
Containment went out on the first call: keep the servers powered but off the network, stop writes and scheduled tasks, no further reboot, no decryption tool on original disks.
- Evidence and imaging. Read-only images of both servers, plus 4624/4625 logon records, account changes and registry autorun entries, with info.hta, FILES ENCRYPTED.txt and encrypted samples preserved intact; egress traffic was reviewed for exfiltration and the internal network swept for signs of lateral reach.
- Family confirmation and recoverability. The .id-8 hex chars.[email].suffix pattern with info.hta and FILES ENCRYPTED.txt identified Crysis/Dharma rather than Phobos or Makop. The .bip extension belongs to the post-2017 .cezar family, for which no public decryptor exists; RakhniDecryptor covers only early variants, so decryption was ruled out.
- Recovery. NAS administrative access had not been taken and its snapshots were intact, so contracts and customer records rolled back from them; gaps came from mail attachments and staff local copies. The OA database was rolled back from the off-site backup onto a clean server running a matching OA build, attachment paths reconciled against database records and the index rebuilt.
- Hardening in parallel. Backdoor accounts and autorun entries removed, public 3389 mappings withdrawn in favour of VPN with enforced multi-factor authentication, built-in accounts renamed with lockout enabled, servers segmented, and backups moved off-site with immutable copies.
- Deliverables. Investigation report and timeline, recovery scope with verification records, an unrecoverable list, a hardening checklist, and the exfiltration assessment.
Recovery result
Scanned contracts and customer records were recovered at about 93%. OA workflow data rolled back to the off-site backup taken in the early hours of the incident day, a rollback window of roughly 18 hours, and core office capability returned within four business days. The client paid no ransom and never contacted the mailboxes in the note.
What could not be recovered: approvals and seal-usage records raised during Friday's working day that had not reached the off-site backup, re-entered from email trails and paper approvals; and a few scans held only on staff laptops and never circulated by email. Re-entry and ledger reconciliation finished within two business days.
Forensics showed the attacker found the exposed 3389 port by scanning, brute-forced the built-in administrator password, logged in by hand, disabled security software, created a backdoor account, and pushed the payload to the file server and NAS shares through mapped drives; the run of failed logons had never triggered an alert. Egress records showed no evidence of bulk exfiltration, but as customer identity and policy data were involved we advised completing regulatory and internal incident reporting and assessing the scope of customer notification.
Recommendations: review the exposure inventory quarterly, keep an immutable backup copy with regular restore drills, and close the alerting loop on failed logons, account creation and bulk file renaming.
This is an illustrative case compiled from typical scenarios and anonymized; it does not refer to any specific client.
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 content
OA Collaboration System Encrypted by Ransomware
An encrypted OA system halts document circulation, approvals, contract archives, HR and knowledge bases at once — and because OA is so often published to the internet, it is frequently the attacker's first foothold. This page covers its vulnerability profile, the twin-track recovery of attachments and database, and how to check for lateral spread.
Financial Services Ransomware Response and Recovery
Financial and quasi-financial institutions face far stricter requirements on data integrity, transaction continuity and regulatory reporting than most sectors, so one ransomware event hits availability, customer trust and compliance simultaneously. This page covers the threat profile, a recovery approach centred on transactional consistency, and hardening priorities.
- Some versions decryptable
Crysis / Dharma
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.