A Ransomware Recovery Case Study in 48 Hours

At 6:18 a.m. on a Monday, a finance employee reported that shared files would not open. Within minutes, the accounting server displayed a ransom note, several workstations showed encrypted files, and the business faced a serious question: could it reopen for the workday without paying criminals? This ransomware recovery case study follows an anonymized mid-sized professional services firm through the first 48 hours after an attack – and shows why recovery depends on decisions made long before the ransom note appears.

The company had approximately 55 employees, a hybrid workforce, Microsoft 365, an on-premises line-of-business application, and a central file server holding active client records. Like many growing businesses, it depended on technology every hour but had a lean internal IT function. Its leadership had approved managed backups and endpoint protection, but the recovery plan had not been tested recently.

The Attack Was Detected Before It Became Total

The first sign was not the ransom note. It was an alert from endpoint monitoring showing unusual PowerShell activity on a workstation used by a remote employee. Shortly afterward, security tools detected a surge in file renames on the file server. The managed IT team treated this as an active incident, not a routine support ticket.

That distinction mattered. The team immediately isolated the affected workstation, disabled the compromised user account, and removed the file server from the network. Remote access sessions were terminated, and potentially exposed credentials were reset. These actions interrupted business activity, but allowing users to continue working would have risked spreading encryption to additional systems and backups.

The attack had likely started with a stolen credential used through a remote access pathway. Investigators found that the attacker had moved laterally after gaining entry, attempting to disable security software and locate backup repositories. The endpoint protection agent prevented some of those actions, but not before part of the shared data was encrypted.

Ransomware Recovery Case Study: The First Eight Hours

The first eight hours set the direction for the entire recovery. Leadership was briefed early with plain language: what had happened, what was isolated, what was still operating, and what decisions were pending. The message was not “everything is fine.” It was that the incident was contained, recovery work had begun, and updates would arrive on a defined schedule.

The response team preserved logs, ransom notes, suspicious files, and authentication records before making major changes. This supported forensic review and helped determine whether sensitive information may have been accessed or removed. Encryption is visible. Data theft can be harder to detect, and it affects notification, legal, insurance, and client communication decisions.

The company also contacted its cyber insurance carrier and legal counsel. This step is often missed when a business is focused on restoring files, but timing can matter. Insurers may require the use of approved incident response vendors, and counsel can help coordinate communications where privacy or contractual obligations apply.

Meanwhile, the IT team reviewed backup status. The most recent backup had completed overnight, but recovery was not automatic. The team needed to confirm that the backup was clean, that the attacker had not reached the backup environment, and that restoring it would not reintroduce malicious files or compromised accounts.

Recovery Started With Clean Systems, Not Encrypted Files

A common mistake during ransomware incidents is trying to clean every affected computer and restore data immediately. That can feel faster, but it may leave persistence mechanisms, stolen credentials, or unauthorized remote access in place. The business chose a more disciplined path.

Affected workstations were rebuilt from known-good images. The server environment was reviewed, patched, and segmented before restored data was introduced. Administrative credentials were rotated, multifactor authentication was enforced for remote access and Microsoft 365, and unused accounts were disabled. The team also checked forwarding rules and mailbox permissions because email accounts are frequently used to extend an attack or impersonate employees after the initial event.

This added several hours to the process. It also reduced the chance of recovering into the same exposure that caused the incident.

The backup strategy made the difference. The company had separate backup copies, including an immutable backup that could not be altered during its retention period. The recovery point was less than 12 hours old, so the business did not lose weeks of work. However, restoring the full file server would take longer than the leadership team could accept for every department.

Instead, the team prioritized restoration by business impact. Accounting, payroll, active client files, and scheduling data came first. Archived project folders and lower-priority shared drives followed. This approach brought the company’s highest-value functions back online before every last file was restored.

What the Business Could and Could Not Do During Recovery

By the end of the first day, employees could access email through secured cloud accounts, communicate with clients, and use temporary collaboration folders for urgent work. The accounting and client management systems were restored in a segmented environment and validated by department leads.

Not everything returned at once. Some historical files remained unavailable while backups were scanned and restored. A few employees had to work from loaner devices while their endpoints were rebuilt. Leadership accepted these limitations because the alternative was reopening the environment too quickly and risking a second incident.

This is the operational trade-off many businesses underestimate. Recovery is not simply a technical target measured in hours. It is a controlled process of deciding what must return first, what can safely wait, and which security controls must be strengthened before normal operations resume.

At the 48-hour mark, the organization had restored critical systems, rebuilt affected endpoints, reset access controls, and resumed core client work. It did not pay the ransom. The remaining work involved restoring lower-priority data, reviewing forensic findings, documenting the incident, and communicating next steps to affected stakeholders where appropriate.

Why the Recovery Worked

The business did not avoid disruption. Ransomware created real downtime, delayed work, and placed pressure on staff. What it avoided was a prolonged business shutdown. Three decisions made that possible.

First, the team isolated systems early. Fast containment limited the number of encrypted devices and protected cloud services from further misuse. Second, it had recoverable backups that were separated from the primary environment. A backup that an attacker can delete or encrypt is not a recovery plan. Third, leadership had access to technical support that could coordinate containment, recovery, communication, and hardening without waiting to assemble a response team in the middle of an emergency.

There were also gaps. The incident showed that the company needed more frequent recovery testing, tighter controls around remote access, stronger identity monitoring, and clearer department-level recovery priorities. Backups had worked, but the organization had not fully documented which applications and datasets needed to be restored in what order. That knowledge was held by a few people, which introduced delay.

The Controls That Changed After the Incident

Following recovery, the business treated the event as an opportunity to improve its operating model rather than simply close a ticket. It implemented phishing-resistant multifactor authentication for privileged users, tightened conditional access policies, and required managed devices for access to critical applications.

It also adopted a more structured backup and disaster recovery process. Backups were monitored daily, restoration tests were scheduled, and recovery objectives were documented with business leaders. The goal was not just to prove that a backup job completed. It was to prove that the company could restore the right systems within an acceptable timeframe.

Network segmentation was improved so that a compromise in one department would have fewer paths to servers and sensitive data. Endpoint detection and response was expanded, with 24/7 alert handling for high-risk activity. Employees received practical security training focused on credential theft, suspicious login prompts, and reporting unusual behavior quickly.

For small and mid-sized companies, this level of protection does not require building a large internal security department. It requires a managed approach that combines monitoring, backups, identity security, documented processes, and accountable response ownership. That is where a partner such as Krove can help turn scattered tools into a continuity strategy.

What Your Business Should Test Before an Attack

A ransomware plan is only useful if it works under pressure. Start by asking whether your organization can answer a few direct questions without guessing: Which systems must be restored first? How long can each department operate without them? Are backups protected from an administrator account compromise? Who can authorize shutdowns, communicate with employees, and contact insurance or legal resources?

Then test the answers. Restore a sample of critical files. Recover a server or virtual machine into an isolated environment. Confirm that former employees cannot access cloud applications. Run a short tabletop exercise with leadership, operations, finance, and IT. These exercises expose unclear ownership before an attacker does.

The most useful measure of ransomware readiness is not how many security products you own. It is whether your business can contain an attack, restore trusted systems, and keep serving customers with a clear plan. A tested recovery process gives leaders something far more valuable than a promise of protection: control when the pressure is highest.