Dealing with Ransomware - a real life tale

Ransomware is one of the biggest risks to individuals and organisations today.  This malicious code encrypts your files, rendering them inaccessible, before presenting you with a ransom demand.  Some years ago one of the clients I support was infected by ransomware and this is the tale of how we found, and stopped, the malware[1].

Typically, ransomware starts by contacting a command and control (CNC) server to obtain a new encryption key.  By using a key unique to each victim, the malicious actor can gain more money - otherwise one person would buy the decryption key and share it.  Unfortunately the CNC traffic wasn't detected and blocked so the client was in trouble.

Once a key has been obtained the ransomware sets about encrypting the files, generally alphabetically although that's not a hard and fast rule.  Files often have their name changed (for example accounts.xlsx to accounts.nuke55) which is one way to spot the infection. In my experience ransomware starts with the user's folders (desktop, documents, pictures etc.) before moving on to other drives (so A:\, B:\, C:\ ...).  On a home PC there's typically only a C:\ and maybe a D:\ but in businesses, where organisations use something called mapped drives, there's often many more.  These mapped drives provide access to files found on servers, shared with other people and it's those shares that alerted us to a problem.

Early in the day a user had called up complaining they could no longer access some business files - they just wouldn't open.  This should have been an early indication of a problem (the file extension had changed to .nuke55) but that was missed and the file was restored from backup.  A few hours later, which we later learnt equated to several hundred thousand files, our team heard someone query what a "nuke55 extension was".  We dived into action!

Locating "patient zero"

Fortunately we knew one of the servers that was storing the files in the process of being encrypted.  The knee-jerk response would be to disconnect that server from the network to stop the loss of any further files.  Knee-jerk reactions are often problematic and would have cost a lot more files had we taken the server offline.  That sounds counter-intuitive (it is), so let me explain.

If the ransomware process had lost access to the files it was working on the process would have just moved on to the next mapped drive.  Eventually we'd have needed to shut down the whole data centre but would still have had a rogue device waiting to start encrypting files again.

At the cost of encrypting more files, I and a colleague took the time to look at the open files section of the shared folders Microsoft Management Console snap in.  This showed a username (we'll call them "Janet") had a lot of files open including some with the ransomware's file extension.

Preventing further data loss

Firstly, we had to locate "Janet".  Fortunately that was a simple case of finding them in the staff directory and making a phone call.  We were particularly lucky in this case, as Janet often worked out and about and was not primarily desk based.

Having got Janet on the phone I confirmed what was on her screen (a ransomware application) and talked her through pulling the power cable out of her PC.  By pulling the power cable the malware doesn't have opportunity to erase itself or perform other actions.  I chose this step as I couldn't rule out the possibility of needing to perform forensic analysis at a later date.

Janet kindly labelled the computer with an A4 skull and crossbones, annotated with "this computer has the plague!  Do not plug it in.".  A nearby colleague grabbed the machine and it was delivered to my desk the next morning.

Oh, I want to highlight that Janet wasn't in trouble for bringing the ransomware in.  Equally she wasn't in trouble for not raising the alarm when the message popped up about encryption.  As she explained to me:

I know you folk in ICT use encryption, so I assumed it was you and thus legitimate!

Preventing ransomware in the future

Clearly we didn't want to have a repeat scenario.  Prior to locating Janet's machine the ransomware had been running about three hours which equated to hundreds of thousands of files encrypted.  Most files were restored from backup but any new work was lost.

File screens

File screens are part of the File Server Resource Manager tools available in Windows Server since 2003 R2.  By configuring a file screen it's possible to prevent a file being saved to the file system.  In our case we created rules that said "if the filename ends with these extensions, don't save the file".  That was followed by an email the the security team alerting them to the problem, and another email to the user saying "call the service desk immediately".

There are scripts available online that update the file extensions being used by ransomware.  I leave it to the reader to investigate further.

Behavioural analysis

Anti-virus has historically used signatures to determine if a file is malicious.  Trouble is, malware can be changed so quickly that keeping signatures up-to-date (or even vaguely close) to protect against a current strain of malware is an impossible task.  Enter behavioural analysis.

Given the steps ransomware takes is known (read file, encrypt data, write file) it's possible to detect and block ransomware by looking for its behavioural pattern rather than a file signature.  As this is behavioural analysis the ransomware has to actually run which means some files will be encrypted.  Nonetheless, better a handful of files get encrypted than all of them.

Sophos InterceptX is one product that works this way.  I'm not on commission, this is an unbiased comment, but I'd recommend you give InterceptX a look.  I've not tested InterceptX against a live sample of malware, so I can't personally validate its effectiveness, but I can tell you I've not seen a successful ransomware infection at a client that's running it.

A crucial thing - offline backups

It would be remiss of me not to mention how important having good, tested, offline backups are.  By offline I mean a backup that is not accessible from the machine that's been infected - there have been plenty of examples of ransomware encrypting the backup too, so your backup needs to be inaccessible to the malware.

Restoring from backup, rather than paying the ransom, ensures the "bad guys" don't win.  That's why it's also important to perform test restores of your backups.

Banner image, the WannaCry ransomware message from Wikipedia.

[1] Malware is short for malicious software