Scanning using Nmap - Part 2

Hi guys,
How were you first scanning attacks? :)
I hope you all enjoyed getting your hands dirty.

Today, we are going to complete what we started in the last article, where we started talking about the steps of "Scanning and Enumeration", and our first step were to find the live hosts on our target's network, and then we started the second step which was port scanning.
Our main tool was Nmap, and because this tool is full of features so I found that 1 article won't be enough at all to cover the basics of Nmap. That's why we are here again to complete what we started.

TCP ACK Scan:
The idea behind the TCP ACK scan is very simple and very smart; I will give you an analogy to get how it is working.
We don’t know each other, right?
Imagine I met you once in the street, and suddenly I went to you and said “hey man, where have you been all of this time? not even a single mail, shame on you?” :)
What will you think? You will say “This man knows me for sure, but probably I don’t remember him”, and then you will start answering me “Oh, I’m fine, and sorry for not sending you mails but I was very busy the last few weeks. I got a baby and…” and you will start talking friendly.

TCP ACK Scan almost works the same, it sends an ACK to the target’s ports, the target will think “it seems like I started a connection with this computer before, let’s answer him”
The targeted port – if open – will check if there is an existing connection already with this computer, if there is no existing connection already (which is our case here) then the answer will be a RST, and if the port is closed then no responses will be sent back.

And because this scan type is just used to check Packet Filtering, so the response to nmap would be “Filtered” or “Unfiltered”
Filtered indicates that there is a Packet Filtering device (may be a firewall) that filters these type of packets, while unfiltered indicates that there is no Packet Filtering devices and that this port might be open or closed.
So the purpose of this scan is not to find open ports on our targets but to audit the rules of Packet Filtering.





The command used is
nmap –sA 192.168.2.31



IDLE Scan:
What was the main disadvantage of all the previous scans?
Whenever they are detected, they will lead to us, because our IP address will be logged, right?

So how can we avoid something like that? IDLE Scan is the ingenious solution for this problem.
IDLE Scan uses another machine (zombie) as an attacker, and spoofs its IP address whenever it communicates with the Target



* First, I choose a machine that will be the Scapegoat or Pivot Point for our attack. This machine has to be an IDLE machine, which means no active traffic on this machine.
Note – Every IP packet on the Internet has a "fragment identification" number or IPID. Many operating systems simply increment this number for every packet they send. So probing for this number can tell an attacker how many packets have been sent since the last probe.
* I will send the Zombie a SYN/ACK, the zombie will see that there is no existing connection established between itself and my machine, so it will send a RST (this RST will include the IPID number)
* I will send a forged packet (spoofed) from my computer to the target (it will appear to the target as if it came from the zombie)
* Please concentrate here very well. If the port on the Target is closed, the target will send the zombie a RST. And the zombie will not send further packets, so its IPID will remain as it is.
If the port on the Target is open, the target will send the zombie a SYN/ACK.
The zombie will find that there is no existing connection with the Target machine, so it will send the Target a RST (remember here that because the zombie is idle, so the IPID will be equal to the previous IPID plus 1.
* Now, it’s my turn again. I will send the zombie a SYN/ACK; the zombie will find that there is no existing connection established between itself and my machine, so it will send a RST.
If the IPID in this RST packet is increased by 1, then it means that the zombie didn’t send any packets back to the Target (which means that the port scanned is closed)
If the IPID in this RST packet is increased by 2, then it means that the zombie sent 1 packet back to the Target (which indicates an open port)

Let’s analyze the nmap command and the output on Wireshark
But before we start, I want you to notice the MAC Address for the machines I’m using

The Attacker’s IP is 192.168.2.47 – 00:0C:29:B0:BC:EF (Backtrack OS)
The Zombie’s IP is 192.168.2.45 – 00:0C:29:68:5A:DD (Windows OS)
The Target’s IP is 192.168.2.31 – 00:0C:29:C6:21:DC (OpenSuSe OS)









The command used is:
Nmap –sI 192.168.2.45 192.168.2.31



Here we will notice that there is not a single packet that shows “My Computer” talking to “My Target”; all the communication is between 192.168.2.45 (the zombie) and 192.168.2.31 (the target)

Let’s analyze one of these packets, to see what the truth is.



Aha, though the connection appeared to be from the zombie to the target, but the MAC address shows the truth, it shows that the MAC address of the source is 00:0C:29:B0:BC:EF (which is the MAC address for My Computer)

I liked this one :)

UDP Scan:
Let’s not forget other protocols as well :)
Because UDP is simpler than TCP; no 3-Way handshaking, no Flags, no Sequence numbers, so the UDP scan is very simplified.
The attacker sends a UDP packet to each port on the Target. There might be here 3 responses; an ICMP Port Unreachable (which indicates a closed port), no response (which means the port might be open or filtered by firewall), or a UDP response



Let’s see what we can get from Nmap:
The command used is
nmap –sU 192.168.2.45

Note – if your target is a Linux, be aware that your scan might take 18 hours or even more because on Linux when Nmap doesn’t receive a response for a UDP Scanning from the Target, Nmap keeps trying till it times out, then it tries to resend the UDP packets again in case of a lost connection. Another reason is that Linux is by design limiting Destination Unreachable messages to a message per second (which is a very long time), so imagine how long it would take to scan 65,536 ports on just 1 machine if every message takes 1 second.

From “Wireshark”, we can see that the attacker is sending a UDP packet to different random ports on our target (The cyan blue lines), and the target is responding with an ICMP Destination Port Unreachable if the port is closed (The black lines)
Note – if you would like to see that the open|filtered ports didn’t respond, just add a filter to your Wireshark such as udp.port==123 (as in our case here). This will show only the NTP packets, and you will see no responses from the port (which indicates either open or filtered)



Version Scanning:
Do you think it would make any difference in your attack if your target’s web server is hosted on an Apache Server 2.2.8 or on Apache Server 2.0.0?
Sure there is a difference, a great difference, Apache 2.2.8 is one of the latest versions which means that it covered all of the bugs and vulnerabilities found in previous versions, while 2.0.0 means that it’s still includes all of the bugs and vulnerabilities found between version 2.2.8 and 2.0.0.
So it means a lot for an attacker to know what software versions is the target running. And here comes the Version Scanning.



First of all, Nmap installation folder contains a file called “nmap-services-probes”, if you open this file with WordPad (on Windows) or KWrite (on Linux) you will be able to see a series of software services and the expected responses. If there is a software service that is not listed there, then Nmap will not be able to support you in detecting the version of this software.

Version detection on nmap has to be accompanied with any of the port scans (TCP SYN scan, TCP FIN scan…), and if no scan type is mentioned in the command line then the default will be a TCP SYN scan.

When the attacker uses the Version detection scan, Nmap starts with a TCP SYN scan and gathers all of the open ports on the target, then it sends some probing traffic to the port trying to identify the service listening on this port. Each port will operate differently according to the service listening on this port.

Let’s see what we can get from Nmap:
The command used is
nmap –sV 192.168.2.31








From “Wireshark”, we can see that the attacker is sending a SYN to different random ports on our target (The grey lines), and the target is responding with RST if the port is closed (The red lines).
If the port is open, then the attacker completes the 3-Way handshake, then it starts generating some traffic to gather more information about the service running on this port.

In our example here, Nmap connects to the SSH service, completes the SSL handshake negotiation and then runs the detection scan to find that the real service behind the SSH is OpenSSH version 4.6.

Guys, what I mentioned in these 2 articles are few of the great options of Nmap; I can’t mention them all otherwise I will end up with a book :).
What I recommend at this moment is to go through a manual page for nmap extracted from a Unix/Linux machine, and start reading and applying what you are reading immediately.

I’m sure we are not finished with Nmap and its great capabilities, but all will come in time.

Till next article,
Take care.