A Quick Guide to SMB Security
Updated: Apr 9
The Server Message Block (SMB) protocol is one of the most widely used, and oft misconfigured, network protocols around today. On our internal network penetration tests, we’re very commonly able to leverage these misconfigurations to uncover sensitive information, escalate privileges, or even gain remote code execution on systems in the network. This guide is meant to help administrators better understand the security holes that they may be inadvertently opening via SMB and how they can better configure the networks under their care to avoid the most common pitfalls.
What is SMB?
Sharing resources is, at the core, the foundational purpose that networks were developed for in the first place. The SMB protocol was developed to make this task easier by allowing for drive and file shares, printer access, and other resource shares between different endpoints on the network. The protocol is most associated with Microsoft Windows/Server environments but is also used on Unix-based networks where it is known as SAMBA. For the purposes of this guide, we’ll be focusing on the security implications in Microsoft environments, as this is the most common case.
To make things easier to follow, we’re going to take a list-based approach to the most common misconfigurations that we find in internal networks in order to help administrators address these issues once and for all. Let’s get started!
Enabling SMBv1: Let’s face it, this variant of SMB is old. Too old. As such, it suffers from the symptoms of having been made for a very different time. One of the most high-profile issues with SMBv1 is its mishandling of specially crafted network packets which could lead to remote code execution, such as in the infamous EternalBlue exploit developed by the NSA. There is no value in having support for SMBv1 enabled on the modern network, so disable it right away in favor of v3.
SMB Signing Not Enforced: If SMB signing is not enforced between client-server connections, it becomes possible for an attacker positioned on the network to conduct a variety of Man-in-the-Middle attacks and, combined with other misconfigurations, could even result in Remote Code Execution. As such, you should ensure that SMB signing is enforced across the entire network. Find out more here and here.
Unencrypted Shares: At-rest encryption on SMB file and drive shares can, and definitely should, be easily handled through Microsoft’s BitLocker drive encryption, but in-transit network communications also need to be secured in order to prevent unintended eyes from monitoring the traffic. Check out the official documentation from Microsoft to learn more.
Open SMB Shares: It’s worryingly common to find improperly secured/open shares on an internal network. If authentication or authorization controls are not in place, you could be leaving sensitive information exposed to any malicious threat actors on the network. In other words, not good. We tend to see this a lot with old and abandoned shares that the creator forgot about. On some occasions, we’ve even found administrator credentials lying around in the share! If you’re familiar with Nmap, you can use the “smb-enum-shares” script to help scan for such shares in your network, or more robust tools such as SMBMap. Obviously, make sure you have the proper permission before running any scans.
We’ve only touched on the surface of the SMB protocol and its security implications here, so we encourage you to read more if you have anything to do with administering and internal network. The Wikipedia article and official Microsoft documentation are great places to start.