Ransomware Recovery: How to Choose a Backup You Can Trust

On Sunday, 24 August 2025, information systems across the US state of Nevada began experiencing outages. Virtual servers stopped working, some services became unavailable, and investigators discovered encrypted files along with a ransom note.

At first glance, it appeared to be a typical ransomware incident. The attack had become visible, systems were affected, and it was time to restore operations.

However, the investigation revealed a crucial fact: the attacker had gained access to the environment on 14 May 2025, more than three months before the visible attack.

Over the following weeks, the attacker maintained access, obtained credentials, escalated privileges, and moved laterally between systems. Although a security tool detected the original malware in June, the hidden access persisted. In August, the attacker reached sensitive systems and deleted backup volumes before deploying ransomware.

According to the official report, restoring the affected services took 28 days. Nevada did not pay the ransom, but responding to the incident required significant internal resources and external support.

This case raises a question that is often more difficult for security teams than restoring the data itself: If the attack became visible in August but the compromise began in May, how far back can systems be safely restored?

The Latest Backup May Not Be the Most Trustworthy

When dealing with an ordinary technical failure, the decision is usually relatively straightforward. If a server fails or data becomes corrupted, the IT team typically looks for the most recent working backup, aiming to minimise data loss and downtime.

A cyber incident, however, changes the rules.

Imagine a company discovering on Friday morning that its production systems have been encrypted. Backups are available from Thursday, Wednesday, Monday, and the previous Friday.

Which one would you restore?

The first answer would probably be Thursday’s backup. It is the most recent, and using it would minimise data loss.

Then new information emerges: the first compromised user account was identified 12 days earlier. Would you still choose the same backup?

There is no single universally correct answer. A backup created after the initial intrusion is not automatically unusable. Equally, it cannot be assumed to be safe simply because it can be technically restored.

In the meantime, the attacker may have created new accounts, changed permissions, modified service configurations, or introduced a mechanism that would allow them to regain access.

A technically successful restoration does not necessarily mean that the compromise has been eliminated.

The Detection Date Is Not the Start of the Attack

Ransomware is often the final and most visible stage of an incident. It may be preceded by a period during which the attacker quietly explores the environment, identifies sensitive data, and determines how they can move between systems.

This is why reconstructing the timeline of a compromise is essential during recovery.

Security teams need to ask not only when the systems were encrypted, but also when the first unusual logins, permission changes, new remote access connections, or suspicious configuration changes occurred.

This is where security logs become particularly important.

Records of logins, privileged account activity, system changes, and security events can help reconstruct the sequence of events. An individual log entry may not appear suspicious on its own. Only when correlated with other events might it become clear that the activity was not routine administration.

For example, an administrator logging in outside business hours does not automatically indicate an incident. However, if that login is followed by a permission change, the creation of a new service, and access to a backup server, the security implications of the entire sequence change.

The problem arises when this information is unavailable.

Attackers may attempt to remove traces of their activity. In the Nevada case, investigators also identified the deletion of event logs. If an organisation stores its logs only on systems that the attacker has compromised, it may lose crucial evidence precisely when it needs it most.

Collecting logs is therefore not enough. Their protection, availability, and ability to be analysed alongside other information are equally important.

How to Identify a Recovery Point You Can Trust

In practice, recovery decisions combine technical analysis with risk management.

The security team must first understand the scope of the incident. Identifying encrypted servers is not sufficient. It is necessary to determine which accounts were compromised, what privileges the attacker obtained, and whether they could have affected systems used for backup or infrastructure management.

The next question concerns the integrity of the available backups.

Security scanning can help identify suspicious or malicious files within backed-up data. However, scanning results alone may not detect every form of compromise.

A backup may contain data with no detected malicious code while still including unwanted configuration changes, modified permissions, or accounts created by the attacker. These may not be recognised as malware during a conventional file scan.

Multiple types of information must therefore be evaluated together.

If security logs indicate that privileged accounts were modified on Tuesday, while the backup system contains recovery points from Monday and Wednesday, this information may significantly influence the next steps.

Wednesday’s backup may contain changes made by the attacker. Monday’s backup may provide a more suitable starting point, but it must still undergo further verification.

The goal is not always to identify one absolutely “clean” date. More often, it involves gradually reducing uncertainty and selecting a state for which the organisation has sufficient evidence to accept the risks associated with recovery.

It is also important to distinguish between restoring data and restoring trust in the entire system. These two tasks are related, but they are not the same.

When Should You Restore, and When Is It Safer to Rebuild?

During an incident, restoring an entire virtual server from backup may be the fastest option. However, it is not always the safest approach.

If the team has reasonable grounds to suspect that the attacker obtained administrative privileges, modified system components, or established persistent access mechanisms, restoring the original system image may reintroduce the compromise into production.

In such cases, it may be more appropriate to rebuild the system from trusted installation sources, configure it securely, and restore only the necessary, verified data.

The decision between restoration and rebuilding depends on several factors: the type of compromise, the quality of available evidence, the trustworthiness of the system image, the criticality of the service, and the time required for each option.

The approach will differ for a standard file server, a domain controller, a database system, or a server where the attacker obtained the highest level of privileges.

The essential question is: Can we adequately verify the integrity of the system we are about to return to production?

If the answer is not sufficiently supported by evidence, a rapid restoration may create only a temporary sense that the problem has been resolved.

Before Returning to Production, It Is Not Enough to Verify That the System Works

Successfully starting an application or database is an important step. However, it does not mark the end of secure recovery.

Before returning to normal operations, the team needs to adequately verify that identified attacker access has been removed, compromised accounts and credentials have been reviewed, and the restored environment does not contain known mechanisms that could enable reinfection or renewed compromise.

It is equally important to review relevant configurations, network access, and security controls. Restored systems should be monitored to detect any potentially continuing suspicious activity.

Business context also plays an important role in the decision-making process.

Not all systems need to be restored simultaneously. The organisation must prioritise services according to which are essential for maintaining operations and which can safely be brought back online gradually.

For a manufacturing company, these may include systems controlling production and logistics. In a hospital, the priority may be the availability of critical healthcare applications. For a service provider, it may be systems required to support customers.

The security and speed of recovery therefore cannot be assessed separately. The goal is to restore critical services as quickly as possible without unnecessarily increasing the risk of the incident recurring.

The Challenge of Information Spread Across Different Systems

In many organisations, the necessary information exists, but it is scattered across multiple tools.

The backup system shows available recovery points. Security tools report suspicious events. Logs contain records of logins and system changes. IT administrators hold additional information about configurations and operations.

During an incident, however, this information needs to be brought together quickly.

This is where the importance of preparing for recovery before an attack becomes clear. If a team only starts determining where to find the necessary logs, who has access to backups, and how their usability will be verified during a crisis, valuable time is lost.

The value therefore lies not only in backup itself or in standalone threat detection, but also in the ability to build a usable picture of the incident from the available data.

Why IXPERTA Combines Backups, Security Analysis, and Logs

IXPERTA’s IXTRUST solution addresses this need.

Its underlying principle is that secure recovery after a cyber incident requires more than simply having backups available. Organisations need a better understanding of the security status of those backups, along with relevant information about the events that preceded the incident.

IXTRUST therefore combines secure backup, security scanning of backups, and the use of security logs.

The service’s extended capabilities include collecting and securely storing logs, analysing security events, and evaluating them in relation to backed-up data. This information can support incident reconstruction, the identification of potential threats, and the selection of an appropriate recovery point.

This does not automatically guarantee that every restored backup will be safe. Instead, it provides better information to support expert decision-making in situations where the availability of an entire organisation depends on choosing the right course of action.

Such an approach is particularly relevant in environments where IT downtime directly disrupts manufacturing, service delivery, or other critical processes.

The Question Every CISO Should Ask

The Nevada case demonstrates that a visible cyberattack may be the culmination of events that began long before the attack became apparent. It also shows that attackers may target not only production data but also the organisation’s ability to recover.

For security teams, this calls for an important shift in thinking.

It is not enough to know how often backups are performed or whether the latest recovery test was successful. Organisations also need to understand how they would determine the scope of a compromise during an incident, obtain trustworthy information about past events, and decide when and how systems should be returned to production.

The latest backup may not be the safest. And a technically successful restoration does not automatically mean a secure return to operations.

Every CISO should therefore ask one practical question:

In the event of a real incident, can we justify why we trust the particular recovery point we have selected?

If the answer rests solely on the fact that it is the latest available backup, it may be time to reconsider how the organisation connects backup, security logs, and recovery readiness.