#WannaCry and #NHSCyberAttack
While I’ve included the trending twitter tags WannaCry and NHSCyberAttack in the title, it’s because that’s what most people have come to know Fridays worm attack as.
In reality, this wasn’t an attack directed specifically at the NHS as it affected computer systems world wide including big name companies such as Telefonica, Fedex, Nissan and Renault to name but a few.
I’m not going to do an in-depth review of what the wCry (or WannaCry as it became known on twitter) worm does as that’s been covered by people with far more knowledge than myself. If you do want the nitty gritty, I recommend checking out these resources:
The stark reality is, this could mainly have been avoided (or at least the impact reduced) due to these three things:
- Up to date patching
- Not running SMB1 on devices
- Not allowing access to SMB from the Internet
Microsoft released the patch that fixes the exploit used by the worm to spread back in March.
Now, while it’s easy to say “Well there’s no excuse then, everything should be patched!” it’s never as easy as that for large environments and sometimes even more so for NHS where resources are always tight at the best of times and there is often no dedicated resources or InfoSec teams.
I will acknowledge however, specialist devices such as MRI’s etc that have dedicated controllers connected running an old OS that aren’t allowed to be touched/modified/patched by anyone other than the vendor. So are often well behind with updates.
What I will say is that making sure management systems such as Microsoft Configuration Manager are in place, functioning and configured to automate the patching process wherever possible makes life easier to manage with limited resources, easy reporting is something that should be looked at to allow you to quickly zone in on problem areas (that are within an organisations control).
I recommend checking out the PowerON ConfigMgr PowerBI report set that @Raf_Delgado created as an example of enhanced reporting.
The good news is, Microsoft have now even released an out of band security fix for non-supported OS’s (XP, 2003 etc), download links are in the post here.
As Ned Pyle is quite happy to remind anyone and everyone that prods him with an SMB1 carrot, the recommendation from Microsoft has been to disable/remove SMB1 from devices for ages. In fact, Ned wrote a post on it back in 2016 which you can read here.
In most environments this shouldn’t have too much impact to remove, just consider the following:
- Networked (old) devices such as Multi Function Printers that use scan and share type features – check firmware SMB support levels
- Storage devices such as NAS boxes or NetApp where they might still be using SMB1
- Windows XP or Server 2003 devices
It’s that last point that will be the sticking point for some organisations (Thinking of you NHS!). While we are seeing less and less of Windows XP out there, I know full well that most organisations are still migrating away from their 2003 servers (bear in mind 2003 end of support was 14th July 2015…).
If you are lucky enough, or want to try it on some systems, to be able to disable SMB1, I’ve written a quick ConfigMgr Compliance Setting baseline that you can import into your Configuration Manager environment and deploy to systems to disable/remove SMB1 with minimal effort.
Block SMB1 at the edge
Since the WannaCry worm isn’t spread via e-mail, it is in fact scanning IP ranges for devices vulnerable to the SMB1 exploit, then closing down the incoming ports for SMB is recommended.
There should be no excuse for having a corporate environment openly exposed to the internet on TCP 445, close it.
This is where some of the, amusing for onlookers but not the businesses, Kiosks and public terminals etc are getting infected. It’s quite common, although insecure, to see these types of devices directly connected to the internet and either setup with lax security or left open intentionally for “support” reasons.
While you should certainly close off TCP 445 for your environment make sure you consider any roaming devices you have and how their protection is going to behave when connected to home networks or partner networks. The last thing you want to see happen is an unpatched device land on a network that the device marks as trusted and allows traffic on 445, gets infected only to infect your network when the user brings in back into your internet environment.
WannaCry Kill Switch
While investigating the worm, MalwareTech saw connection attempts to an unregistered domain and therefore promptly registered it. This had the bonus affect of effectively activating a kill switch for the worm meaning that any infected device will exit the malware before encrypting files if it can see the domain.
However… it looks like organisations that utilise proxy servers to route and control internet traffic won’t benefit from this as the worm doesn’t play nicely with them.
If at all possible, look to enable devices within the network to resolve the following DNS address:
N.B. This could just be a temporary thing, as it’s fairly trivial for attackers to release a new strain of the worm with modified code that doesn’t use this address, but hey, it’s better than nothing!
This might sound like a broken record by now, but if this incident isn’t a prompt for people to listen then there’s bigger issues.
- Make sure your patch strategy is solid along with easily visible reporting.
- Look to harden your environment and close down legacy/unwanted protocols whenever possible.
- Look to assess new OS and management capabilities whenever available, don’t get stuck in the past…
And one thing I didn’t mention in the main post, make sure you have backups! This is yet again another reason to look at technologies such as Azure Backup and Azure Site Recovery.
If any of this sounds daunting, reach out to the team at PowerON we’re more than happy to help!
Keep Safe out there!
Product Development Director – PowerON
Microsoft MVP – Cloud and Datacenter Management