If you are calling someone to handle this, remember one thing first: whether they can give a reliable judgment and quotation depends on whether the following items are still intact. To get straight to the point, before an assessment you usually need to prepare five types of materials:
- The original ransom note (not a paraphrase, but the file itself);
- Two to three small encrypted samples that contain no sensitive information, with complete file names;
- A list of affected assets: systems, virtualization platforms, database types and versions, business ledgers, data volume;
- The true status of backups and snapshots: whether they exist, where they are, and whether they were also encrypted;
- What you have already done since the incident, including scans, restarts, and tools you have run.
Before collecting these, first disconnect and isolate machines that are still spreading, and set affected storage to read-only or stop writing to it. Always use copies for sampling; do not move or rename the original files.

Original Ransom Note: The Starting Point for Identifying the Family and Variant
Ransom notes are usually new files such as README.txt, HOW_TO_DECRYPT.html, !INFO.hta, etc. on the desktop or in each encrypted directory. Some variants also change the desktop wallpaper. They usually contain the attacker's email address, a Tor onion address, and a unique identifier assigned to you (Victim ID / Personal Key). This information is the main basis for determining which family and which branch version you are dealing with—different versions of the same family may have completely different recoverability.
Note:
- Copy the original file out and keep it. Screenshots can only be supplementary and cannot replace the original, because identifiers and encoding details are easily lost or misread in screenshots;
- If multiple machines are affected, keep a copy of the ransom note from each machine; sometimes this can reveal the intrusion path and encryption order;
- Do not contact the attacker yourself based on the ransom note, and do not click links in it. Identifying the version does not require contacting the attacker.
It is unreliable to draw conclusions based only on a file extension or the name reported by antivirus software. The same extension has been used by multiple families, and antivirus detection names are often generic. Therefore, samples and ransom notes should be examined together.
Encrypted Samples: Choose Small, Generic, Non-Sensitive Ones
Technical judgment requires looking at the structure of encrypted files: whether the file header was modified, whether the entire file was encrypted or only the header or segments, and whether there is an appended marker block at the end. These can only be seen from real samples.
Sampling recommendations:
- Choose two to three small files ranging from tens of KB to a few MB, such as built-in sample images, generic templates, installers for publicly available software, or test documents with no value;
- Keep the complete file name, including the seemingly random string in the middle. Many variants use the naming format
报表.xlsx.id-xxxxxxx.[邮箱].后缀, and the ID and email address in it are also identification clues; - If you can find the unencrypted original of the same file (for example, re-download the same version of the installer from the official website, or find a template with the same name and version on an unaffected machine), provide it as well. With a plaintext-ciphertext pair, in some scenarios comparative analysis can be performed to determine the encryption method and whether implementation flaws exist.
Do not choose financial ledgers, customer lists, or scanned documents with ID numbers as samples just to "make it clearer for the other party." Qualitative analysis does not require your core data.
Asset Environment: Determines Workload and Feasibility
A large part of the quotation difference comes from environment complexity, so clarify these:
- Whether the affected systems are Windows or Linux, and approximate versions;
- Whether they are physical machines or run on virtualization platforms such as ESXi or Hyper-V, and whether the encrypted items are files inside guest machines or virtual disks such as
.vmdk/.vhdx; - Database type and version: SQL Server, MySQL, Oracle, etc.; approximate volume and storage paths of key data files (
.mdf,.ldf,.bak,.ibd,.dbf); - Business software and ledgers: Yonyou, Kingdee, etc., and whether the ledger is a local database or on a separate server;
- Number of affected machines, whether encryption is still ongoing, and whether shared drives and NAS were affected;
- Which data you most need to recover first. The more specific the recovery scope, the more realistic the assessment and scheduling.
If virtualization or databases are encrypted, do not rush to perform any repair actions on the original storage. For the relevant judgment order, see Handling order when an ESXi virtual machine is encrypted and there is no snapshot and Which files to preserve after a Yonyou database is encrypted.
Backups and Snapshots: The Fork in the Road
This item directly determines which path the solution takes—whether it centers on decryption, or mainly on backup repair, database structure extraction and fragment reassembly, and mining residual files and logs. You need to inventory more than just "whether backups were made":
- Offsite backups, offline cold backups, tapes, and the last successful time;
- Whether NAS snapshots, VM snapshots, and storage-layer snapshots still exist;
- Historical versions and recycle bins of cloud drives/sync drives;
- Whether the backup server itself was encrypted and whether backup files can be opened.
In reality, backups often exist but were hit as well. That does not mean there is no hope, but the inventory must be honest; vagueness will lead the assessment in the wrong direction. For the handling order when backups are also affected, see another article: How to judge what can still be saved when backup files are also encrypted by ransomware.
Actions Already Taken: Say It Even If It Is Uncomfortable
This item is most easily omitted, but it is often the key to whether recovery is still possible. Provide truthfully:
- The approximate time the anomaly was discovered, and what you believe was the starting point (a certain machine, an email attachment, a remote login);
- Whether you restarted or forcibly powered off. Temporary data in memory and traces not yet written to disk will disappear;
- Whether you performed a full scan and quarantined/deleted detected items. Some samples may leave analyzable information in local files; once deleted, it is hard to find;
- Whether you ran
chkdsk, disk repair, formatting, or system reinstallation on the affected volume; - Whether you ran third-party decryption tools or data recovery software, on which disk, and whether they wrote directly back to the original files.
Some tools, when the version does not match, produce a batch of files that "look decrypted but cannot be opened," which instead obscures the original ciphertext. In such cases, first see Troubleshooting when a decryption tool says the file is not supported and How to tell whether a decrypted file cannot be opened because it was not decrypted or because decryption failed. If the system has already been reinstalled, also specify which disk was formatted and whether the data disk was repartitioned; this determines how much recovery space remains after reinstallation.
Boundaries for Submitting Materials
- Do not directly send complete production databases, financial ledgers, or files containing ID numbers and customer information to channels without a signed confidentiality agreement, and do not upload them to public forums, Q&A posts, or any random cloud drive/online analysis site;
- Do not spread suspected malware samples through public channels, and do not double-click them on other machines "just to let someone see." When submission is needed, handle it separately according to the other party's explicit instructions;
- Do not repeatedly try tools on the only original media. If necessary, make an image first or analyze on a read-only copy;
- Do not write production passwords or VPN credentials in chat logs, and certainly do not change them on a machine that may still be controlled.
If Materials Are Complete, Will the Quotation Be Accurate?
Usually: once materials are complete, you can first get a recoverability judgment and a range of handling options, and the cost converges to a negotiable range. However, some cases still require read-only image analysis and trial decryption of a few samples before a specific plan can be set. If the hard drive itself has physical faults, the RAID array is damaged, or data has been overwritten a second time, hardware parameters and intermediate storage space often need to be supplemented; such cases can only be verified on site.
If someone gives you a fixed price, promises 100% recovery, or guarantees delivery within a fixed number of hours without having seen the ransom note and samples, that number's basis is worth questioning. Several questions to judge whether the other party's plan is reliable are collected in How to judge whether a ransomware decryption company's plan is reliable; for why there is no uniform price, see Several variables that determine ransomware recovery costs.
If You Suspect Silver Fox or Remote Control Rather Than File Encryption
The materials to prepare for this type of incident are completely different: the source of the suspicious file or link (group message, email, recruitment attachment), the approximate time it was opened, which accounts were logged in on this machine (WeChat, QQ, corporate email, online banking, financial software, remote tools), whether there were abnormal transfers or changes to receiving information, and whether USB shields and certificates were inserted in the machine.
Antivirus not reporting a virus cannot be taken as evidence that it has been cleaned. Host handling, account sessions, and financial risk are three separate lines: account passwords and two-factor authentication should be changed on another trusted device, and abnormal transfers should be handled immediately through the bank's customer service and public security official channels, with complete materials preserved. For the specific order, see How to handle it when the mouse is controlled by someone else and antivirus does not report a virus and Which account passwords need to be changed after discovering Silver Fox Trojan; for what to preserve before reinstalling, see this article.
Next Steps
Organize the materials into a directory according to the five categories above (original ransom note, samples, environment list, backup list, operation record), then seek an assessment. Communication costs will be much lower, and you can avoid being led in the wrong direction due to missing information.
She Mo Wu Le's approach is to first perform family identification and recoverability assessment, and after confirming the scope, provide a handling plan and quotation. It does not pay ransoms and does not negotiate on your behalf. To understand the specific sequence from assessment to delivery, see Recovery assessment and delivery process; if you already have the ransom note and samples and need a judgment for a specific incident, provide them according to Material submission requirements, and do not upload production data to public channels. If multiple machines are still being encrypted and business has already stopped, prioritize emergency response—in this situation, isolation and loss containment come before all analysis.
Comments(0)