Exposed SMB (Port 445 / 139)
detect, fix, and prevent regression
Internet-facing Server Message Block on TCP 445, and the older NetBIOS session service on TCP 139, are among the most consistently exploited ransomware and lateral-movement vectors in joint CISA, FBI, and NCSC advisories. Learn how to detect them, close them, and keep them closed.
No credit card required. Free plan available forever.
What is exposed SMB?
Exposed SMB refers to a Server Message Block service that is reachable directly from the public internet, typically by leaving TCP port 445 (modern SMB) or TCP port 139 (the older NetBIOS session service that still tunnels SMB over NetBIOS) open on a file server, domain controller, Windows workstation, network attached storage device, or Linux Samba host. Once the listener is reachable, attackers fingerprint the dialect, enumerate shares, attempt authentication, exploit known protocol weaknesses, and relay or replay credentials harvested elsewhere.
Internet-facing SMB is one of the most consistently weaponised exposure classes in joint advisories from CISA, the FBI, the UK NCSC, and ENISA. The 2017 WannaCry and NotPetya outbreaks both rode an SMB exploit, EternalBlue (CVE-2017-0144), into hundreds of thousands of hosts in days. SMBGhost (CVE-2020-0796) added a pre-authentication remote code execution path on Windows 10 and Windows Server 2019 SMBv3.1.1 stacks. The CISA Known Exploited Vulnerabilities catalog carries multiple SMB-related entries, and SMB-relay attacks remain a fixture of ransomware playbooks because the protocol carries credentials and access tokens that are useful well beyond the original host.
The impact tracks the operating context of the exposed host. A domain controller on the public internet is a different blast radius from a developer's test virtual machine. Even where the host itself is unimportant, SMB exposure typically leads to credential harvesting through default credentials or relay attacks against NTLM, followed by privilege escalation on the foothold and lateral movement to higher-value systems including file shares, backup repositories, and domain trust relationships.
Exposed SMB is also a recurring audit and insurance finding. PCI DSS, NIST 800-53, ISO 27001, the CIS Controls, and most cyber insurance questionnaires either prohibit or restrict direct internet exposure of file sharing and remote administration services. Closing the exposure is usually inexpensive compared to the operational and compliance cost of leaving it open, which is why this class of finding tends to move quickly through remediation tracking once it is surfaced on a controlled record alongside its sister exposures, exposed RDP on the Windows administration side and SSH misconfiguration on the Linux, UNIX, cloud, network appliance, and OT side.
How attackers exploit it
Discover open 445 or 139
Attackers continuously sweep IPv4 (Shodan, Censys, Masscan, custom scanners) for hosts answering on TCP 445 or 139. Banner and SMB negotiation responses identify the dialect, the operating system, and often the workgroup or domain name.
Enumerate shares and accounts
Tooling (enum4linux-ng, smbclient, rpcclient, CrackMapExec, NetExec) lists open shares, anonymous-accessible folders, domain user lists, password policy, and session information without ever submitting valid credentials.
Exploit protocol weaknesses
Where the host is unpatched, attackers run known SMB CVEs (EternalBlue CVE-2017-0144, EternalRomance, SMBGhost CVE-2020-0796, the 2022 SMB driver RCE class). On hosts with SMBv1 enabled, the attack surface widens further.
Establish foothold and pivot
Once authenticated, attackers stage tooling on writable shares, dump credentials, abuse NTLM relay to escalate, enumerate Active Directory, move laterally, and stage ransomware deployment or large-scale data exfiltration through SMB-readable file repositories.
Common causes
File server placed on a public subnet
A Windows file server, a Linux Samba host, or a NAS appliance is provisioned on a public cloud subnet, an on-premise DMZ, or a colocation rack without a network access list in front. SMB ports follow the default service configuration and reach the internet on day one.
Cloud security group rule too broad
An AWS security group, Azure NSG, or GCP firewall rule opens TCP 445 to 0.0.0.0/0 during a migration, a temporary mount, a partner share, or a vendor handoff. The rule is never narrowed, and a public listener persists long after the original use case ends.
Legacy SMBv1 and weak signing left enabled
SMBv1 stays enabled on a legacy host because removing it broke a printer or a NAS in the past. SMB signing is disabled or not required, leaving the dialect open to relay attacks and the host exposed to the EternalBlue family of exploits when the patch level lags.
Domain controller or backup host reachable from the internet
A domain controller in a satellite office, an unmanaged backup target, or a disaster-recovery NAS is reachable externally. The privileged operating context turns the exposure from a single-host concern into an immediate authentication-and-data-theft event.
How to detect it
Automated detection
- SecPortal's external scanner port-scan module probes TCP 445 and TCP 139 across every verified domain and host in scope, captures the service banner where available, and raises a high-severity finding with the recommendation to block at the perimeter and restrict SMB to trusted networks.
- Continuous monitoring re-runs the external scan on a schedule, so a security-group edit or firewall change that re-exposes 445 or 139 reopens the finding rather than leaving the regression invisible until the next manual review or audit cycle.
- Bulk import accepts Nessus, Burp, and CSV output from network-tier scanners that already report exposed-SMB and SMBv1 findings, so the catalogue stays centralised even when a third-party scanner is the original discovery source.
Manual verification
- Use nmap -p 139,445 with service detection (-sV) and the smb-os-discovery, smb-protocols, and smb-security-mode scripts against the external IP range to confirm the listener, the dialect set, whether SMBv1 is offered, and whether SMB signing is required.
- Cross-reference exposed hosts against the CISA Known Exploited Vulnerabilities catalog and Microsoft security advisories to identify whether EternalBlue, SMBGhost, or any SMB-class CVE is unpatched on the discovered build.
- Check Shodan and Censys for the organisation's netblocks and known hostnames to see whether external observatories already list exposed SMB services and the share or session metadata they advertise.
How to fix it
Remove direct internet exposure
Block TCP 445 and TCP 139 inbound at the perimeter firewall, the cloud security group, and the load balancer. SMB should only be reachable from inside the trusted administrative network, an enterprise VPN, a software-defined perimeter, or a peering relationship explicitly governed by a documented sharing agreement.
Disable SMBv1 everywhere
Remove SMBv1 from Windows hosts (Optional Features, Set-SmbServerConfiguration -EnableSMB1Protocol $false, Group Policy), retire any printer or NAS that requires SMBv1, and confirm Samba hosts are configured with min protocol = SMB2 or higher. SMBv1 is unsupported, exposes the EternalBlue family directly, and is the default explanation for ransomware blast radius across joint advisories.
Require SMB signing and channel encryption
Enable mandatory SMB signing (RequireSecuritySignature) on both client and server. Where the dialect supports it, require SMB encryption per share or globally. Both controls block NTLM relay attacks and harden the session against passive interception even when the listener remains reachable inside the trusted network.
Patch and harden the host
Apply Windows updates and Samba patches promptly, particularly any advisory affecting SMB, the LSASS authentication stack, or NTLM. Rotate local administrator credentials, restrict NTLM where Kerberos is available, and remove anonymous share access by disabling RestrictNullSessAccess, AllowInsecureGuestAuth, and unused null-session pipes.
Front file sharing with a brokered access pattern
Where remote SMB access remains a real business need, broker it through a software-defined perimeter, an identity-aware proxy, or a secure file transfer service. Do not republish the SMB protocol directly to the internet to satisfy a remote-access requirement that an HTTPS portal or a managed file transfer can serve more safely.
Restrict source IP and add monitoring
Where a brokered pattern is not yet feasible, restrict inbound 445 and 139 to a short allowlist of partner egress IPs and instrument the host with logging that forwards SMB authentication, share access, and command events to the SIEM or detection pipeline so the security operations team sees relay and brute-force activity before it succeeds.
Operationalising the fix on the workspace
Closing exposed SMB is rarely the technical hard part. The operational hard part is keeping it closed across changes of ownership, cloud security-group drift, vendor migration windows, mergers and acquisitions, and the long tail of file-sharing hosts that nobody currently lists in a primary asset inventory. The workspace pattern below is what AppSec, vulnerability management, and security engineering teams use to keep an exposed-SMB finding from coming back six months later under a new account or a renamed host.
Surface every listener on one finding record
External scanning and bulk import land every exposed-SMB and exposed-NetBIOS detection on the findings management record with CVSS, the discovered host, the scan timestamp, and the named owner so the catalogue is a single source of truth rather than a Shodan tab, a spreadsheet, and a Slack thread.
Run remediation as a tracked workflow
Each finding flows through the remediation tracking workflow with severity, target close date, named owner, and the agreed compensating control if the host cannot be removed from the internet immediately (for example, an inbound source allowlist while the migration completes).
Verify the fix with retest
Once the firewall rule, security-group edit, host retirement, or service migration completes, the retesting workflow re-runs the external scan, confirms the listener is gone on both 445 and 139, and stamps the closure with timestamped evidence rather than a verbal sign-off.
Catch regressions through continuous monitoring
Scheduled continuous monitoring re-scans of verified domains reopen the finding if SMB returns to the public internet, so a maintenance window, a new cloud account joining the estate, or a recovered backup host does not silently reintroduce the exposure.
Pair with the broader exposure catalogue
Exposed SMB rarely shows up alone. The same host frequently exposes exposed RDP, default credentials, or weak password policy. Treating SMB exposure as one finding inside a host-level posture review keeps the queue ordered against real residual risk rather than chasing isolated ports one at a time.
Carry the audit trail through closure
The activity log records who opened, scoped, remediated, and verified each exposed-SMB finding, so the next ISO 27001, SOC 2, PCI DSS, or cyber insurance review reads the operating evidence from the record rather than from reconstructed memory, archived ticket exports, or screenshots taken weeks after the fact.
Compliance impact
Related features
Vulnerability scanning tools that map your attack surface
Monitor continuously catch regressions early
Vulnerability management software that tracks every finding
Verify fixes and track reopens on the same finding record
Bulk finding import bring your scanner data with you
Compliance tracking without a full GRC platform
Every action recorded across the workspace
Find every exposed SMB and NetBIOS listener across your estate
SecPortal's external scanner probes TCP 445 and 139 across verified domains, raises a high-severity finding with port and service evidence, tracks remediation, verifies the fix through retest, and re-runs continuously so a firewall change or cloud security-group edit does not silently undo the closure. Start free.
No credit card required. Free plan available forever.