Scenario solution
File Servers and NAS Encrypted by Ransomware
- Windows Server 文件服务
- Linux Samba / NFS
- 通用 NAS 与 iSCSI 存储
- DFS 命名空间
- 共享盘映射
- SVN / Git 服务器
- 图纸与档案共享库
When shared folders on a file server or NAS are encrypted, drawings, contracts, archives, quotations and design sources all become unusable at once — and mapped drives spread the impact to every endpoint. This page covers how to gauge spread, what shadow copies and snapshots realistically offer, and how to sequence recovery by business value.
Typical symptoms
- Files across shared folders carry appended extensions — .locked, .phobos, .[email].makop, .[8 random chars] — with a ransom note dropped in each directory level
- On endpoints, files on mapped drives (Z:, Y:) show blank icons and will not open, and Office reports an invalid file format
- The file server's disk IO is saturated for a long period, or the event log shows mass file rename and delete activity
- Shadow copies (Previous Versions) have been cleared, with vssadmin activity visible in the logs
- Shared folders and the recycle bin on the NAS are encrypted together, and the NAS's own backup jobs fail or have been disabled
- Unknown administrator accounts appear on the server, RDP logons originate from external IPs, and antivirus has been uninstalled or given directory exclusions
Business risk & common mistakes
File-server encryption damages differently from a database: it is not one large broken file but thousands of business documents failing at once, with value distributed very unevenly — a single tender package, an as-built drawing set or one client contract may matter more than the rest of the share combined. Recovery here is therefore less a single technical problem than a prioritisation problem.
The spread pattern is distinctive too. Having gained access to one domain endpoint or server, attackers enumerate network shares and encrypt outward through mapped drives, DFS namespaces and any share with write permission. Where the compromised account is a domain administrator or holds broad share rights, one execution can cover an entire file-service cluster. Public reporting shows the Phobos lineage — including its Makop derivative — breaks in chiefly through weak-password RDP exposed to the internet, and CISA has issued a dedicated Phobos advisory; GlobeImposter and Crysis/Dharma spread similarly. These families appear persistently in Chinese file- and application-server encryption cases.
Business risks and mistakes:
- Backups destroyed alongside. Where the backup target is a shared folder on a NAS to which the server has write access, backup files are encrypted with everything else — the single most common cause of backup failure.
- Everyone reconnecting shares, causing a second wave. Restoring the network before the source is eradicated lets still-infected endpoints re-encrypt recovered files.
- Running recovery software on the original volume and writing back to the same disk.
- Deleting encrypted files to free space. Those files may be the only remaining material; deleting them removes both repair and carving options.
- Rebuilding the RAID, initialising the storage pool or resetting configuration on a NAS, destroying recoverable underlying data.
- Believing that "files come back once antivirus cleans it." Eradicating malware and recovering data are two separate jobs.
We do not recommend paying, and we do not negotiate on your behalf.
Our response plan
Disconnect shares and map the blast radius
Immediately disconnect the file server and NAS from the network, or at minimum stop SMB / NFS services, and map the blast radius at the same time: which endpoints are still running the encryptor, which shares carry write permission, and which hosts the DFS and mapped-drive topology reaches. Do not rush to power off. Then image or snapshot the storage volumes read-only. Evidence includes encrypted samples, ransom notes, event logs (4624 / 4625 / 4720 / 7045), SMB session records, share permission configuration, and antivirus logs plus any exclusions that were added.
Identify the family and encryption characteristics
Determine the family from extension naming conventions, ransom note filenames and contact-address patterns — Phobos, Makop, GlobeImposter and the Crysis/Dharma lineage feature heavily here — and check whether a public decryptor exists. At the same time, sample different file types for entropy: many families encrypt only the header, or in segments, above a certain file size. That means large design sources, video, archives and VM images may carry real repair value, while small files such as Office documents and PDFs are usually encrypted in full.
Assess recoverability and build a business priority list
Two tables are essential here. First a technical recoverability table: surviving shadow copies and NAS snapshots, backups and offline copies, the repair value of partially encrypted large files, the scope for carving deleted files, and whether a public decryptor applies. Second a business priority table: confirm with each department which directories and files matter most — active project documentation, current contracts, accounting vouchers, live tender packages — and direct effort there first, rather than working through directories in order.
Recover in batches and prevent re-encryption
Recover onto a clean new server or in an isolated environment: build a clean share first, then load data in priority batches. For sequencing, grant a small group read-only access for verification, and open write access only once the content checks out. Keep source endpoints off the network throughout, until the estate has been swept and cleaned. Validate every batch by opening samples — do the drawings open, are the documents complete, do the archives extract — rather than counting files.
Govern permissions, rebuild backups, and sign off
Hardening here centres on permissions and backup architecture. Tighten share permissions to the minimum per department and project, removing Everyone / Full Control; stop forwarding 3389 publicly in favour of a jump host with MFA; remove rogue accounts and persistence; and close patch and EDR coverage gaps. Rebuild backups so the target is not a share the production server can write to — use an independent backup host or immutable storage, and enable read-only or immutable snapshots on the NAS. Sign off item by item against the business list, with an incident report and remediation plan.
Recovery paths
In file-share incidents the value density is more dispersed than in database cases, so assessment must run in two directions: by file type and by directory value.
Path 1: shadow copies and snapshots. Check first, but set expectations. Windows shadow copies are almost always deleted with vssadmin by the encryptor, so the success rate is low. By contrast, read-only NAS snapshots, storage array snapshots and hypervisor snapshots survive far more often, because they sit outside the permission scope of the encrypted filesystem. This is the resource most worth verifying first.
Path 2: backups and offline copies. The question is reachability. A backup written to an SMB share the production server can write to has very likely been encrypted; one written to an independent backup host, immutable storage, tape or a periodically detached external drive is worth a great deal. Entropy-check the backup files themselves, to confirm they are not present-but-header-encrypted.
Path 3: partial-encryption repair on large files. For speed, many families encrypt only the header or selected segments of files above a size threshold. That matters here: CAD / BIM sources, video assets, database exports, archives and VM images often carry substantial repair value, recoverable by rebuilding headers and extracting unencrypted segments. Small files such as Office documents and PDFs are usually fully encrypted, leaving limited room.
Path 4: carving and residual recovery. Encryptors typically read the original, write a new file, then delete the original — and deleted originals can be carved from unallocated space while they remain unoverwritten. This path works comparatively well for small files, which is why stopping all writes to the affected volume immediately is so important: it directly determines how much of this path survives.
Path 5: distributed and endpoint-local copies. Do not overlook local copies and caches on staff laptops, version history in OneDrive or enterprise sync folders, email attachments, files transferred over messaging apps, print server spool caches, SVN / Git history, and archived project media. In drawing and contract recovery these frequently supply the critical missing files.
Path 6: public decryptors, depending on family and version, validated against a copy.
Stated plainly: where small files were fully encrypted, snapshots and backups both failed, and the original volume has since been heavily written, the recoverable proportion drops noticeably. We do not promise "100% recovery"; the assessment sets expectations per directory and file type. No ransom payment, no negotiation.
Common ransomware families
- Free decryptor available
Phobos
Phobos is a RaaS family that relies mainly on brute-forced RDP and has spawned a long list of variants (.eking, .faust, .elbie, .devos and more). It has been a persistent presence in Chinese server-ransomware cases, and in July 2025 Japan's National Police Agency released a free decryptor covering part of the lineage.
- No public decryptor
Makop
Makop has operated as a RaaS since 2020, with affiliates breaking in mainly through brute-forced remote desktop credentials and deploying by hand. Extensions include .makop, .mkp and .baseus, with a readme-warning.txt note. It ranks consistently high in Chinese infection statistics and has no public decryptor.
- Some versions decryptable
GlobeImposter
GlobeImposter has been active since 2017 and is highly prevalent in China through its Chinese-zodiac variants (such as .Dragon4444) and Olympian-gods variants (such as .Ares666). It spreads by brute-forcing RDP/SMB and moving laterally, and caused widespread hospital infections in China in 2018. Mainstream variants have no decryptor.
- Some versions decryptable
LockBit
LockBit is one of the largest ransomware-as-a-service operations in the world. Despite the 2024 law-enforcement takedown it returned as LockBit 5.0, with working Windows, Linux and VMware ESXi payloads, and it remains one of the most frequently seen families in China.
- 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.
- No public decryptor
BeijingCrypt
BeijingCrypt takes its name from the .beijing extension used by early builds. It is a persistently prevalent family in China, deployed by hand after brute-forcing remote desktop or database credentials, and has cycled through .beijing, .360, .520, .halo and .bixi variants. No public decryptor exists.
Hardening recommendations
- Minimise share permissions. Scope shares by department and project, remove Everyone / Full Control, and give ordinary users read-only access to archive directories. The narrower write access is, the smaller a single encryption run's reach.
- Keep 3389 and SMB ports off the public internet. Public reporting shows weak-password RDP is the principal entry point for Phobos, Makop and GlobeImposter; route all remote access through VPN plus a jump host with MFA.
- Separate backup targets from production permissions. Never write backups to a share the production server can write to; use an independent backup host, immutable storage or tape, and detach one copy regularly.
- Enable read-only or immutable snapshots on the NAS or storage. This is the most effective single defence here, because it sits outside the permission scope of the encrypted filesystem. Close NAS internet access and port forwarding at the same time.
- Shadow copies must not be the only line of defence, but enable them alongside tamper protection, and turn on shadow-copy protection and ransomware behaviour blocking in EDR.
- Manage endpoints too. Mapped drives are the spread channel, so endpoints need EDR, macro restrictions and no standing local administrator rights; local data on key staff machines belongs in the backup scope as well.
- Patch the file server and govern its accounts. Regularly remove departed and dormant accounts, disable unnecessary local administrators, and enable failed-logon alerting and account lockout.
- Drill recovery. Every six months, fully restore one department's directory tree, verifying the backup chain, permissions and real usability while recording actual RTO.
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 questions
- First response
What should I do if I've been hit by ransomware?
Isolate first and keep the power on: unplug the network cable or turn off Wi-Fi, but do not reboot, format, delete the ransom note or contact the attackers. Then work in order: confirm it is ransomware and whether it is still spreading, preserve the note, encrypted samples and logs, identify the family, inventory backups and snapshots to assess recovery paths, and report the incident. Do not reconnect restored systems until the entry point is closed, credentials are rotated and backdoors are removed.
- Recovery
Can files encrypted by ransomware be recovered?
Often in part, sometimes almost entirely, but nobody can promise it before seeing samples. Recoverability comes down to four things: the family and version (is there a public decryptor, seized keys or a known flaw), how the files were encrypted (in full, or only partly), which backups, snapshots and other copies survived, and what has been written to the disks since. Where a modern family encrypted files correctly and completely, no copies survive and the remnants have been overwritten, the data may genuinely be gone. Stop all writes and identify the family first.
- First response
What should we do when a server is hit by ransomware?
Isolate first and do not reboot: cut the affected server off at the switch or in the cloud security group, but leave it running. Then snapshot or image the system and data disks, keep the ransom note and encrypted samples, and check read-only whether shadow copies, cloud snapshots and backups survived. If several servers are down, set a restore order by business dependency, and bring nothing back online until the entry point is closed and every credential has been changed. What can be recovered depends on the family, the encryption mode and the backups.
- Ransom & cost
How much does ransomware decryption cost, and how long does recovery take?
There is no fixed price and no fixed timeline. Cost and duration depend mainly on whether the family and version can be decrypted, how many hosts and how much data are affected, how hard database and virtual machine repair will be, whether work is remote or on site, and whether overnight parallel work is needed. We do not quote over the phone: we assess first, then issue a written quotation covering scope, deliverables and expected timing, and start once both sides confirm. An initial family read usually takes hours; a full recoverability assessment normally takes one to several business days.
- Recovery
Which ransomware decryption tools exist, and are downloaded ones safe to use?
Yes, but not many. Legitimate free decryptors come from the No More Ransom project, law enforcement agencies and the official channels of vendors such as Emsisoft, Avast, Kaspersky, Bitdefender and 360, and each usually works only for specific versions of a specific family. Programs circulating online as universal or dedicated decryptors are often malware or paid scams. Even with a genuine tool, confirm the family and version match first, and run it only on copies of your files.
- First response
My files all have a new extension and won't open - what should I do?
Do not rename or repair anything yet. If files of many types share the same unfamiliar appended extension (often with an ID and an email address), text, HTA or HTML notes have appeared in every folder and the wallpaper has changed, it is almost certainly ransomware. If only one file type fails, USB files turned into shortcuts, or names are garbled but content opens, a file association, USB worm or encoding problem is more likely. Until you know, disconnect the network, keep the machine on, and save a sample plus the note for identification.
- First response
Infected with the Silver Fox trojan - what now, and how do I remove it?
Stop the losses first and remove the malware second. If money has already gone out, call the police (110 in mainland China) and your bank immediately - that comes before any technical step. Unplug the PC from the network but do not shut it down or reboot it, and stop using it for banking, WeChat, QQ, DingTalk or payment approvals. From a separate clean device, change passwords and sign out every other session; tell finance to hold and phone-verify each pending payment, and warn contacts and groups that messages from the account may be fake. Once evidence is preserved, sweep with genuine vendor tools and rebuild any machine confirmed as compromised.
- Systems & software
What should we do when a Linux server or BT Panel is hit by ransomware?
First work out which kind of incident you have: website and database files that have genuinely been encrypted (new extensions, ransom notes in the directories), or databases that were dropped and replaced with a ransom table. The second involves no encryption, nobody can prove beforehand that the attacker kept a copy, and paying is not a recovery path. In both cases cut public access but keep the host running, do not reinstall or keep restarting the database, snapshot or image the data partition, then look for the data in backups, binlogs and disk remnants - and remove every back door before going live again.
- Aftermath
Why do we keep getting hit by ransomware, and how do we stop it for good?
Repeat infections are rarely bad luck; the previous incident was almost always left unfinished. The real entry point was never found or never closed, accounts, scheduled tasks, remote-access tools or web shells left by the attacker are still there, credentials were only partly changed, or systems were restored from backups that already contained the backdoor. Environments that paid, or whose access was resold, also get revisited. The fix follows an order: forensics to find the real entry point, a rebuild-or-clean decision, closing the entry and removing persistence, a full credential reset, then verified hardening and ongoing monitoring.
Related industries
Construction and Real Estate Ransomware Response
In construction and real estate the core assets are drawings, models and project documentation — typically scattered across project-site NAS units, shared drives and personal computers with no unified backup. This page covers the sector's threat profile, recovery of drawings and BIM models, and defences for dispersed, multi-project environments.
Manufacturing Ransomware Response and Recovery
Ransomware in manufacturing hits information systems and production cadence at the same time: with ERP down there are no orders, with MES down there is no schedule, and an encrypted drawing library takes the process documentation for an entire product line with it. This page covers the asset profile, recovery priorities and targeted defences.
Government and Public Sector Ransomware Response
Public sector ransomware incidents run on three lines at once: service interruption, data security and mandatory reporting. When document circulation, archives and integrated service platforms stop, both public services and internal operations are affected. This page covers the handling sequence, reporting duties and hardening priorities.
Education and Research Ransomware Response
Schools and research institutions run open networks with dispersed endpoints and systems built across many eras, often unattended at night and during holidays — a combination attackers exploit. This page covers the sector's threat profile, recovery priorities for academic and research data, and defences suited to campus networks.
Related services
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Ransomware Decryption
Identify the family first, then commit to a recoverable scope — without paying a ransom.
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
FAQ
Frequently asked questions
Hundreds of thousands of files on our share are encrypted — how much can be recovered?
The recovery rate varies sharply by file type, so a single blanket percentage is meaningless. The general pattern: large files — CAD/BIM sources, video, archives, database exports — have more room, because many families encrypt only headers or segments above a size threshold. Small files (Office, PDF, images) are usually fully encrypted, and depend instead on snapshots, backups, carving the deleted originals, and endpoint-local copies. So during assessment we sample encryption coverage across file categories and give expectations per directory and type rather than one number.
Previous Versions is empty — is there anything left?
Deleted shadow copies are the norm — virtually every major family removes them — so this does not mean recovery is over. The copies worth checking are those outside the same permission domain: read-only NAS snapshots, storage array snapshots, hypervisor snapshots, backups on an independent backup host, and offline media. There is also a commonly overlooked category: copies on endpoints and sync services, email attachments, version control history and archived project media. All of these are inventoried during assessment.
Can we delete the encrypted files to free up space?
Do not delete them. Encrypted files retain value in two situations: if the family has a public decryptor, or keys later leak, they are the only material that can be decrypted; and where large files were only partly encrypted, content can be recovered by rebuilding headers and extracting unencrypted segments. More importantly, deletion writes to the original volume and overwrites the fragments of the originals the encryptor deleted, directly reducing what carving can recover. Keep things as they are, image the volume, and work on the copy.
Why were our backups encrypted as well?
Usually for one reason: the backup target was a shared folder the production server had write access to. As the encryptor enumerates network shares it follows write permissions outward, and the backup directory sits squarely in that path. Other causes include a backup server joined to the same domain using domain administrator credentials, a NAS backup job that dutifully synchronised the already-encrypted files, and theft of the backup software's own credentials. The remediation is clear: the backup target must not be writable from production, immutable backups should be enabled, and one genuinely offline copy retained.
Could it be encrypted again after recovery?
If the source is not eradicated first, very likely. The typical pattern: endpoints or servers still carrying the payload and its persistence, attacker accounts or SSH keys still present, and the entry point — exposed RDP, an unpatched flaw, leaked VPN credentials — still open. Our process requires three things before recovery begins: a full sweep and eradication, a complete credential reset, and closing the entry point with patching. Recovery then validates in an isolated segment, returns to production in batches, and keeps heightened monitoring in place afterwards.
Updated