https://www.sikich.com

Easy Wins for Active Directory – Part 2

Hank Wyatt, CISSP, GSEC, GCIH, GPEN

Nov 21 2019

3 min read

In part 1 of this three-part series, we discussed detection methods and recommended fixes related to NetBios Name Service (NBNS) and Local-link Multicast Name Resolution (LLMNR) usage in an Active Directory environment.

In part 2, we will show you how to check hosts for Server Message Block (SMB) version 2 (SMB2) security levels. We will also demonstrate how to configure security levels with Group Policy.

How to Detect SMB2 Security Levels

To detect the current SMB2 security level for our Windows lab system, we will use Nmap, a popular port scanning tool. A default script comes with Nmap called smb2-security-mode. With default settings, the script attempts to connect to the target’s listening SMB2 service as the guest user. It will then provide information about the service.

Run the following command to use the smb2-security-mode script against port 445/tcp of the target host:

nmap --script smb2-security-mode.nse -p445 <target ip>

The command provided the following output.

Host script results:

| smb2-security-mode:

| 2.02:

|_ Message signing enabled but not required

There are three potential results for the message signing:

Message signing disabled
Message signing enabled but not required (default for SMB2)
Message signing enabled and required

Options 1 and 2 are vulnerable to SMB relay attacks, which Ethan Hobart described in detail in his blog post, Multirelay – Responder’s Overlooked Little Brother. Option 3 is the most secure option and what we will be configuring in the next section.

Please note that requiring SMB2 signing on both clients and servers could have an impact on network performance and system stability. Make the change on a small subset of the environment or in a test environment to make certain the changes won’t negatively impact your environment.

Enabling and Requiring SMB2 Signing

We will focus on the more modern implementation, SMB2, as it is the version most often used in systems today. Configuring SMB2 to require signing is done through Group Policy.

To require SMB2 signing on both clients and servers, use the Group Policy Editor (Windows 10):

From the Start menu, search for msc.
Navigate to Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options ->
Set Microsoft network client to “Enabled” for “Digitally sign communications (always)” and the Microsoft network server “Digitally sign communications (always).”
If on a local system, reboot the computer and use Nmap to validate that SMB2 signing is required.
If applying the Group Policy Object across an Active Directory domain, apply the updated policy to the appropriate scope and wait for systems to pull the new policy before using Nmap to validate that SMB2 signing is required.

Wrapping Up

Requiring SMB2 signing is an easy win for Active Directory security. If your environment is constantly adding new systems, it is important to continue to monitor for weak SMB settings using Nmap or a vulnerability scanner. Maintaining a proactive approach to security will keep your team ahead of attackers.

In Part 3 of this series, we will discuss how to prevent attackers from capturing plaintext passwords in memory on Windows machines.

Have any questions on SMB2 signing? Please contact us at any time.

This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.

About the Author

Hank Wyatt, CISSP, GSEC, GCIH, GPEN

Hank is a Consultant at Sikich who focuses on performing penetration testing of client networks and applications. He has previous experience as a network administrator in the United States Marine Corps, where he was exposed to a wide range of system architectures in a fast-paced environment. He spent time after his military career providing ERP software integration consulting services to large health care organizations. With his experience and knowledge, Hank is well suited to help clients solve the complex problems associated with the ever-increasing number of technologies involved in enterprise networks today.