How to Block Outbound SMB to Stop NTLM Hash Leaks

To block outbound SMB, deny TCP 445 from your internal networks to the internet at the perimeter firewall, then add a matching host firewall rule on laptops that leave the office. Test first in log-only mode to find the few systems with a real need. This stops most NTLM hash leaks, including the one used in the November 2026 Outlook zero-day, CVE-2026-124194, from reaching an attacker's server.

Why block outbound SMB at all?

Blocking outbound SMB stops Windows from sending a user's NTLM authentication to servers on the internet. Most organizations have no business need for workstations to reach external file shares over TCP 445, so the rule costs little and removes a common credential leak path.

SMB is the protocol Windows uses for file shares. When a file, link or bug tells Windows to open a remote share, it tries to log in with the current user's credentials. Inside a domain that is convenient. Pointed at an attacker's server, it hands over an NTLMv2 response that can be cracked or relayed. Our explainer on what an NTLM hash leak is covers why that response is valuable.

The Outlook zero-day CVE-2026-124194 is a current example. A crafted message file made Outlook connect to an attacker-controlled location without its normal warning. With outbound SMB blocked, that connection fails at your edge.

How do you find out who needs outbound SMB?

You find out by logging before you block. Run the new rule in log-only or alert mode for one to two weeks and review every internal host that tried to open TCP 445 to an external address.

Expect a short list. Typical legitimate cases are:

• A backup appliance or file transfer job that writes to a partner's or provider's share
• A hosted file service that still requires SMB access from specific servers
• Legacy line-of-business software configured with a remote path

Each of these should come from a known server, not from user workstations, and should go to a known destination. That lets you write a narrow exception (one source, one destination, one port) instead of leaving the whole rule open.

Workstations that show up in the log with no business reason deserve a second look. A connection from a user laptop to an unfamiliar external address on 445 is exactly the pattern a hash leak produces.

Step 1: Block at the perimeter firewall

Add an outbound deny rule for TCP 445 from all internal address ranges to any external destination, placed above your general outbound allow rule. Add explicit allow rules above it for the exceptions you documented, scoped to source and destination.

Turn on logging for the deny rule. Those log entries become your detection feed: every hit is either a misconfigured application or an attempted leak worth investigating.

If you use a cloud firewall or secure web gateway for remote users, apply the same rule there. A perimeter rule only protects devices whose traffic passes through the perimeter.

Step 2: Add a host firewall rule for mobile devices

Laptops on home or hotel networks bypass your perimeter entirely, so the perimeter rule alone leaves them exposed. Push a host firewall rule through your endpoint management tool that blocks outbound TCP 445 to addresses outside your internal ranges.

Scope it carefully. The rule should block 445 to the internet while still allowing it to your internal file servers and domain controllers, whether the device connects over VPN or on site. Define your internal ranges once in the policy and reference them, so the rule stays correct when a subnet is added.

Deploy to a pilot group first. Confirm mapped drives, home folders and Group Policy still work over VPN before rolling it out to everyone.

Step 3: Watch for other paths out

SMB is not the only way Windows can send credentials to a remote host. When the WebClient service is running, Windows can try to reach a remote path over HTTP-based WebDAV instead, and that traffic uses ordinary web ports your firewall allows.

You do not need to block web traffic to deal with this. Review which devices actually need the WebClient service and disable it where they do not, and watch proxy logs for WebDAV requests from workstations to unfamiliar hosts. Treat this as a second layer, not a replacement for the SMB block.

Step 4: Verify the block works

After rollout, confirm the rule is doing its job:

1. From a test workstation on the corporate network, attempt a connection to an external host on TCP 445 and confirm it fails and is logged.
2. Repeat from a laptop on an outside network with the host rule applied.
3. Confirm internal file shares and VPN-based access still work for the same devices.
4. Add the firewall deny log to your monitoring so new hits raise an alert instead of sitting in a log file.

What blocking outbound SMB does not fix

An egress block stops leaked hashes from leaving the building. It does nothing about an attacker already inside your network who can catch and relay authentication internally. Pair it with SMB and LDAP signing, strong passphrases and a plan to reduce NTLM use.

It also does not replace patching. The Outlook fix for CVE-2026-124194 ships in Office updates, which run separately from Windows Update. Our guide on why Office update patching needs its own track covers how to close that gap.