TAZ Forum Community

2007 A Hacking Odyssey: Part Two – Network Scanning & Nmap Part 1




If you have followed part one you will have most of the information needed to allow you to progress on to the second phase of your attack/Pen test.

You can find part one here:
http://tazforum.thetazzone.com/viewtopic.php?t=5445

The second phase can be generically summed up as ‘Scanning’. To even start this phase we need of an absolute minimum one thing; an IP address. If you have not been able to glean and IP address during your reconnaissance phase, then you will need to go back and persevere with it, because until you get one you will not be able to do anything else….you can’t scan something if you don’t know where it is.

Scanning typically involves all or some of the following:

Covered in this paper:
War Driving
War Dialling
Network Mapping
Port Scanning

Covered in Part 3:
Vulnerability Scanning
IPS and IDS detection and evasion
Firewall ‘auditing’
PBX scanning

Scanning a network is a very unique activity as all networks are different; they are configured in different ways, secured in different ways, use different hardware, have different services running, respond differently to various scans and use different software/OS’s – to name but a few of the variations. For this reason it is impossible to write a step by step paper along the line of ‘enter this command and you will get this output, now enter this command and you have exploited the service’. It just won’t work this way.

What I will do however is explain the theory of how it all works and explain how to use the most common tools for doing this; the most common of these common tools being Nmap, hence a large part of this paper will be devoted to it.

I will briefly cover War Dialling and War Driving first though, as they are not terribly hard to understand.

**Before I go on I need to point out that the scanning phase is the complete opposite to the reconnaissance phase in terms of exposing yourself to the target network. Reconnaissance when done properly is nearly completely passive and is entirely legal. Scanning on the other hand is not passive in any way shape or form and is for the most part illegal. You WILL leave log entries on the remote system when scanning it. Whether these look suspicious to an administrator or are suspicious enough to set off an IDS alarm is entirely up to you and the methods you chose to adopt**


War Dialling

Pretty much everyone has heard of War Dialling in today’s cyber world. It was probably made famous by the film War Games – where a young teenager connects to a government network via a Modem.

This film was released in the early 80’s and the technique used in it is still valid today…

Before VPN’s and Remote Access software were readily available the only feasible way for an employee to connect to the corporate LAN or indeed for an administrator to connect to a remote system was via a Modem; which they would ‘Dial in’ to.

Even though there are a lot more secure methods for remote access in today’s world, it does not mean that remote access via a modem does not still exist anywhere. A lot of people use the ‘if it is not broke, then don’t fix it’ philosophy. Couple this with the price of a modem (£5) and you have a very quick and extremely cheap remote access solution, albeit not a very efficient one but a working one all the same.

Think of your own dial up connection (everyone over the age of 10 must have been unlucky enough to of had a dial up connection at some point). You dial out onto the internet, usually to your ISP, enter a user name and password and viola you are connected to the Internet.

Obviously data flows both ways through this connection. If used in the conventional sense the data coming back is return traffic to one of your legitimate requests, i.e. a web page you have requested to see.

However what if the return traffic is not legitimate…….how does your modem know this……well, it doesn’t.

To use a dialup connection you must have a phone line, right? If you have a phone line then you will have a phone number. If someone dials this phone number and the line is connected to your modem…..what will they dial in to? Yep you guessed it; your modem and in effect your computer.

A very popular procedure amongst employees was to install some remote control software such as VNC and set it to listen on the COM port that the modem was using.
Then when they go home, they can dial in to the line attached to their computer and be greeted with the VNC login prompt.

In modern times (modern from an IT point of view) there is a plethora of remote control software available to any user for free or for very cheap. And all they need is a phone line installed by their desk. Chances are they will already have a phone next to their desk….so when they leave at night they connect this up to their modem, go home and dial their own number, connect to the free edition of VNC they have installed and start working from home. As far as they are concerned they are doing the company a favour as they can get more work done and it hasn’t cost the company a penny……what do they care about network security, that’s the job for they guy who keeps saying no to them whenever they ask for something……..sod him, right?

Unfortunately it is not just clueless end users who do this; Routers, switches and firewalls used to be remotely managed via a dialup link into them, with basic authentication. How often does a network infrastructure get upgraded? Not very often……..

Sadly in my experience of pen testing, 60% of the unsecured modems I find are attached to routers and not to end user work stations. System Admins come and go and they have a lot more to think about than one poxy phone line coming into an old router…….

The most common application used for War Dialling is probably THC-Scan (The Hackers Choice - http://www.thc.org/thc-scan/). It runs on pretty much anything that has a kernel and an emulator (yes even a MAC) and is extremely easy to use.

Obviously the final thing we need is a range of phone numbers right? If you have read part one you may have noticed the first two things we ever learnt about the target……its phone numbers and office hours. Why are the office hours important? Well we don’t want to try and take over a PC whilst the user is sitting in front of it do we….also if they do plug their phone line into the computer it is going to be so they can work from home….which won’t be in office hours will it?

I won’t cover instructions on how to use it as I don’t want to spend too much time on War Dialling, but there is a very good video tutorial showing how to use it on the above mentioned site and very extensive documentation is included with the download.

So you dial away and look at the log detailing what it found. If you use the Nudge feature of THC you may very well see some banners that can be very informative to use – such as ‘Hi, I’m a PC, or Hi, I am a MAC’. You will need to learn to recognise the return strings from the various modems it finds to be able to know what is listening behind the modem, i.e. VNC, PC Anywhere etc.

Some commercial War Diallers have a database that will tell you this automatically; if you don’t mind paying for them then this is a good choice to go for. PhoneSweep is probably the best commercial one available (http://www.sandstorm.net/products/phonesweep/) you can see a screen shot to better explain what I mean about identifying the system type – THC will just show you the raw output and it will be up to you to trawl through the logs and work out what system is what.

That’s pretty much it for War Dialling, find a modem, dial into it, see what remote control software is listening on the COM port, try and connect to it. The most common software listening will probably be VNC as it is free…..there is also a well publicized exploit for circumventing VNC authorisation……


War Driving

War Driving derives its name from War Dialling. If War Dialling is phoning every number in a range to find a modem, then War Driving is driving round an area looking for every Wireless Access Points.(WAP). There are subsets of War Driving such as War Walking, War Mountain Biking, War Flying, War sitting on the bench outside the building with my laptop hoping I don’t look suspicious…generically they can all be safely called War Driving.

The chances of finding a WAP in today’s world are much greater that the chances of finding a modem. In the past most security/hacking type books typically confined Wireless LAN (WLAN) hacking to a few pages at the back of the book, however now-a-days it is becoming more and more popular and more and more rewarding in terms of illegally accessing a network. Due to this the newer security and hacking books tend to devote a lot more page space to WLAN hacking.

When conducting a Pen Test, after the reconnaissance phase I usually set up a laptop and leave someone with it to carry out the War Dialling , whilst that is running I will drive around the targets building and War Drive it. By the time I get back we are able to go through the results of both assessments. If we find any ‘miss configurations’ it usually gives us a general impression as to the state of the network and its security.

WLAN’s obviously use radio transmissions to transmit data from one node to another. Our aim as WLAN hackers is to put ourselves within range of these transmissions so we can also receive them and look at the contents being sent.

Before we do this we obviously need to find the Wireless networks.

WLAN’s all have a network name, which is what distinguishes them from each other and helps employees know which one they are meant to connect to. This network name is known as the Extended Service Set Identifier or ESSID. If you open your wireless network properties and search for networks, you will end up with a list of networks that your wireless adaptor is within range of. Each of these will have a name, what you are looking at is the ESSID of each WLAN.

ESSID’s are transmitted in clear to every wireless client that may be listening; this forms part of the ‘beacon’ that is transmitted periodically by the AP and is included on most packets leaving the WAP. Likewise when a client is associated with an AP, this also transmits the ESSID in clear.

It is possible for a wireless client that is not associated with an AP to send a ‘probe request’ to the AP asking for various bits of information. Normally the ESSID is included with these requests and any AP that does not have the same ESSID will drop the packet.

The rules of the various 802.11 protocols say that it must acknowledge a probe request that is using the ESSID configured on the AP OR that has the ESSID parameter set to ‘Any’.

If you re-read the above statement you will see a fairly large whole in the 802.11 implementations that we can exploit: “OR that has the ESSID parameter set to ‘Any’.”….

SO, if we send probe requests and set the ESSID bit to ‘any’…then all WAP’s within range must respond to the requests….. and when the WAP’s send traffic what is included in the packet, yep the ESSID.

Netstumbler (http://www.netstumbler.com/) which is arguably the most popular War Driving tool around uses this ‘flaw’ in the 802.11 protocols. It sends out 100’s of probe requests with the ESSID bit set to any and waits for return traffic. When this traffic comes it extracts the ESSID, sending MAC address, wireless channel and approximate signal strength of the WAP or the wireless client. If your wireless adaptor is set to receive a DHCP IP address (one that is automatically assigned to you) then Netstumbler will also record the IP range in use on that WLAN.

Wireless Access Points can be configured to ignore probe requests with the ESSID bit set to ‘any’, but as we will see later on this does not really increase the WLAN security. They will however defeat Netstumbler static of using the ‘any’ ESSID and will remain hidden to it.

Personally I don’t like Netstumbler due to it being very very noisy…..100’s of probe requests with the ESSID set to ‘any’ will set wireless IDS alarms of in an instant. Couple this with the fact it won’t pick up WLAN’s with the ESSID set to ‘any’ and you are found wanting when conducting an ‘Active Scan’. You set all the IDS’s off and may still not find all the WLAN’s.

It must be mentioned that Netstumbler comes into its element when using it with a GPS and a decent antenna though.

So how do we find the WLAN’s that are ignoring probe requests with the ‘any’ ESSID bit set and at the same time avoid setting off IDS’s?

To accomplish this we need to put of card into Monitor mode (sometimes referred to as rfmon mode)

Most people confuse promiscuous mode with monitor mode. They are two very different things.
Promiscuous mode will listen to all traffic that is sent on a WLAN that it is currently associated with. If it is not associated with a certain WLAN, then it will not accept traffic from it.
Monitor mode on the other hand listens to all WLAN traffic without associating to any WLAN.

Obviously if we have not associated with a WLAN and are not sending any packets to any, then no one will know we are there and no IDS alarms will be raised.

Airodump (http://www.wirelessdefence.org/Contents ... rodump.htm) which run on *nix platforms, Airodump-ng (http://www.aircrack-ng.org/doku.php?id=airodump-ng) which runs on Windows platforms and Wellenreitter (http://www.remote-exploit.org/) which is now part of the BackTrack live CD are the most popular tools for this and are all capable of capturing packets in monitor mode. For the anoraks that use a MAC, Kismet will run on your *cough* MAC (http://www.kismetwireless.net/index.shtml) as well as pretty much any other OS too.

See here for a tutorial on using Airodump and indeed how to crack the WEP encryption: http://www.tazforum.thetazzone.com/viewtopic.php?t=2069

There will be a counterpart explaining packet injection with Windows and how to crack WPA-PSK at some point in the near future.

Which ever one you chose to use you will more than likely need extra drivers to put your wireless adaptor into monitor mode. Once in monitor mode you can chose to capture all packets as either an ‘.ivs’ file (for WEP cracking) or a ‘.cap’ file for viewing with applications such as Ethereal or Wireshark as it is now known.

The only occurrence left that we may find is if the WAP has been configured to not reply to probe requests set to ‘any’ and it is not broadcasting the ESSID with its beacons and is not a whole lot of traffic going over it. As long as there are clients associated with it (Airodump will tell us this, as will Wellenreitter) we can force a client off the WLAN and make it have to re-associate again. Commonly referred to as a Deauthentication Attack or Deauth for short, this forces traffic to be sent over the WLAN and will reveal the ESSID to us. It also forms the basis for WPA-PSK hacking.

A deauth attack utilizes yet another weakness with the 802.11 protocols, whereby a client will accept and obey a deauthentication packet that is sent by the AP without any authentication at all. In a nutshell what this means is that if we can send a deauthentication packet to a wireless client and make the packet look like it came from the AP, then the client will disassociate from that WLAN.

To take it one step further if we send the deauthentication packet to the broadcast address of the LAN then all of the wireless clients will disassociate from it.

When the clients re-associate to the LAN they have to broadcast an association packet which contains the ESSID in plain text to announce to the AP that they want to associate with it, otherwise no AP will answer, as if you remember from earlier they will only answer to their own ESSID, (or the ESSID of ‘any’ if configured to do so).

This is a slightly more noisy way of finding the ESSID, but nowhere near as noisy as Netstumbler. You may set IDS alarms off with this too, so use it with caution.

The trick in all of the above is finding the right WLAN for your target as you could be up 10’s of WLAN in the area, so you need to know which one is the right one.

Most companies will name their WLAN something relevant to them or even name it the same as the company name. If this is the case then they have just made your job a lot easier.
If the ESSID does not give you any info and you still have no idea which one belongs to your target you could try using the signal strength to make a best guess as to which WLAN is coming from your targets building, maybe visit the reception of your target and ask for directions to somewhere and then have a look at your WLAN sniffer’s logs to see what network had the strongest signal for the time you were in the building. If this is not providing you with any results you could even try phoning the IT dept up and asking them…..most will tell you the name there and then.


The final things to say are that if you are having trouble picking up the signal, try again at night time or better yet at night time after it has been raining. Wireless signals travel further at night and further still when the ground is damp. If you still can’t get a signal try using a better antenna.

Mapping the Network

If we are going to try and gain entry to the network, it is a good idea to know the layout of it. Any half decent attacker will draw out his findings so that he has a diagram with as much information as he can find, which might be a lot or a very little.

It is rather hard to map out networks that use NAT/PAT as our traces won’t get past the border router or firewall – we can’t trace to an internal IP address over the internet. However, if we have managed to find a way in via our War Driving and/or Dialling attempts then we already have access to the internal address space so can trace away to our hearts content. Either way a trace route works the same and the inner workings of it are very simple.

An IP packet has a Time To Live field set in it, commonly referred to as a TTL. Every layer 3 device such as a router or a layer 3 switch will decrement this TTL field by one as it routes the packet.

(See here if you are unsure what layer 3 refers to)

Once the frame has passed through enough layer 3 devices to reduce the TTL field to zero, the layer 3 device who reduced it to zero will drop it altogether. Without the TTL theoretically an IP packet would travel around a network for ever….

(According to the RFC the TTL is decremented by one for every second that the router has it. Due to the routing speed of most routers they typically have it for a lot less then a second, so it is safe to say that it will be reduced by one for every router it passes though)

When this last router drops the packet it needs to send something back to the original sender to say that the packet has timed out, as per RFC rules. To do this it will send an ICMP Time Exceeded message (ICMP type 11 as defined in RFC792).

Here is where the trace part comes in:

We now that only a router will send the ICMP time exceeded message.
The source IP address of this times exceeded message will be the routers IP address.
If we know what the original TTL setting was we can determine how many hops away the router that sent the time exceeded message is.

(A hop is considered to be a routing device that the packer passes through, so two hops means it has gone through two routers)

So we set the TTL to one – then send it to the first router, this will decrement the TTL to zero and be forced to drop the packet and send the ICMP message to us – when we receive this message we learn the IP address of the first router.

Then we set the TTL to a value of two – the first router decrements the TTL to one, but then as it is not zero it sends it on to the next router in its path – this router receives it, decrements the TTL to zero and is forced to send the ICMP type 11 message to us – thereby giving us the IP address of the second router.

Then we set the TTL to three and the same process occurs until it gets to the final router.

Setting all thses TTL fields manually can be quite a time consuming task, so MS and *nix have an application that will do it for us. The Microsoft version is called tracert and the *nix version is called traceroute.

Simply open up a command prompt and type ‘tracert’ followed by the destination IP address or Fully Qualified Domain Name (FQDN):



The numbers on the side indicate what the TTL was for that hop. The next three columns tell us the round trip time and the last part of it tells us the FQDN of the router if there is a DNS entry in existence for that IP address, or it will just tell us the IP address of it.

You can usually tell by the trace route output which routers belong to the same organisation; the first seven hops in my trace all belonged to NTL.

Some times however the routers won’t play by the rules and will be configured to not send ICMP Time Exceeded messages out. If this is the case you will get some '*******'s' instead of an IP address.

You could also be unlucky enough to come across a router that not allow ICMP type 11 packets to pass through it. If this is the case you will get all ****’s from this router onwards as the return packets can not get to you hence you can’t trace the routers IP address.

Ping Sweep

To go hand in hand with traceroute you can also PING a target or a targets subnet to see what hosts are active on it.

There are hundreds of tools available but I suppose the most common is Nmap.
Use the –sP option to Ping Sweep a subnet. For example if we ping sweep the IP addresses adjacent to Google (we found Google’s IP from our trace route) we will be able to see what is alive:



Oh my, doesn’t Google have rather a lot of servers.

The last thing to note is that just like ICMP time exceeded messages; ICMP replies can also be blocked by routers & firewalls and the actual host can also be configured not to reply to ICMP requests.


Port Scanning

Port scanning is a very useful tool that is very much in favour of the attackers. If we are to find a way into a network then it will more than likely be through a vulnerable service of some kind.

Most newcomers find ‘ports’ a difficult concept to grasp due to them trying to think of them as physical ports, hence when I say there are 65356 different ports you probably try and picture the back of a computer with all these ports sticking out of it.

The ports are entirely configured in software and in very simple terms all they are is a way of keeping traffic from different services separate.

A service can be a Mail Server, a Web Server, an FTP server etc. If someone sends you an email, you don’t want it going to your web server do you?

So all these services are given their own ports to use by way of a port number. There are 65356 TCP ports and 65356 UDP ports.

Take a SMTP Mail server and an FTP server for example:

An SMTP Mail server usually uses port 25 (TCP) and an FTP server will usually use port 21 (TCP)

If I send you an email, your computer can’t just simply read it and determine it is an email and needs to go to the mail server – likewise if I send you a file via FTP your computer cant read this and know it is a file destined for the FTP service…only the relevant services will know what to do with the data. So we need a way to tell your computer to send the right data to the right service.

To accomplish this we put the destination port number in the packet and then send it to the computer. This way when the data arrives at the computer all it has to do is look for a port number, if it says port 25 then it knows to send it to the service listening on port 25, which will be the Mail server – the mail server receives this traffic, understands what it is and passes it on up to your mail client so you can read it.

If I want to send you a file via FTP I first open up a channel to you on port 21. Your computer receives this data, looks at the destination port number and knows where to send it to, in this case the service listening on port 21.

There is more to it than this, but in essence this is what happens.

The obvious limitation to this is that every service needs to be listening on the correct port – if I am to send an email to you I need to know that your mail server is listening on port 25 for me to put the destination port number in the packet…if you have your mail server listening on port 50, when I send an email to you, your computer will look at the port number (25), see there is no service listening on that port and drop the data. You would also be disrupting the service that should be listening on port 50.

For this reason the Internet Assigned Numbers Authority (IANA) have a very strict registration process to control which service will listen on which port.

From the IANA web site:



In layman’s terms; Well Known ports are used for the most common services specific to network and Internet functionality, such as FTP, SMTP, Telnet, HTTP, DNS etc

Registered Ports are for common services that are not specific for the functionality of a Network or the Internet such as PC games, Kazza, SQL cluster manager, Anti Virus etc – things that are widely used and that others need to know the port number in advance for.

The Dynamic and private ports can be used by anyone for anything.

You can find a constantly updated list of port assignments on the IANA web site:
http://www.iana.org/assignments/port-numbers

So, taking it a step further and looking at it from a bad guy’s point of view, if someone wants to run a mail server and receive email then they need to have a mail server listening on port 25.

If we send a data packet to that port and we get a response back, we know that as per IANA regulations that is has to be a mail server who sent this response. If we don’t get a response back then there is nothing listening on that port, hence there is no service running.

There are two mail types of protocol used for the transmission of data over a network and the Internet; User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). Even though they both do the same job, they do it in very different ways. If you are not to sure about how TCP and UDP works and the differences between the two, please read THIS before continuing on with this paper as you will need to have a rudimentary understanding of it to understand how a port scan works and the benefits of using different types of scan.

Which brings us nicely on to Nmap….

Nmap (Part 1 of 3)

Nmap is probably the worlds most famous and useful port scanner. It runs on pretty much every Operating System and is relatively straight forward to use. For Windows there is a graphical version and a command line version, which can both be found here:
http://insecure.org/nmap/download.html

For this paper I shall use the Command Line Interface (CLI) version however if you have never used it before it maybe worth while to use the graphical version until you are comfortable with it.

After installing Nmap and the Winpcap drivers that come with it Windows XP Service Pack 2 users should install the registry file. It can be found in, C:\Program Files\Nmap, simply right click on ‘nmap_performance.reg’ and select merge – the latest release has this as an install option.

You can now use Nmap by typing nmap directly into a command prompt. You need to be an administrator/root of the host you install Nmap on to use all of its features. If you already have Nmap installed use the following command to ensure you have the latest version (Version 4.20 as of this writing): “nmap --version”

If you do not add any option after typing nmap it will display a list of commonly used parameters that you can use for your scan:



Some of these options you will use all the time and some you may never use but if you spend a few minutes to read through them it will give you a basic understanding of the way you configure nmap to scan for you.

The syntax is generally ‘nmap’ followed by the scan type and any scan option, followed by the IP address or IP address range, followed by the ports you want to scan (not always required), followed by the output you want i.e. filename and file type:



This simple scan tells Nmap to conduct a TCP connect scan, against 80.80.80.80 on port 80 and to save the results to a file called scan.doc.

**I use the IP address of 80.80.80.80 in this paper purely due to the fact it is quick to type**

The following pages will cover all of the Scan Types, most of the scan options and a few maybe not so well known tips and tricks we can do perform with Nmap.

As this moment in time there are 12 different types of scan you can perform with nmap:

1) TCP Connect –sT

This is the ‘scan by the rules’ option and will try to establish a full and RFC compliant TCP connection to the remote host on the necessary port. If the connection is successful then the port is reported as being open. Although this is the most reliable scan type it is also the most risky for a would-be attacker as the connection will be recorded by the remote system due to it being a complete connection.

The syntax for this would be: nmap –sT 80.80.80.80. (obviously substitute 80.80.80.80 for the IP address you want to scan)

2) TCP SYN scan -sS

The SYN scan is a little stealthier than the Connect scan as it does not establish a full TCP connection. Instead of completing the full TCP three-way handshake it will only go through half of it.
If you have read the above paper I linked to you will understand the three-way TCP handshake:

SYN
SYN-ACK
ACK

The initiating host sends a packet marked with a SYN flag, next the receiving host will respond with a SYN-ACK and finally to complete the three-way handshake the initiating host will send an ACK packet. (This ACK is then flagged in all subsequent packets for that connection – remember this for later)

In plain speak the SYN packet saying ‘I have some data for you, do you want it?’ to with the receiving station will send a SYN-ACK which means ‘Yes I do, please send it’ and the initiating host responds with the ACK which means ‘OK, here it comes’.

Now if we send the initial SYN packet and the remote host responds with the SYN-ACK packet as it should BUT we do not send the expected ACK packet, then we have not completed a valid connection. If we send a FIN packet, which tells the remote host to tear down any connection it may have, and then our connection attempt may not get logged due to the connection being terminated before it was complete.

The fact that the remote host responded with a SYN-ACK on the port we sent the SYN packet to is enough to tell us that there is a service listening on that port and that is all we need to find out…

Some modern firewalls and routers will recognise this pattern of packets (SYN, SYN-ACK, FIN) as a SYN scan though and may still log it.

The syntax for a TCP SYN scan is: nmap –sS 80.80.80.80

3)TCP ACK scan -sA

Following on from the packets we have sent and received so far, it makes sense to try and send an ACK packet and see what we get. This is where we start to break the rules of TCP connections. So far we have complied with the RFC rules that dictate a valid TCP connection starts with a SYN, then has a SYN-ACK and then has an ACK (which we bent a little on the last scan by not sending a final ACK but the connection was still initiated by the book)

By sending an ACK packet first we hope to get past any packet filters that may be filtering our normal SYN/SYN-ACK packets.

Some older non-stateful packet filters base their decision on what packets to allow and what to drop solely on the TCP control bit (the SYN/ACK etc). If you were on an internal LAN that allowed all outgoing traffic but denied all inbound traffic you would not be able to do anything on the Internet as nothing would reach you, i.e. when you wanted to view a web page the data would not get to you as your packet filter would be blocking it all..

To get around this problem non-stateful packet filters such as a border router or a low end firewall will look at the TCP control bit and see if it is a SYN or an ACK; if it is a SYN then it must be someone trying to originate a connection from the Internet, hence it will drop the packet. However if the ACK bit is set, then by the RFC rules it must belong to a connection that is already established, and since it won’t let SYN packets in, only out, the connection must have been established by an internal host therefore it will allow the packet through.

However there is a slight difference with this type of scan – our first two scans (TCP Connect and SYN) will determine if a port is open by the response it receives from the remote host. If a SYN-ACK comes back the port obviously is open and replying to the SYN packet as normal, however when a SYN packet is destined to a port that is closed the remote host will send a RST (Reset) packet back. Nmap will determine the port state by these responses and show you the port as open or closed accordingly.

If you send a packet that does not comply with the RFC rules (such as an ACK packet that does not follow a SYN, SYN-ACK) then it will respond with a RST packet and reset the connection.

Can anyone see where we are going to run into trouble here? If we send a TCP ACK packet to a remote host, as it does not comply with the rules we will get a RST packet back…..but we have just said that if a port is closed a RST packet will also be sent back…..so no matter if the port is open or closed the remote host will always send a RST packet back to an ACK scan probe……….what use is this ACK scan then?

The ACK scan is used to test non-stateful packet filtering rules. So say a border router has been configured to block all packets to ports 100-200 but to allow them on port 80, further to this established connections are allowed on all ports over 1024.

When we scan this with an ACK scan the packet filtering device will drop all packets destined to ports 100 – 200 as this is what it has been told to do – so we will either get no response or an ICMP Destination Unreachable response back, either way Nmap will know the probe failed. When it gets to port 80 the packet filter will let the traffic through and the host on the other side of the packet filter will send a RST packet because as we know an ACK packet is not a valid way to start a TCP connection – if a RST packet comes back Nmap knows the packet filter must have allowed the packet through (otherwise either an ICMP unreachable or nothing at all would have come back) and will mark it as UNfiltered. When it gets to port 1024 and over as the packet filter has been told to allow established connections through (packets with the ACK flag) all of our probes will be allowed to traverse the packet filter and we will get back a load of RST packets – therefore Nmap will flag the ports as UNfiltered.

Going off this output we will be able to determine that port 80 and all ports over 1024 will accept incoming packets that are part of a valid connection.

This type of scan does not actually tell us if a port is open or closed on the remote host; it only tells us if the packet filter device allowed the packet through or dropped them, as even if there was a Web Server running on the host behind the packet filter, it will still send a RST packet back when a probe comes to port 80……likewise if there was no Web Server running then a RST packet will still come back.

The theory of the ACK scan can be quite confusing if you are new to TCP connections and packet filters but just remember that it will only tell us if a packet filter will allow the packets into the network, it will not tell us if the port is actually open on the remote host.


The syntax for the ACK scan is: nmap –sA 80.80.80.80
The output will be something similar to the following:



If there is no mention of the port then it is deemed to be blocked by the packet filtering device, if it says UNFiltered then obviously the packet filter let the ACK packet through.

4) FIN Scan –sF, Xmas-Tree Scan –sX and Null Scan –sN

So far we have not managed to scan a remote host in a way that is not likely to leave log entries. We have initiated a connection in the proper way and two thirds of the way and the ACK scan will not tell us what ports are open. This is pretty useless to someone who needs to know what ports are open but does not want to leave log entries, a.k.a. an attacker.

Nmap includes a range of stealth scans; they are called stealth scans as they do not open a connection to a remote host in a normal everyday way. They violate the normal TCP protocol rules by sending unexpected packets and packets that are meaningless to a remote host that does not have a valid connection.

The first of these stealth scans is a FIN scan. This sends a packet to a remote host with the FIN flag set. Normally the FIN flag would signal the end of a connection and mark it to be reset, however if we have never setup a valid connection with the remote host we have no need to send a FIN packet.

The TCP protocol state that if an unexpected FIN packet arrives destined to a closed port then a RST packet should be returned and if an unexpected FIN packet arrives on an open port, then nothing should be returned – the packet should be ignored.

Using these TCP connection rules Nmap is able to determine if a port is open or closed by looking to see if a RST packet comes back or not – if it does the port is closed, if it doesn’t the port is open.

It’s important to remember that a FIN scan will not work against a Windows based hosts, as Microsoft do not follow the TCP rules completely and their Operating Systems will return a RST packet in response to a unsolicited FIN packet arriving on a closed or open port. Hence Nmap will think that all ports are closed – however if you run a –sT or a –sS scan on the same target and Nmap reports that there are ports open, it is a safe assumption that you are scanning a Windows box (this method was used a lot until Nmap OS detection was added and improved) – it is worthwhile noting that some Cisco, HP and IRIX equipment also respond to a unsolicited FIN packet in the same way as Windows – there is also one extra little used use for this; if you are scanning a web server that is behind a firewall and only permitting traffic to port 80 and when you scan it with a SYN scan Nmap reports the port as open but a FIN scan comes back as closed, then you know there is a high chance of the web server running on a Windows based machine just from this very quick and easy scan – a fact which can come in very handy when trying to exploit the web server or perform SQL injection.

The syntax for a FIN scan is: nmap –sF 80.80.80.80

5) Xmas Tree Scan –sX

The Xmas tree scan works in exactly the same way as the FIN scan except that is sets the PSH (Push) and URG (urgent) flag in conjunction with the FIN flag. This may get around some IDS/IPS setups. This scan still has the same effect on the Windows OS as the FIN scan.

The syntax for a Xmas tree scan is: nmap –sX 80.80.80.80.

6) Null Scan

To follow on from the logical pattern we are using so far the Null scan does the opposite of the Xmas tree scan and does not set any TCP control bits at all. The TCP RFC dictates that a RST packet should be sent from closed ports and an open port should drop the incoming packet – in exactly the same way as the pervious two scans. Again this may defeat some IDS/IPS setups and still has the same effect on Windows.

The syntax for a Null scan is: nmap –sN 80.80.80.80


We have run out of options for the TCP control bits now; we have tried setting the SYN, SYN-ACK, FIN, FIN-URG-PSH TCP control bits and also tried setting none of them. (You may notice that RST is missing, this is because the TCP RFC says that a RST packet is responded to with a RST packet regardless of if the port is open or closed, hence we would be no more the wiser than before we started.)

Wouldn’t it be good if we could play with these TCP control bit’s ourselves and create our own scan parameters to try and find miss configurations in firewalls, IPS’s, Routers and packet filtering devices? …..Well we can and it is very simple to do.

7) Customise your TCP packet

To customise out own TCP packets we use the ‘--scanflags’ option followed by the TCP control bit(s) we want to set, such as:

Nmap --scanflags FINACKSYN 80.80.80.80.

This will obviously send TCP probes with the FIN, ACK and SYN flags set. You can have some god results with poorly configured network border security devices by using this option. It is an individual trial and error technique though and one you should practise on your own equipment so you can get to understand what works with what type of configuration.

You can specify scan types to tell Nmap how to interpret the responses it receives. By default it uses a –sS.

8) FTP Bounce scan

In my experience not a lot of people seem to know about the FTP Bounce capabilities of Nmap. The FTP bounce feature exploits a very old feature of FTP servers whereby a client that has connected to an FTP Server can instruct it to send a file to a remote host other than the machine the client is connecting from.

This feature was very useful in the early days when bandwidth and connection speeds could be very low. Instead of having the file transferred to your own machine over a very slow link, you could have it transfer the file to a different machine you knew was using a faster link than yourself.

However, with the advances in technology faster links are a lot more common and bandwidth, or lack of bandwidth to be more exact, is not sure a problem anymore. Due to this (and probably due to Nmap) more and more FTP servers disable the File Forwarding feature and some even do not have the feature available at all.

There are still some FTP server on the Internet that can be used for this or if you manage to take over a remote FTP server that supports File Forwarding you could turn it on and use it to commit your terrible Nmap cyber crimes without bringing the forces of good to your own doorstep.

It all works by Nmap sending a request to the FTP server and telling it to send a file to X.X.X.X IP address on port X. If the FTP server comes back and says that it was unable to establish a connection on that port then Nmap will show the port as closed. If the FTP server is able to make a connection on the specified port, it will come back as able to establish a connection but unable to transfer the file – hence Nmap will list the port as open.

The benefits of this are that in so far as the target machine (the one you port scanned) all the connection attempts came from the FTP server. For anyone to find out that it was in fact you port scanning the target machine they would have to find the owner of the FTP server and ask him to look through his logs – and if the admin of the FTP server is slack enough to allow File Forwarding through his FTP server than chances are he may not even keep logs..…

It can be time consuming to find an FTP server that allows File Forwarding but if you do find one be sure to keep the IP Address to yourself to ensure it stays configured that way for as long as possible. If half the world starts using it for FTP Bounce scans pretty soon the admin is going to figure out what is going on and configure it correctly.

To find one, use the “-p” switch, this is a feature of Nmap which I will cover later on that allows you to specify which port you want to scan. Then chose a subnet and scan them all of port 21 (FTP). Once you find some hosts listening on port 21 try and use them to conduct your FTP Bounce scan…..if it works your in luck, if it doesn’t then you will have to keep looking.

Nmap 123.123.123.0-255 –p21 – This will scan all hosts from 123.123.123.0 right through to 123.123.123.255 on port 21 only, looking for a live FTP Server.

Once you have found an FTP server try connecting to it to see if it allows Anonymous logons. (Use the user name ‘anonymous’ and anything for the password). If it does you’re in look and can try an Nmap bounce scan straight away. If it doesn’t allow anonymous logons you can either try and find a valid user name and password with a program such as Brutus or Hydra, or move on to another FTP server. I will cover how to use Brutus in a separate paper.

Once you have found either a valid logon for an FTP server or one that allows anonymous logons, use the following command to launch your FTP Bounce scan:

nmap –b username:password@IP_of_FTP_server IP Address to scan

So:

nmap –b nokia:taz@123.123.123.123 80.80.80.80

Would logon to 123.123.123.123 with the user name of nokia, the password of taz and then attempt to port scan 80.80.80.80

The following shows the result of a successful logon to an FTP Server that I use for FTP Bounce scans



If Nmap manages to successfully logon to an FTP server but you receive the following:

“Your ftp bounce server doesn't allow privileged ports, skipping them.”

It means the FTP server is configured to not send anything to ports 0-1024 less for port 20 & 21 – this was an early way of preventing such things as Nmap from connecting to ‘well known’ ports except for 20 & 21 – which is mostly the only ports it will need to connect too to send a file.

If your FTP Bounce server does not allow it to act as a proxy at all, eventually you will get the message:



You may find more false positives with this type of scan than any other for obvious reasons, so you should try and verify your results with another type of scan if possible.

The mort astute of you and those that think for themselves rather than blindly following a tutorial may have realised another use for this type of scan.

The FTP server will more than likely be sitting on a LAN with a fully routable internet IP address…….if we can find out the IP range in use on the internal LAN we can use this method to port scan internal hosts by specifying an internal IP at the end of the Nmap command, or even try scanning 127.0.0.1 (localhost A.K.A itself). If you find port 80, 25 etc open the odds are that this could be acting as an FTP, Web and Mail server - even though the external IP addresses maybe different for these three services a firewall can translate them all to the same internal host.

This method could be used as a long-winded ping seep method also – if you can find out the internal IP range in use you can try a port scan each host in that range and see what positives you get back. If you get a positive back the host must be alive so you have the IP address of a valid internal machine. The FTP server will usually be on a DMZ so theoretically you can find the internal hosts of the DMZ, work out what ports are open and try and tie these in with the external IP’s in use. As mentioned in the previous paragraph if port 25 is open on an internal host you know there is a mail server – if you have taken the time to conduct a reconnaissance then you will know the external IP for the mail server….chances are you have just found the internal IP of it.

A lot of people write-off FTP bounce scans as being dated and useless in today’s world, yet I do occasionally come across susceptible servers during Pen testing and they can be a very good path into a network and help you understand the topology better. If you happen to stumble upon a susceptible public FTP server, be sure to keep it as quiet as possible…..

I could not find that in the link that you have pointed out, I have just read this :
http://insecure.org/nmap/install/inst-windows.html


Did you mean to mention these below for instance ?

http://www.openxtra.co.uk/freestuff/nmap-xtra.php

http://www.darknet.org.uk/2007/01/nmapv ... on-windows

Regards

Please see the bold phrase, I got confused , you was talking about : ACK bit is set , then you said : it won’t let SYN packets in, only out,,,,

I could not figure out, is the second sentence consequent to the first one ?

yes
SYN arrives
ACK sent by return to set up connection and session
SO no more syn allowed in

but it can send them, hance the bit 'only out'

HTH

and I hope it's fecking right too
but it's my birthday NOW
and I'm on the brandy, got a job interview in the morning too
so maybe just finish the one bottle :hic:

Hi Zillah,

As Foxy said, the ACK bit is set on all packets in an established connection, so the packet filter device will know to allow these packets is as they 'should' be return traffic to someone inside the network.

If a SYN packet arrives out of the blue then someone from the outside must be trying to establish a connection to something from the inside, hence the packets will be dropped - for return traffic to come to the firewall (ACK traffic) then there must be an established session somewhere - but as it won't allow SYN packets in, then the only way that the session could have been established is for someone from inside the network to send a SYN packet out, to kick of the three-way handsake.

No, I meant what I wrote - if you read all of the page I linked to, you will see what to do and where to get NmapFE from.

In the link that you have provided,till now the only GUI (Nmap front end) that I have found is for : (Linux, Solaris, Free/Net/OpenBSD, and Mac OS X), but I could not find GUI for windows platform(yes there is a project for GUI for windows, still going on), but since you have mentioned that there is a GUI for windows, I will try to read it again to find out where is that one

Regards