Skip to content
HackIndex.io

SMBv1 Enabled Detection

3 min read Created Mar 6, 2026 Last updated May 15, 2026

SMBv1 is a finding by itself. It keeps the host compatible with legacy SMB attack paths and old remote code execution checks that no longer apply to hardened SMBv2 and SMBv3-only systems. The protocol has no encryption and no mutual authentication. Any client and server negotiating SMBv1 are exposed to man-in-the-middle capture. The label [dangerous, but default] in the nmap output is the script flagging the dialect, not an assessment you need to make yourself. Start with the supported dialects.

Detecting SMBv1 Enabled Hosts

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p 445 --script smb-protocols $TARGET_IP 
| smb-protocols:
|   dialects:
|     NT LM 0.12 (SMBv1) [dangerous, but default]
|     2.1
|     3.0.2
|     3.1.1

Add host context before deciding how much time to spend on it. The OS version from smb-os-discovery tells you which CVEs are plausible. Server 2008 R2 and older systems are almost always unpatched against MS17-010. Server 2016 or later with SMBv1 enabled usually means a legacy application dependency or an admin who skipped hardening. The hostname and domain membership tell you whether this is a production server or an isolated artifact. nxc returns signing status alongside host info, which matters for relay attacks regardless of SMBv1 state.

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p 139,445 -sV --script smb-os-discovery $TARGET_IP
┌──(kali㉿kali)-[~]
└─$ nxc smb $TARGET_IP

On a modern Windows host, SMBv1 usually means hardening debt and keeps legacy CVE checks in scope. On a clearly old system, it is still important, but often less surprising. Check whether SMBv1 is the only advertised dialect or whether it coexists with SMBv2 and SMBv3. A host that negotiates only SMBv1 is a more severe finding than one listing all dialects. When smb-protocols times out or returns no output, the port may be filtered at the protocol layer rather than closed. Use smbclient to confirm the service is reachable before assuming the script failed. Some network appliances and older printers advertise SMBv1 support in dialects but fail all active exploit checks. Risks associated with SMBv1:

  • MS17-010 (EternalBlue) remote code execution
  • MS08-067 stack overflow on legacy systems
  • No encryption or mutual authentication
  • Man-in-the-middle capture of credentials
  • Downgrade attacks forcing weaker protocol negotiation

Once SMBv1 is confirmed, move straight to targeted legacy checks instead of generic enumeration.

┌──(kali㉿kali)-[~]
└─$ nmap -Pn -p 445 --script smb-vuln-ms17-010 $TARGET_IP

A positive MS17-010 result leads directly to EternalBlue MS17-010 SMB RCE. If the Print Spooler service is running, also check PrintNightmare. For very old hosts running Windows XP or Server 2003, run smb-vuln-ms08-067 instead. EternalBlue does not apply to those versions. A negative MS17-010 result does not clear the host. The patch covers that specific CVE, but SMBv1 itself remains active. Hosts patched against MS17-010 but still running SMBv1 can accept relay and capture attacks. Keep SMBv1 flagged in scope even when individual CVE checks return clean results.

If SMBv1 is absent, drop most legacy SMB vulnerability paths and focus on signing, share exposure, and access control.

References