Ransomware realities: In your normal life, strangers don't extort you. But here you are

No crying at the back

As "trendy" as ransomware is at the moment, it's a sobering thought when you remind yourself that in this case you're literally having to deal with some miscreant holding your data to ransom.

In practical terms, when your systems become infected, the malware encodes your files using a strong encryption algorithm, and leaves you a "ransom note" inviting you to pay a sum of money to buy the "key" that will unlock them.

Some ransomware takes a slightly different approach – “leakware” threatens to send your private data out over the internet unless you pay up, for instance, and there are “inconvenienceware” flavours which simply pop up unwanted windows until you stump up the readies. But the simple encode-and-extort approach is the one we know as proper ransomware.

How does an attack happen?

Ransomware gets in just like any other malware. It might be through a virus-laden attachment on an email message or an infected item that a user clicks on in a web browser: ransomware is merely a variation on the malware theme.

And as with other malware, zero-day attacks – where the malware is so new that the anti-malware writers haven’t yet catered for it – are a common underlying cause. Given that it’s incredibly hard to protect against all zero-day attacks, you should assume that you’ll be clobbered one day and prepare to deal with an infection.

The 'gotchas' of ransomware

Ransomware has some unusual characteristics that set it apart from other types of malware. First off, it will often delete itself when it’s run out of files to encrypt. This means it is hard to find the source unless you catch it while it’s running. Also, it may leave little or no trace: in some cases it will shuffle files around without them being stamped with the user iD under which the malware ran. This again makes it hard to investigate. And if it’s a zero-day attack a full scan of your server volumes won’t help either as the AV package won’t know what it is looking for.

The other gotcha that’s easy to fall for is the auto sync backup. Use Google Drive or iCloud to sync your PC or Mac to the cloud in case your files get corrupted? Well, the entertaining news is that when the ransomware encrypts a file on your PC, the cloud driver will spot the change and helpfully sync the encrypted version to the cloud-based disk too. And you wouldn’t be the first: The same applies even if you don’t have an auto-sync mechanism for file copies: if your backup volume is available as a file share and the ransomware can see it and write to it, it’ll crawl over it and encrypt the contents.

How will I know?

You’ll often discover a ransomware infection when the IT Service Desk gets a call from a confused user whose budget spreadsheet is no more. If you’re lucky, a scheduled AV scan may also pick up an infected file before the ransomware starts running – after all, even if it got in as a zero-day infection, your AV vendor’s signature file may catch up before long and spot it before it activates. Oh, and probably the worst case is when the Information Commissioner phones you to tell you that someone’s complained about their personal data being out on the internet …

How do I respond?

When you discover you’re being attacked, ask yourself three questions:

• “Can I see where the malware is running?”
• “Can I see the scope of the files it’s working on?”
• “Am I sure no data is leaking?”

If the answer to at least one of the above is “no”, invoke your Business Continuity plan. Actually you may well invoke the BC regime even if you are reasonably confident that the incident is contained, because a good BC team will run the logistical and communication mechanisms while the techies deal with the attack itself.

Step one of dealing with the incident is identification: find the files being accessed, where they’re being accessed from, whose login is accessing them, and (if you can) the identity of the malware that’s hit you. There’s an important fact to remember on this latter point: the anti-malware vendors often produce unsupported free widgets for one-off usage (McAfee has Stinger, for instance - https://www.mcafee.com/us/downloads/free-tools/stinger.aspx) and these often have pre-release virus signature files that haven’t yet made it to the commercial versions and which will spot malware that the production version can’t.

Step two is to contain the infection. If it’s a shared directory that’s being infected, dismount the share. If it’s a workstation, pull the power on it (don’t shut it down gracefully – the malware might see the shutdown signal and delete itself, thwarting your later investigation). If it’s a virtual server, pause it – as with powering down the workstation, if you can stop the machine in its tracks you may retain a copy of what was in memory to assist your investigation.

Next comes investigation. First establish that the attack has actually stopped (just because you killed off one workstation doesn’t mean it’s not running on another as well). Snapshot key systems so you can safely work on a copy of the infected drive and memory, and boot workstations from a USB disk so you’re not touching the boot disk. Find out as much as you can, because it will not only help you understand how to eradicate the malware but also give you confidence that you understand the attack and are able to deal with it fully.

Eradication is next. If a desktop’s infected, reformat the drive and reinstall – never, ever just run the malware recovery tool and hope it deletes the ransomware. In the investigation section you understood how the attack happened, so you now need to plug whatever gap let the malware in in the first place. And the chances are that you’ll have a ransom note for each of the files that was encrypted, so you’ll need to bulk-erase those too in order to clear up.

Next comes recovery – which generally means restoring the files from backups. If you’ve had thousands of files encrypted, this means restoring thousands of files – which will take time. We’ll come back to this later when we talk about tools and mitigation.

Finally we have the follow-up phase. This is often done very badly – and sometimes not at all – and where it is done it’s common to treat it as a one-off activity. Follow-up from a ransomware attack should be treated as an ongoing, continuous improvement exercise.

The key protection tools

I mentioned earlier that you should assume you’ll be nobbled by ransomware at some point, but this doesn’t mean you shouldn’t try your hardest not to. Adopt an approach of “defence in depth” – have anti-malware on your Internet proxy and email servers, then more anti-malware on your file servers, then even more on your client PCs. If you can use different AV vendors for each of these then great, because multiple vendors equals a greater chance of one of them spotting an infection. And as I mentioned earlier, have good access to pre-release tools, as they can dig you out of a hole when the production version might not.

Protection techniques

Aside from tools, the way you work can also help greatly. Work on a system of “least privilege” – where users have access only to the files they need. If the user ID under which malware is running has access only to a small number of files, it’s only that small number of files that can be damaged by the malware.

Keep comprehensive logs of file access (particularly modification), and squirrel the log files away to a SIEM system or other location that the malware can’t get access to: although this won’t help you prevent infection, it’ll greatly assist the investigation process.

And schedule regular system scans: as I noted previously, even if something sneaked in under the zero-day radar, regular scheduled scans may pick up infections once the malware has been recognised by the anti-malware vendor and added to the signature file.

Last but not least, make sure your backups are air-gapped – that is, the malware can’t simply access them or let your cloud software sync encrypted versions to the cloud. Backup applications that use an agent to pull the files from the client to the server are a good choice here as there’s no direct file sharing putting your systems at risk.

Mitigation techniques

To prepare for being hit by ransomware, make sure your BC regime is in order and your response team have the training they need to run the process once invoked. It’s invaluable to have a team that can take the logistical and administrative chores and leave the technical team to sort out the infection.

Ensure that the technical team – particularly those who may be called out of hours – have the necessary skills and access privileges to do what they need. If I had a fiver for every time the 3am on-call engineer couldn’t get into the building, or had an expired login, or …

Make sure you test your backups regularly. Really obvious and commonly forgotten, untested backups often result in tears and or the potential for a P45.

Most importantly, have documentation that enables non-skilled engineers to do all the things they might need to. Backup restorations are the most important in this respect, because if you’ve had a quarter of a million files encrypted, it’s going to take some hours to resurrect them from the backup: so rather than the poor chief sysadmin keeping his eyes open with matchsticks and Pro Plus, enable the team do to it in shifts with suitable documentation.

Keep your suite of tools up to date so that you don’t have to go frantically Googling for tools when the effluent has hit the fan and all eyes are on your team. And keep the toolkit offline – there’s no point having it on the server if you just took the server offline to stop the ransomware’s infection spree.

And importantly: ensure that the line of authority in the response process is clear: you will undoubtedly have disagreements (for instance the finance people might insist the attack is stopped while the techies want to let it run to help find out more) and the authoritative person must be known to everyone.

The top three tasks of ransomware

This feature is based on a presentation I gave at the Old Magistrate’s Court in Jersey in April 2017 under the auspices of the Channel Islands Information Security Forum (http://www.ciisf.org/), It was a lot for the audience to take in in a 40-minute presentation, so I picked my top three things to remember as they departed. And they were:

• Assume you will be infected by ransomware: there’s a very good chance that you will be at some point.

• Continuous review and improvement: the last stage of incident response should actually be adopted as an ongoing programme of review and enhancement of your protection and mitigation mechanisms.

• Have a solid response process: use your technical brain power to deal with the ransomware, and let the BC team do the rest.