What is an SMB file share?

SMB (Server Message Block) is a client-server network protocol used to share access to files, folders, printers, and serial ports across a network. An SMB file share is a directory on a server that has been made available to network clients through the SMB protocol, so users can read, write, and manage files remotely as if they were stored locally.

SMB is the default file sharing protocol in Windows environments. macOS and Linux support it through the Samba implementation.

If you have ever mapped a network drive, accessed a shared folder through a UNC path (\\server\share), or connected to a DFS namespace, you were using SMB. For IT administrators, understanding how SMB works, which versions are secure, and how to audit file share access matters for data security and compliance.

How SMB file sharing works

SMB runs on a client-server model. The client sends a request to the server, the server processes it, and sends back a response. Every file open, read, write, or close operation on a shared folder travels over this request-response cycle.

A typical SMB session has four stages:

1. The client and server negotiate a dialect, agreeing on the highest SMB version both support.
2. The client authenticates using either NTLM or Kerberos credentials.
3. The client connects to a specific share by name.
4. The client performs file operations on that share.

SMB communicates over TCP port 445 for direct hosting. Older environments may use TCP port 139, which routes SMB traffic over NetBIOS. Port 139 is a legacy configuration; most modern networks rely exclusively on port 445.

SMB uses opportunistic locks (oplocks) to improve performance by letting clients cache file data locally and reduce network round trips. SMB signing is another mechanism worth understanding: when enabled, it attaches a cryptographic signature to each packet, preventing attackers from tampering with SMB traffic in transit.

SMB versions compared

Not all SMB versions are equal. Each major version introduced security and performance improvements, and the version your environment runs determines your exposure to specific threats.

SMB 1.0 is the single largest SMB-related risk in any environment. Microsoft deprecated it because it lacks encryption, uses weak authentication, and is the protocol version exploited by EternalBlue. You can check whether SMB 1.0 is still enabled on a Windows server by running this PowerShell command:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

On Windows 10 and later, you can also check through Windows Features:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

If either command returns True or Enabled, disable SMB 1.0 immediately.

SMB vs. NFS

SMB and NFS (Network File System) are both network file sharing protocols, but they serve different ecosystems and handle authentication differently.

In mixed Windows and Linux environments, SMB is typically the better choice because of its native Active Directory integration and user-level access control. NFS is more common in Linux-only or UNIX-only environments where host-based trust models are acceptable.

Security risks and attacks targeting SMB

SMB has been a high-value target for attackers because it handles authentication credentials and provides direct access to file data. Several major attacks have exploited weaknesses in the protocol or in how organizations configure it.

EternalBlue and WannaCry

The most damaging SMB exploit in recent history is EternalBlue (MS17-010), a vulnerability in SMB 1.0 that allows remote code execution. EternalBlue was the exploit behind the WannaCry ransomware outbreak in May 2017 and the NotPetya attack that followed weeks later.

Both attacks spread laterally across networks by exploiting unpatched SMB 1.0 services. The damage from NotPetya alone exceeded $10 billion globally, according to a 2018 Wired report on the attack.

SMB relay attacks

In an SMB relay attack (a form of manipulator-in-the-middle attack), the attacker intercepts NTLM authentication traffic between a client and a server, then relays those credentials to a different server to gain unauthorized access. This works when SMB signing is not enforced, because the attacker can forward authentication messages without the server detecting the tampering.

Lateral movement over SMB

Once an attacker gains a foothold in a network, SMB shares are a primary channel for lateral movement. Techniques like pass-the-hash and pass-the-ticket attacks let attackers authenticate to SMB shares using stolen credential material without knowing the actual password. From there, they can access sensitive files, deploy malware, or move deeper into the environment.

Credential harvesting and brute-force attacks

Attackers can set up rogue SMB shares that prompt connecting clients to submit their credentials, capturing NTLM hashes for offline cracking. Brute-force attacks against SMB authentication are also common, particularly against internet-exposed SMB services where TCP 445 is not blocked at the perimeter.

Data exfiltration

SMB shares that store sensitive data without proper access controls become exfiltration targets. An attacker with valid credentials (or stolen hashes) can copy large volumes of data from file shares without triggering alerts if the environment lacks file access monitoring.

ADAudit Plus detects pass-the-hash attacks through its Attack Surface Analyzer and monitors file share access anomalies using user behavior analytics, sending real-time alerts when unusual file activity occurs on SMB shares.

How to secure SMB file shares

Securing SMB requires protocol hardening, network controls, and access auditing. Here is what that looks like in practice.

Disable SMB 1.0 on all systems. There is no legitimate reason to run SMB 1.0 in a modern environment. Disable it on every server, workstation, and domain controller. On Windows Server, use Set-SmbServerConfiguration -EnableSMB1Protocol $false.

On Windows 10 and later, remove the SMB 1.0 feature through Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol.

Enforce SMB signing. SMB signing prevents relay attacks by cryptographically verifying that packets have not been tampered with in transit. Set RequireSecuritySignature to True on both the SMB server and client via Group Policy or PowerShell. Without enforced signing, your environment is open to credential relay.

Enable SMB encryption. SMB 3.0 and later support end-to-end encryption. You can enable encryption per share (Set-SmbShare -Name "ShareName" -EncryptData $true) or globally (Set-SmbServerConfiguration -EncryptData $true). Encryption protects data in transit without requiring a VPN or IPsec.

Use Kerberos authentication instead of NTLM wherever possible, since Kerberos provides stronger mutual authentication and is resistant to relay attacks.

Restrict SMB traffic to internal networks. Block TCP 445 at the perimeter firewall. SMB was designed for LAN communication, and exposing it to the internet invites brute-force attacks and exploit attempts. If remote users need file share access, route them through a VPN rather than opening SMB ports externally.

Apply least-privilege share permissions so that users can only access the shares and folders they need for their role.

Audit SMB share access. Enable object access auditing in Group Policy and configure SACLs on critical shares. Monitor Event IDs 4656 (handle requested), 4663 (object access attempted), and 5140 (network share accessed) in the Security event log. This audit trail is your foundation for detecting unauthorized access and investigating incidents.

Limitations of native SMB auditing tools

Windows gives you the building blocks for SMB file share auditing through Group Policy, SACLs, and Event Viewer, but these native tools fall short at scale.

Event Viewer logs are local to each file server. If you have five file servers hosting SMB shares, you need to check the Security log on each one individually. There is no centralized view of file share access activity across your environment without writing scripts or deploying a third-party tool.

Security log size limits make this worse. When the log reaches its maximum size, older events get overwritten, and you lose audit data for SMB access events that occurred before the rollover.

Native tools do not offer real-time alerting on suspicious file share activity. If an attacker copies thousands of files from an SMB share at two a.m., you will not know until someone manually reviews the logs. There is no scheduled report delivery either; pulling a weekly summary of SMB access events requires manual filtering and export on every server.

Correlating related events (linking Event ID 5140 with Event IDs 4656 and 4663 to build a complete picture of a file access session) requires PowerShell scripting or third-party tools. Native Windows auditing also provides no user behavior analytics or anomaly detection, so you cannot automatically flag patterns like a sudden spike in file deletions or access from an unusual time of day.

Monitoring SMB file share access with ADAudit Plus

What ADAudit Plus monitors on SMB file shares

ADAudit Plus audits all file and folder changes on Windows file servers and 13 NAS device types, including creates, modifications, deletions, moves, renames, and copies. Every event captures who performed the action, when it occurred, from which client machine, and the full file path.

Beyond change tracking, ADAudit Plus monitors file read access (both successful and failed attempts) and tracks folder permission changes with old and new ACL values, so you can see exactly what changed in a folder's access control list. Network share access events (share added, modified, deleted, and read) are captured through dedicated reports under the Server Audit tab.

ADAudit Plus applies machine learning through its UBA engine to detect anomalous file activity patterns. It flags unusual volume of file access, file access at unusual times, and spikes in file deletions or modifications, which are strong indicators of ransomware activity.

When the system detects a potential ransomware pattern, it triggers the "Possible Ransomware activity detected" alert. You can configure real-time alerts for any file share event and schedule reports for automatic delivery to compliance teams on a daily, weekly, or monthly basis.

Native Windows auditing vs. ADAudit Plus

Frequently asked questions