Skip to content

Critical “SMBleed”, Vulnerability: Why Should You Be Worried?

Critical "SMBleed", Vulnerability: Why Should You Be Worried?

This blog is contributed by Apoorv Saxena, technical team, FireCompass.

At the end of May a researcher by the pseudonym “chompie”  published a tweet that showed a working PoC for CVE-2020-0976(SMBGhost), expecting a similar disclosure from the ZecOps security. As part of Microsoft June 2020 Patch release on June 9, ZecOps Researcher disclosed a new vulnerability with PoC in Microsoft SMB named SMBleed. ZecOps combines both SMBGhost and SMBleed to gain unauthenticated RCE and publishes GIF of working PoC. 
The Airbus security team also disclosed one vulnerability: SMBLost, exploitation is possible only if the attacker has user credentials to connect to a remote share folder.
Much lethal combination is SMBBleedingGhost: achieving unauthenticated RCE with SMBGhost and SMBleed.

What is the business impact ?

The vulnerability received a CVSS score of 10, which means if exploited it can have high privileged access to the exploited machine and can move laterally to the connected machines.

Root Cause

The SMBleed vulnerability happens in the Srv2DecompressData function in the srv2.sys SMB server driver, similarly to SMBGhost. It receives the compressed message sent by the client, allocates the required amount of memory, and decompresses the data. 

Then, if the Offset field isn’t zero, the Srv2DecompressData function will take the data placed before the compressed data and copy it, as is, to the beginning of the allocated buffer. See appendix for a simplified version of the function.

Technical Analysis

SMBGhost Inadvertently Revealed

On March 12, Microsoft published an out-of-band advisory for CVE-2020-0796, a remote code execution (RCE) flaw in SMBv3 that was inadvertently revealed in Microsoft’s March 2020 Patch Tuesday release. Within one day, security researchers from KryptosLogic and SophosLabs published proof-of-concept (PoC) scripts that could trigger a blue screen of death (BSoD) on vulnerable systems. At the time there was an expectation that a PoC achieving RCE would be released.

Gaining RCE using CVE-2020-0796

In April, a report from researchers at Ricerca Security states they were able to construct a PoC for CVE-2020-0796 to gain RCE. However, the researchers opted not to publicly share their script to “avoid abuse,” instead offering it to their paying customers.

At the end of May, a researcher known by the pseudonym “chompie” published a tweet that showed a working PoC for CVE-2020-0796 capable of gaining RCE.

One day later, chompie decided to publicly release their PoC for “educational purposes” with the expectation that ZecOps would be publishing a PoC of their own “in the coming days.” The researcher stressed that the PoC “needs some work to be more reliable.”

Wait and SMBleed

On June 9, Microsoft released an advisory for CVE-2020-1206, an information disclosure vulnerability in SMBv3 due to an issue in handling compressed data packets. It was discovered and disclosed by researchers at ZecOps, who have dubbed the flaw “SMBleed.”

SMBleed builds on previous research surrounding SMBGhost. ZecOps published a blog post at the end of March that included a PoC for gaining local privilege escalation using SMBGhost. In their latest blog post, ZecOps says the SMBleed vulnerability exists in Srv2DecompressData, which is “the same function as with SMBGhost.” It is likely that they identified SMBleed during their analysis of SMBGhost.

SMBleedingGhost: Achieving RCE with SMBleed and SMBGhost

ZecOps cautions that unauthenticated exploitation of SMBleed, while possible, is “less straightforward.” As a result, they combined both SMBleed and SMBGhost to gain unauthenticated RCE. They’ve not yet provided technical details about chaining the two flaws together. However, they did share a PoC as well as a GIF that shows them gaining RCE.

Haunted by EternalBlue

In our blog for CVE-2020-0796, we alluded to the potential similarity between SMBGhost and EternalBlue (CVE-2017-0144), an RCE vulnerability in SMBv1 that was used as part of the WannaCry attacks in 2017. The comparison was clear to many, so much so that CVE-2020-0796 was initially dubbed EternalDarkness by security researcher Kevin Beaumont, in addition to its SMBGhost moniker. However, since the vulnerability only affects SMBv3, its potential for a WannaCry-level impact was mitigated by the fact that the flaw only resides in specific versions of Windows, such as Windows 10 and Windows Server 2016.

SMBLost In Space

In addition to SMBleed, Microsoft also released an advisory for CVE-2020-1301, an RCE vulnerability in SMBv1 due to an improper handling of a specially crafted SMBv1 request. The vulnerability was disclosed to Microsoft by researchers at Airbus’ cybersecurity division.

On June 9, Airbus published a blog post by vulnerability researcher Nicolas Delhaye, detailing their discovery of CVE-2020-1301, which they’ve dubbed SMBLost.

Unlike SMBGhost and SMBleed, SMBLost is more akin to EternalBlue because it impacts SMBv1. However, as Delhaye notes in his blog, SMBLost is “much less harmful” than SMBGhost and EternalBlue due to two mitigating circumstances:

  1. SMBLost is post-authentication (valid credentials), whereas SMBGhost and EternalBlue are pre-authentication (no credentials).
  2. The presence of a shared partition on the vulnerable SMBv1 server (e.g. “c:\” or “d:\”) is required for exploitation, which Delhaye notes is “less common.”

Airbus provided a proof of concept for SMBLost in their blog, which results in denial of service (DoS) by way of a BSoD.

As a caveat, the blog post mentions that using SMBLost to gain RCE “seems conceivable,” but they believe it will be “difficult to make it reliable.” In the case of SMBGhost, a similar situation occurred where the only PoCs to emerge initially were for a DoS and Local Privilege Escalation (LPE). While there is no RCE currently available for SMBLost, it is possible that determined researchers or attackers could find a way to develop a reliable PoC to gain RCE in the near future.

How FireCompass Can Help ?

At Firecompass we have a continuous monitoring system which looks at the complete attack surface of the organization and all the exposed services. It notifies the organization in case of rise of new vulnerability through released CVE or through misconfiguration. Get a free scan here


How Can You Fix It ?

There are several ways to mitigate the risk from the SMBleed vulnerability.

1. Windows Update

The most recommended solution is to apply Windows updates: 

Windows Version


Windows 10 Version 1903


Windows 10 Version 1909


Windows 10 Version 2004



Mitigation through workarounds

However, we realize that applying an update is not always an option. This is why we’ve attached several workarounds, which could help mitigate the risk immediately.

2.  Disabling SMB 3.1.1 compression

You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server with the following PowerShell command:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” DisableCompression -Type DWORD -Value 1 -Force


  1. No reboot is needed after making the change. 
  2. This workaround does not prevent exploitation of SMB clients; please see item 2 under FAQ to protect clients. 
  3. SMB Compression is not yet used by Windows or Windows Server, and disabling SMB Compression has no negative performance impact.

You can disable the workaround with the following PowerShell command:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” DisableCompression -Type DWORD -Value 0 –Force 


3. Block TCP port 445 at the enterprise perimeter firewall

TCP port 445 is used to initiate a connection with the affected component. Blocking this port at the network perimeter firewall will help protect systems that are behind that firewall from attempts to exploit this vulnerability. This can help protect networks from attacks that originate outside the enterprise perimeter. Blocking the affected ports at the enterprise perimeter is the best defense to help avoid Internet-based attacks. However, systems could still be vulnerable to attacks from within their enterprise perimeter. 


4. Blocking port 445 inside the enterprise where not needed

Where it is not needed, block port 445 on the relevant assets. This will stop lateral movements using these vulnerabilities.

At Firecompass we have a continuous monitoring system which looks at the complete attack surface of the organization and all the exposed services. It notifies the organization in case of rise of new vulnerability through released CVE or through misconfiguration. Get a free scan here