Hey folks, Ned here again with another guest post. Today we discuss hardening the SMB protocol in Windows against interception attacks, previously referred to as “Man-in-the-Middle” attacks. As you know, interception attacks involve manipulating communications between client and server. An attacker might be eavesdropping, stealing credentials, or diverting a client to an evil endpoint masquerading as a friendly server.
Interception doesn’t always mean attack; a packet-inspecting firewall or a WAN accelerator are both examples of friendly intercepting devices. For the purposes of this blog post though, everything in the middle is an enemy and your goal is to keep your users and organization safe from them. No distributed system protocol security is foolproof; we just want an attacker to move on to easier prey.
This blog post is for IT Pros and Infosec Red & Blue teams working in organizations, not home users. I assume you have basic familiarity with Windows, TCP/IP networking, SMB, Kerberos , NTLM, Active Directory Domain Services, & Group Policy. This post will also become - without the Nedisms and soul-patched bad guy pics – a technical article on docs.microsoft.com next month.
You don’t need to implement all the options I discuss in this post to start seeing tangible results. Information security deployments aren’t a marathon, they’re the preparation for a marathon.
Dang, that was pithy phrasing. Or dumb. Never mind, let’s do this!
Some of the ways an attacker might attack you are:
There’s no single step to prevent all interception attacks on any network protocol other than removing the protocol completely. It's a tough job to secure a distributed system, especially when they otherwise provide value to users and organizations through ease of use at scale. The earth's computing would be much "safer" without the Internet too, but the same way a villain might poison a city's water supply, no one suggests we get rid of plumbing. The goal here is to create a highly discouraging target through layered defenses; don't be worth the trouble of attacking!
Here are ten recommended steps you can take:
I count the last line as two so I can get to the magic 10. Cheeeeaaaatttinnnggg! :)
Ensure that you update Windows clients and servers with Microsoft-supplied security updates released every month to Microsoft Update, Windows Server Update Services, Microsoft Endpoint Configuration Manager, Microsoft Update Catalog) and Azure Update Management. Security updates are your best defense against known SMB vulnerabilities, and you should apply them as soon as your testing and change control process allows. The same goes for your third-party products using SMB; contact vendors for their update methods and patch those appliances and software.
Notice how I am not saying “if you don’t patch that Tuesday, you’re a dumdum.” I am saying patch as soon as you can. Defense in depth gives you the breathing room to deal with patching, big fleets, and technical debt. Notice how I am also not saying “always wait six months,” because I don't depend on ad clicks to live.
Who could’ve seen this one coming? The SMB1 dialect dates to the 1980s with IBM and Microsoft DOS, a time when computer security was non-existent. It has significant architectural issues around interception attacks:
If you don’t know, I’m the grim reaper of SMB1
Solution: Uninstall or disable the SMB1 client on every device in your organization, regardless of their operating system. For Windows devices, review How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server. You should also remove or disable the SMB1 server on every device as an added best practice, as it has its own architectural security issues. Starting in Windows 10 and Windows Server 2019, the SMB1 protocol is no longer installed by default on most editions and is uninstalled automatically if not used on consumer and small business devices. Review the SMB1 Clearinghouse to see if you own any third-party products that require SMB1, then upgrade or replace them.
In Windows’ and other implementations of SMB1, if credentials fail from a bad password, the SMB client will try guest access. This is another legacy artifact of a time before NT and Active Directory domains, where workgroups often used guest access. For interception attacks, a malicious actor creates a server and tricks users into accessing it. The user password will fail, but then guest credentials work and the user connects and accesses malicious files. SMB2 and later also allow this behavior, but unlike SMB1, you can disable it and we did so by default in later operating system versions.
Solution: Disable the use of SMB guest fallback via Windows 10 and Windows Server 2016 and later OSes.
To stop use of guest fallback on Windows devices, configure the following group policy:
Computer configuration\administrative templates\network\LanmanWorkstation
"Enable insecure guest logons" = Disabled
Alternatively, set the following DWORD registry value:
Starting in Windows 10 Version 1709 Enterprise Edition and Windows Server version 1709, guest fallback is off by default. Windows 10 and Windows Server 2016 were the first to support this option.
Windows itself has not enabled guest authentication in the SMB server component since Windows 2000 and connections to a Windows server will never use guest unless an administrator intentionally enabled it. Many third-party SMB server implementations and devices allow this guest behavior however, and worse, many consumer storage devices intentionally rely on guest for "ease of use." Nothing like someone's photos folder on unsecured Wi-Fi with no SMB password.
The Web Distributed Authoring and Versioning (WebDAV) protocol is a 1990s extension to HTTP for file access defined in IETF RFC 4918. Windows implements WebDAV via the "WebClient" service. When using WebDAV, access to a UNC path is converted to HTTP to allow access to a web server, exposing files. A server may implement HTTPS WebDAV, but many do not and by default the Webclient connects to HTTP/80 instead of HTTPS/443 unless a user specifies "@SSL" on the end of their server name in the UNC path.
It's not possible to reliably upgrade the connection to TLS because many servers will not have certificates configured or even supports WebDAV over HTTPS. This means that most WebDAV connections for UNC paths are unencrypted. It’s also possible for a client to be configured to require SMB signing or encryption, then encounter a WebDAV-enabled server on the local network which does not allow either, which then forces the Windows client to downgrade to an unencrypted WebDAV connection.
Solution: Disable the WebClient service in Windows.
To stop use of WebDAV on Windows devices, configure the following Group Policy Preference:
Computer configuration\Preferences\Control Panel Settings\Services
Service Name: Webclient
Service action: Stop service
Alternatively, you can use an elevated PowerShell session:
Set-Service WEBCLIENT -StartupType DISABLED
On Windows Servers, WebClient is a removable feature, called the "WebDAV Redirector". You can uninstall it with Windows Admin Center, Server Manager, or Powershell. It’s not installed by default.
Note: enabling UNC hardening (see below) also prevents the use of WebDav. Two birds and all that.
Any kind of trick that sends a user to an evil destination server – like emailing them UNC links or dropping shortcuts into friendly SMB shares – counts as an interception attack in my book. One of the best defensive measures you can make is ensuring there’s no way to get redirected to a malicious server in the first place, by controlling your Defender and edge firewalls.
Solution: Follow the guidance I provided in Beyond the Edge: How to Secure SMB Traffic in Windows to stop access to server that aren’t specifically part of your org. That’s it, that’s the whole solution. :)
UNC Hardening is an SMB security option added in 2015 to Windows Vista/Windows Server 2008 and all later OS versions. It changed the SMB security model to start using client-defined security requirements instead of legacy server-defined requirements. UNC Hardening added the ability to check UNC paths for mandated security settings and refuse to connect if a server could not meet them. It's a highly effective tool against redirection attacks because the client can authenticate the identity of the server to block spoofing attacks as well as guarantee SMB payloads aren't tampered with or read, and refuse to connect.
Solution: Enable UNC hardening for some or all SMB shares in your environment, using the steps in KB3000483 under section "Configuring UNC Hardened Access through Group Policy". You can specify a variety of UNC path patterns:
For your list of servers using SMB you might want to refer to my earlier post on Beyond the Edge: How to Secure SMB Traffic in Windows.
You should require at least mutual authentication (Kerberos) and integrity (SMB signing), and you should evaluate using privacy (SMB encryption) instead of signing. Only SMB 3.x supports encryption; don’t require encryption unless all your machines are at least Windows 8 and Windows Server 2012 or are third parties with SMB 3 and encryption support. Requiring Kerberos doesn’t prevent an attempt at NTLM, so keep reading below.
There’s no need to configure both signing and encryption in SMB; encryption implicitly includes those signatures, and the SMB client ignores orders to do both. For more information on how UNC Hardening works, review MS15-011 & MS15-014: Hardening Group Policy.
Note: Windows 10 and Windows Server 2016 first enabled UNC Hardening by default for all shares named "SYSVOL" and "NETLOGON," requiring mutual authentication and integrity when connecting. If neither of these share names mean anything to you, crack those AD books.
SMB 3.1.1 first shipped in Windows 10 and Windows Server 2016 and it includes a new mandatory security feature called pre-authentication integrity. This protects against any tampering with Negotiate and Session Setup messages by using cryptographic hashing, which enables the client and server to mutually trust the connection and session properties. This new feature supersedes “secure dialect negotiation” introduced in SMB 3.0. In simple terms, it signs or encrypts the early phases of SMB connections that define security capabilities later. You can’t turn pre-authentication integrity off, but if a client uses an older dialect, it won’t be used.
Solution: Ensuring all your devices and virtual machines in your organization support SMB 3.1.1 is the first step; Windows always negotiates to the highest available protocol and is going to use 3.1.1 if the server allows it.
But you can take this further by mandating the latest dialect. I describe this in Controlling SMB Dialects, which means setting two DWORD registry values:
Remember that your environment isn’t just Windows. If some third-party device or software in your org doesn’t support SMB 3.1.1, requiring that dialect will break them. This is another candidate for Group Policy Preferences configuration of your fleet.
Windows versions 1709 and later went a bit further and allow you to create encrypted or signed mapped drives on the fly from the command-line. While this is outside the reach of the average user, it’s a great option for logon scripts and admins.
Solution: Map drives that require signing or encryption. You can use the NET USE command or New-SmbMapping PowerShell cmdlet to map drives by specifying “RequireIntegrity” (signing) or “RequirePrivacy” (encryption).
This feature doesn’t change how signing or encryption work or the dialect requirements. It just means that if you try to map a drive and the server refuses to honor your requirement for signing or encryption, the drive mapping will fail. The idea being that it’s better to not connect than connect unsafely.
Finally, we come to the one solution that’s not about SMB at all: preventing the use of the unsafe legacy NTLM protocol and all its variants, then increasing Kerberos’ default security. If you really want to stop harvesting of credentials, pass-the-hash, SMB relay and that entire class of attacks that are really about the security provider and not the network protocols used, you need to end your use of NTLM. It’s not always easy, but it is certainly easier now than when I first discussed this option 11 years ago. Furthermore, if you want to prevent more sophisticated attacks like pass-the-ticket and Kerberoasting, you’ll need to increase your Kerberos security defaults.
11 years ago, ohnoes, I am so old.
Solution: Restrict or stop use of NTLM, then increase Kerberos security.
For NTLM, this means auditing your environment to find which clients and applications are using NTLM and either reconfiguring them to use Kerberos (because it was a mistake, like using IP addresses) or upgrade them. Windows has a full event log auditing mechanism for client, server, and domain controller NTLM usage. You can assess your usage by enabling that auditing mode, reviewing logs, and start turning NTLM off in a controlled and staged fashion. One option that wasn’t available when I wrote that blog post in 2009 is Azure Sentinel and its insecure protocols dashboard. If you have a Premier contract with us, dive into that option instead of doing things by hand. And it finds SMB1 too!
For Kerberos, this means adding increasingly effective protection layers for offline and ticket passing attacks:
If you’re not already planning your Windows Hello rollout, it’s time to get hot.
Like all security plans, you are on a journey that's unlikely to end. Your goal is to get secure enough make your environment is very unpleasant to attack. SMB is a hugely important protocol through Windows, Mac, Linux, storage, devices, and mobile. It is transporting the only thing your organization cares about in computing: data. You know, the “I” in "Information Technology.” Securing it from most interception attacks is likely to secure from practical attacks for all but the most demanding threat models.
If you’re interested in learning more about how SMB signing and encryption work, I highly recommend Edgar Olougouna’s SMB 2 and SMB 3 security in Windows 10: the anatomy of signing and cryptographic keys and SMB 3.1.1 Pre-authentication integrity in Windows 10. Edgar leads our protocol documentation team and he’s forgotten more about how the protocol works than I’ll ever know.
I hope you found this useful. Until next time,
- Ned Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.