Last week, we introduced to you Jack — an experienced IT veteran — and began the story of how, one day, he found himself the unwitting victim of a ransomware attack.
While the shock of the Phobos malware on his Windows® servers still stung, Jack soon got a hold of himself and calmed down enough to assess the situation and damage. After carefully examining his files on the Windows® Servers, he found a glimmer of hope.
He noticed that the three production virtual machines had not been encrypted by the hackers. Two years ago, when Jack had set up this system, he had virtualized the Windows® Server, and installed three virtual machines on top of the Windows® Server to run all his business applications.
Jack learned that the ransomware hacker couldn’t obtain Windows admin privileges that would allow him to kill the virtualization processes that were actively running on these virtual systems. This prevented the hacker from encrypting the virtual machine related files, as those files were in use. Instead, all the files remaining in the Windows® Servers were encrypted, including Security Account Manager (SAM) and System Restore files. With these files encrypted, Jack couldn’t log into the system or even restore the Windows Servers from recent backups.
Suddenly, Jack found himself in a cold sweat.
If the ransomware remained in his system, it could eventually gain admin privileges through Privilege Escalation, and then Force Quit all processes and ultimately start the encryption process in the virtual machines.
The thought terrified him a little: one of the production virtual machines hosted a very large database, 1 Terabyte in size. Even though encrypting a 1T file takes a very long time to process, ransomware can still do it if it gets the time it needs.
Jack made a quick but critical decision – force shutdown the two compromised Windows® Servers, just like in the espionage films. Shutting down the server would prevent the further spread of the ransomware malware. But more importantly, it would give Jack a chance to recover some of his critical data.
It turned out to be a wise decision.
Jack disconnected the Windows® Server hard drive from the server chassis, put the hard drive in a USB enclosure, and connected it to a clean computer as external storage. From this clean computer, he was able to access all the files from the hard drive, including the files encrypted by the ransomware malware AND the virtual machine files NOT encrypted by the ransomware.
In that moment, he felt that luck was on his side, and his glimmer of hope became a beacon of hope.
He then carefully made a copy of these critical virtual machine files and set about to reimage his servers. Jack found another clean server, performed a clean installation of the Windows® Server. This time around, he took his time and diligently installed all the necessary patches, specifically, the critical security patches needed to protect against intrusive malware.
Then, he followed the same process to virtualize the Windows® Servers, but he didn’t have to install virtual machines from scratch. Instead, he imported the virtual machines he had salvaged from the old Windows® Server hard drive.
After reimaging, patching and re-installing his VMs, Jack was able to get his business applications up and running again, with his orders still intact.
And no …. he didn’t pay the ransom! But he did learn a valuable lesson.