Enable SMB Signing via GPO
"SMB Signing not required" may appear as just a Medium severity finding in most vulnerability scans, but under the right circumstances, it can be quite impactful. Here's a guide on how to enable and require signing.
![Enable SMB Signing via GPO](/blog/content/images/size/w2000/2024/06/smb-signing-feature-1.png)
Many attacks in Active Directory environments rely on capturing or obtaining password hashes, attempting to crack them (e.g., Kerberoasting), and then using them to move laterally. Setting incredibly strong passwords can halt many of these attacks.
However, if SMB signing is not required on servers in the environment, or by clients, attackers can gain access to systems without ever knowing the user's password!
![](https://projectblack.io/blog/content/images/2024/06/image-14.png)
This can be especially impactful when the authentication attempt relayed is from a privileged user, such as a domain administrator.
By relaying these authentication attempts, we immediately gain access to various devices in the environment.
You might wonder why a potential victim would willingly authenticate to our attacker, but there are a variety of mechanisms to force clients to do this. See below for a link to a Windows feature that pairs well with this relay attack (LLMNR).
![](https://projectblack.io/blog/content/images/2024/06/llmnr-feature.png)
The GPO
There are 4 GPO settings that relate to SMB signing. These can be found under:
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
![](https://projectblack.io/blog/content/images/2024/06/image-15.png)
We can ignore the two settings that negotiate signing (if server agrees) and (if client agrees) as these GPO settings only apply to SMB v1 servers and clients. You should disable SMB v1 if it's still in use, but that's a topic for a separate article!
This leaves us with a server side setting, and a client side setting to enable:
- Microsoft network server: Digitally sign communications (always)
- Microsoft network client: Digitally sign communications (always)
The resultant signing decision when configuring these settings is represented below.
Server | |||
---|---|---|---|
Require SMB Signing | Do NOT Require SMB Signing | ||
Client | Require SMB Signing | Signed | Signed |
Do NOT Require SMB Signing | Signed | Not Signed |
Impact of Requiring SMB Signing
- In most environments, the only impact you'll notice is increased CPU usage (on both servers and clients) and reduced transfer speeds.
- This is important if you run a monolithic file server that has hundreds of concurrent clients.
- You will break things IF:
- You have a client that doesn't support SMB signing and you require SMB signing on the server side.
- You have a server that doesn't support SMB signing and you require clients to always use SMB signing.
Implementation Tip
If you suspect there are unknown legacy devices in the environment, avoid rolling out both client and server side Group Policy Object (GPO) settings simultaneously.
Separating the rollout will reduce the number of issues you need to troubleshoot at any one time, so you're not addressing problems with both clients and servers simultaneously.
Here’s what I mean by that.
- Roll out the server side policy first
- Microsoft network server: Digitally sign communications (always)
Implementing this policy will help identify any legacy client devices, such as an old thin client in a cupboard, that do not support SMB signing.
- Then roll out the client side policy
- Microsoft network client: Digitally sign communications (always)
Implementing this policy will help identify any legacy server devices, such as scanner file shares, that do not support SMB signing.