When the infrastructure is running, but the files no longer open: recovering a file server encrypted by ransomware on Nutanix AHV with Rubrik

“The folders are there, but the files will not open!”

It is Monday morning, around 08:15. I receive a call from Elena in the finance department. She tells me that she can access the company share and that the folders are there, but she cannot open the file she works on every day, bugeteQ4-2026.xlsx. The finance department works on a drive mapped to the share \\FS-PROD-07\Financiar. Elena also tells me that the file icons have changed. I ask her to read me the full file name and she tells me it is bugeteQ4-2026.xlsx.locked. I ask her to check another file in the same folder. It now appears with the following name: contract-furnizor-2026.pdf.locked. The original names and the .xlsx or .pdf extensions are still visible, but the same unknown extension has been added to all files: .locked.

At that moment, the first thought that crosses my mind is… ransomware!

I start checking. From a workstation with administrator rights, I access the server shares directly. I can list the folders and their contents. I check \\FS-PROD-07\Financiar and \\FS-PROD-07\Achizitii. The files are visible, as are their sizes. Their names are still recognizable, but the same extension has been added to the files. Then I find a README_TO_RESTORE.txt file in several folders checked within the Financiar and Achiziții shares. I open it. The message inside asks us to contact the attackers. The changed extensions, the files that no longer open and the ransom note are clear evidence that the data has been encrypted following a ransomware attack.

Monday, 08.15: the infrastructure is available, the data is not

To get an overall picture of the incident, I open Prism Central, Nutanix’s central management interface for the virtual infrastructure. All nodes are online. There are no critical alarms for the Nutanix cluster made up of 3 Lenovo ThinkAgile HX servers hosting the FS-PROD-07 virtual machine. Most likely, Nutanix is not the cause of the outage. I open the VM console in Prism. The console is the virtual equivalent of connecting a monitor and keyboard directly to a physical server. Windows Server is running normally. After several checks, I conclude that the physical nodes are online. The cluster is running. AHV is running the VM. AOS is providing the virtual disks. Windows on the affected VM is running. The network reaches the VM. SMB responds. But none of these checks proves that the files are usable. There is nothing to indicate a Nutanix platform issue that would explain the incident. The Windows VM is still running, but the data inside it has been encrypted. The first thing I do is disconnect the vNIC from the production network and shut down the VM. Disconnecting it immediately removes network access, while shutting down the VM stops any activity inside the operating system. The question is: what do I restore and from which recovery point? To understand the recovery options available on Monday morning, we need to go back six months.

Six months earlier: the migration from VMware to Nutanix AHV

The company was using VMware and decided to migrate a large part of its virtual environment to Nutanix AHV, installed on Lenovo ThinkAgile HX servers.

Lenovo ThinkAgile HX provides the physical platform. The HX nodes contain the processors, memory, local disks and network interfaces used by the cluster. Together, they form the platform on which the Nutanix software runs.

Nutanix AOS (Acropolis Operating System) provides distributed storage at cluster level. In practice, AOS combines the storage resources of the cluster nodes and presents the VMs with the storage space they need. A VM such as FS-PROD-07 therefore uses virtual disks provided by the Nutanix platform instead of depending on separate storage.

Nutanix AHV (Acropolis Hypervisor) is the hypervisor. A hypervisor is the software layer that creates and runs virtual machines and allocates processing, memory and network resources to them. In this environment, AHV has a role similar to ESXi in a VMware environment.

Prism Element manages a single individual Nutanix cluster. It provides detailed visibility for operations such as checking hosts, storage and local VMs.

Prism Central, on the other hand, provides centralized visibility and management for multiple clusters. It is the first place to check the overall status of the infrastructure.

At workload level, FS-PROD-07 is a Windows Server VM running on AHV and using AOS storage. Nutanix already provides infrastructure-level resilience, snapshots and disaster recovery capabilities. Rubrik, however, provides an independent backup and recovery layer, with its own recovery points, retention policies and restore workflows.

The company implemented physical Rubrik infrastructure on HPE ProLiant DL360 Gen11 hardware, in a configuration validated and supported according to Rubrik compatibility requirements. The infrastructure is connected to Rubrik Security Cloud (RSC). Rubrik Security Cloud is a SaaS platform from which workloads, SLA policies, recovery points, jobs and Data Threat Analytics can be managed centrally. The Rubrik infrastructure was connected to Prism Central. This allowed Rubrik to discover the Nutanix clusters managed through Prism Central and the VMs running on them. Discovery meant that the backup platform could see objects such as the FS-PROD-07 VM. This did not mean that protection was automatically applied to every discovered VM. Protection was controlled through a Rubrik SLA Domain. An SLA Domain defines how often a workload is protected and how long its recovery points are retained. The SLA policy can also include other requirements related to the data lifecycle. I also enabled Rubrik Data Threat Analytics – Anomaly Detection. This feature automatically analyzes protected snapshots and compares the changes between two successive recovery points. In this way, Rubrik can identify an unusual volume of modified files, indicators associated with encryption or snapshots showing suspicious activity.

Back to Monday: the newest recovery point is not automatically the best one

On Monday morning, Rubrik displayed four recent recovery points for the FS-PROD-07 VM: one from Sunday at 22:00 and others from Monday at 01:00, 04:00 and 07:00. The encrypted files were discovered shortly before 08:00. No one knows whether the encryption process started at 07:50 or earlier. The unusual extensions show us what happened to the documents, not the exact moment when the changes occurred. A colleague suggests restoring the newest recovery point, the one from 07:00, arguing that the most recent copy would result in the smallest data loss. However, that snapshot may already contain the encrypted files. I open the anomaly information for the FS-PROD-07 VM in Rubrik Security Cloud. The snapshots from 04:00 and 07:00 are flagged as anomalous. The 01:00 recovery point is the one that appears clean, and Rubrik suggests it as a candidate for recovery. This does not mean that the 01:00 snapshot is guaranteed to be clean. The Anomaly Detection feature shows me where suspicious changes appear and helps me avoid affected snapshots. However, it cannot prove with certainty that before 01:00 there was no unwanted change or malicious file that had not yet produced an anomaly. After an analysis, we decide that the Monday 01:00 snapshot is the first candidate for recovery testing. The available information gives us enough confidence to validate it. Choosing the 01:00 recovery point instead of the 07:00 one results in the loss of up to six hours of legitimate changes.

Recovery for FS-PROD-07

Step 1: The compromised VM remains isolated

Before performing any operation in Rubrik, I return to Prism Central and check the original FS-PROD-07 VM again. I confirm that the original VM is shut down and that its vNIC is disconnected from the production network. The powered-off state prevents malicious changes from being made on that VM. The disconnected vNIC prevents the compromised guest OS from communicating with the production network if someone accidentally starts the VM. The VM will not be deleted; it will be kept for further analysis.

Step 2: Selecting the recovery point

In Rubrik, I check the four available recovery points and select the one from Monday at 01:00. A snapshot is the state of the VM captured at a specific point in time. It contains the information Rubrik needs for the recovery procedure. It is not yet a running VM.

Step 3: Creating a Live Mount

I create a Live Mount in Rubrik and name it: FS-PROD-07-RECOVERY. Live Mount allows a Nutanix AHV VM to start directly from Rubrik storage, without waiting for the VM to be fully copied to Nutanix storage. For a 4 TB file server, the time saved is essential. This means that instead of waiting for a full restore to finish, I can already begin checking the VM while it is running directly from backup storage. I can choose whether the VM starts automatically after creation, but I choose to keep it powered off. A VM recovered from backup normally retains the hostname and IP configuration saved in the snapshot. I do not want it to somehow reach the production network. When FS-PROD-07-RECOVERY appears in Prism, I first check that it is powered off. Then I check the status of the vNIC. I make sure it is disconnected from the production network and connect it to an isolated recovery network. Only then do I start the VM.

Step 4: Checking the VM from the console

I connect through the Prism console. This gives me direct access to the VM without depending on its production IP address. Windows starts the boot sequence and reaches the login screen. The first observation is therefore that the 01:00 recovery point contains a guest OS that can boot. This is a necessary condition, but not a sufficient one. A file server can boot and, at the same time, contain encrypted data. I check the Windows volumes. The system volume is present, and the D: data volume is online. The reported capacity matches what I expect for FS-PROD-07. The fact that the volume is online proves that Windows recognizes the recovered data disk. It does not prove that the directories or documents inside are the correct ones.

I access D:\Shares\Financiar. I navigate through several directories. This confirms that the correct hierarchy was preserved in the 01:00 recovery point. Next, I check whether the Windows file sharing service has started. I check whether the shares exist and point to the correct local folders. The Financiar share, for example, must point to the corresponding Financiar directory in D:\Shares.

I then check the NTFS permissions. NTFS permissions are rules configured in Windows that determine which users and groups can read, modify, or manage a file or folder. The finance department must receive the same access it had before, while unauthorized users must not gain broader rights as a result of the recovery process. Only now do I check the files. I start with their names. The additional extensions observed on the compromised VM no longer appear. The names end normally in .xlsx or .pdf. I also check the same folders for the README_TO_RESTORE.txt ransom note; the file is not present. I also verify that the files can be opened and read.

At this point, I have demonstrated several practical things about the Monday 01:00 recovery point:

• Windows starts;
• The data volume is accessible and has the correct capacity;
• The Windows file sharing service is functional;
• The NTFS permissions checked match the configured access;
• The files can be opened or executed;
• The folders no longer contain the .locked extensions or the ransom note.

I have not demonstrated that all documents on the 4 TB file server are correct. However, I have enough evidence to request management approval for this 01:00 recovery point.

Step 5: Migrating the recovered VM back to Nutanix storage

Live Mount allowed me to start and quickly validate the VM. However, it is only a temporary state; a production file server cannot remain on Rubrik storage. The recovered VM must once again become a workload in the Nutanix infrastructure, with its virtual disks located in the Nutanix storage container. A storage container is a logical area in AOS used to store VM disks and apply the relevant storage configuration. From Rubrik, I start the procedure that migrates the Live Mount to Nutanix storage. I check the destination before starting and monitor the job until completion. After Rubrik completes the job, I return to Prism Central. I confirm that the VM disks are now on Nutanix storage and no longer depend on Live Mount. I confirm that Windows works correctly after the migration and that the D: volume, the file sharing service, and the share are available. If the VM worked during Live Mount, it will most likely also work after the migration.

Step 6: Verifying the VM identity before reconnecting it to production

In Prism, the recovered VM is named FS-PROD-07-RECOVERY. In Windows, however, the hostname is still FS-PROD-07 because this was the hostname saved in the recovery point. Before reconnecting anything, I confirm once again that the original compromised VM is powered off and isolated. The two VMs must not be running simultaneously on the same production network. After the migration, I check again that Windows is running, the D: volume is accessible, the file sharing service is running, and the shares respond. I also check networking, IP addressing, and that the VM is joined to Active Directory. The migration is considered complete only after these checks. I also check the vNICs and MAC addresses of the recovered VM in Prism.

Step 7: Reconnecting production

The selected recovery point has been validated. The data has been migrated to Nutanix storage. The original VM remains powered off and isolated. The identity and network configuration of the recovered VM have been verified. The next step is to connect the vNICs of the recovered VM to the production network. I check that DNS resolves FS-PROD-07. Basic connectivity works. I test TCP port 445 again and confirm that SMB is accessible. Then I directly open each share, including \\FS-PROD-07\Financiar and \\FS-PROD-07\Achizitii. I call Elena and ask her to open the file. It loads and the data is visible. Only at that point can the service be considered restored for the users in the finance department. The Lenovo ThinkAgile HX nodes remained operational. AHV continued to run the virtual environment. AOS continued to provide centralized storage. Prism Central continued to report the status of the entire Nutanix infrastructure. Rubrik was the component that provided a recovery point. Live Mount allowed me to start and validate the Monday 01:00 state before bringing it back into production. The validated VM was then migrated back to Nutanix storage. After several checks, the file server became available again.

Benefits of the Nutanix and Rubrik solution

Nutanix provides: the compute platform, AHV virtualization, AOS distributed storage, and management through Prism. These components run and manage the VM, but a platform like this does not guarantee that the files inside the guest OS are usable.

Rubrik provides: protected and independent recovery points, protection and retention, Live Mount for rapid validation, and a supported workflow for migrating the mounted VM back to Nutanix storage. And much more.

In the event of an incident, the engineer must provide: isolation of the compromised VM, selection of a recovery point, validation of VM functionality, migration to the original storage, prevention of IP conflicts, and reconnection to production.

Neither Nutanix nor Rubrik are solutions that stop ransomware. The value of this architecture is that I have independent recovery points available and a method for testing them before bringing the VM back into production when the data inside a VM is no longer usable but the infrastructure is still running.

If you would like to learn more about the right solutions for protecting and recovering your organization’s data, write to us at [email protected].