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. Once you're done here, go read Beyond the Edge: How to Secure SMB Traffic in Windows.
Dang, that was pithy phrasing. Or dumb. Never mind, let’s do this!
SMB Interception Attacks
Some of the ways an attacker might attack you are:
- Intercepting or tampering with data that users are copying, reading, or writing remotely. These might be for industrial or state-level espionage, blackmail, or finding sensitive security data stored in files. Most individual SMB usage is as a remote file system for users, no different than a local hard drive. Most organizations keep much of their data in files on SMB shares.
- Relaying and capturing NTLM challenges or Kerberos tickets that a client sends to allow authentication of SMB connections. By influencing a client to connect to a malicious server – perhaps by tricking them into opening a shortcut in an email or on an unsecured share – an attacker might get an NTLM credential to brute force or reuse elsewhere.
- Causing a client to believe automatically invoked executable code lives on a trusted server. For instance, impersonating a domain controller that clients use to run logon or startup scripts containing malicious payload.
SMB Interception Defenses
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:
- Install updates
- Remove SMB1
- Remove guest authentication and fallback
- Disable the WebDAV protocol
- Restrict outbound SMB destinations by firewall
- Use UNC Hardening to require signing, encryption, and mutual authentication
- Use SMB 3.1.1
- Map drives on the fly with mandated signing or encryption
- Block NTLM & increase Kerberos Security
I count the last line as two so I can get to the magic 10. Cheeeeaaaatttinnnggg! 🙂
Install Updates
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.
Remove SMB1
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:
- SMB1 depends on the server to tell the client what security capabilities to use. A malicious server pretending to be your server can reply with "don't be secure" and a client will connect unsafely.
- SMB1 doesn't stop a malicious actor from altering the security capabilities response even from a legitimate server.
- SMB1 always tries user credentials, but if there is a failure, it then tries guest credentials. A malicious server pretending to belong to your organization - and didn't have your credentials to begin with - can allow the connection and then steal your files or execute malicious code from its own provided files.
- SMB2 and later have many effective security features. A malicious actor who can intercept the initial SMB Dialect conversation can reply with "this server only supports SMB1" and client will then negotiate that unsafe protocol.
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.
Remove Guest Authentication & Fallback
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\Lanman Workstation
"Enable insecure guest logons" = Disabled
Alternatively, set the following DWORD registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
"AllowInsecureGuestAuth"=0
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.
Disable the WebDAV protocol
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
Startup: Disabled
Service action: Stop service
Alternatively, you can use an elevated PowerShell session:
Set-Service WEBCLIENT -StartupType DISABLED
Stop-Service WEBCLIENT
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.
Restrict outbound SMB destinations by firewall
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. 🙂
Use UNC Hardening to require signing, encryption, and mutual authentication
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:
- \\<Server>\<Share> - The configuration entry applies to the share that has the specified name on the specified server.
- \\*\<Share> - The configuration entry applies to the share that has the specified name on any server.
- \\<Server>\* - The configuration entry applies to any share on the specified server.
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.
Use SMB 3.1.1
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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
MinSMB2Dialect: 0x000000311
MaxSMB2Dialect: 0x000000311
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.
Map drives on the fly with mandated signing or encryption
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.
Block NTLM & increase Kerberos Security
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:
- Longer passwords and phrases: 15 characters or more without dictionary words makes offline brute force extremely time consuming. Avoiding dictionary attacks with pass phrases makes that even better. Hard to enforce or train users but Azure AD Password Protection can help here. Increasing password length and complexity with NTLMv2 can help too, but… ick.
- Windows Hello for Business/smart cards: Two-factor authentication with Windows Hello For Business or smart cards adds an entire new layer of protections, as well as switching to Public Key Cryptography for Initial Authentication (PKINIT) in the Kerberos protocol instead of just using passwords. If you’re interested in how the Windows Hello passwordless solution works with AD and Kerberos, review the How it works docs or watch some of their short videos.
If you’re not already planning your Windows Hello rollout, it’s time to get hot.
- (gMSA: using group Managed Service Accounts for services makes brute force and dictionary attacks to crack passwords effectively impossible, with its 127 random character construction. Doesn’t help your end users though)
- FAST: Kerberos Armoring (Flexible Authentication Secure Tunneling) prevents Kerberoasting because the user’s pre-authentication data is protected and no longer subject to offline brute force or dictionary attacks. It also prevents downgrade attacks from spoofed KDCs and now requires you to compromise computers locally to make use of ticket attacks instead of just picking them off the wire. Adding Credential Guard can make that local compromise of tickets even harder, as stealing of a ticket-granting ticket and cached service tickets is now blocked. FAST requires raising your AD domain functional level and ensuring all your computers are at least Windows 8 and Windows Server 2012. You can control it all through group policy. Like Windows Hello for business, it’s the next level you need to start planning.
- SCRIL: Smart Card Required for Interactive Logon is one final choice, but frankly, difficult to deploy. When you configure a user with SCRIL, AD changes the user's password to a random 128 bit set. Users can no longer use a password to logon interactively and don’t even know their password; it can even have un-typeable bits. Their smart card, with its local protection PIN, becomes their password. And this means anytime anyone needs to know their password to do something, especially if they are an Admin, they are out of luck. All sorts of enterprise thingies are likely to be very unhappy about this.
Last thoughts
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.
A huge thanks to Steve Syfuhs for sharing his in-depth knowledge around Kerberos and to Sean Metcalf for his always-excellent AD Security blog. A couple of menschen.
I hope you found this useful. Now go read Beyond the Edge: How to Secure SMB Traffic in Windows.
- Ned Pyle