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!

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).

Disable LLMNR via GPO (Together with NBT-NS and MDNS)

You’re probably reading this because some pentesters got Domain Admin using LLMNR as a part of their attack chain in your internal network. Here’s a quick tutorial for how to disable it via GPO.

Research Blog | Project BlackEddie Zhang

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.

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.

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.

1. 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.

2. 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.