300 Users Down: What Ransomware Recovery Actually Looks Like

Hour Zero

The first sign was a help desk ticket at 7:14 AM: "I can't open any of my files." Within fifteen minutes, there were forty more. By 7:45 AM, it was clear this wasn't a software glitch or a permissions issue. Every file on every workstation across three office locations had been encrypted. File extensions had been changed. Ransom notes appeared on every desktop.

A 300-user multi-state professional services organization was completely down.

The First Response

The immediate priority in any ransomware event is containment. We needed to stop the encryption from spreading to any systems that hadn't been hit yet — if there were any.

Every server was power-cycled. Not gracefully shut down — physically rebooted. When ransomware is actively encrypting, you don't wait for a clean shutdown. You pull the plug. Every workstation that could be reached was disconnected from the network, either physically or by disabling network ports at the switch level.

Within the first hour, we had isolated the environment. The encryption had stopped spreading. But the damage was already extensive.

The Assessment

Once containment was complete, we began assessing the scope. The results were devastating:

- Every workstation: Encrypted. Local files on every machine across all three locations were locked. - File servers: Encrypted. Shared drives containing years of case files, documents, and client data were inaccessible. - Email: Exchange server encrypted. No one could send or receive email. - Line-of-business applications: Database servers encrypted. Practice management, billing, and document management systems were offline.

The attacker's ransom demand arrived via a text file on every affected machine. We don't disclose amounts, but it was substantial — and we never recommend paying. Payment doesn't guarantee decryption, it funds future attacks, and it marks your organization as a willing payer for future targeting.

The Recovery Process

Recovery from an event of this scale is not a single action. It's a methodical, multi-day process that requires discipline, documentation, and a clear chain of command.

Day 1: Server Recovery We focused exclusively on servers. Backup systems — hosted offsite and isolated from the production network — had not been compromised. This was the critical factor that made recovery possible rather than catastrophic. We began restoring server images from the most recent verified backup point. Each server was rebuilt on clean infrastructure, verified for integrity, and brought online in priority order: Active Directory first, then email, then file servers, then line-of-business applications.

Day 2-3: Service Restoration With servers coming back online, we began restoring access to critical services. Email was operational by the end of Day 2. File shares were accessible by Day 3, though some teams had to work from backup copies while final verification completed. Practice management and billing systems required additional configuration but were functional by Day 3.

Day 4-7: Workstation Rebuilds This was the most labor-intensive phase. Every workstation — all 300 of them — had to be wiped and rebuilt. Local files on workstations were lost. This is an important point: server-based backups saved the organization, but nothing saved the files stored locally on individual machines. Documents saved to desktops, local downloads, and files not synced to the server were gone.

Each workstation was reimaged with a clean OS build, domain-joined, had security software deployed, and was returned to the user with their server-based files accessible. At peak, we were rebuilding 40-50 machines per day across the three locations.

The Lessons

Server backups were the difference between recovery and ruin. Without verified, offsite, isolated backups, this organization would have faced a choice between paying a six-figure ransom with no guarantee of recovery, or starting from scratch. The backup investment — which probably cost a few thousand dollars per month — saved millions.

Local files are not backed up. Every file saved to a desktop, a Downloads folder, or a local drive was permanently lost. This is a policy issue as much as a technical one. Firms must enforce server-based or cloud-based file storage with clear policies prohibiting local-only file storage.

The speed of response matters enormously. Containment within the first hour limited the damage. If the ransomware had continued spreading unchecked for hours, backup systems could have been compromised, and recovery might not have been possible.

What This Means for Your Firm

> 📋 Read the full case study → [View the EDR/MDR Implementation case study](#case-studies)

If your firm experienced a ransomware event today, ask yourself:

- Do you have verified, offsite, immutable backups? - Have those backups been tested with an actual restoration? - Do your staff store files locally or on the server? - Can your IT provider respond within the hour — not the day?

If you're not confident in every answer, that's exactly what our free site audit is designed to uncover.

Don't wait for the ransom note. [Get your free site audit](#assessment) and find out where your vulnerabilities are before an attacker does.