During a recent pen test, I was asked to perform an internal vulnerability scan across a number of IP’s on the customer LAN, sounds simple enough right? However, in this particular case, the client firewall configuration had been set to filter all 65,535 TCP and UDP ports. Regardless of this, the client still wanted this to be confirmed through a network scan.
I followed the normal pen test procedure and fired up Nmap with a TCP scan similar to the following:
Shortly after launching the scan, it quickly became apparent that this was not going to be a viable option for scanning, since the finish time was showing around five days to complete! Okay, so this type of behaviour is not uncommon during a pen test; however, let’s see if we can quicken this up
So the next step would be to apply some additional timeouts to reduce the amount of time spent on each port. I issued a command similar to the following:
This dramatically reduced the five days down to around 6 hours, which still was an impractical amount of time seeing as I was only on site for one day.
*Masscan enters into the ring*
This is a product I had previously remembered watching the video from the 2014 Defcon conference entitled “Masscanning the Internet - Defcon 22 (2014)” If you haven’t done so already then I would recommend checking out the video.
I then tried MasScan on the same IP’s scanning for open ports as previously done with Nmap:
The results were MUCH faster, with the scans finishing in under 10 minutes compared to 6 hours!
I was dubious about the integrity of Masscan to begin with and tested it over my own network against Nmap; again Masscan was much faster and produced identical end results. Part of the reason that Masscan is so fast is due to it being an asynchronous design. In other words, it is to nmap what the nginx web-server is to Apache. It has separate transmit and receive threads that are largely independent from each other. Because it's asynchronous, it runs as fast as the underlying packet transmit allows.
Please note that I was only scanning for open ports in this particular instance, should you wish to the scan for service banners you should be aware that Masscan has its’ own TCP/IP stack from the system you run it on. When the local system receives a SYN-ACK from the probed target, it responds with a RST packet that kills the connection before Masscan can grab the banner. The workaround for this would be to specify a source IP different from your own.
The Masscan product comes as standard as part of the Kali package, or is available on GitHub at:
Categories