What could have limited the impact of the WannaCry / Wcry / WannaCrypt ransomware?

The WannaCry / Wcry / WannaCrypt ransomware

A major wave of ransomware called WannaCry / Wcry / WannaCrypt has hit many organizations around the world, causing panic among many users, system administrators and security professionals. The details of the ransomware have been covered in detail at other posts

The massive impact of the ransomware was due to three primary factors

  • This variant of ransomware posessess the capability to spread itself as a so-called worm
  • It exploits a known vulnerability in Windows
  • It uses a network protocol (SMB) that is often unfiltered inside corporate networks

The exploit abused a flaw in all versions of Windows that was patched by MS17-010 on 14th of March 2017. Windows 10 and Windows Server 2016 were protected in their default configuration. The flaw was located in SMB (ports 139, 445), a protocol used by Windows systems to communicate with file systems over a network. The exploit, also known as ETERNALBLUE and released earlier by Shadow Brokers, allows remote access with system privileges. This means an attacker can execute remote code at will, taking full control of the system. Additionally it was observed that the ransomware scans for the presence of DOUBLEPULSAR on other systems.

You can follow the activity of the malware via the Malwaretech bot tracker.

Note that the spreading of the ransomware was stopped by MalwareTech by registering a domain that was used internally in the malware.


Ransomware isn’t something new but we’ve not witnessed a ransomware wave on such large scale. What’s the reason why this flavor had such a large impact on companies around the world?

It’s the fault of the NSA!

The vulnerability that allowed the execution of this ransomware was known by the NSA for quite some time. This was disclosed by the Shadow Brokers leak in April. Sample exploit code was quickly available (and here) and put to use by attackers. The fact that the NSA (or any other agency – both government and private) uses these type of -until then unknown- vulnerabilities should not come as a surprise. It’s the way they run their surveillance business. It is reasonable safe to assume (but it does not justify the use) that the NSA used this vulnerable only against specific targets.

The fact that there was a vulnerability however meant that it was only a matter of time until another organization discovered the same flaw and benefited from it. In an perfect world the NSA should have informed Microsoft (‘responsible disclosure‘) so users would have been protected. Unfortunately, this isn’t the way things work. Remains the fact that the very same vulnerability that allowed surveillance by a (or more?) government agency now causes havoc for those same governments.

Quickly after the public disclosure of the bug Microsoft patched the vulnerability. Closing the hole for everyone. Right?

You should have patched!

Microsoft patched this vulnerability as part of MS17-010. The vulnerability was rated Critical. Windows systems that use Windows Update should have received this update during patch Tuesday. This works well for home users (provided they have enabled Windows Update!) however corporate environments are rarely going to deploy a patch without profound testing. In some cases a patch changes the way a system works, introducing the risk of breaking a business critical application. Therefore proper testing has to be done before deploying a patch to an entire organization. This can cause a lot of delay between the annoucement of the patch and the actual implementation of the patch, leaving a window of opportunity for attackers.

I can restore my files from backups!

You should have made backups!

If your documents are encrypted (or inaccessible due to some another malfunctioning) you can restore them from backups. Note that relying on shadow copies is not going to help in this case as the ransomware also targets these files (by using WMIC.exe, vssadmin.exe and cmd.exe).

Unfortunately a restore procedure takes precious time. Restoring backups isn’t something that happens immediately nor is it done by an automatic process. These things requires an intervention by your IT department and in the mean time people are unable to continue with their work. It also takes some time for your IT department to figure out what is going on.

Many corporate environments run backups, but not all of them have tested their restore procedures properly and had the opportunity to iron out the obstacles that prevent a swift recovery.

Some environments make backups via … SMB (copying files to a remote share or disk). This means that the file share (or in some cases, merely an external disk) used as a safe backup could have been crippled as well by the ransomware. Having encrypted backups is not going to help in recovering from this incident.

You should not have opened that file!

Awareness campaigns warn users of phishing attacks. These campaigns play a big role in preventing malware from being introduced to your network.

This type of ransomware however only needed one curious user on your network to open the file to cause havoc and spread to other systems. Awareness is certainly going to help in preventing a lot of maliciousness on your network but you can not control the behavior of everyone. Attackers know that you run awareness campaigns, so they try to make their phishing messages more enticing for users to open. Even security conscious users can be taken of-guard. It only takes one convincing e-mail or document to get by that line of defense. This also introduces the reason for having multiple lines of defense.

I have an up-to-date anti-virus!

An anti-virus application will only protect you against the known threats. Although most anti-virus vendors will have their signatures updated by now, this would not have prevented the initial attack when it was still unknown and under investigation. Once attackers change one bit in the malware, signatures will not help.

How can I prevent the impact of WannaCry / Wcry / WannaCrypt?

Patch!

Critical patches with known exploits should require immediate attention

Applying the MS17-010 patch would have prevented this incident. Corporate environments can not apply every patch immediately. This is understandable. In your patch policy your should however take into account that

  • A patch rated as critical
  • A vulnerability for which known exploits exist

should require immediate action. Whether you use a CVSS scoring mechanism or any other rating, knowing that there is a vulnerability that is easily exploitable in your environment should require immediate attention. It can be a struggle to request for sufficient resources to be assigned to having testing and deployment set as a priority. This incident however shows that by preventing the problem you can save on resources (be that human resources or financial consequences). In essence this has not have to do as much with ‘security’ but more with having good IT governance and applying good practices. Rapidly applying critical security patches should be part of your regular IT governance process.

Unsupported systems? Microsoft discontinued support (including security patches) for a number of products (like Windows XP) but provided some mitigation measures for these out-dated products.

Disable what is not needed – SMBv1!

Application whitelisting

Disable SMBv1

Application whitelisting is a must have but is often not always feasible in a corporate environment. Preventing execution in a random path, the one where the ransomware can execute, will limit the impact of most malware (not only WannaCry). This can be achieved via application whitelisting but also by system hardening.

For this particular incident, disabling SMBv1 would have prevented the malware from spreading further in your network. Disabling SMBv1 is described in a Microsoft document. There’s no real excuse for still using SMBv1 in your corporate environment.

Filter SMB connections

Limit SMB to systems that really need it

Most corporate environments will now filter SMB connections coming from the internet. In a lot of environments however internal SMB connections are allowed (do not forget the VPN!). You should reconsider this. Not all of your machines require incoming SMB (or RDP) connections. Most security suites now include a local host firewall. If you are not using a security suite you can use the build-in firewall of Microsoft. Deploy a policy that filters all SMB connections for machines and only allow authorized connections.

Disconnect your backups and test your restore procedures

Use a dedicated backup solution that is not using SMB!

Backups do not have to be run through the regular file sharing protocol. There are backup solutions available that are not subject to flaws inherent to the SMB protocol! If you do backups via SMB, make sure that the disk (or share) is only connected during the time of the backup!

Use ACLs and network segmentation!

Apply network segmentation and strong ACLs

Use network segmentation, with proper network filtering, and implement strict ACLs. Your corporate workstations do not have to be able to connect to every internal resource available via SMB!

Integrate threat intelligence to your security work flow

Implement detection rules based on community threat effort

The security community was very quick in recognizing this threat and issued a list of indicators and detection rules (including YARA rules). Threat intelligence will not patch the vulnerabilities that are out there but it will give you a very quick heads-up on what is going on, allowing you to implement detection measures and filtering rules. If you have not done so, contact CIRCL to subscribe to their MISP threat intelligence feed.

Block access to the ‘kill-switch’ domain on our firewall/proxy?

No you should not. When the malware is capable of reaching the ‘kill-switch’ domain it will not further spread the malware. Please note that when you block this domain, it will in fact continue spreading both internal and external.

I’m safe!

No you are not safe! Even if you have mitigated the effects of this particular strain of malware, it’s only a matter of time until miscreants alter the behavior or infection path. As long as you have not patched your systems for this particular vulnerability you will be at risk!

Note that patching this vulnerability will not remove the danger of ransomware. This flavor of ransomare uses a vulnerability that can be patched but there are other avenues that can be used by malware to cause havoc in your organization. The key to combat this danger is

  • Patch your systems
  • Log network, system and service events so that you know what is going on
  • Limit functionality to what is only needed
  • Limit user access
  • Filter network access
  • Use threat intelligence feeds for early awareness
  • Have a tested backup and restore plan
  • Repeat awareness campaigns

References

Leave a Reply

Your email address will not be published. Required fields are marked *