Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Using nmap to scan for MS17-010 (CVE-2017-0143 EternalBlue) - SANS Internet Storm Center SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms:

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Using nmap to scan for MS17-010 (CVE-2017-0143 EternalBlue)

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)


324 Posts
ISC Handler
Jul 2nd 2017
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.

324 Posts
ISC Handler
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.

324 Posts
ISC Handler
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.

324 Posts
ISC Handler
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!
I wish NMAP would work on this. I have always had a problem trying to get useful data while using it. One thing you could do, is to create a list of IP addresses you need to scan, and to script as scan against those. Then you could grep through the scans to find the vulnerable systems. There is a tool you can use to create this list of IP addresses from a CIDR.
I have been frustrated by this as well. Nmap could easily fix this by simply adding the IP address to each port it discovers. One thing you could do is to create a script that will run NMAP against all the IP addresses you need to scan. There is a web application that will allow you to create the IP list via CIDR. Then you can simply grep through the results.
Running nmap 7.01 on Kali, I got multiple errors when I ran it:

root@kali:/usr/share/nmap/scripts# nmap -Pn -p445 --open --max-hostgroup 3 --script smb-vuln-ms17-010.nse -oN smb-vuln-ms17-010_vLAN3.txt

Starting Nmap 7.01 ( ) at 2017-07-13 17:28 EDT
NSE: failed to initialize the script engine:
/usr/bin/../share/nmap/nse_main.lua:254: /usr/bin/../share/nmap/scripts/smb-vuln-ms17-010.nse:7: unexpected symbol near '<'
stack traceback:
[C]: in function 'assert'
/usr/bin/../share/nmap/nse_main.lua:254: in function 'loadscript'
/usr/bin/../share/nmap/nse_main.lua:582: in function 'new'
/usr/bin/../share/nmap/nse_main.lua:805: in function 'get_chosen_scripts'
/usr/bin/../share/nmap/nse_main.lua:1249: in main chunk
[C]: in ?

Anyone has any ideas why? Do I need to update my nmap??

51 Posts

Sign Up for Free or Log In to start participating in the conversation!