On May 12th 2017, reports began surfacing that a virulent ransomware attack, which takes advantage of a number of known vulnerabilities in unpatched Microsoft Windows systems to encrypt files on file shares, was spreading around the world. The initial compromise vector was like any other attack, in that it requires user action, but then it takes off on its own.
Unless you’ve been hiding under a rock since the 12th, you’ve likely already heard about the basics of this attack. This piece is not about those details, which you can read about elsewhere, but rather about the key reminders of the basics of cybersecurity and lessons learned from this attack.
1. Patch Your System
Every technical vulnerability exploited has been patchable for up to two months for MS17-010 (Published March 14, 2017). There are no zero-day exploits involved in this attack. Two months ago, when the (apparently) NSA-derived tools were released by Shadow Brokers, Microsoft had already patched some of the more potentially damaging vulnerabilities, exactly one month before.
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 professionals 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 next recommendation.
2. Protect File-Sharing
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.
3. Go Beyond the Preventative
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.
4. Domain Blocking isn’t a Quick Fix
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.
5. Active Network Monitoring is Always Your Best Bet
If your systems are monitored by Critical Insight's 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’ve been looking for instances of MS17-010 exploitation via signatures for almost two months now on every network we monitor. 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.
The Sequel is Coming…
The second wave of this attack is surely coming, and there will be no simple kill-switch. Even given the ability to assess risk and prioritize patching-exposed services that are clearly likely to be attacked, many systems simply cannot have the necessary modifications applied. Industrial control systems, mobile data terminals for law enforcement and public safety, financial, medical and other technologies have extreme operational requirements, and vendors do not certify new operating systems with any regularity; nor do they typically perform the regression testing that would allow routine patching while maintaining guarantees of operation. This means that there are very few network-internal solutions that can be applied to shore up systems against the next wave of this attack.
If you’d like to ensure you are protected from future versions of this attack as well as a wide array of other cyber threats, contact us here.
