Avatar

Watch the threat landscape long enough, and you’ll see that some things are cyclical. Threat types and attack methods fall in and out of fashion. As the use of one vector declines, another increases in popularity.

Take network shares for instance—the technology that allows users to share files and folders over a network. Network shares have been a popular target of computer worms, but their popularity waned in recent years, overshadowed by high-profile attacks that used email and compromised websites.

This all changed about 18 months ago. As WannaCry cut a path of destruction across the threat landscape, attention was drawn back to network shares, and in particular a popular protocol central to many: Server Message Block (SMB).

You may think WannaCry is ancient history in the fast-changing threat landscape. The shock has certainly passed, but that doesn’t mean the mechanisms that helped it spread aren’t still in need of attention. If anything, WannaCry has shown SMB to be a weak point and returned it to prominence, as attackers have continued to leverage it regularly.

For instance, multiple SMB intrusion detection rules, used by our Next Generation IPS appliances, consistently rank in the top ten. It’s no surprise either, as port 445—the primary port used by SMB—is often left open. In fact, a quick search on shodan.io returns more than 2 million devices with the port open (link requires login).

Overall SMB-related activity is consistent. Looking over a two-month stretch of Cognitive Intelligence telemetry, covering October through November 2018, we see a fairly stable pattern emerging for SMB port activity on endpoints. This indicates regular use of SMB as an attack vector.

Of course, it’s worth calling out the spike in incidents that we see beginning on November 13th. This coincides with the release of a security advisory detailing a vulnerability that could be remotely triggered through SMB. While we can’t say for certain if these are malicious attacks, penetration testers testing a newly disclosed vulnerability, or both, what is clear is that SMB garnered some activity as a result.

SMB’s origin story

From a user’s perspective, the beauty of a network share is the seamless experience. You can access or copy files to and from a remote computer just as though they were on the local machine. You don’t even need a server to communicate between the computers—they can connect directly.

 

Historically, SMB was one of the most popular protocols used to facilitate such shares. Much of its popularity can be credited to Microsoft’s adoption, implementation, and investment in the protocol, beginning in the early 1990s. Setting up and using SMB on Windows was easy, requiring very little configuration, and worked for a variety of purposes. Not only could you share files and folders, but also printers and other devices.

There’s no question the SMB protocol helped to get many internal networks off the ground. However, that ease of use had a darker side: the protocol required little-to-no authentication or encryption. Its security did improve in later versions, but thanks to backwards compatibility, older versions continued to work long after they had been called out for their insecurity.

The protocol became a natural target for hackers looking to traverse a network, since it connected computers directly. The same applied for computer worms, which spread by jumping from computer to computer. So, while not always the first choice of vectors, SMB was a tool in a malicious actor’s belt. However, this changed with news of a critical vulnerability in SMB.

The SMB1 protocol, alongside other outdated 90s tech.

EternalBlue comes to light

Vulnerabilities, worms, and SMB all came to a disastrous intersection in 2017. A major flaw in SMB version 1 (SMB1) had been discovered, dubbed EternalBlue. This exploit opened the door for a malicious actor to install malware on any computer running SMB1.

EternalBlue was released to the public by a hacking collective known as the Shadow Brokers. As the severity became apparent, Microsoft released an out-of-band patch for the vulnerability—MS17-010—to cover all supported versions of Windows.

In an ideal world, everyone would have patched, and the story would end here. Unfortunately, the divide between principle and practice is wider than that. Patches take time to roll out, and unfortunately, MS17-010 covered supported versions of Windows exclusively. Machines running non-supported versions of Windows remained vulnerable.

WannaCry breaks loose

May 12, 2017 seemed like any other Friday. That is, unless, you were partway through your workday and suddenly your computer displayed this:

WannaCry spread like wildfire, tearing through vulnerable computers, thanks to the EternalBlue exploit. If SMB1 was enabled, WannaCry was able to exploit it without any action from the user, install its ransomware payload, look for more computers with SMB1 enabled, and infect them.

WannaCry managed to cause serious problems for governments and industries around the world, crippling large healthcare, automotive, telecommunication, and transportation organizations. In an unprecedented move, Microsoft even released a patch for end-of-life versions of Windows, such as XP.

Nyetya’s 1-2 punch

If WannaCry was a left jab, then the Nyetya worm was a right hook that landed a month later. Initially pushed out through a supply chain attack, Nyetya used EternalBlue to spread. Nyetya also leveraged a second SMB-related exploit, dubbed EternalRomance, which more reliably compromised older Windows versions.

At first glance, WannaCry and Nyetya seem similar: They both spread through SMB and encrypted computers, rendering them unusable. However, while WannaCry’s payload was ransomware, Nyetya only masked itself as such. In reality, it was wiper malware. It displayed a ransomware-esque message, but there was no way to pay. Once a system was infected by Nyetya, it was toast.

It’s not just exploits

These two examples show the dangers of using vulnerable networking protocols, as well as the importance of patching systems. However, SMB has been just as attractive to attackers even without an easy-to-abuse exploit.

While threats such as SamSam, Bad Rabbit, and Olympic Destroyer used different tools to gain access to networks, once inside they leveraged SMB to traverse them. There have also been cases where data breach were achieved using brute-force attacks against SMB shares, where attackers used tools to enter share passwords over and over again, in the hopes of guessing correctly.

What to do about SMB

So how do you protect against SMB-related attacks? Simple: stop using it. There are few reasons to continue to use it today. In fact, as of April 2018, the protocol no longer comes preinstalled in Windows.

Instead of sharing files by linking computers via SMB, use a dedicated file server or a cloud-based offering. Configure network printers to use other protocols. If you cannot turn off SMB in your environment, at least ensure SMB1 is disabled. Block TCP ports 445 and 139 at the network boundary to ensure SMB communication is limited to the internal network. Beyond that, endpoints should not be able to communicate with one another via SMB.

In addition, consider the following:

  • Stealthwatch can detect connections to SMB shares, correlating this activity to alert administrators.
  • AMP’s continuous monitoring and patented retrospective security capabilities are ideally suited to keep you safe against attacks such as WannaCry and Nyetya.
  • Network Security appliances like NGFW, NGIPS, and Meraki MX can detect malicious activity associated with SMB attacks.
  • Threat Grid helps identify malicious file behavior and automatically informs all Cisco Security products.

One thing that is for certain is attackers will exploit the path of least resistance. Remove SMB from your network, and that’s one less tool for the attackers to leverage, permanently ending its cycle as a threat vector.

 

Want to read more about threat intelligence? Subscribe to the Threat of the Month blog series and get alerted when new threats are identified. 



Authors

Ben Nahorney

Threat Intelligence Analyst

Cisco Security