Heya folks, Ned here again. I've got a new SMB preview feature to share: the SMB authentication rate limiter. It's available in Windows Server Insider build 25075. In a few weeks it will also appear in Windows Server Azure Edition Insider & Windows 11 Insider Dev Channel builds.
Even though the SMB server runs by default in all versions of Windows, it's not accessible by default unless you open the firewall. IT staff often enable access to the SMB server service even on machines that aren't dedicated file servers for legitimate reasons like opening remote files or copying logs. A side effect of this is that SMB becomes a way to attempt authentication. Knowing a username, an attacker can send local or Active Directory NTLM logons to a machine using common opensource tools - from dozens to hundreds of logon attempts per second - to guess a password. If your organization has no intrusion detection software or doesn't set a password lockout policy, an attacker might guess a user's password in a matter of days or hours. A consumer user who turns off their firewall and brings their device to an unsafe network has a similar problem.
Starting in Windows Server Insider build 25075 and later, the SMB server service now implements a 2-second delay between each failed NTLM or PKU2U-based authentication. This means if an attacker previously sent 300 brute force attempts per second from a client for 5 minutes (90,000 passwords), the same number of attempts would now take 50 hours at a minimum. The goal here is to make a machine a very unattractive target, a key aspect of defense-in-depth techniques.
This setting has variable time configuration, and you can enable/disable it. It's controlled by PowerShell:
Set-SmbServerConfiguration -InvalidAuthenticationDelayTimeInMs n
The value is in milliseconds, must be a multiple of 100 (i.e., you can set it to 500, 2000, or 4800, but not 50 or 1337), and can be between 0-10000. Setting to 0 disables the feature.
To see the current value, run:
Here's a demo
Side note: did you see something interesting in my demo's time? The Windows SMB client redirector is also passing through the DFSN redirector, leading to two connection attempts for each mapped drive attempt. My times are actually doubled as each attempted mapping is really two mappings, so my "attack" is especially penalized; the actual rate of 45 attempts a second is just under an hour for 1000 passwords, which is still a huge change from the 22 seconds in the first section :). That's just a peculiarity of me using a mapped drive and Windows to test this, your red team attacker is probably a Kali user running a specific brute forcing tool. The 2 seconds may actually be a few milliseconds longer per attempt due to timer overhead, especially on a busy CPU. The goal here is to take longer, so that's ok - it will never be faster than the delay you specify.
This behavior change has no effect on Kerberos, which authenticates before an application protocol like SMB connects. It is designed to be another layer of defense in depth, especially for devices not joined to domains. It's possible the default time and behaviors may change after we evaluate usage in Insiders and take feedback; it's also possible some third-party applications may have problems with this new feature - please use the Windows Feedback Hub to file bugs or DM me here if you find that disabling the feature resolves your application's issue.
This continues the new generation of SMB and file server security enhancements first begun with SMB over QUIC in Windows 11 and Windows Server 2022. We will change, deprecate, or remove many legacy SMB and pre-SMB protocol behaviors over the next few major releases of operating systems in a security modernization campaign, similar to the removal of SMB1. I will have a lot more to share over the coming year, stay tuned.