WannaWakeup? - James Townsend's view on the latest malware crisis

Tuesday, May 16, 2017 - 09:00

Heatmap from MalwareHunter Team (https://twitter.com/malwrhunterteam) showing WannaCry distribution at 24 hours after “explosion”.

WannaCry/Wannacrypt0r/WCry is certainly receiving a great deal of attention in the press, but this is by no means a new problem – in March this year no less than 40 new ransomware campaigns took root. In fact mitigation and containment of malware is something fundamental to the way in which we plan, design and maintain our networks. I wrote in a previous blog that you will be hacked and it is a case of when, not if you will be affected to some degree. Though I wouldn’t go so far as to say that the NHS being hit in such a dramatic way is a good thing given the consequences for patients, it does serve as a high profile wake-up call to every organisation: you are not immune to this, you need to take it seriously and you need to take steps to secure your network from the ground up.

Don’t forget that WannaCry is merely one of the latest versions of a rapidly growing criminal enterprise. It’s so lucrative that Ransomware as a service (RaaS) is trivial to buy, deploy and operate – just see one of the slick marketing videos on youtube, this one for “Philadelphia” https://www.youtube.com/watch?v=5WJ2KHoo5Fo. WannaCry, Philidelphia, Spora, sage, sanctions, PetrWarp, Crypt0L0cker, Dharma, Cerber.. the list is growing constantly and they all have user friendly interfaces, customer support and an attractive price tag for potential risk/reward trade off.

So why are we seeing a dramatic rise in ransomware? The answer is simple – money. Ransomware pays, and is less risky than slurping credit card details and the work it takes to turn that into a revenue stream. Even though on Monday morning after the Friday before the BBC are reporting analysis (http://www.bbc.co.uk/news/technology-39915440)  of 3 accounts suggesting just shy of £30,000 has been paid in ransom to the people behind this malware, this is just the tip of the iceberg. For example, without taking into account unreported incidents, the FBI estimated that in Q1 2016 an estimated $209m was extorted by ransomware criminals. In February 2016 a Hollywood Hospital paid 40 bitcoin, or $17,000 in old money (ref: http://www.latimes.com/business/technology/la-me-ln-hollywood-hospital-bitcoin-20160217-story.html), but in that same month two affected German hospitals stood up to an attack without payment and only a couple of hours-worth of data lost (REF: http://www.theregister.co.uk/2016/02/26/german_hospitals_ransomware/).

Why the difference in response? What lessons can we learn from other people’s misery? How can we design our network and guiding principles to a) stop the malware entering the network b) mitigate the effects if it does?  Let’s look briefly at some of the foundations:

  1. Zero Trust. Just because a machine is local to your network doesn’t mean you should trust it any more than you would a machine on the internet. Separate the network logically and inspect traffic. Verify and validate users and their machines continuously.
  2. Endpoint security. Behaviour of malware (ransomware as just one example) can be specifically profiled. AV is not perfect but protects against the known and thus is effective in 99% of cases. Sandboxing and behavioural analysis are excellent components to your endpoint security – they don’t have to be deployed liberally, just on the “crown jewels” or on legacy systems.
  3. Backup Policy. Have a robust and regular backup regime – just don’t backup ransomware encrypted files over the good files!
  4. Patching policy. The NSA-supplied exploits that were used to deliver and propagate WannaCry were patched even before the shadowbroker disclosure. Take patching seriously and have mechanisms for acting swiftly on patch releases.
  5. Legacy systems. In environments where legacy operating systems are the only option (a MRI scanner where software only runs on an outdated OS for example), seriously consider your endpoint security and the requirement for the system to be connected to the internet or the network at all.
  6. Security Incident Response. When mess hits the fan, you need to know that it has and have a well-oiled process of dealing with it.
  7. User & systems permissions. Should a .zip/.exe/.scr etc be allowed into the network as an email attachment? Is there a legitimate reason for it? Should SMB be open on the network? Should it be (eeek!) open on the internet? Should Windows-esque filesharing (tcp/139 & tcp/445) be permitted by default?
  8. User education. This doesn’t make up for a lack of security but will make a difference to your incident response and empowers your users to spot the signs of an issue.

Talk to us about defence-in-depth, your network and the ways in which we can help you review and tighten your systems, policies and processes.

By James Townsend, Data Integration's Technical Architect.

Connect with James on LinkedIn.