QNAP NAS Encrypted by Ransomware

QNAP devices have been through several publicly documented targeted campaigns, and knowing the differences helps you place your own situation:

• DeadBolt (from 2022): hijacks the device login page to display the ransom message, encrypts files with AES-128 and appends .deadbolt, and runs a multi-tier extortion scheme that also demands payment from the vendor. Public records show it hit QNAP first, then ASUSTOR and TerraMaster devices.
• Qlocker (2021): performed no conventional encryption, instead packing files into password-protected 7-Zip archives — extremely fast and extremely damaging. Reporting linked the campaign to exploitation of a hardcoded-credential flaw in HBS 3 (CVE-2021-28799).
• eCh0raix: a NAS-focused family that public reporting shows affected both QNAP and Synology devices across several waves.
• Checkmate (2022): QNAP's own advisory described attacks against devices with SMB enabled and exposed to the internet, using dictionary attacks against weak-password accounts, appending .checkmate and leaving a !CHECKMATE_DECRYPTION_README note. QNAP advised not exposing the NAS to the internet, using a VPN instead, reviewing account strength, disabling SMB 1, keeping firmware updated, and maintaining backups and snapshots.

The shared precondition across all of them is remarkably consistent: the device was reachable from the internet, with weak credentials or an unpatched flaw.

Mistakes to avoid:

• Resetting the device, rebuilding the RAID, initialising the storage pool. Destroys every recovery option at once. In DeadBolt cases the hijacked login page pushes many people straight toward a factory reset — precisely the worst choice.
• Deleting encrypted files or the 7z archives. They may be the only recoverable material.
• Scanning and writing to QNAP drives directly from a PC. QTS also builds on Linux software RAID and LVM, and careless handling destroys the array.
• "Fixing" it with a firmware upgrade. That writes to the device and can overwrite evidence; firmware updates belong to the hardening phase, not the recovery phase.
• Following online guides to enter a key supplied by the attacker. Some campaigns attracted fake pages and secondary fraud.

We do not recommend paying, and we do not negotiate on your behalf.

• Do not expose the NAS to the internet. This is the shared precondition across every publicly documented QNAP ransomware campaign. Remove router port forwards and UPnP, disable unnecessary external access services, and use a VPN for remote access — QNAP's own first recommendation in the Checkmate advisory.
• Govern accounts and passwords. Review every account immediately: disable or rename the default administrator, enforce strong passwords, enable two-factor authentication and automatic lockout after failed logons, and delete dormant accounts.
• Disable SMB 1 and use SMB 2 or higher, and turn off services you do not need — SSH, Telnet, FTP, the web server, multimedia and container packages.
• Keep firmware and packages updated. In past campaigns, unpatched package vulnerabilities such as hardcoded credentials in a backup sync package were used directly for mass delivery; enable automatic updates or check manually on a schedule.
• Enable snapshots with a sensible retention policy. Snapshots are among the most effective recovery tools on a NAS, but recognise that a compromised administrator account can delete them — they do not replace offline backups.
• Keep the backup destination off the device. Use HBS to back up to another device, an external drive detached after each run, or cloud storage, retaining multiple versions. Never write backups to the same NAS.
• Minimise share permissions and restrict LAN reachability. Keep archive directories read-only and deny blanket write access to ordinary users, so one infected endpoint cannot encrypt every share.
• Review logs and drill recovery. Watch for anomalous logons and mass file-change alerts, and every six months genuinely restore a key directory from backup to prove the chain works.