•  Oxford: +44 (0)1865 877830 
  • Manchester: +44 (0)161 713 0176 
  •  London: +44 (0)203 5983740 
  •  New York: +1 646-781-7580 
  • Dubai: +971 (0)4 427 0429

Do You WannaCry? A Taste of SMB Exploitation

You are here



Do You WannaCry? A Taste of SMB Exploitation

On Friday, 12th May 2017, an unprecedented ransomware attack, named WannaCry infected more than 230,000 computers in 150 countries and a number of large organisations such as the NHS, Telefónica, FedEx and Deutsche Bahn were among them.

WannaCry spreads across local networks and infects systems that have not been updated with recent Windows security updates (MS17-010). The vulnerability was exploited using the EternalBlue exploit developed by the U.S. National Security Agency (NSA), which was released by the Shadow Brokers hacker group two months before.

The Shadow Brokers Releases

The EternalBlue is one of the exploit released by the Shadow Brokers that is abusing a weakness in the Server Message Block (SMB) protocol. It has to be noted that a number of other exploits were also made publicly available which also rely on weaknesses in the older versions of the SMB protocol as shown below:

ETERNALROMANCE: SMBv1 exploit for Windows XP, 2003, Vista , 7 Windows 8, 2008 and 2008 R2, which allows to get SYSTEM privileges.


EMERALDTHREAD: SMB exploit for Windows XP and 2003.

ERRATICGOPHER: SMBv1 exploit for Windows XP and 2003.

ETERNALSYNERGY: remote code execution exploit through SMBv3 for Windows 8 and 2012.


ETERNALCHAMPION: SMBv2 exploit tool.

SMBTOUCH: SMB reconnaissance tool.

ARCHTOUCH: SMB reconnaissance tool.

It is also quite interesting to notice that SMBTOUCH can check if a targeted system is vulnerable to ETERNALSYNERGY, ETERNALBLUE, ETERNALROMANCE exploits, and this would eventually allow the automation of traversing inside the infected network, known as the "worm attack" similar to the famous Stuxnet malware propagation (that was a combination of SMB and RPC protocols exploitation).

What is SMB?

Essentially, SMB is the network protocol that manages communications for Windows based systems to handle things such as domain/network authentication, network file shares, remote administration, and printer sharing.

The Different Versions of Windows SMB

The following list shows each different version of SMB in use from legacy until up-to-date versions of Windows operating systems:

CIFS: The ancient version of SMB that was part of Microsoft Windows NT 4.0 in 1996. SMB1 supersedes this version.

SMB 1.0 (or SMB1): The version used in Windows 2000, Windows XP, Windows Server 2003 and Windows Server 2003 R2.

SMB 2.0 (or SMB2): The version used in Windows Vista (SP1 or later) and Windows Server 2008.

SMB 2.1 (or SMB2.1): The version used in Windows 7 and Windows Server 2008 R2.

SMB 3.0 (or SMB3): The version used in Windows 8 and Windows Server 2012.

SMB 3.02 (or SMB3): The version used in Windows 8.1 and Windows Server 2012 R2.

SMB 3.1: The version used in Windows Server 2016 and Windows 10.

The version of SMB used between a client and the server will be the highest dialect supported by both the client and server. This means if a Windows 8 machine is talking to a Windows 8 or Windows Server 2012 machine, it will use SMB 3.0. If a Windows 8 machine is talking to Windows Server 2008 R2, then the highest common level is SMB 2.1. To check which dialect version is in use, the following PowerShell cmdlet can be used which will show the SMB connections and the dialect used. This could help IT administrators to assess which version of SMB is needed on their network and which ones need to be removed.

Get-SmbConnection or gsmbc


ServerName    ShareName     UserName     Credential   Dialect      NumOpens
----------    ---------     --------     ----------   -------      --------
servertest01  c$            TESTUSER...   TESTUSER... 2.10         1
servertest02  c$            TESTUSER...   TESTUSER... 3.00         1
servertest03  sharedfolder  TESTUSER...   TESTUSER... 3.00         1

Notice that in this example the connections established from a Windows 10 host to the servers servertest02 and servertest03 (which are Windows Server 2012 servers) are using SMB version 3.0, while the connection from the same host to servertest01 (which is a Windows Server 2008 R2 server) uses SMB version 2.1.

While we are mentioning the different SMB versions note that SMB 1.0 is not secure as it allows security features to be bypassed that are implemented in it and, therefore, should not be used at all. However it might be the case where outdated operating systems are still in use on the network (such as Windows XP or Windows server 2003). These hosts should be decommissioned or isolated as soon as possible so that the security of the whole network is not compromised. For further information refer to the following article from Microsoft, which provide details on how to avoid downgraded connections that can lead to compromise of the earlier version of SMB in use:


It has to be noted that for compatibility reasons SMBv1 is enabled by default on Windows 10 and Windows 2016 Server and therefore it is recommended to disable it before deployment in the production network.

Compromising Windows by SMB Exploitation

Among the best known remote code execution (RCE) exploits on the Windows platform, MS08-067, MS09-050 and MS10-061 are the ones that quickly come in mind to any attacker familiar with Windows exploitation. Therefore, and from now on, attackers will add the EternalBlue exploit (MS17-010) to their toolkits for harvesting low hanging fruit on unnecessary services directly exposed on the internet. As these vulnerabilities and exploits are well publicised, it gives an attacker a simple exploitation path leading to remote code execution on unpatched Windows systems, so as a general recommendation make sure that all of your systems are patched in a timely manner and that you are not exposing unnecessary services on the internet.

Further information to verify if the patch for MS17-010 has been successfully installed on your machines, please read the following article:


Spear Fishing by Redirecting to SMB

Please note that SMB does not only suffer from unpatched versions, there is also another decade-old vulnerability called the SMB redirection attack. This can be effectively used in spear phishing, and is worth mentioning due to its age and its fairly simplistic but efficient and straightforward exploitation.

When a computer running Windows uses SMB to attempt to access a resource, it will attempt to authenticate with the user's encrypted login credentials to the remote SMB server. One attack is to use spear phishing in which a victim is tricked in to clicking a link, which will then attempt to authenticate against the attackers server via SMB by forcing a redirection from the internet to a SMB server.

As a reminder it might be useful to mention that in order to access files on a Windows host the following path patterns can be used:

1) The URI Scheme:

For a network location:


Or for a local file, the hostname is omitted, but the slash is not (note the third slash):


2) The UNC path:


The Windows operating system will interpret requests to these paths as requests to the remote SMB server, and unless securely configured, will attempt to connect and authenticate with the SMB server running as the current user. This means a vulnerable application, despite having no access to the current user's credentials, can lead to an authentication attempt with an SMB server controlled by an attacker as demonstrated in the following example:

SMB Redirection in Chrome

Despite this vulnerability being old, recent attacks rely on the same principle that uses SMB redirection. For instance, users of Google Chrome has been some of the latest to be affected where a victim's password could be harvested by using a malicious shortcut file. This files that contains special Windows Explorer commands would then be executed while Windows Explorer would interpret the commands embedded in the shortcut. Once it has been downloaded and browsed to, it would automatically force the victim's host to attempt to connect to a remote SMB server controlled by the attacker.

See the following URL for further information:



Sufficiently protecting against SMB attacks would have to be part of a layered approach in security. SMB should not be required externally, for systems exposed on the Internet SMB traffic should be blocked. Organisation machines being used offsite should have fine-grained rules to block SMB when in public places.

As SMB is required internally for most of the organisations, this has to be enabled. To further protect this, and reduce the risk of malware spreading internally, SMB traffic should be only allowed in between the systems requiring it following a whitelist approach, if possible. Additionally, if SMBv1 is not specifically required, this should be disabled. The following link from Microsoft provides further details on disabling SMB.


Patching quickly in a central and consistent manner is vital in this case, as SMB is a protocol being actively targeted by attackers. Additionally, carrying out periodical vulnerability scans would aid organisations in identifying systems which are missing crucial SMB patches, as well as reviewing firewall rules to ensure that no unnecessary services are exposed. Finally, organisations should consider providing phishing and information security trainings to all their staff.

Posted by Matt

Leave a comment