SMB1 - Audit Active Usage using Message Analyzer
Well, it’s another weekend and here we are again talking about SMB1. The WannaCrypt Ransomware attacks that impacted customers all over the world have put a spotlight on SMB1, and how important it is to Stop using SMB1. Let’s say you have gone ahead and successfully deployed the security update associated with Microsoft Security Bulletin MS17-010 to all of your systems, but SMB1 is still allowed in your environment. If this is the case, you are still operating at a high risk level and you need to find your path towards completely ending SMB1 usage.
If you haven’t taken the time to disable SMB1 in your environment yet, you need to start working on it right now. If SMB1 is still lingering around because you’ve been fearful that turning it off would break something, you need to take the time to review system level communication in your environment to determine if there are any devices that communicate with your Windows servers that only work with SMB1 and would be negatively affected if SMB1 were removed or disabled. In an environment with only Windows servers (2008 and above), disabling SMB1 should have zero negative impact. Servers will use either SMB2 or SMB3 to communicate via SMB with one another, auto-negotiating to the latest available protocol version.
So, you know what you need to do, but you're not sure if you might break some existing functionality because you don't know if there are devices that connect in to your systems that can only use SMB1. There are a few options that can help in this scenario:
- If you are running Windows 10 and Windows Server 2016, you can use the Set-SmbServerConfiguration cmdlet and the AuditSmb1Access parameter to configure SMB1 auditing by running the command: Set-SmbServerConfiguration –AuditSmb1Access $true (You can then review the Microsoft-Windows-SMBServer/Audit log for any events indicating SMB1 activity)
- Talk to your network or security team to see if there is anything that they can enable on your organization’s routers and switches that can log traffic throughout your environment to see if SMB1 is being used anywhere.
- Perform network captures on systems that you suspect may be communicating with devices that only support SMB1. System design documents can be useful here to point out the expected communication flow for a deployed application. It is also worth noting that end user client systems can sometimes act as SMB servers, so they should be evaluated too and their traffic analyzed if needed. Clients can talk to seemingly innocuous devices that run SMB1, like printers, NAS, manufacturing gear, etc. that themselves aren’t running Windows but Samba/Linux, and they would need to be investigated in some promiscuous fashion.
If you’re like me, you’ll most likely be going with the option 3 network capture, which I will explain in detail below. Overall, your goal should be to disable SMB1 on all Windows systems in your environment, but I recommend that you review server communication in your environment to determine if there are any devices that communicate with your Windows servers that only work with SMB1 and would be negatively affected if SMB1 were removed or disabled. If any devices are discovered that need to communicate with Windows servers over SMB which only support SMB1, further investigation and coordination will be needed before SMB1 is removed or disabled from the Windows servers these devices communicate with to avoid any interruption to service.
To assist with this effort, network traffic can be captured and analyzed using Microsoft Message Analyzer. Message Analyzer can be used to create network trace sessions which can log all inbound and outbound communication on a system. These logs can then be filtered and reviewed to see if there is any active SMB1 traffic happening on the Windows servers in your environment. To filter the logs to only display SMB1 related data, use SMB as a filter within Message Analyzer. If the SMB1 protocol is being used, you will likely see many events in your view, similar to the example shown below.
In the example above, the first message shows the initial negotiation attempt from the client to the server. The summary field shows information from the negotiation, including the available protocols that the client can utilize in its attempt to communicate with the server.
ComNegotiate, Status: STATUS_SUCCESS, Selected Dialect: NT LM 0.12, Requested Dialects: [PC NETWORK PROGRAM 1.0, LANMAN1.0, Windows for Workgroups 3.1a, LM1.2X002, LANMAN2.1, NT LM 0.12]
Looking at this, we see a list of legacy protocols which by themselves indicate that the client in this example only supports SMB1, and if SMB1 was disabled or removed from the server we can expect that the client would start having problems communicating to the server using SMB.
In contrast, the example below showcases the same filtering options, but takes a look at a client that supports SMB1, SMB2 and SMB3.
In this case, we are again looking at the initial negotiation from the client to the server, but we can see additional protocols listed in the summary field that the client can utilize in its attempt to communicate with the server.
ComNegotiateRequest, Tid: 0xFFFF, Mid: 0x0000, Dialects: [PC NETWORK PROGRAM 1.0, LANMAN1.0, Windows for Workgroups 3.1a, LM1.2X002, LANMAN2.1, NT LM 0.12, SMB 2.002, SMB 2.???]
We can see that this client not only supports SMB1 but SMB2 as well at a minimum, and in this example we are looking at Windows Server 2012 R2 system that supports SMB3 as well. If SMB1 was disabled or removed from the server we can expect that the client would have no issues communicating to the server using SMB as it will negotiate up to SMB 2/3, which we can see in the screenshot below that uses the SMB2 filter in Message Analyzer.
After reviewing server communication and performing network captures where required, please disable or remove SMB1 from as many systems in your environment as possible. SMB1 existence can be scanned for by using DSCEA so you can track your progress as you complete this important task.