TheTAZZone - Internet Chaos

2007 A Hacking Odessey Part 2 – Continued


Do not use, republish, in whole or in part, without the consent of the Author. TheTAZZone policy is that Authors retain the rights to the work they submit and/or post…we do not sell, publish, transmit, or have the right to give permission for such…TheTAZZone merely retains the right to use, retain, and publish submitted work within it’s Network


[quote]I had to split this paper in to two parts due to post size limits; please find the first half of this paper here:[/quote]
[b]9) Idle Scanning -sI[/b]

Idle scanning is perhaps a more realistic way of obscuring your real location on the www. Although FTP bounce scans will work, there are a lot of variables that have to fall into place. Wouldn’t it be better if we could use something that does not require logon details? Well, luckily for us there is a way we can use another host to bounce our probes off without anyone knowing we are doing it.

A little knowledge of TCP and IP is needed to totally understand how an Idle Scan works; if you are not too familiar with these protocols I would suggest you read [url=]THIS[/url] to allow you to follow the following few paragraphs more closely.

Part of an IP header includes the IP ID. This is used in case any fragmentation occurs whilst this packet is on its travels around the LAN/Internet.
For example; say you send an email, following the rules of OSI this will go through all the various layers until it ends up as a frame and ready to be place on the Ethernet cables as voltages and sent to wherever it is destined for.

During its trip down the OSI model it will pass the IP part of the Network layer – here, amongst other things, if will be assigned a unique identifier called the IP ID. We will say our email fits into on packet and this packet is assigned the IP ID of 3333.

This packet becomes a frame when it reaches layer 2, and it converted to bits and sent on to the actual cable at layer one.

On its travels it bumps into a router. This router decides that the packet is too big to be routed and sent any further, so decided to fragment the packet in to two parts and send it on its way.

Now, without the IP ID, when the receiving station received these two packets it would have absolutely no way to tell that they were originally part of the same packet and hence the same email, resulting in your email not being delivered.

What would have happened (in layman’s terms) is when the router decided to fragment the packet it will have added one to the IP ID, so IP ID + 1. The IP ID was 3333 for our packet, so the router will have left the first packets IP ID as 3333 but will have incremented the other packets to 3333-1, if it had fragmented it into three the thirds IP ID will be 3333-2 on so on.

Now when the packet arrives at the receiving host it looks at the IP ID, sees that the two packets have the same IP ID, looks for the incremented on (3333-1) and reconstructs the packet – sends it on its way up the OSI resulting in the email being displayed on your screen.

** It is a bit more complicated than this as things like Fragment Offsets are used – the ‘-1’ is not literally added to the IP ID but you get the general idea**

But how does all this help us scan a target?

As I mentioned, the IP ID is a unique identifier to that packet and as such the next packet the host sends must have a new IP ID. Windows, FreeBSD and some Linux boxes all increment the IP ID by a set variable for each packet. So after sending our email with the IP ID of 3333, if the set variable was one, our next email will have the IP ID of 3334, etc. (For the remainder of this chapter we will say it increments by one)

As we know from the previous chapters, if a SYN packet arrives out of the blue then the receiving host will presume that someone wants to open a TCP connection to it and will respond with a SYN|ACK. However if a SYN|ACK arrives out of the blue then a RST packet is sent back to the initiating host. Finally, if a RST packet arrives out of the blue then the packet is to be dropped and nothing is to be returned. – remember this!

If we were to spoof the source IP address of our probe and send a SYN packet to our target, following the above reasoning the target would have to send a SYN|ACK packet back to whatever the IP address is we spoofed in the probe. Obviously our spoofed host did not send the initial SYN packet in the first place, so will be forced to respond with to the unsolicited SYN|ACK packet with a RST packet.

Again following the above mentioned rules, if we send a SYN packet to our target with a spoofed source IP address but the port is closed, then the target will send a RST packet back to our unsuspecting host – however as a RST packet required no further action our spoofed host will not need to send any packets back to the target machine.

Some of you may have already worked out how we can abuse these rules of TCP and make them work to our advantage.

If we send a SYN|ACK packet to the host we want to use as a zombie (the IP address we are going to spoof), when it replies with a RST packet we are able to see the IP ID it uses. If we then send another SYN|ACK packet, the zombie will again reply to it and we will see the new IP ID – simple maths will tell us by how much it has incremented. We can carry on doing this until we are positive we have worked out how much it will increment by.

[quote] –> TCP; D=80 S=59242 SYN ACK=9995679210 SEQ=153927672 LEN=0 WIN=3042 –> TCP; D=59242 S=80 RST WIN=0 [b]ID=4532[/b] –> TCP; D=80 S=61347 SYN ACK=9995679210 SEQ=153927495 LEN=0 WIN=3042 –> TCP; D=61347 S=80 RST WIN=0 [b]ID=4533[/b]

If you look at the above [edited] output you can see that sent a packet to, the packet was [b]TCP[/b] the [b]d[/b]estination port was [b]80[/b], the [b]s[/b]ource port was [b]59242[/b], it was a [b]SYN ACK[/b] packet with a [b]seq[/b]uence number of [b]153927672[/b]

Then as we know a RST packet should be sent in reply to an unsolicited SYN|ACK. sent a packet to which was [b]TCP[/b] [b]d[/b]estined to port [b]59242[/b] with a [b]s[/b]ource port of [b]80[/b], it was a [b]RST[/b] packet and had the [b]IP ID of 4532[/b]

The second trace shows the same types of packets but note that the IP ID has gone up by one. We do this as many times as is necessary to determine that a) the host is idle and b) we are sure what the IP ID is incremented by.

If the IP ID shows no set pattern and increments by a seemingly random amount each time, then chances are the host is not idle – Nmap will very helpfully tell us if this happens.

So, after working out that our zombie host is indeed idle and that the IP ID is incrementing by one each time we probe it; we then send a SYN packet to out TARGET but with source IP of our ZOMBIE – the target responds to the SYN request with a SYN|ACK and send this to our zombie, the zombie receiving this SYN|ACK out of the blue will respond with a RST packet – therefore increasing its IP ID by one. If we now send a SYN|ACK to our zombie the RST packet the is sent by way or a reply to us will have an IP ID +2 from when we last probed it as it has just sent a RST packet to our target.

If the port on our target is closed it will send a RST packet to our zombie and as we know the zombie will not reply to that RST packet, so when we probe it again the IP ID will increase by +1 and not +2.

[u] Learn the IP ID[/u]
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->—>—>—> SYN|ACK –>–>–>–>–>- + Zombie +
+ STEP 2 +
+ +—<---<---<-RST (IP ID=1000) <---<---<-+ + +++++++++++++ ++++++++++++++ +++++++++++++ ++++++++++++++ + + STEP 1 + + + US +->—>—>—> SYN|ACK –>–>–>–>–>- + Zombie +
+ STEP 2 +
+ +—<---<---<-RST (IP ID=1001 <---<---<--+ + +++++++++++++ ++++++++++++++ +++++++++++++ ++++++++++++++ + + STEP 1 + + + US +->—>—>—> SYN|ACK –>–>–>–>–>- + Zombie +
+ STEP 2 +
+ +—<---<---<-RST (IP ID=1002) <---<---<-+ + +++++++++++++ ++++++++++++++ [/code] [u]If the port is open[/u] Once we have learnt the IP ID and that it increments by one, we can launch our Idle Scan against the target. [code] +++++++++++++ ++++++++++++++ + + STEP 1 + + + US +->->SYN(Fake source IP>->+ Target +
+ +
+ + + +
+++++++++++++ ++++++++++++++
Step 2 SYN|ACK | |
To spoofed IP SYN ^
Responding to ACK |
Our SYN packet | RST—
| | |
++++++++++++++ |
+ + |
+ Zombie + |
+ |
+ + |
++++++++++++++ |
Step 3 RST
The Zombie responds to the SYN|ACK with a RST, thereby increasing its IP ID by one. If we now send a SYN|ACK direct to the Zombie we can look at the IP ID and see if it has been incremented or not. If it has incremented a RST must have been sent, indicating the port on the target is open.


Now we probe out zombie to learn the IP ID:

+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->—>—>—> SYN|ACK –>–>–>–>–>- + Zombie +
+ STEP 2 +
+ +—<---<---<-RST (IP ID=1004) <---<---<-+ + +++++++++++++ ++++++++++++++ [/code] We left the IP ID at 1002, it is now 1004 which indicates that a packet has been sent in response to our probe directed towards out target. This tells Nmap that a SYN|ACK came from the target to the zombie and that the port is open. [u]If the port is closed[/u] [code] +++++++++++++ ++++++++++++++ + + STEP 1 + + + US +->->SYN(Fake source IP>->+ Target +
+ +
+ + + +
+++++++++++++ ++++++++++++++
Step 2 RST |
To spoofed IP RST
Responding to |
our SYN packet |
as the port is |
closed ++++++++++++++
+ +
+ Zombie +
+ +
——————————– ++++++++++++++
As we know nothing is sent in response to an unsolicited RST packet therefore our Zombie does not reply and the IP ID does not increment by one.

+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->—>—>—> SYN|ACK –>–>–>–>–>- + Zombie +
+ STEP 2 +
+ +—<---<---<-RST (IP ID=1003) <---<---<-+ + +++++++++++++ ++++++++++++++ [/code] We left the IP ID at 1002, as it is now 1003 we know that it could not have possibly replied to the target host indicating a RST packet was sent to the zombie in response to our SYN packet. This tells Nmap that the port was closed and it will report it to you as such. **If you do not tell Nmap to not ping the host (-P0, covered later) then it will first send an ICMP request to the host from [i]your real IP address[/i]. So consider using the –P0 option, however Nmap does use ICMP to determine scan speeds etc so it may lead to more unreliable results** You should be able to better understand why the host has to be idle for this scan to work; if it is not we will not be able to tell the IP ID incremented due to our probe to the target machine or due to normal traffic. There are more uses for this type of scan, or to log the IP ID of a host to be more exact as it can be used to gauge how busy the client is, if there is a cluster of nodes using a virtual IP; in fact Fyodor posts an example of this on his site using hping: [quote] # hping2 -c 10 -i 1 -p 80 -S HPING (eth0 S set, 40 headers + 0 data bytes 46 bytes from flags=SA seq=0 ttl=56 id=57645 win=16616 rtt=21.2 ms 46 bytes from flags=SA seq=1 ttl=56 id=57650 win=16616 rtt=21.4 ms 46 bytes from flags=RA seq=2 ttl=56 id=18574 win=0 rtt=21.3 ms 46 bytes from flags=RA seq=3 ttl=56 id=18587 win=0 rtt=21.1 ms 46 bytes from flags=RA seq=4 ttl=56 id=18588 win=0 rtt=21.2 ms 46 bytes from flags=SA seq=5 ttl=56 id=57741 win=16616 rtt=21.2 ms 46 bytes from flags=RA seq=6 ttl=56 id=18589 win=0 rtt=21.2 ms 46 bytes from flags=SA seq=7 ttl=56 id=57742 win=16616 rtt=21.7 ms 46 bytes from flags=SA seq=8 ttl=56 id=57743 win=16616 rtt=21.6 ms 46 bytes from flags=SA seq=9 ttl=56 id=57744 win=16616 rtt=21.3 ms [/quote] As you can see for the [IP] ID there are obviously two different hosts sitting on that particular IP. Idle scanning can also be used to test out firewall rules that only allow access from certain IP addresses. Obviously you will need to find out what the allowed IP address is. If you scan a target that is located behind a firewall that is only allowing packets from a certain IP address to reach it, your probes will all be dropped (Nmap will show them as filtered), however if you spoof the source IP to an allowed one your probes will get through and you can check the host who does actually have the real IP you spoofed to see if the IP ID is incrementing or not. There are a lot of variables that need to be known and fall into place to allow the above to happen, but nonetheless it is possible. IP ID detection is also used in OS detection too, as certain OS’s increment it by certain amounts. The syntax for an idle scan is: namp –sI zombie IP > Target IP

Nmap –sI

[b]10) Window Scan –sW[/b]

If you take a closer look at the above trace outputs and the descriptions I gave of each field you may notice I didn’t describe what the WIN=xxxx field is for. This is because I wanted to talk about it here instead.

[quote] –> TCP; D=21 S=56545 ACK=0 LEN=0 [b]WIN=3042[/b] –> TCP; D=56545 S=21 RST [b]WIN=0 [/b]ID=5324 –> TCP; D=23 S=61513 ACK=0 SEQ LEN=0 [b]WIN=3042[/b] –> TCP; D=61513 S=23 RST [b]WIN=0[/b] ID=5325

As we all know TCP is a stateful connection with error checking. The error checking part of this means that both parties involved need to verify that what has been sent is actually what is received.

To ensure complete error checking not only do the individual packets needs to be checked but the amount of packets sent needs to be checked also. It’s no use having a method of checking that packets are intact, if you can’t check you have received all of them in the first place.

TCP packets included a Cyclic Redundancy Check (CRC) commonly referred to as a Checksum which pertains to the integrity of the packet. This is a mathematical algorithm that is derived by the size of the TCP packet – this produces a result which is added to the tail end of the TCP header. When the receiving station receives the TCP packet it will put it through the exact same mathematical algorithm that the sending station used and compare the result with the number in the checksum field. If the data has been altered even minutely the checksum result will be wildly different and a request for the retransmission of the packet is sent.

That takes care of the individual packets, but does not provide anyway of checking if all of the packets have been received. Obviously if we don’t get all of the data the CRC checks will still be valid but the data will be useless to us.

For this reason another option in the TCP header that needs to be set is the Window size (nothing to do with the Windows OS). This Window size tells the sending station how much data to send, before it will need an acknowledgment from the receiving station, or to be more exact how much unacknowledged data can be in the connection flow.

So, say during the initial three-way handshake the window size is set to 64KB. The sending station will send 64KB of data and then stop. It will now wait for an acknowledgment to come from the receiving station to say how much data is has received. If it comes back saying it has received 64KB then all is well and the traffic flow commences for another 64KB. If it comes back saying it has only received 32KB then something has gone wrong and some data needs to be resent – as there is still the 64KB limit for unacknowledged traffic to be sent in the connection the sending station can only send another 32KB until an acknowledgement is needed (the receiving host has only acknowledged 32KB of it, so if any data exceeding 32KB is sent then there will be a violation of the initial 64KB limit that was established)

You may be thinking, that’s very nice but how do this help us port scan a remote host though?

Well, if you study the trace even [i]more[/i] closely you will see a sort of pattern that the different packets follow:

[code] –> TCP; D=21 S=56545 ACK=0 LEN=0 [b]WIN=3042[/b] –> TCP; D=56545 S=21 RST [b]WIN=0 [/b]ID=5324 –> TCP; D=23 S=61513 ACK=0 SEQ LEN=0 [b]WIN=3042[/b] –> TCP; D=61513 S=23 RST [b]WIN=0[/b] ID=5325

See if you can work it out with before reading on……

The WIN sizes of the RST packets are all ‘0’. Why would this be?

As we know from our ACK scan, if an ACK comes in to a port then a RST is sent back regardless of if the port is open or closed, BUT if the port does happen to be closed then no further communications can occur on that port anyway, so why send back a value telling the initiating host how much data it can send before it needs an acknowledgment if the port is closed? There is no need to do this, so the WIN size is 0 on a RST packet from a closed port in response to an ACK. Also, as there is no service sitting behind the port to set the WIN size the default will also be 0.

This tells Nmap that the port is closed.

If the port is open then yes a RST packet is still sent in response to an unsolicited ACK packet, however as there is a service sitting on that port to set the WIN size and further communication is possible, then the WIN size may be set to a non-zero value:

[quote] –> TCP; D=80 S=51876 ACK=0 LEN=0 [b]WIN=3042[/b] –> TCP; D=51876 S=80 RST [b]WIN=4096 [/b]ID=5378 –> TCP; D=8080 S=64281 ACK=0 SEQ LEN=0 [b]WIN=3042[/b] –> TCP; D=64281 S=8080 RST [b]WIN=4096[/b] ID=5379

So, although a RST is still sent back, there WIN size is 4096 and Nmap will inform us that the port is open.

This method is very similar to the ACK scan mentioned earlier, however as we know the ACK scan can’t determine open or closed ports (as a RST is sent by both) and is mainly used for packet filtering auditing, whereas the WIN scan can make an informed guess by looking at the WIN size to see if the port is open or not.

If you are able to put yourself in front of a host in such a way that you can sniff the traffic going to it, you could use this method to port scan a target with a spoofed IP address that is maybe behind a packet filtering device.

If you sent an ACK scan to a host on a DMZ (behind a packet filtering device) with a spoofed source IP, the responses would go back to the host with the IP you have spoofed. By looking at these responses via sniffing, you will be able to determine if the packets got through to the DMZ host and if the port is open – just by looking at the WIN size of the packet, and of course all logs lead back to the host whose IP you spoofed. The host does not have to be idle either.

Of course this will also work for normal port scans via a spoofed IP as you will be able to see all the responses going back to the host with the real IP – as you have absolutely nothing to do with this host and have never sent a single packet to it, then this is truly an anonymous method of scanning with endless variants on port scanning techniques.

Sadly once again Nmap becomes a victim of its own success. Since there are literally hundreds of papers out there detailing how the various Nmap scans work, it was relatively simple for manufactures to make the RST packet from a closed port include a non-zero WIN value, which in effect ‘breaks’ this type of scan.

That being said, there are still a large number of un-patched/legacy machines out there that are susceptible to this type of scan.

The syntax for a Window scan is: nmap –sW ip address

Nmap –sW

[b]11) Maimon scan –sM[/b]

Lastly for those who want to scan BSD boxes the Maimon scan may come in useful.

Uriel Maimon discovered that sending a FIN/ACK probe to a BSD box resulted in the probe being dropped if the port was open, and a RST being returned by a closed port, whereas non BSD boxed would return a RST regardless of the port state.

The syntax for this scan is: nmap –sM ip address

Nmap –sM

That covers all available ‘type of scan’ available to Nmap users when scaning TCP ports, there are a lot of options to use in conjunction with these scan types which I will cover shortly after I have explained UDP scanning.

[u][b]12)UDP Scanning[/b][/u]

Due to the nature of User Datagram Protocol (UDP) and its connectionless method of data transmission it is very hard to reliably scan the UDP stack of ports.

We already know that a TCP session requires a three-way handshake, ergo if we send a SYN packet we will get a SYN|ACK back from an open port.

UDP does not have anything in its rules to say it has got to send a single thing back in response to a packet arriving at an open port.

If we send a packet to a closed port we may get an ICMP type 3 code 3 reply – port unreachable. If this happened Nmap will inform us that the port is closed.

If any other ICMP type 3 messages are returned such as Host unreachable (code 1), Protocol unreachable (type 2) etc then Nmap will mark the port down as filtered – meaning something is receiving the probes but it may not be the interned target, i.e. it may be a packet filter of some kind, hence Nmap can’t say if the port is open or closed.

If no reply is received from the probe then the port is displayed as open|filtered which means that Nmap was unable to confirm the port was definitely closed hence could be open or be behind a packet filter of some kind.

As you can see due to the unreliable nature of UDP port scanning via empty USP datagram’s is a fairly unreliable method to use.

It is usually the service that replies on a UDP port – take port 53 for example which is the DNS port. If you send an empty UDP probe to it (which is what Nmap will do with the default USP scan) then the DNS server is never going to reply to it – why should it as there are no rules such as those in TCP to say it has to.

However if you conduct a ‘version scan’ ,which I will cover next, then Nmap will try to connect to the service that listens on the port by default.

So take our DNS service on port 53 for example – Nmap knows DNS uses UDP:53 so by carrying out a version scan Nmap will consult its database, look for a nslookup query and send it out to the target on port 53. If a reply comes back to this DNS query then Nmap will inform you that the port was open.

As you can see, for UDP ports it is the actual service that will reply to Nmap, but to get it to reply we need to give it information it can understand, not just a blank UDP packet. For this reason usually a version scan is conducted in conjunction to the UDP scan.

Timing is another issue with UDP scanning, as most operating systems (especially Linux) will limit the rate that the ICMP type 3 messages can be sent out at. Most set it to one every second but this can be changed manually by the user of the machine. If nmap has to wait one second for every probe on every port and you are scanning all 65,536 ports then you are going to be in for a long wait…….

The syntax for a UDP scan is: nmap –sU ip address

nmap –sU

It is possible to conduct a TCP scan and a UDP scan at the same time:

nmap –sT –sU

[b][u]Version Scanning[/b][/u]

All of the above is great providing that any services are using the port number they are meant to, i.e. the mail server is listening on port 25 and the FTP server is listening on port 21 etc.

There is however nothing illegal about setting your FTP server to use port 54321 and setting your mail server to use port 60000. In fact some companies do this to certain services and PAT/Port Forward them on to the correct port internally.

+++++++++++++ ++++++++++
+ + +Firewall+
+ Us +FTP logon request port 54321 + +
+—>—>—>—>—>—>–>–>+>–> +
+ + ftp + V +
+++++++++++++ + | +
+ V +
+ | +FTP request port 21
+ >–>–>–>–>- ++++++++
++++++++++ + +
+ +
The firewall will take the FTP traffic destined for 54321 + FTP +
and will be configured to Port Forward the request to +Server+
the FTP server on Port 21. To our knowledge the FTP Server + +
is listening at ‘’. A basic port scan + +
will only tell us that port 54321 is open, it won’t say what ++++++++
is listening behind it, which is where the version scan comes
in handy as we will now know there is an FTP service there.

So the old security by obscurity technique, whereby reconfiguring the default ports your service listens on to confuse would be attackers, does not really help anymore.

But how does Nmap know it is an FTP server listen on port 54321?

To accomplish this is does something called Banner Grabbing. To demonstrate Banner Grabbing it is best to show it first hand; so if you open up a command prompt (go to Start > Run > type cmd > press enter, if you don’t know how to do this). You will know have a black command window open.

Type: ftp

C:\Documents and Settings\Nokia>ftp

Once you have successfully connected, you will be greeted with some information:

Connected to
220 FTP server ready.
User (
530 Please login with USER and PASS.

This information is known as the banner and is what Nmap will grab. Once it has this banner it will compare it to an internal database and look for a match, it will also continue to probe the service to solicit as many responses as possible to enable it to get an accurate result.

If you really want to continue logging in to the FTP server with anonymous credentials, you can do like so:
ftp> user anonymous
331 Guest login ok, send your complete e-mail address as password.
230-Welcome to the FTP server for the WU-FTPD Development Group
230-This server is the primary distribution site for the WU-FTPD daemon.
230-The pub directory contains the distribution and supporting files.
230-If you are uploading contributions; please place them in the incoming
230-directory and email announcing your upload.
230 Guest login ok, access restrictions apply.

Ok, well this is all well and good but what has it got to do with version scanning? Well although we were able to identify this as an FTP server by trying to connect to it via FTP on the default port, what version FTP server is it using? If we wanted to try and exploit it we will need to know the version to know what vulnerabilities it has.

It may also be of interest to know if there is anything else listening on it, so let’s give it a quick SYN scan:

C:\Documents and Settings\Nokia>nmap

Starting Nmap 4.20 ( ) at 2007-02-24 18:39 GMT Standard Time

Interesting ports on
Not shown: 1692 closed ports
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
26/tcp open unknown
80/tcp open http

Nmap finished: 1 IP address (1 host up) scanned in 334.140 seconds

We can see there are FTP, SSH, Mail and Web servers available to connect to. However Nmap only makes this determination by listing what [i]should[/i] be using those ports – if the mail server was listening on port 80, Nmap would still list is as HTTP. We could telnet and SSH to all the different ports and see if any banners are displayed, however an Nmap version scan will be much more productive for us and tell us exactly what services are using these open ports, which is informative if we want to try and exploit these services.

Go and Google “generic mail server exploit”……… Good luck with that….however if you Google ‘remote exploit Exchange 2003 sp1’ you will get a lot of hits, if you Google ‘remote exploit exchange 2003 sp2’, you will get a different set of hits…..knowing the version and patch state is essential to exploiting any service.

Take a look at port 26… are we going to exploit that? Well we could nip over to the IANA web site and see what [i]should[/i] be running on port 26:

# 26/tcp Unassigned
# 26/udp Unassigned

Hmmmm, that’s no help…..

So, let’s fire Nmap up and see if that can tell us more information about port 26 and the others, to enable us to narrow our search for an exploit:

C:\Documents and Settings\Nokia>nmap -sV

Starting Nmap 4.03 ( ) at 2007-02-24 18:03 GMT St
dard Time

Interesting ports on
(The 1669 ports scanned but not shown below are in state: closed)
21/tcp open ftp
22/tcp open ssh SSH 1.2.33 (protocol 1.5)
25/tcp open smtp Postfix smtpd
26/tcp open ssh OpenSSH 3.1p1 (protocol 1.99)
80/tcp open http?

Good, so now we know it is an SSH service listening on port 26; version OpenSSH 3.1p1 using protocol 1.99 to be exact. A Google search for ‘remote exploit OpenSSH 3.1p1 protocol 1.99’ will help tremendously if you wanted to try and exploit this service.

So now not only do we know what type of service is listening on the port, we also know the exact version number and patch state of it and can start researching the various vulnerabilities that this service suffers from.

We can see what version Mail Server is on port 23 and that there is a different SSH deamon listening on port 22.

However, we didn’t get lucky with the FTP and Web server this time as the second part of Nmap’s output shows us:

2 services unrecognized despite returning data. If you know the service/version
please submit the following fingerprints at
vicefp-submit.cgi :
SF:n\r\n\r\n\x20\r\n\x20\x20WU-FTPD\x20Development<br /> SF:\x20Group\r\n\x20\r\n\r\n\x20\r\n\x20\x20\r\n\x20\x20\x20WU-FTPD\x20Development\x20Group\r






  • \n\n400\x20<br /> SF:Bad\x20Request\n\n






    Here is your change to help Nmap’s usefulness with regard to version scanning. It very kindly asks us to go to a URL and submit the fingerprint we received.

    The nmap-service-probe file which can be found in your install directory holds all the fingerprints that Nmap can currently use to compare banners and probe responses against. This was last updated on 10th Jan 07 (version 4.21ALPHA2) and is updated on a regular basis only because its users submit fingerprints to be included in it.

    The more fingerprints is has, the more reliable it will become. So if you know what the service is, pop along to and submit your fingerprints that Nmap does not recognise. C+P everything that has an SF: at the beginning of the line.

    Likewise if you think that something is being reported wrongly and want to tell the Nmap developers about it, then a URL is provided for this also:

    Service detection performed. Please report any incorrect results at http://insec .
    Nmap finished: 1 IP address (1 host up) scanned in 192.594 seconds

    I included the FTP service in this paper to inform of the fingerprint submission page and to encourage you to do it and also to demonstrate the fact that you should not rely on the one tool to do everything for you. Nmap is good but it is not perfect, if it returns a null value for something like a version scan then you can always telnet in to the port and take a look for yourself – Nmap just automates this procedure but may sometimes provide more information then we can get manually due to the large database it has.

    Our main lesson here was port 26 – nmap was able to inform us of the service and version of that service to allow us to progress with our assessment/attack further….SSH using a non default port…

    This can also be used for the power of good and enable Sys Admins to determine versions of services and their patch state on an internal LAN in a relatively small amount of time.

    The final thing to say is that it is always a good idea to include this with a UDP scan to improve the reliability of UDP results.

    The syntax for this scan is: nmap –sV ip address

    nmap –sV

    [b][u]Ping Sweeps[/b][/u]

    A lot of people don’t understand Nmap’s full potential when it comes to ‘ping’. Typically a ping refers to an ICMP echo request being sent to a host and an ICMP echo reply being sent back to the initiating host. For the majority of people this is enough to determine if a host is up or down.

    However, it is considered good security practise in today’s world to block most ICMP types from entering a network – take a PIX firewall for example, by default it will block every ICMP type from coming in to the network it is protecting – so an internal users can send the ICMP echo request out to the Internet but the reply will never get back in, resulting in a **timed out** being displayed to the user.

    This can really mess Nmap up if using the default scan options as the first thing it will do is try and ping the host – if no reply is received the scan will be aborted.

    To overcome this obstacle we can simply use the –P0 switch in our command, which will tell Nmap to not ping the host we are scanning; a fact which Nmap will helpfully inform us of:

    C:\Documents and Settings\Nokia>nmap -sT

    Starting Nmap 4.20 ( ) at 2007-02-25 13:55 GMT Standard Time

    Note: Host seems down. If it is really up, but blocking our ping probes, try -P0

    Nmap finished: 1 IP address (0 hosts up) scanned in 3.937 seconds

    With the –P0 option:

    C:\Documents and Settings\Nokia>nmap -P0 -sT

    Starting Nmap 4.20 ( ) at 2007-02-25 13:55 GMT Standard Time

    Stats: 0:03:16 elapsed; 0 hosts completed (1 up), 1 undergoing Connect() Scan
    Connect() Scan Timing: About 72.66% done; ETC: 14:00 (0:01:13 remaining)
    Interesting ports on
    Not shown: 1696 filtered ports
    80/tcp open http

    Nmap finished: 1 IP address (1 host up) scanned in 253.344 seconds

    So either the host is sting behind a firewall of some kind that is blocking ICMP or the host itself is ignoring our ICMP packets.

    (Try an ACK scan to see if you can determine if it is behind a packet filter or maybe a stateful firewall, and maybe what it will allow through it)

    Nmap does you ICMP response times to judge the speed of its scan, so you may run in to timing issues if you use the –P0 switch.

    If you are using the Idle Scan option or spoofing your IP address it is a good idea to use the -P0 option as Nmap will use your real IP address to ping the host before starting the scan – it can’t use the spoofed IP address as it needs to receive the ICMP echo request back.

    However, as mentioned Nmap does not always think of ping in the typical ICMP way but we may still need to ping a host that is behind a firewall which is blocking all ICMP types. How can we do this?

    Nmap includes a range of non ICMP pings:

    Nmap can determine if a host is alive and the latency to that host be sending a variety of TCP packets with different flags set, to a specific port; known as a TCP ping.

    [b]TCP ACK:[/b]

    In the same way the TCP ACK scan works, Nmap can send a TCP packet to a specific port on a host with the ACK bit set. Just like the ACK scan if a RST packet is returned Nmap will deem the host to be alive, if not RST is received Nmap deems the host to either be ‘dead’ or that the packets where filtered.

    So even though ICMP may be blocked we could ping it with a TCP packet instead.

    Do not think of this as a port scan as it is not; its sole aim is to detect if a host is alive behind a given IP address that may have ICMP filtering active.

    The syntax for it is PA:

    nmap –PA25

    You can still specify a normal scan option too if you so desire:

    nmap –sT –PA25

    If you want to ping multiple port simply separate them with a comma.

    To prove it works, consider the following output:

    C:\Documents and Settings\Nokia>ping

    Pinging with 32 bytes of data:

    Request timed out.
    Request timed out.
    Request timed out.
    Request timed out.

    Ping statistics for
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

    So something is blocking ICMP from reaching that host; lets try the TCP ACK Ping:

    C:\Documents and Settings\Nokia>nmap -PA80

    Starting Nmap 4.20 ( ) at 2007-03-02 20:18 GMT Standard Time

    Stats: 0:00:01 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
    SYN Stealth Scan Timing: About 1.41% done; ETC: 20:18 (0:00:28 remaining)

    By pressing the space bar we can get Nmap to give us some information to tell us what stage it is at. Notice the ‘0 hosts completed (1 up)’ part – Nmap has successfully pinged the host with a non ICMP packet. ‘(1 up)’.

    [b]TCP SYN Ping:[/b]

    The TCP SYN Ping is exactly the same as a TCP ACK Ping, except is uses a SYN packet instead of an ACK packet. Stateful firewalls with usually filter out unsolicited ACK packets, hence a TCP ACK Ping may fail. To overcome this we can ping a host on a well known port that we thing may have a chance of getting through a firewall – usually ports 80 and 25.

    We will send a SYN packet to make the firewall think we want to establish a valid connection to the service that is listening on that port.

    The syntax is:

    Nmap -PS

    Again separate multiple port numbers with a comma.

    [b]UDP Ping:[/b]

    A UDP ping works in conjunction with ICMP and relies on an ICMP Port Unreachable message to be retuned by the host if a UDP packet is sent to a closed port.

    For this reason you should try and ping a port that has a good chance of not being open, as open UDP ports may drop a packet completely that it does not understand (See UDP port scanning, above, for a more detailed description)

    The syntax for a USP ping is:

    Nmap -PU

    Again, separate the port numbers with a comma if you want to scan multiple ports.

    UDP Pinging is an inherently unreliable ping due to it relying heavily on ICMP packets, which as we know are usually filtered out.

    ICMP Mask and Tine-Stamp pings:

    There are two rather antiquated pings that Nmap still supports called an ICMP Time-Stamp ping and an ICMP Mask ping.

    I would strenuously suggest staying away from both of these as, a) the chances of them working are very remote, and b) they stand out like a MAC at a Defcon meeting to someone analysing the packets flowing through a network.

    A timestamp request is a prehistoric method for two hosts to synchronize their clocks – now-a-days NTP is the preferred method. There is a small plus to using this method and that is if it works you have a very good chance of successfully attacking the network as anyone who allows there packets to traverse layer 3 devices probably does not understand their job to well.

    An ICMP Mask Ping is an ICMP query to a host asking it for it’s subnet mask. If this works then just like the timestamp request the chances of the network not being secured properly are very high, or the OS patching state is not very recent or even that they are using legacy infrastructure hardware on the network.

    They syntax for the timestamp request is:

    nmap -PP

    And the syntax for the Mask Ping is:

    nmap -PM

    I think this is waaay getting two long now, so will end Part two here.

    In Part three I will cover further basic Nmap options, Nmap timing options, OS fingerprinting, real world examples of using all the options and some not so well known tips and tricks for using Nmap.

    [quote]I had to split this paper in to two parts due to post size limits; please find the first half of this paper here:

    Additionally if you liked this tutorial then please Digg it [url=]here[/url][/quote]

Leave a Reply

Your email address will not be published. Required fields are marked *


If you'd like to advertise on The Mutt ( aka ) feel free to contact us at: administration[at]

TheTAZZone is a non-commercial entity. We do not sell any products or services ourselves. Our revenue comes from advertising and donations only.

We appreciate your support! Your advertising revenue ( or donations ) helps us to continue to upgrade, improve, and offset the costs of maintaining this site.

Donations can be made through the page ' Donate '.