Many years ago, I read a fascinating article from 1948 in which various travel writers predicted the air travel experience of 1984.* In reading the article, I remember being surprised both by what they got right and what was off base. Namely, the article made no mention of airport security. By today’s standards (like the standards of 1984), this might seem naïve and even reckless. But recall that the article was written for a bygone world – one that tells us more about the world of 1948 than the one of 1984. It was written for a reality that no longer exists, in a time and place in which security was simply not top-of-mind yet.
Sound familiar? We’ve just been looking backwards from 1984 – now look forward. Were the computing realities of 1984 not unlike the physical realities of 1948? Could the protocols and practices of computing’s bygone age possibly have anticipated today’s security realities? Of course not.
Hey folks, it’s Jon again with this month’s installment about the Visual Auditing Security Tool (Project VAST). Today I’d like to introduce a new VAST capability we have created in direct response to multiple customer and internal requests. Today I want to discuss Project VAST and SMB1.
Quick Review: What is SMB
For our project, we don’t need to spend very much time on how SMB works. My colleague and an owner of SMB at Microsoft, Ned Pyle, has written extensively on the subject (start here). Note that Microsoft has implemented three versions of SMB over the years; SMB2 and SMB3 are much more secure than SMB1.
The good news is that supported operating systems will use SMB2/3 by default. The bad news is that your out-of-support computers (you definitely don’t have any of those, right? ![😊]()
), such as Windows XP and Server 2003, support only SMB1. And as is the case with so many other deprecated protocols, your overall security posture may very well be being set by these outdated computers and applications. This is not a good situation. (To be clear, there is no way to use SMB1 securely – at least not at the protocol level. To be very clear, if you are running out-of-support Operating Systems in your production environment, then SMB1 support is but one of the many security pratfalls you face.)
The other places that SMB1 may be coming from are outdated (or not updated) printers and multi-function devices. If you have devices on your network that require SMB1, then it’s time to have a heart-to-heart with the vendor or the team requiring their use. Ned and team publish a clearinghouse of SMB1 products here.
Digging a bit deeper – what’s the specific problem with SMB1?
If you’re convinced and just want to learn how to remove SMB1 without wrecking your environment, skip to the next section. But if you’d like to learn a bit more, read on. The security built into SMB2 and SMB3 is primarily around protecting against security downgrade attacks (Pre-authentication Integrity, Secure Dialect Negotiation) and attacker-in-the-middle attacks (Encryption, Insecure guest auth blocking). SMB1 simply doesn’t know about or contain any of these protections.
Worse yet, if you have SMB1 enabled on your file servers or (worse, worse yet) your domain controllers, then an attacker-in-the-middle can simply block SMB2/3 and force a downgrade attack. The net effect here will be that your computer(s) will gracefully and happily flip over to SMB1, thereby exposing the exchange’s data.
As if this all weren’t scary enough, the world experienced several massive ransomware attacks with SMB1 components last year. Petya/WannaCrypt and their variants marked a sea change in their use of rapid destruction combined with credential theft.** From the Microsoft Secure blog:
[Petya] ransomware drops a credential dumping tool (typically as a .tmp file in the %Temp% folder) that shares code similarities with Mimikatz and comes in 32-bit and 64-bit variants. Because users frequently log in using accounts with local admin privileges and have active sessions opens across multiple machines, stolen credentials are likely to provide the same level of access the user has on other machines.+
In addition to impersonation via stolen credentials, Petya/WannaCrypt also leveraged an EternalBlue exploit to utilize the ticking timebomb of SMB1 to worm through the environment.
One piece of good news is that MS17-010 solved this specific exploit. But we will almost certainly see other SMB1 exploits in the future.
Okay, I’m convinced – what to do about SMB1?
Unless you’re in the rare position of knowing exactly the sources of your SMB1 traffic, we need to start with auditing. Beginning in Windows 10 and Server 2016, and back-ported via an update to Server 2012 R2 and Windows 8.1, Microsoft made SMB1 auditing available. To enable SMB1 server-side auditing, you’ll run the following PowerShell command:
Set-SmbServerConfiguration –AuditSmb1Access $true
To set auditing on a group of servers or across a large swath of your environment, export a list using PowerShell or LDIF. And then run something like this:
$computers = Get-Content "c:SMB_computers.txt" foreach ($computer in $computers) {Invoke-Command -ComputerName $computer -ScriptBlock {set-smbserverconfiguration -auditsmb1Access $true -Force}}
(In this example, SMB_computers.txt is the list of your exported computers or server to targets.)
This will set auditing for the Applications and Services LogsMicrosoftSMBServerAudit hive. Specifically, Windows will write a simple EventID 3000 for each and every time that a client attempts to access the server using SMB1. As shown below, you will log the IP address or hostname of the client. You will then need to don your best Sherlock Holmes cap and figure out what is using SMB1 on the client. Finding out is typically not very hard.
![]()
As with other protocols, this logging presents several immediate problems. Natively, you will have to hop between servers to check the event logs. Depending upon the amount of SMB1 traffic you are seeing, you may be able to employ technologies like Windows Event Forwarding (WEF) to aggregate the log data. However, there’s a high probability that you will need more than just aggregation to deal with the sheer number of log events that you’ll be generating. And that’s where Project VAST comes in.
Enter Project VAST
As we’ve discussed in previous blog entries, we need to deal with this data in two ways. First, we clearly need to aggregate it and then we need to make the SMB1 big data set consumable and truly actionable.
We’ll start, as we always do in Project VAST, with Azure Log Analytics. Once we have EventID 3000 aggregated in Azure, we can create Kusto queries to view the data and control the output.
![]()
Notice a couple of things here. First, Azure Log Analytics combined with the Kusto query language makes this data highly extensible. With a single line, we can pull the ClientAddress attribute out of the common ParameterXml attribute.
Second, notice on the right-hand side, this query returned almost 7,500 records in just seven days of data. Even with some creative Azure Log Analytics queries, we may need to employ another step to render our data truly actionable. After all, recall that a central guiding principle of Project VAST is to provide the ability to make well-informed, data-centric decisions about security budgets.
A Closer Look
Let’s take a look at Project VAST’s new SMB1 tab. Recall that here we are exporting the Kusto query out of Azure Log Analytics and importing it into Power BI. This configuration allows Power BI to query Azure Log Analytics directly with no need for intermediary data sources. The SMB1 tab in Project VAST allows us to visualize the EventID 3000 data and filter the display in a number of ways.
![]()
Let’s start examining this tab in the box in the upper left. The box entitled SMB1 Traffic Flow (Top 5) is a visual representation of the top five largest SMB1 flows in the data set. In other words, this box shows us where to start. Notice that we have four IP addresses and a loopback address responsible for this SMB1 traffic. Because we enabled logging for SMB1 (and not 2 or 3), all of this traffic is part of our problem. We want this data addressed so that SMB1 can be removed, with haste, from our organization’s infrastructure.
Clicking on any one of these data flows will filter the other panes on the screen to only reflect that data flow filter. For example, clicking on the largest of the IP addresses, 192.168.2.57, would filter the data set to only reflect the flow from this IP address against Server2.Contoso.com (the server it is hitting).
We could also filter by ClientAddress or SMB Server in the boxes directly to the right. Or, below those boxes, we could also filter on the SMBv1 traffic flow by Destination. In fact, this is where I tend to start with customers. Without even filtering this sample data set, we see that Server1.Contoso.com is by far the largest offender for fulfilling SMB1 data requests. Let’s click on it and display only the SMB1 data going against this Server, Server1.
![]()
Clicking on it greys out the other SMB1 flows in the data set. SMB1 flows hitting Server1 are now the only ones in scope. This is reflected in the box we looked at originally -- the one that represented SMB1 client-server traffic flows:
![]()
At this point, we have a specific, actionable set of SMB1 client computers to investigate and remediate; in other words, we have now actionable data.
Our investigation here would quickly lead us to the clients making SMB1 calls against Server1 and then against other servers. It is likely that either the clients or something running on them are responsible for requiring the use of SMB1.
It is also possible that the server itself is demanding SMB1 usage through misconfiguration (I’ve seen that several times). This is all the more reason to remove SMB1 from the environment, and then to disallow its use globally.
If you have read my previous blog entries on Project VAST, the process should be becoming familiar to you. We have now surfaced a major vulnerability with SMB1 and can now take action to mitigate it. This is a central story to any modern and thoughtful security journey. Once we’re satisfied we’ve mitigated SMB1 traffic, then by all means we will disable it in the environment.
That wraps it up for Project VAST and SMB1 auditing for now. Good luck, let us know how we can help and, as always, happy auditing.
*If I get my hands on the article, I will post a link.
**Thanks to my friend and colleague Mark Simos for this insight.
+https://cloudblogs.microsoft.com/microsoftsecure/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/
), such as Windows XP and Server 2003, support only SMB1. And as is the case with so many other deprecated protocols, your overall security posture may very well be being set by these outdated computers and applications. This is not a good situation. (To be clear, there is no way to use SMB1 securely – at least not at the protocol level. To be very clear, if you are running out-of-support Operating Systems in your production environment, then SMB1 support is but one of the many security pratfalls you face.)
