Using nmap to scan for MS17-010 (CVE-2017-0143 EternalBlue)

Published: 2017-07-01
Last Updated: 2017-07-02 16:09:42 UTC
by Rick Wanner (Version: 2)
13 comment(s)

With both WannaCry and NotPetya using MS17-010 for propagation it is important to be able to detect servers which are vulnerable.  Even if you have comprehensive vulnerability management and patching programs there are almost certainly servers that have been missed, whether because they are vendor supported or part of your company's cottage IT.  It is important to be able to find those servers and either remediate them or put additonal controls in place to protect them.

My fall back to do any kind of discovery scanning is always nmap.  It is easy enough to identify devices that have SMB open using nmap.

nmap -Pn -p445 <ip-netblock>

Starting Nmap 7.40 ( ) at 2017-06-30 23:40 EDT

Nmap scan report for ...

Host is up (0.11s latency).


445/tcp open  microsoft-ds


While detecting SMB is the first step, there are legitimate reasons why a server may have SMB open. For the specific case of finding servers that are vulnerable to MS17-010 we need to dig a bit deeper.

Fortunately, Paulino Calderon has created an nmap NSE script which will reliably detect MS17-010.  The script is not part of the standard nmap NSE scripts, so you will need to go and grab the smb-vuln-ms17-010 script from github and place it into the NSE scripts directory before you can use it (on linux that directory is /usr/share/nmap/scripts/)

This is the nmap command line that seems to work best with this nse script.  (with thanks to Neo23x0)

nmap  -Pn -p445 --open --max-hostgroup 3 --script smb-vuln-ms17-010  <ip_netblock>

When the scan finds a server with SMB open and not vulnerable to MS17-010 then the output looks identical to the previous scan however a vulnerable server will generate additional output.

Starting Nmap 7.40 ( ) at 2017-07-01 11:13 EDT

Nmap scan report for ...

Host is up (0.23s latency).


445/tcp open  microsoft-ds


Host script results:

| smb-vuln-ms17-010: 


|   Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)

|     State: VULNERABLE

|     IDs:  CVE:CVE-2017-0143

|     Risk factor: HIGH

|       A critical remote code execution vulnerability exists in Microsoft SMBv1

|        servers (ms17-010).


|     Disclosure date: 2017-03-14

|     References:





UPDATE: It was pointed out that a version of this script was packaged with the 7.50 version of nmap that was released in mid-June.  For those of you who are not yet on the 7.50 version (like me) you can get the packaged version of the script from the nmap svn repository.  The packaged version is slightly different than the one on github.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - - Twitter:namedeplume (Protected)

13 comment(s)


There is a script with the identical name that shipped with the Windows port of nmap 7.50. Same author listed in the code comments. SHA-256 is 35c37d0eac3d8a83fe5732ff1a58bbbb5d68eae49bd3f599a51153695072836b

The script that shipped with the Windows nmap 7.50 port has a specific reference to github in the code comments, which the script that your piece references does not have. It also contains a clause to the test beginning with "if smb_cmd == 37", as follows:

elseif err == 0xc0000008 then
stdnse.debug1("STATUS_INVALID_HANDLE response received. This system is likely patched.")
return false, "This system is patched."

Is this a different version of the same script, as comparison suggests?
I started testing with this script a number of weeks before 7.50 was released and have been doing all my scanning from Linux. I missed that they bundled smb-vuln-ms17-010 into the 7.50 version. Thanks for pointing that out. For those that are interested the official version of the script is at:

It does appear to be slightly different than the github version. The version on github was last updated May 23rd. I haven't found a way to tell when the nmap version was last modified. Personally I would go with the version distributed with nmap whether you scanning using Windows, OS X, or Linux.
YEah, I received an ERROR: Script execution failed on that ms17 (May 23 13:48). But the default smb-vuln scripts worked fine (old ms10s). So comparing the output I didn't see any vulnerablity flags. Maybe another script will bubble forth soon, thx.

Linux 4.4.0-83-generic on x86_64 & Nmap version 7.01
Both scripts work fine for me. I am on the 7.40 version of nmap on my Linux box.
This is probably a bit of a n00b question, but how do you get an easy to read list out of this, when scanning multiple targets? I have it running, and outputting to XML, which I had hoped would be a bit easier to parse.

I'd like to get a list of just the vulnerable IPs, that I can then hand to the admin teams to hunt down and remedy.

Funny you should mention that. I have been working on the same thing.

It appears that an argument of vulns.short should give you exactly what you want, but I can't seem to get it to work.

That would make the command line:

nmap -Pn -p445 --open --max-hostgroup 3 --script smb-vuln-ms17-010.nse --script-args vulns.short <ip-range>

Let me know if it works for you.
The CSV output option would be more human-readable than XML
I received this error as well. After using the NMAP debugging option, I believe it is generated due to the fact that we do not allow GUEST access to SMB shares. Below is output from debugging. Since I did not specify an account (not sure how to) it defaults to 'guest' and no password.

NSE: SMB: Added account '' to account list
NSE: SMB: Added account 'guest' to account list
NSE: LM Password:
NSE: SMB: Extended login to 10.x.x.x as MYSERVER\guest failed (NT_STATUS_ACCOUNT_DISABLED)
NSE: LM Password:
Rick, "--script-args vulns.short" did the trick, thanks!

Anon, there is a way to specify credentials to use, so it doesn't log in as guest. This is what worked for me:

nmap -Pn -p445 --open --max-hostgroup 3 --script smb-vuln-ms17-010.nse --script-args vulns.short,smbuser=user,smbpass=password <ip-range>
A common problem. The output from nmap is so noisy and hard to correlate. This script is actually one of the worst.

I resorted to copying the script creating: smb-vuln-ms17-010-local

and hacking LUA - I haven't used the determine how to add data to a LUA table.

I chose to add it to the IDS value

action = function(host,port)
local vuln_status, err
local vuln = {
title = "Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)",
IDS = {CVE = 'CVE-2017-0143', HOST = host.ip },
risk_factor = "HIGH",


Run the new script and pipe to grep:

nmap -Pn -p445 --open --max-hostgroup 3 --script smb-vuln-ms17-010-local | grep "IDs"

| IDs: HOST: CVE:CVE-2017-0143
| IDs: HOST: CVE:CVE-2017-0143
| IDs: HOST: CVE:CVE-2017-0143
| IDs: HOST: CVE:CVE-2017-0143

a few more pipes with tr and cut and a nice list is yours!

Diary Archives