Unless you’ve been hiding under a rock since the May 12th, you’ve heard all about the WannaCry attack. This article is not another 3-month late opinion piece about the attack, but rather one that highlights WannaCry’s five key malware-prevention reminders.
Every technical vulnerability that WannaCry exploited was patchable for up to two months before the attack. There were no zero day exploits involved. By the time the (apparently) NSA-derived tools were released by Shadow Brokers, Microsoft had already patched some of the more potentially damaging vulnerabilities.
Patching is hard, it might affect operations, we must test patches – etc. However, we must do the risk analysis. Within minutes of the patch being published, many cybersecurity professional were all but shouting about just how likely a serious attack using the SMBv1 vulnerability embodied in MS17-010 was. If we use the simplified expression risk = likelihood * impact, and people with great technical chops and credibility are saying likelihood is high, then all we must do is determine the potential impact. Then, we can evaluate the risk of not patching, versus the risk to operations for applying a patch quickly, which brings us to…
The SMBv1 vulnerability is a remote code execution vulnerability which is trivial to exploit (code was provided in the NSA / Shadow Broker dump) and allows the attacker to take control of the target system. SMB is an application layer protocol used by Microsoft systems to provide access to file shares, printers and some other resources. The version exploited is version 1, which was superseded by version 2 in 2006, and version 3 (actually 2.2, renamed to 3 in 2012).
As old as version 1 is, it’s still turned on by default for backward compatibility in most versions of Windows. It’s unrealistic to assume that everyone should have known better and turned this “off” long ago (though there were signs that it was not something you wanted “on” somewhat earlier). Instead, anything remotely like SMB or CIFS-based filesharing should always be safely behind firewalls and inaccessible to Internet-based attackers. Several systems were found to be on the Internet and vulnerable during this attack, which any decent vulnerability scan should have brought to light. Even this however, wasn’t how most networks were compromised.
WannaCry follows in the footsteps of many recent attacks in just assuming that, provided a plausible phishing email, a small percentage of people will click on just about anything and that people have been conditioned to keep clicking until they succeed in executing whatever is in front of them. User training is certainly key to overcoming this human tendency, but it generally only results in short-term security gains. Many of the victims of this attack surely thought that their preventive controls were good enough. However, if you rely solely on preventative controls, be they administrative, technical or physical, there’s a long history of those controls – even the exact controls you are using — failing. This is a basic fact of the cyber-arms race, and one that will likely remain true for many, many years.
Speaking of controls and control failure, we (briefly) lucked out with WannaCry. A malware analyst who goes by the name, “MalwareTech” discovered a domain that the malware checked-in with, but was currently not-registered. He registered the domain, in order to understand what the check-in behavior might be and discovered that when properly done (with an actual answering server), it acted as a kill switch for the malware, resulting in no post-infection activities. This was helpful and interesting, but nearly immediately resulted in a version with no kill switch being deployed. Number Four is really about all of the folks that read enough about the kill switch to see the domain name, and then helpfully blocked that domain at the ISP or DNS server level. This action however, had the opposite effect, which was to deny access to the existence of the ‘killswitch’ domain that could have prevented file encryption and subsequent extortion attempts from occurring.
If your systems are monitored by Critical Informatics’ Managed Detection and Response service then you are sitting pretty. We were aware of the growing infection rates early on through professional connections, active intelligence and other means. As soon as it was clear which vulnerabilities were in-play, we modified our detection mechanisms to ensure that we would see some or all of the malware’s activities if your preventive controls failed (See Number Three.) We have techniques for finding “highly entropic” domain names, specific domains as they become known as well as more sophisticated proprietary detection algorithms which weren’t even needed for this particular attack. This is/was easy to spot so far, and good detective controls, tied to activation incident response provide the highest levels of security.
More malware is surely coming, and there will be no simple kill-switch. Work to ensure your organization is applying these lessons-learned and if you have any questions or need support, don’t hesitate to reach out to us HERE.