Diving right into it, I finished the ‘Network Enumeration with Nmap‘ section over the weekend and am dragging my feet on the ‘Footprinting’ module this week so I decided to write a short post about the Nmap module and how it is shaping my enumeration methodology. For those who don’t know, NMAP is a free and open source network mapping utility for network discovery and security auditing. It is capable of many things, primarily host and port enumeration, which is what it is used for in the CPTS pathway.
.
.
There are many types of scans that can be performed by Nmap and my goal is not to teach these, so I’ll proceed with the scans that I found useful primarily in the labs of the module. The labs for the Nmap module are directed at evading firewalls and IDS/IPS solutions with Nmap scans, as Nmap scans can generate a lot of noise on a network and lead to your attack IP being banned if detected. This is usually caused by rate limiting or IDS systems detecting a list of ports being scanned by a single IP. To avoid this, you can add spoofed IP ranges with the -D RND:# flag, which will generate a set amount of random IP’s that are specified as the source address. This can increase the time it takes to scan and can be noisy.
.
.
The first lab was labeled ‘easy‘, and believe it or not it was the one I had the hardest time with. The goal of lab 1 is to identify which operating system the machine was running on via Nmap OS detection. There was a detection counter hosted on port 80 that could be refreshed to see the IDS/IPS detections from the script. The common script that I attempted for the initial port enumeration is below:
sudo nmap 10.x.x.x -sS -Pn -n --disable-arp-ping --reason -T2
This gave me a general overview of the ports open on the machine and their statuses. It also did not increment the detection counter. So naturally my next scan was the following:
sudo nmap 10.x.x.x -sS -O -Pn -n --disable-arp-ping --reason
The -O operator performed OS detection and came back with different results as I ran it with a couple different flags, including -sA, -sT, -sU. Two of the main results were ‘Tomato‘ and ‘Linux 2.1.x‘ if I recall correctly. Neither of these were the correct answer for the lab, and after running nmap another 10 times I decided to see if it was an issue with my syntax by visiting the forum. Here I found that the question was actually asking for the -sV flag, which can determine which version of software is running on a port. This contained the correct answer, although I argue that it was not an OS but a distribution that was being requested, hence my confusion.
.
.
Following this, the second lab, ‘medium‘ was easy. I learned a trick from the course content that seems to be pretty effective. Set the –source-port 53, DNS, as sysadmins often allow all on suspected DNS traffic. Using this and the -sU flag, I was able to find the flag in the DNS server version running on port 53.
sudo nmap 10.x.x.x -sU -Pn -n -V --source-port 53 -- or something similar to this is what I used.
.
.
The ‘hard‘ lab was the easiest, as there was nearly a step-by-step guide to complete it in the course content. The methodology was simple for this as well, run a basic scan to check for ports and statuses, run a second scan to determine if you can get past the firewall, and lastly the trick was to use ncat to banner grab the flag from the service port. I won’t post the actual command here, because it’s easy enough to find on your own and I don’t want to spoil any of these challenges.
.
.
Overall, I would say to begin your methodology with a quick and soft scan to determine what ports are open, then perform increasingly complex scans in a stealthily fashion to determine what firewall rules are being used. Using the DNS source port is a smart workaround that I imagine is a common misconfiguration. Next, I’ll be posting about a handful of service enumeration techniques, from FTP to SMB, NFS, DNS, SMTP, etc. I’ll probably split this into two posts as there’s a lot to cover and I need to stop posting text walls. Thanks for reading.

Leave a comment