CVE-2017-0147: Microsoft Windows SMBv1 Information Disclosure Vulnerability

CVE-2017-0147 is an information-disclosure vulnerability in the Microsoft SMBv1 server that lets a remote attacker obtain sensitive data from process memory by sending a crafted packet. It matters because SMBv1 is often reachable on Windows hosts used for file and printer sharing, and successful abuse can leak memory contents that aid further compromise. Public reporting links this issue to ransomware activity, so organizations still running SMBv1 should treat it as a priority.

Confirm every version, patch, and configuration detail against the official Microsoft advisory before acting; the guidance below stays within the published facts and general practices for this weakness class.

How it works

The flaw is classified as CWE-200 (exposure of sensitive information). In the SMBv1 server implementation, improper handling of a specially crafted network packet can cause the service to return data from process memory that should not be disclosed to an unauthenticated or unauthorized remote party. An attacker who can reach the SMBv1 listener crafts and sends such a packet; the server responds with memory contents that may include credentials, cryptographic material, or other in-process secrets. No further exploit mechanics are detailed in the available facts; defenders should treat any unexpected SMBv1 traffic that elicits unusual responses as potentially malicious and verify behavior against the vendor advisory.

Am I affected? How to find it in your systems

Microsoft SMBv1 server components typically run on Windows workstations, member servers, and domain controllers that still have the legacy SMB 1.0/CIFS File Sharing Support feature enabled. Inventory steps include:

• Query installed Windows features or roles for SMBv1 (PowerShell Get-WindowsOptionalFeature or Get-SmbServerConfiguration on supported releases) and note any host that reports the SMBv1 server as enabled.
• Scan internal networks for TCP port 445 and identify systems that negotiate SMBv1 dialects; disable or isolate any that still accept SMBv1.
• Review configuration baselines and Group Policy objects that may re-enable SMBv1 after it has been turned off.
• Check vulnerability-management or EDR inventories for the CVE identifier and for the presence of the unpatched SMBv1 server component.

Telemetry signs of attempted exploitation are limited in public detail; look for anomalous SMBv1 session establishments, unexpected packet sizes or malformed requests reaching the server, and any subsequent unusual process-memory access or lateral-movement activity. Correlate with authentication logs and endpoint detection alerts. Exact indicators must be confirmed against the vendor advisory and your own threat-intelligence sources.

How to remediate

Apply the security updates Microsoft released for this vulnerability, following the vendor’s instructions exactly. After patching:

• Disable the SMBv1 server where business needs allow; modern Windows releases and most applications no longer require it.
• Enforce SMB signing and reject SMBv1 dialects at the firewall or via Group Policy so that only SMBv2/SMBv3 are accepted.
• Verify the patch level and SMBv1 state across the estate with configuration-management or vulnerability-scanning tools, then document residual exceptions.

CISA’s required action is simply to apply updates per vendor instructions; complete that step first, then harden.

If you can't patch immediately

Until the vendor update can be deployed, reduce exposure with compensating controls:

• Segment or isolate hosts still running SMBv1; block inbound TCP/445 from untrusted networks and restrict it to only necessary management subnets.
• Use host-based or network firewalls, and consider virtual-patching rules on IDS/IPS or WAF-like devices that can drop malformed SMBv1 packets matching known patterns for this class of flaw.
• Disable the SMBv1 server feature entirely if no legacy dependency exists; this removes the attack surface without waiting for the patch cycle.
• Increase monitoring on remaining SMBv1 endpoints—alert on unusual connection volumes, failed negotiations, or post-connection process anomalies—and ensure EDR is running with memory-scraping and lateral-movement detections enabled.

These measures lower risk but do not replace the official update.

If your data may have been exposed

Actively exploited vulnerabilities of this type have been used in ransomware campaigns, so any confirmed or suspected compromise should trigger incident-response procedures: isolate affected hosts, preserve memory and disk evidence, rotate credentials that may have resided in process memory, and hunt for follow-on activity. As a quick external check, you can run a free exposure scan of your email addresses against known breach data sets to see whether related credentials have already appeared in public leaks.