Example of recovery after cryptovirus

Example of recovery after a cryptovirus in a medium-sized company

The company has 65 employees, a central office and several retail locations. It operates a file server, a customer management system, accounting software, e-mail and remote access for part of the team. On Friday afternoon, a user opens an attachment that looks like a document from a supplier. The malicious code uses compromised user data and encrypts files on a server and several workstations overnight.

On Monday morning, monitoring reports an unusually high number of renamed files and failed attempts to access network resources. This is the critical moment: if the team starts randomly restarting servers, connecting external drives with archives or searching for files randomly, the damage can spread.

The first hour: Containment before recovery

The first task is not to recover data, but to stop the spread. The affected computers are isolated from the network without hastily shutting down. This preserves information that can help with the investigation - active processes, user sessions, logs and traces of the method of penetration.

Access to server shared folders is temporarily restricted, and remote access is suspended until all accounts are verified. The IT team checks whether the encryption has reached virtual machines, cloud storage, archive systems and backups. This is an important difference: an archive that is constantly accessible with write rights from a compromised environment can also be encrypted.

Management receives short and clear information: which services are not working, which data is affected, what temporary restrictions there are and when the next update will be. Unfounded promises of an exact recovery time are not useful at this stage. Facts, designated responsibilities and control over communication are useful.

Which systems are restored first

Not every system needs to be restored at the same time. In this case, the company sets three priorities. First, identity and secure access are restored - domain services, user accounts and multi-factor authentication. Then comes the order management system and accounting software, because without them the company cannot process sales and payments. Shared file folders and secondary applications are restored next.

This order reduces the risk of rolling back an old, vulnerable configuration before access control is ensured. It also allows the business to start working partially, rather than waiting for each service to be fully restored.

Prioritization should be agreed in advance with management. IT may know which system is technically dependent on another, but management determines which interruptions cost the business the most. For one company, these are orders, for another - production, customer service or access to project documentation.

Recovery from a clean and verified environment

In this scenario, the archives are divided into several levels: local copies for quick recovery, a separate storage with limited access and a copy outside the main environment. Having a separate copy is crucial, as some of the local archives were accessible by the compromised account.

The team does not restore the data directly to the affected server. First, a clean environment is created with an updated operating system, security updates, and a reviewed configuration. Administrator passwords are changed, existing sessions are terminated, and accounts with elevated privileges are checked. Multi-factor authentication is enabled wherever possible.

Then, a restore point from before the incident is selected. The selection is not mechanical. The archive must be scanned, checked to see if the files are openable and if it contains the expected data volumes. In the case of databases, a test restore and integrity check are performed before the system is made available to users.

File data is restored in stages. Active work folders, contracts, customer data, and financial documents are restored first. Archive catalogs with lower operational value can wait. This solution reduces the time that core teams are blocked.

The company does not pay the ransom. This is not just a matter of principle. Payment does not guarantee a working decryption key, does not guarantee that data was not copied, and does not eliminate the cause of the breach. There are cases where the lack of a valid archive makes the choice significantly more difficult. This is why backups that are isolated and regularly tested are a business control, not a formal IT task.

Check before returning to normal operation

A restored system does not automatically mean a secure system. Before full access is restored, inbound and outbound network activity, unusual login logs, active administrator accounts, and remote access policies are checked. Antivirus protection and monitoring tools should be updated and confirmed to be working.

A business audit follows. Finance, sales, and administration employees confirm that they can open key documents, enter an order, issue an invoice, and work with up-to-date data. Technically, the restored service is only valuable when it supports the actual workflow.

If there are indications of personal data being exported, the case requires a separate GDPR assessment. The scope of the data, the likely risk to the affected individuals, the available evidence, and the notification deadlines are important here. This assessment should not be postponed until all systems are fully restored.

What changes after the incident

After the emergency phase is complete, the company reviews the causes and control gaps. In this case, a lack of multi-factor authentication for some of the remote access, excessively broad rights on file folders, and insufficiently frequent testing of the recovery procedure were identified.

Corrective actions include network segmentation, the principle of least privilege, stricter email policies, employee training, and centralized monitoring of critical systems. A specific incident response plan is also added: who isolates the systems, who makes business decisions, how employees are notified, and when external experts are involved.

The most significant change is regular testing. An archive is not reliable because it has a green status in the console. It is reliable when the organization has proven that it can restore the necessary data in the required time. For some companies, one working day of downtime on a secondary system is acceptable. For others, even two hours are too much. The plan must reflect this real risk.

Helpdesk Bulgaria works with companies that want such procedures to be part of daily environment management, rather than improvisation on the day of the incident. Proactive monitoring, controlled archives, and a clear helpdesk process put businesses in a better position when time is critical.

A cryptovirus can disrupt operations, but it shouldn't put a company's ability to continue in question. The best time to test whether recovery will work is before the first encrypted file, through a real-world test, clear responsibilities, and a decision about which services the business can't afford to lose.