SMB Security Check
SMB (Windows file sharing) on TCP/445 is one of the most abused attack surfaces on the public internet — the path behind EternalBlue, WannaCry, NotPetya and NTLM relay. This check sends real, read-only SMB2 and SMB1 NEGOTIATE requests (the pre-auth handshake) to a host's port 445 and reports whether SMB is reachable at all, the negotiated dialect, whether the obsolete SMBv1 is still enabled, and whether message signing is required. It never authenticates, brute-forces, or writes anything — it only proves reachability and policy from the handshake.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- Whether TCP/445 answers and completes an SMB negotiation at all (the closed/filtered port is the safe result)
- Exposure — that SMB / Windows file sharing is reachable from an untrusted network (SVC_SMB_EXPOSED)
- The negotiated SMB dialect / version reported in the handshake
- Whether the obsolete SMBv1 protocol is enabled — the pre-auth-exploitable protocol behind WannaCry and NotPetya (SVC_SMB_V1)
- Whether SMB message signing is required, or can be stripped to allow NTLM relay and session tampering (SVC_SMB_NO_SIGNING)
- The equivalent command — nmap -Pn -p445 --script smb-protocols,smb2-security-mode,smb-os-discovery <host>
How to read the result
- OK — no SMB on 445: TCP/445 is closed or filtered, so Windows file sharing isn't reachable from here. This is the safe result; SMB should never face the public internet.
- Open but no SMB negotiation: the port answered but never completed an SMB handshake — it's filtered or not actually SMB, and no dialect/signing/SMBv1 state could be confirmed.
- Reachable SMB is already a Warn/Fail: any internet-exposed SMB is high risk because it is the entry point for ransomware worms, NTLM relay and the EternalBlue (MS17-010) family.
- Fail — SMBv1 enabled: the obsolete, pre-auth-exploitable protocol is on; disable it immediately on every host.
- Warn — signing not required: an on-path attacker can relay NTLM authentication or tamper with the session; require SMB signing.
- Fix in all exposed cases: restrict SMB (445/139) to the LAN or a VPN at the firewall, require signing, and keep SMBv1 disabled.
Frequently asked questions
Should SMB ever be open to the internet?
No. SMB / port 445 is meant for trusted LANs. Exposing it publicly is how worms like WannaCry and NotPetya spread and how NTLM-relay attacks start. If this check finds 445 reachable from the internet, the priority fix is to block it at the perimeter firewall and only reach file shares over a VPN.
Does the check log in to my shares or read files?
No. It sends only the pre-authentication SMB2 and SMB1 NEGOTIATE requests — the very first step of the handshake, before any login — to learn the dialect and signing policy. It never authenticates, never guesses credentials, and never reads, writes or enumerates shares.
Why is SMBv1 such a problem if SMBv2/3 also work?
SMBv1 is a decades-old protocol with pre-auth remote-code-execution flaws (notably MS17-010 / EternalBlue) that cannot be safely patched away — it should simply be turned off. Modern Windows negotiates SMBv2/3 fine without it, so disabling SMBv1 removes the EternalBlue/WannaCry attack surface with no functional loss for current clients.
What does 'message signing not required' mean for me?
SMB signing cryptographically validates each message. When it isn't required, an attacker positioned on the network can relay your NTLM authentication to another server or tamper with the session (a man-in-the-middle / NTLM-relay attack). Requiring signing on servers and clients closes that path.
How do I disable SMBv1 and require signing on Windows?
Disable the SMB1 feature (e.g. Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol, or the equivalent Group Policy) on every host, and require signing via the 'Microsoft network server/client: Digitally sign communications (always)' policies. Then re-run this check — it should report SMBv1 not offered and signing required, and ideally 445 not reachable from outside.
It says 445 is filtered — am I safe?
From this vantage point, yes — nothing completed an SMB handshake, so external attackers can't reach it the way the probe did. Confirm it's also blocked from any other untrusted network (not just this one path) and that internal hosts still have SMBv1 off and signing on, since most SMB compromise happens after an attacker is already inside the LAN.