Too many ransomware cases: when TUNGTEK reaches intake capacity

Recently, several ransomware requests have reached us within the same few hours. One message reports a customer’s NAS encrypted by malware. Another asks whether data can be recovered from a system affected by .PIZ ransomware. When our schedule is full, the immediate answer may have to be: “Please give me a little time; I will reply soon.”

1. One afternoon, several cases at once

The screenshots accompanying this article are simple: two different conversations and two different situations, but the same underlying concern. One involves an encrypted NAS; the other, ransomware with a .PIZ extension. Both ask the familiar question: “Can you help recover the data?”

Sending that question takes seconds, but answering it involves a chain of work: verify the condition, triage urgency, inspect the environment, identify the most important assets, find any surviving backups or snapshots, assess the affected data structure and only then choose a suitable recovery or encrypted-data extraction approach.

For business data—especially SQL Server, ERP, file servers, virtual machines, NAS and SAN—we do not want to answer yes or no based only on a filename extension. An extension may offer a clue, but it cannot describe the whole condition. Two machines with the same ransomware extension may have very different damage, overwrite history, volume, backups and recovery prospects.

2. Reaching capacity is not good news

In recovery work, more cases do not mean the market is “good”. They often mean that backup and defenses failed somewhere at the moment they were most needed.

We understand what it feels like when a business needs ransomware help. This is seldom an ordinary IT request. Accounting may be stopped, ERP unavailable, a clinic unable to access records, a factory unable to run production software, or an entire NAS share renamed within minutes.

The administrator then faces more than technical pressure. They must answer to management, departments, customers and sometimes partners. That is why we do not want to turn Ransomware Recovery into an ad saying, in effect, “get hit and bring it to us.”

Recovery is the last line.
Backup and defense should be the first.

3. Ransomware Recovery is not a button

As requests increase, the constraint is not only whether a machine is powerful enough. Recovery consumes storage, I/O time and human attention. Some cases need tens of terabytes of temporary space for a working copy. Others require prioritizing a few database files before the rest. Some require preserving evidence for investigation.

That is why, when several cases arrive together, we triage by actual impact: which system is entirely down, which data drives the operation, whether a replacement backup exists and what the customer needs first.

4. Why do cases arrive in clusters?

Ransomware does not schedule an appointment with IT. Many attacks are triggered after hours, on weekends or during periods of limited monitoring. Symptoms become obvious when users return to work, bringing multiple requests for help at once.

We often find that a business has backups, but they occupy the same risk domain: the same permissions, network, administrator account, NAS or always-online repository. Once an attacker gains sufficient privileges, backups can be the next target.

So “we have backups” needs more specific follow-up questions: Are any copies offline or immutable? Are backup accounts separate from everyday Domain/Admin accounts? Has the newest copy been test-restored? If all primary servers go down, does IT know the order in which to rebuild services?

5. What to do while waiting for ransomware intake

When a recovery team is handling several cases, a few early actions by the customer can preserve the chance of recovery. The aim is to stop further spread and overwriting—not to try every tool found online.

Do

• Isolate affected systems from the network if spread or further encryption remains possible.
• Stop unnecessary writes to the NAS, volume, datastore or disk containing affected data.
• Preserve the ransom note, unusual filenames, extensions, logs and the time the incident was discovered.
• Record which machines were affected first and later, and which administrator or remote-access accounts may be involved.
• Identify priority data immediately: which databases, folders and VMs, and their approximate size.
• Check backups safely: are any offline, immutable, snapshot or offsite copies intact?
• For complex or virtualized systems, consult someone before shutting down many hosts or deleting snapshots.

Do not

• Do not format, initialize or recreate the source filesystem just to see whether the drive becomes recognizable.
• Do not reinstall Windows on the same disk that contains data needed for recovery.
• Do not delete ransom notes, logs or artifacts merely because they look dangerous.
• Do not run batches of unverified decryptors or repair tools against original data.
• Do not write substantial new data to the volume from which you need to extract information.
• Do not use a file extension alone to identify the ransomware family or judge recoverability.

6. Backup 3-2-1-1-0: more than one copy

We keep emphasizing backup because recovering from an encrypted device is inherently uncertain. A clean backup that has been test-restored is almost always a better route than recovering data after an incident.

More important than the formula is the mindset: backups must survive a compromise of production. If ransomware can use the same administrator account to delete both production and backup, all those earlier “Success” job reports mean little.

7. Minimum defenses for NAS, servers and business data

No configuration can guarantee that an incident will never happen. But many basic measures greatly reduce the chance that one incident becomes a system-wide disaster.

• Enable MFA for remote access and important administrator accounts.
• Do not expose RDP, SMB or NAS management directly to the Internet unless strictly necessary.
• Separate backup accounts from everyday operations administrator accounts.
• Apply least privilege: give users only the permissions their work requires.
• Segment user, server, backup, hypervisor and management networks.
• Patch Internet-facing services, VPN, firewalls, NAS and hypervisors promptly.
• Monitor unusual sign-ins, new accounts, AV/EDR shutdowns, snapshot deletions and backup deletions.
• Maintain an inventory of machines, services, data and their owners.
• Rehearse restores regularly instead of waiting until ransomware strikes to open the instructions.

Small and medium businesses do not necessarily need to buy an extremely complex defense stack immediately. Doing the basics well, controlling permissions, maintaining genuinely isolated backups and knowing how to restore is far better than owning many products that nobody checks.

8. TUNGTEK must improve intake too

As requests increase, recovery teams also need stronger operational discipline. We are standardizing intake to avoid asking the same questions repeatedly and help customers supply useful information at the outset.

Our preferred process records the case and its scope, identifies priority data, collects a safe sample for RFC where appropriate, determines the source devices and systems, checks backup status and establishes an operational deadline. For a large case, that matters far more than a quick message saying “send a file and we’ll take a look.”

We also try to be transparent: when the schedule is full, customers may wait a short time for a proper assessment. It is better to say “we are handling a case and will respond at a specific time” than to reply hastily and create inaccurate expectations.

9. Why did we create No.Ransomware.VN?

If we focus only on recovery, we will always be at the end of the incident chain. No.Ransomware.VN is therefore a place to share lessons from cases in the other direction: alerts, backup, defenses, warning signs and steps people can take before ransomware hits.

The goal is simple. If a backup article leads a business to create an immutable copy, an MFA article prompts an administrator to close remote access, or a checklist persuades someone to test a restore before it is needed, that is worth more than another recovery case for us.

10. Conclusion: do not make Recovery your backup strategy

We will continue Ransomware Recovery, analyze difficult cases and seek ways to extract encrypted data where possible. But if this article has one message, it is not “TUNGTEK has many cases.”

The message is that ransomware causes too many situations where preparation with backup and defense could have substantially reduced the damage.

An untested backup is no guarantee. A NAS with snapshots is not enough if those snapshots share administrator permissions. A firewall with MFA does not make an old local account safe. And no recovery service, however experienced, should be the only contingency plan.

Backup first. Defend first.
Recovery should come into play only when every earlier layer has no better option left.