It’s the phone call you don’t want to get. It’s something that companies and organizations say; “We’re careful, that won’t happen to us”. You don’t really plan for it but it’s more and more likely to occur: Ransomware.
Ransomware doesn’t just hit large organizations like governments and transportation networks as we’ve heard about all year, it is also increasingly attacking small businesses – very small organizations, maybe ones like yours!
This is our experience with a Ransomware attack on a small non-profit organization of five desktops and a server. You may be surprised how long it took to mitigate an attack even when the organization is this small.
How It Started
About noon, one of the staff at this non profit organization was browsing the server getting ready to retrieve a spreadsheet. She noticed that filenames were changing to random names. (educating your staff as to what an attack may look like will benefit you!)
They called our IT Support and after a brief discussion we determined that this was a Ransomware attack encrypting files.
Note: This is the first time one of our customers has been hit with Ransomware. It was advantageous that someone noticed it happening and we caught it early, it made a big difference.
First Steps
After determining that this was Ransomware the very first thing was to shut everything down, server and desktops, anything attached to the network. Let’s try to stop it early. Let’s try to keep it contained.
We discussed the option of paying, but decided to assess first and see the extent of the damage.
The Ransomware Source
Once onsite and after some discussion, we determined that this Ransomware was activated by clicking a zip file attached to an email. It was a notification of flight details – and the person was in fact waiting to receive details of the flight she was due to fly out that same day.
Finding the source is important and helpful, it tells you where to focus your time and efforts.
However this source desktop was on a network with drives mapped to the server so the Ransomware also jumped to the server and started encrypting files there as well.
Even though we now know the source, we weren’t sure yet if the Ransomware had maybe propagated and had jumped to other desktops. The best thing is to shut it down, isolate each of the parts, and try to keep it contained as small as possible.
Assess
The source desktop is isolated. The next priority is the server data and getting people back up and working.
We don’t, however, want to turn the server back on in case it is infected and continues to encrypt data. This server is the primary and only Domain Controller for the organization and to rebuild and re-implement it will ugly and time consuming. Before turning it back on we need to assess the server, how bad is it, is it fixable?
The solution is to pull the drives on the server so that a copy of the malware, potentially on the server, wouldn’t kick in when the operating system fires up. We get around this by attaching the server drives to another desktop to be able to review and scan the contents without loading up the server operating system.
The operating system for the server is on the C: drive, separate from the data drive. This was a definite advantage in that no files on the server’s C: drive were encrypted. The data drive however had 6,000 encrypted files. Interestingly encrypted files were not all in the same folder, but scattered across the drive’s many sub-folders. Sometimes three or four, sometimes twenty or thirty under each folder.
File names were randomized, and the extensions were all “.zzzzz”. Here’s what we saw:
After determining that this was the full extent of the Ransomware encryption, we put just the C: drive back in the server (without the data drive) and it started up just fine. The server itself is not causing the encryption. We are lucky!
Check, Scan, Check Again
We now know the source, and we know the server is okay. Let’s make sure there’s nothing else on that data drive.
We ran full virus and malware scans against the server’s data drive, which took the rest of the day and part of the night to perform. By next morning we were confident that the data drive could be used and files could be restored to it.
Cautious Re-Connection
The next morning we put the data drive back in the server and held our breath. (We did have a moment of panic until we realized we plugged the network cable into the wrong jack on the back). The server started up fully, with no issues.
In the meantime we performed full virus and malware scans on every desktop, and then re-connected them to the network. All except the source desktop.
Desktops were able to see the server, no additional encryption was going on. Things were starting to return to normal.
This is one server and five desktops – it has now been 24 hours.
Data Restore
This organization does nightly backups, and the encryption happened about noon, so we know that the previous day’s backup could safely be restored.
We first restored data, then we went through and deleted all the encrypted files.
We were lucky here too in that all files were encrypted the same way and had an extension of “.zzzzz” so they were easy to identify.
Now The Source Desktop
The source desktop has 15,000 encrypted files. The Operating System (Windows) appears to be fine but any data, photos and videos stored locally are mostly gone. We don’t backup the desktops as all organization data should be kept on the server, so there will be unfortunate loss.
This desktop will likely be wiped and rebuilt.
Lessons Learned
We reacted quickly, we got onsite quickly, then we slowed down to assess and make sure the process and methodology was correct. You only get one shot at this to do it right – you want to be right.
Here’s some other thoughts
- Backup nightly – A nightly backup saved this organization. Almost no data was lost and staff was up and running again pretty quickly. In a worse case we could have restored data to another machine and had people connected to that.
- Use Hybrid Backup – this customer has cloud backup but restores would have been much faster with a local backup as a first point of restore. Network speeds beat Internet speeds every time.
- Use a more robust virus/malware scanner – this customer only had basic. Many corporate products now include some protection from Ransomware
- Enforce centralized data – I doubt that particular user will ever keep items locally again
This non profit survived the Ransomware attack without paying and only sustaining a half day’s worth of lost time. It could have been a lot worse.
What do you think? Could you survive a Ransomware attack without paying? Do you have a backup to save you?