Sunday, 10 September 2017

Using defence in depth to mitigate the risk of ransomware

I've written before about the evils of crypto locker and the spawn of that devilish state of affairs known as ransomware. Recently I came across an infection and saw first hand how defence in depth can save your data and the bitcoin.

Firstly, let's consider the perimeter of the network. What vectors for attack exist externally to the network? There are many and they include:

  • malicious emails
  • dodgy websites with malicious payload 
  • malicious actors (hackers) out to get you
The first layers of defence include (in this case):
  • an antivirus/antispam gateway for email, with the firewall at the main router allowing only connections on port 25 (smtp) from the mail scanner gateway
  • antispyware/antivirus email on the computers scanning every website that a user visits, plus using OpenDNS with a variety of restrictions on it to protect the user from themselves
  • firewalls and obfuscated ports where applicable with minimal "open-to-the-world" ports
That's the hard outer layer. Past the router / firewall and onto the network, we use:
  • firewalls on all PCs (granted only the windows ones, but supplemented with the anti-virus product's offerings)
  • WSUS to keep everything patched and up to date
  • VLANs to separate out stuff
  • usernames / passwords for access to all network resource
To further enhance security:
  • all backups go to a UNC path (i.e \\nas\backups) rather than a mapped drive (like an S:\ drive) which is important because ransomware will attack both local drives and network mapped drives - encrypted backups are 100% useless
  • users have restrictions based on principles of least privilege and this is rigorously enforced
  • servers are also patched and up to date
  • logs are maintained on a separate server
  • PRTG is used to monitor network traffic on the switches and a variety of other stuff
So what happened and how did this all help to mitigate a ransomware attack?

Well a user, let's call him Jim Bob, has a very weak password. Let's say it's Secret01 (yes if this is your password, it is shite. Change it now!)

An external attacker managed to get Jim Bob's username, and then proceeded to attack the remote desktop services to see if they could brute force their way in. What would you know, about 2 hours after starting, they got the password and were in. This could have been mitigated by having a password locking system turned on, but remember - you have to balance usability with security. This particular organisation struggles with passwords at the best of times, so locking a user out after 3 failed attempts for 10 minutes would have very high frustration levels as a result.

The attacker now had access to a server. But - Jim Bob's account was extremely limited. He just couldn't do much - he didn't need to. Basically log on and access the internet. That's him to a tee. This therefore, is all the attacker could do. Frustrating I bet!

Along comes the admin and logs on. The attacker - seeing a systems admin hit the server panics and drops a ransomware payload, probably thinking they'll get some sort of a payday somehow. Their ransomware attack manages to get a foothold on a mapped drive. The security on that mapped drive allows for only a small percentage of accessible files to be encrypted before the wily sysadmin spots it and locks Jim Bob's account down, and shuts off the file server. 

Our defence has now limited the risk by controlling the access to files and what could be attacked. And it gets better. Our snapshot backups are working as advertised and have a 15 minute old copy of the entire mapped drive's file system. With a few clicks, our intrepid sysadmin restores the whole lot over the next hour. Hundreds of files, barely out of date and only in a few instances. Within a few hours, Jim Bob's account has been restricted, password changed and the user Jim Bob given a kick in the bum for having a crappy password and the network drive is fully recovered.

Although our initial defensive line was penetrated (users can be your greatest security risk), the rest of the network's defences held firm mitigating the impact of the attack and the organisation's exposure to loss of data. No pay day for our arsehole attacker today! I like to think of how sad they must be, all that effort and no reward.

In the wash up, the sysadmin goes through and using the logs, PRTG and combing files finds the attacker's trail and mops up after them, making notes on what failed and how to improve it for next time. 

The moral of the story is this - defence always loses. Attackers will win. All we can do is to mitigate the damage and risk to the best of our capabilities and budget. Hopefully you will read this and get a few little ideas about how to perhaps enhance your existing defence, or even think about what attack vectors might exist. This pretend network is by no means perfect - it could always be better. Budget and skill restrictions come into play though and mean we have to find the best effort with whatever we've got at hand to make it work. Be smart and get margin into your security so a break in doesn't break your heart or your budget!