How to detect SMBv1 use on your Network
How can I find out if SMBv1 is being used on my network?
Even if you disable SMBv1 on all clients and servers, it is still good practice to check if any systems on your network are using this protocol. You may have un-managed systems like personal laptops or embedded operating systems within other network-connected devices. These are the most common ways to find out if SMB1 is in use on your network:
- Use a network traffic analysis system connected to a SPAN, mirror port or network TAP to monitor traffic associated with your file servers
- Run Get -SmbConnection on a client
- Scan your network using a vulnerability scanner
- Take a packet capture off the network and use Wireshark to identify what version of server message block you are running
What is SMBv1?
Server message block (SMB) is an application layer network protocol used typically to provide shared access to files and printers. It is also known as Common Internet File System (CIFS). Most data is transferred via TCP port 445 although, it also uses TCP port 137 and 139.
SMB was first used in Windows operating systems around 1992. Windows Server 2003, and older NAS devices use SMBv1 natively. It is a very inefficient protocol; Microsoft have advised all customers to stop using SMBv1. SMBv2 was introduced with Windows Vista in 2006 and the latest version is SMB 3.1.1 which was introduced with Windows 10 and Windows Server 2016.
Why all the attention about SMBv1?
In May 2017, the WannaCry Ransomware started to infect computer networks around the world. It was the first in the family of WannaCrypt Ransomware which targeted both locally stored data and network based file shares. It has become a huge problem, and most IT and Security Managers have made detecting WannaCry Ransomware their top priority.
There are three known attack vectors for WannaCry. Some computers were accessed directly, some people opened email attachments and some were redirected to websites where they downloaded the malware. Direct access is an unusual attack vector and occurred if a network allowed NetBIOS packets from external networks.
Data from antivirus provider Kaspersky Lab showed that 98% of the victims were actually running Windows 7. When the Ransomware first came out it was suggested that it was targeting Windows XP systems but the number of affected Windows XP systems looks to be insignificant.
This could be one reason for the widespread infection seen in this outbreak and why many people are unsure about the initial infection vector of the malware. More the reason why need to know what is going in and out of your network. Not just in real-time but also historically so you can look back and see what happened.
Once downloaded the malicious code in the zip file infects the local computer, which then does two things:
- Encrypts the local filesystem
- Attempts to infect other systems, by exploiting vulnerabilities SMBv1 (EternalBlue)
A further exploit known as DoublePulsar is then used to create a backdoor and inject malicious DLLs into the target system’s kernel. The EternalBlue and DoublePulsar exploits are linked to tools originally developed by the NSA which were recently exposed by the Shadows Brokers group.
Customer Use Case – Is there a way to detect SMB1 traffic?
Way back in October 2016 a US public sector customer sent us this query
“Is there a way to detect SMB1 traffic? Microsoft recommends to stop using it so I’d like to see if it’s being used in our network.
At that time our LANGuardian product could detect SMB traffic and extract metadata such as filenames and actions but it did not capture and store the SMB version. Our product management team looked at this and we decided to modify our SMB decoder to capture the following information
- Capture and store the SMB version of all SMB traffic.
- Generate an alert if a client or server establishes a connection using SMBv1
- Generate an alert if a client tries to connect to another network device using SMBv1
This use case also highlight the flexibility and power of using wire traffic data as opposed to logs to get visibility, to get the critical detail, in this case the SMB version. Some critical details like the SMB version may not be available from logs, but are available via network traffic analysis.
It is worth noting that at the time our customer did not have a Ransomware problem. They were being proactive by dealing with the SMBv1 problem before it could be exploited on their network. This is still very relevant today. Too many networks are still using SMBv1 and IT managers have no visibility into what protocols are being used on their internal networks.
What systems are at risk?
Any Windows system that supports SMBv1 and does not have patch MS17-010 applied is potentially at risk. This is not limited to just Windows Server 2003 and Windows XP clients. As far back as September 2016 Microsoft the removal of SMBv1 from networks. Potentially all Windows clients on your network need to be checked and patched. Publicly available exploit code lists targets as:
- Windows XP (all services pack) (x86) (x64)
- Windows Server 2003 SP0 (x86)
- Windows Server 2003 SP1/SP2 (x86)
- Windows Server 2003 (x64)
- Windows Vista (x86)
- Windows Vista (x64)
- Windows Server 2008 (x86
- Windows Server 2008 R2 (x86) (x64)
- Windows 7 (all services pack) (x86) (x64)
Windows XP and Windows Server 2003 can only support SMBv1. Aim to cease use of these systems on your network, as they are end-of-life and Microsoft does not provide regular updates. The latest Windows 10 indsider build removes the SMBv1 server software. he client SMB1 remains, so that users can connect to devices still using the protocol, but server-side is gone.
What should I do?
Make sure you apply patch MS17-010. Disable SMBv1 on systems that can support SMBv2 and SMBv3. SMBv1 and SMBv3 are much more efficient and will use less network resources. Check your backups, are they running and have you tested restoring data.
To disable SMBv1 you need to run these commands in Power Shell on each system.
- Check for SMBv1
- Get-SmbServerConfiguration | Select EnableSMB1Protocol
- To disable SMBv1 on the SMB server
• Set-SmbServerConfiguration -EnableSMB1Protocol $false
Further information on how to disable SMBv1 on other systems available here. You can also disable SMBv1 via Group Policy preferences. This approach will allow you to configure and enforce the registry settings related to disabling SMBv1 client and server components for Windows Vista and Server 2008 and later.
Checking SMB version on a client
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 10 machine is talking to a 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 you are using, run the the PowerShell cmdlet: Get-SmbConnection
Scan your network using a vulnerability scanner
Various vulnerability scanners may help with this, but need to know which systems to query. Microsoft have released Desired State Configuration Environment Analyzer which is a PowerShell module which can be used to scan a Windows Server 2012 R2 environment to see if any of the systems have SMB1 installed. Further reading in this post which also contains a sample script.
Using packet capture and analysis to detect SMBv1 activity
One of the easiest ways to detect what versions of server message block you are using is to use network traffic capture. You can do this locally on a client or server or use a SPAN\Mirror port. Once you have a source of network packets you need to process them using a network traffic monitoring application.
Microsoft have some guides on how to use their Message Analyzer application to audit active SMB1 usage. Further reading on this page which includes some screenshots of what to look out for. As per the image below, Wireshark can also be used to check for SMB1 connections from live traffic or from a PCAP file. However, WireShark and Microsoft Message Analyzer do not monitor continuously and do not alert.
Should I worry about non Windows operating systems?
The main target for Ransomware is Windows based file shares. However, variants such as KeRanger are designed to target maxOS systems. In recent days the Samba team released a patch (CVE-2017-7494) on May 24 for a critical remote code execution vulnerability in Samba, the most popular file sharing service for all Linux systems.
All versions of Samba from 3.5.0 onwards are vulnerable to a remote code execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it.
There is a high probability that this could be the target of a Linux specific Ransomware variant. It is even trending as SambaCry on Twitter at the moment. According to the Shodan computer search engine, more than 485,000 Samba-enabled computers exposed port 445 on the Internet. The main advice you can take from this is to make sure you patch vulnerable Linux systems and close access to TCP port 445 on your firewall if it is not needed.
What does LANGuardian do and how can it monitor SMBv1 traffic?
Deep Packet Inspection Software can monitor all client network connections and if equipped with sufficiently sophisticated application layer decoders, can determine the version of SMB protocol that is being used. All you need is a data source which is typically a SPAN\Mirror port or network TAP. Our own LANGuardian product includes a deep packet inspection engine which can be used to monitor network traffic on any network that has a managed switch.
LANGuardian can detect, report and alert on the following scenarios:
- A client connection request to any server, using SMBv1 protocol
- A successful connection response from a server using SMBv1
- Any file share actions (file write, rename, read etc) transacted using the SMBv1 protocol
The advantages of this continuous monitoring are:
- Any attempt by an infected client to infect any other system on the network (lateral movement) via SMBv1 can be detected. It is not possible for a client to hide its “network traffic trail”
- Clients do not have to be known by the monitoring system beforehand (so monitors managed and unmanaged devices)
- Detects embedded systems that may not be patched
- No endpoint software is needed such as agents or client software
- Very easy to deploy, simply SPAN or mirror the traffic to and from the file share servers (usually on the same VLAN) to get instant visibility
- No logs are required, no configuration changes or extra load on servers
The video below shows LANGuardian in action and how it can be used to root out SMB1 clients and servers on your network.