2007 A Hacking Odyssey

2007 A Hacking Odyssey – Reconnaissance
The aim of this series of papers that will take an in-depth look at how someone may
target and electronically break into an organisation, is to educate people who may be
tasked with looking after and securing a corporate network to do so in an effective
manner.
My personal outlook on this issue is that if you have no idea about the steps a would-be
attacker will take to try and gain access to your systems, then you as an administrator can
not effectively secure your system to an acceptable standard. Some people may disagree
about the concept of demonstrating to people how to gain access to networks they are not
meant to, whilst others agree with the ‘full disclosure’ approach.
Take a firewall for example – if you don’t understand the steps an attacker will go
through to try and get traffic through your firewall, then how can you stop them for doing
it? All you can do is configure it the best way you know how and hope it is good enough.
Hacking, Cracking, Hackers and Crackers
Before I start:
If some innocent looking young teenager came up to you and starting talking about
hackers and hacking, then chances are you, being the IT professional that you are would
mentally dismiss him as not understanding what he was talking about, just because he
used the work ‘hack’. Yet, if a university professor type person in his fifties wearing a
tweed coat, glasses and smoking a pipe came up to you and starting talking about hackers
and hacking then you would more than likely listen to every word he says…… why is
this?
Well, the term ‘Hack’ or ‘Hacker’ is a word coined by the media to mean anyone trying to
break in to something IT related, whether it’s a Network, Computer or any other type of
electronic system.
The more realistic term to use when talking about a hacker in the way the media’s term is
meant, is to use the word ‘Cracker’ or ‘Attacker’. A cracker/attacker is someone who tries
to gain access to things they have absolutely no right to be accessing. A hacker is
someone who tries to make something function in a way it was not originally designed to
do; they ‘hack it apart’.
Take an email program for example; a hacker may try to make this email program send
something other than an email, thereby making it do something it is not meant to do.
Whereas an attacker/cracker will try to gain a level of access to it and read the users
emails contained within the application.
People who are new to the IT community will often innocently use the word hacker until
they get flamed by someone for doing so, probably on an IT related web forum, at which
point they will usually endeavour to find a different word or face public ridicule on the
new IT forum they will inevitably have to find.
There are some people who like to instigate the flaming of the above mentioned people
and think that everyone else will presume they are pretty knowledgeable because they
make a big fuss of the fact they don’t like the word ‘Hacker’……these are the people you
should probably stay away from.
Most people who are secure in their own knowledge of IT and IT security whether for
good or bad purposes and who have worked in the area for a while, really don’t care what
word is used and can even find themselves using the term ‘hacker’ for ease of instruction
when talking to non technical people or media type people. It could also be used to lessen
the effect the work ‘Attacker’ has on someone; non IT people can get pretty scared when
you say a cyber attacker is out to get them.
For the duration of these papers I will use the term ‘attacker’ to refer to someone trying to
do bad things to your computers and to your network. We will also assume the attacker is
a ‘he’.
Reconnaissance
For this chapter we will take the mindset of the Attacker and the preliminary steps he may
go through to attack your IT emporium.
How does an attacker decide which organisation to target? When he has decided on the
organisation how does he set about attacking it, how does he know where to go on the
internet to find the specific network he wants to attack, how does he find your
geographical location if he wants to wardrive you, how does he find useful information to
socially engineer you, how does he find your phone number range to war dial you, how
does he find your mail server?
These are just some of the things the attacker will need to know before planning any
attack against you and is generically referred to as reconnaissance.
There are different types of attacker; attackers who have picked a target for a specific
reason, attackers who pick random targets but have a specific idea about what they want
to do to the target when they find one, and then there are attackers who look for random
targets to launch random exploits against in an attempt to gain any level of access,
without actually understanding what it is they are doing.
This later genre of attackers are commonly referred to as Script Kiddies, Skiddies,
SkiDIE’s, Skids etc and are the ones who don’t usually bother with any reconnaissance
and jump straight to firing Nmap up and start telenting to any open ports they may
happen to find.
I usually start security related courses off by asking, “What is the first step to take when
wanting to attack a network?” 99% of the answers I receive involve the words Nmap and
Telnet. Whilst this is a feasible option, there are still lots of steps to take before Nmap is
even downloaded.
You may have dismissed Script Kiddies out of hand by what I have mentioned above.
Just because they do not understand the ins and outs about what they are doing does not
make them any less dangerous than someone who does. Script Kiddies have all the time
in the world to try and attack you. They usually come across an exploit of some kind that
has been published somewhere, read how to actually perform the exploit and then go off
in search of someone to test their new found uber skill on.
Since they have a specific exploit in mind, which may run over a certain port, they can
scan away to their hearts content looking for that one system that is vulnerable to the
exploit they have.
So, whereas Administrators have to try and secure from 1000’s of possible vulnerabilities,
the Script Kiddies only have to find this one vulnerability on your system…..and have an
infinite amount of time to find it.
Picking a Target
So, how do pick a potential target?
As good guys you may have a specific reason to attack a target, whether it is your own
organisation and are auditing the security of it, or you have been contracted to audit the
security of another organisation – if this is the case then step one has been decided for
you. As bad guys you could have a grudge against a particular organisation, you could
have come across some interesting information in a newsgroup about a certain system
being vulnerable, someone may have posted a firewall configuration on a newsgroup/IT
help site and not removed any passwords or IP addresses (this used to happen a lot). You
could even have been specifically asked by someone to see if you can do any damage
against an organisation…..the list goes on.
What if you have no reason to pick a specific target and any will do?
You could trawl through your own firewall logs and find someone who has targeted you
in the past; Zone Alarm for example has an annoying popup that can tell you about any
external attempts made to gain access to your machine and includes the IP address of the
attacker. If you have a home router they all usually have a logging facility and will record
any attack attempts.
In true Script Kiddie style you could have stumbled across an exploit and want to try it
out, so start looking for susceptible targets.
You could even ping the first IP address that comes into your head, check it is valid and
chose that.
When I teach this subject in particular, to find an organisation for the duration of the
course I usually enter the first words that pop into my head in to Google, take one of the
hits on the first page and use that company to demonstrate the reconnaissance steps
against.
In this case the words are ‘Garden Sheds’.
http://www.google.co.uk/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q
=garden+sheds&spell=1
The company I chose is Shed Store.
That’s the target picked, now let’s see what we can learn about them…
Research the Target
There are a multitude of perfectly legal methods we can use to research our target and we
don’t even have to connect to any of the machines associated with it. Like all good
reconnaissance, the intended target should not know what we are trying to do – for this
reason we try to use publicly available information that is hosted away from any machine
directly belonging to the organisation or has been made to be accessed by the public, i.e.
their web server.
Targets own web site
Once you know who your target is the fist thing to do it browse over to their web site and
simply have a look at all the information they have made freely available to us.
http://www.shedstore.co.uk/
What info can we get from here?
They have kindly given us their address, phone number range, email domain, who they
use for their online billing provider, what their office opening hours are and that they are
part of Guardian Buildings.
Quote:
Shedstore (A trading division of Guardian Buildings). Unit 1, Southview Park,

Caversham, Reading, Berkshire. RG4 5AF.
T: 0870 3500 710 F: 0870 3500 720 E: sales@shedstore.co.uk W:
www.shedstore.co.uk
Quote:
During our office hours of 8.30am to 12.00pm, then 1.00pm to 5.00pm -

Monday to Friday, we accept telephone orders and enquiries upon the following
numbers.
- Sales enquiries & orders: 0845 130 0405 (Local rate)
- General enquiries: 0870 3500 710 (National rate)
- Customer service enquiries: 0870 3500 710 (National rate)
- (For those customers unable to access '08' numbers, please call 0118 946 4182)
By going part of the way through the order procedure we find out they use
http://www.securehosting.com/ to handle their online transactions.
The also have a members only area of the site.
**I will talk about what we can do with all this information later on**
We are starting to build up a ‘feeling’ about this company just from their web site. Going
by this web site they seem to be a fairly well established company, they have what looks
to be a professionally made web site, the seem to do the majority of their business over
the internet, but they don’t necessarily seem IT savvy as they have no need to be, so they
maybe rely on external hosting providers to handle the web site, email, billing etc……
this last point is a point worth remembering for later on when we cover social
engineering.
None or all of the above ‘feelings’ we get from the web site are necessarily true……we
need to confirm it first.
Google
I will not cover Google on this paper as the subject as extremely large and I feel it
deserves a paper to itself (whick will be posted soon). Needless to say typing the
company name in to Google & Google groups may reveal some information that can be
useful to you.
Jobs advertised on company web sites
Although not applicable to this particular web site, let’s say we were using the web site of
a small bank, and on this web site they had a Jobs Section, and in this jobs section they
were asking for a PIX firewall administrator to start immediately….
This little gem of information tells us that the bank uses PIX firewalls, that they may
have no administrator currently employed to manage it/view the logs etc (hence the
immediate start) and that they may be susceptible to a social engineering attack whereby
someone who does not normally configure the PIX maybe coerced into making a change
OR that a new employee is likely to start very soon, who again will be very susceptible to
social engineering to get him to alter the firewall’s configuration…..if you had a phone
call from someone claiming to be the boss of your new company on your first day at
work, would you say no to him if he told you to maybe change an ACL in the firewall?
Maybe, maybe not…..
All this stems from a seemingly innocent job advert….
Newsgroups
Newsgroups are a valuable source of information during the reconnaissance phase of an

attack depending on the type of target, as they are usually used by someone to ask for
help, i.e. I have a PIX 506E and I want to configure a static NAT for a web server with
the IP addresses 192.168.10.10 and 80.80.80.80, how do I do it?
This innocently asked question tells us that particular organisation uses a PIX, the
internal IP range, the external IP range and that the administrator is not so confident with
configuring it, hence it maybe miss configured and easy to attack…..
Out of Office replies are also sent out to some newsgroups…..what better time to attack a
network than when you know the administrator is out of the office and can’t examine any
logs…..or if you want to phone someone up and socially engineer them under the guise
of being the system administrator…. well you know he won’t be there to get in your
way….
If you trawl through it you will find complete router configurations including IP
addresses and passwords, firewall configurations that again include IP addresses and
passwords, the list goes on. If you have managed to gleam a name from the organisations
web site try searching for it and see if it throws anything up.
**When you want to search for say a PIX running configuration that may have been
posted in its entirety, it is best to search for a few words that are specific to the
configuration. I usually use “mtu outside” – which refers to the Maximum Transmission
Unit size for the Outside interface of the firewall and is pretty specific to a firewall - if
you know the domain name of your target try including this in your search string as well;
most firewalls can be configured with a domain name....
The below link has over 13,000 PIX configurations that have been posted in various
newsgroups:
http://groups.google.co.uk/groups/search?hl=en&q=mtu+outside+&qt_s=Search
I find PIX firewall configuration especially useful to search through as there are so many
things that need to be deleted from the configuration to not give away any information.
So often I see IP addresses deleted but domain names remaining intact, a quick
‘nslookup’ of the domain name will sometimes give you the IP Block assigned to the
organisation, once you have worked this out take a look at the Access Control Lists and
see what they allow in…..see if there are any Peer IP addresses in the VPN configuration
etc
There is a very extensive search function on the Google Groups site, which will allow
you to search for almost any aspect of a post, again try and use keywords specific to
either the organisation you are researching or are specific to the type of post you are
looking for.
You may have to trawl back a while to see if anyone has posted via their company email
address in a newsgroup as people are more savvy now-a-days and usually use a
hotmail/gmail/Yahoo type web mail account. However, some people sign their messages
with their full name, company name and company address……and then explain their
entire network setup and what is wrong with it.
We will come back to searching newsgroups in the next section when we go over WHOIS
records.
WHOIS
The Internet is a huge directory of domain names and due to various copyright laws,
trading laws and DNS workings, there can not be two identical domain names in
existence at the same time on the Internet.
A domain name refers to an organisations “Internet presence” and is usually related to

their normal company name. I.e. The domain name for Barclays Bank is Barclays.co.uk
(http://www.barclays.co.uk/) 99% of the time this also means their email addresses will
end in Barclays.co.uk.
Keeping track of all these domain names was historically done by Network Solutions
until 1999 when they lost the monopoly for domain name registration. As the Internet
grew so did the amount of suffixes attached to domain names ( .com, .co.uk, .org etc) and
so did the amount of registrars.
Any domain name ending in . .aero, .arpa, .biz, .cat, .com, .coop, .edu, .info, .int, .jobs,
.mobi, .museum, .name, .net, .org, .pro, and .travel are registered with Internic; who can
be found here: http://www.internic.net .
The country code top-level domains – which are two letter suffixes that refer to the
country, I.e. uk, jp, au will inform the attacker what country the target is in. A list of
ccTLD’s can be found here: http://www.iana.org/root-whois/index.html
What if your targets domain name does not fall under InterNIC’s remit? Well, there is a
very helpful site called Uwhois that will inform us of where to look for the registration
details or our particular domain.
http://www.uwhois.com/domains.html
We browse to Uwhois and enter “shedstore” in the domain box, tick .co.uk and click Go.
Depending on who the domain is registered with Uwhois may show us the complete
registration record or it may tell us where to go and look for the records.
In our case we are told that the domain name is registered:
Quote:
The answer to your domain search is

________________________________________
Uwhois search forshedstore.co.uk Registered
Notice shedstore.co.uk is a hyperlink? Click on it and you will be taken to either the
registration details or you will be told where to look:
Quote:
[whois.nic.uk]
We now know that whois.nic.uk holds the registration records. Type that into Google and
the first hit you get is for Nominet. http://www.nominet.org.uk/other/whois/
Browse to Nominet and enter shedstore.co.uk as the search term:
Quote:
Domain name:
shedstore.co.uk
Registrant:
Keith Taylor
Trading as:
Guardian Buildings
Registrant type:
UK Partnership
Registrant's address:
Guardian Buildings
Unit 1
Southview Park
Caversham
Reading
Berkshire
RG4 5AF
United Kingdom
Registrant's agent:
Thus plc t/a DSVR [Tag = DSVR]
URL: http://www.dsvr.co.uk
Relevant dates:
Registered on: 24-Jan-2000
Renewal date: 24-Jan-2008
Last updated: 20-Jun-2006
Registration status:
Registered until renewal date.
Name servers:
ns0.serve.co.uk
ns0.serve.net.uk
Now we are getting some information that we can use to aid our attack. We have a name
of someone who is probably fairly high up in the Guardian Buildings organisation; Keith
Taylor. We also know Shed Store is part of the Guardian Building group from
information we were able to get from their web site.
We have the address of both Shed Store and Guardian buildings; again we have this from
their web site and from this WHOIS record.
We now know who they use to host their web site and who they used to register their
domain name from the Registrant’s Address information: URL: http://www.dsvr.co.uk .
We can see the record was renewed in June 2006, so ‘Keith Taylor’ is probably still
working for the organisation.
Finally we have the most important piece of information to us so far; the name servers,
which I will talk about in a minute.
You maybe thinking, Yeah, Ok I have all this information but what use is it to me? It will
all become apparent right after I run through DNS and DNS zone transfers.
Domain Name Service – DNS
DNS could be considered the post office and telephone directory of the Internet. Without
it the Internet would not be anywhere near as efficient and easy to use as it is today.
In a nut shell DNS takes an IP address and ties it in to a domain name. I will presume
most people know what an IP address is and will not insult you all be explaining it (PM
J_K9 if you need to know)
To explain DNS it is best to give an example; so if you go to your RUN prompt (Start >
Run) and type CMD into it and press enter(Or your Linux equivalent) You will get a
black box popping up; this is your command prompt.
Whenever we want to perform any DNS queries, or interact with DNS in anyway we use
a program called ‘nslookup’. (Linux users may want to use ‘dig’ instead of nslookup as
most recent Linux distro’s have butchered the nslookup program somewhat)
Type nslookup:
Code:
Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Nokia>nslookup

Default Server: speedtouch.lan
Address: 192.168.1.254
>
Notice the prompt changes to ‘>’, this tells us we are now in the nslookup application and
not in the normal command prompt.
The Default Server will tell you what your own DNS server is. (this may not always be
an actual server, especially if you are using a home router. If you are using a home router
then the IP address show will usually be that of the router)
At the ‘>’ prompt type google.com:
Code:
Address: 192.168.1.254
> google.com
Server: speedtouch.lan
Address: 192.168.1.254
Non-authoritative answer:
Name: google.com
Addresses: 64.233.187.99, 64.233.167.99, 72.14.207.99
>
You will see that the output of the command you entered is three different IP addresses.
Now at the prompt type in one of these IP addresses:
Code:
> 64.233.167.99
Address: 192.168.1.254
Name: py-in-f99.google.com
Address: 64.233.167.99
>
**Tip – right click the blue bar on top of your command prompt and select properties, in
the Edit Options field make sure Quick Edit and Insert Mode are ticked. You can now
copy and paste as you would normal text. Try highlighting a Google IP address in the
normal way by moving your cursor over it with the mouse button pressed, the text will go
white; now right click. To paste the text simply right click again and the text will be
pasted where the flashing cursor is.**
The output from the above command tells us the IP belongs to Google.com.
What you have just done is preformed a DNS query to find out the IP address(es) that
Google use for their web presence; when you entered the domain name you done a
forward DNS lookup and when you entered the IP address you done a reverse DNS
lookup (rDNS).
You may still be thinking what the hell you are on about but it will become apparent now:
Try typing one of the IP addresses you got from your DNS lookup into your web browser.
You are still taken to Google.
Your computer does not talk to other computers by using words such as Google.com.
When you enter Google.com into your browser your computer needs to convert this into
a form both it and other computers will understand. As you probably know everything on
the Internet needs an IP address, as this is how all traffic is addressed on the Internet (it is
different on an internal LAN but for now assume everything uses IP addresses). So
something needs to take google.com and convert it to an IP address to enable your
computer to go out on to the Internet and find the server that hosts the Google web site.
If you haven’t guessed it already, it is DNS’s job to do this.
Without DNS you would have to remember 64.233.167.99 and use this when you wanted
to go to Google. Then when you wanted to go to Hotmail you would have to enter
64.4.33.7, and then if you wanted to go to Digg you would have to enter 64.191.203.30…
… can you see how confusing this would become. If you wanted to advertise your
business web site you would have to use an IP address and hope everyone could
remember it……
DNS allows us to use a human readable syntax that we can remember easily, to browse
the Internet. Without it, the Internet would be very chaotic.
You can find a very good explanation of DNS here:

http://en.wikipedia.org/wiki/Domain_name_system
But what has all this got to do with our reconnaissance? Well there are different types of
DNS records that will be used for different services. If we wanted to send an email to an
organisation the a DNS record would tell the appropriate mail server the IP address of
where that organisations mail server is located. This records is called an MX record (Mail
Exchange), DNS records can also be used for web servers, FTP servers etc.
If we could get our hands on all of these DNS records for our target domain, we would
have a huge chuck of valuable information for when it comes to the next phase of our
attack; as we would know where to go to try and gain specific entry to the network….if
we wanted to exploit their mail server DNS would tell us where it is, if we wanted to
attack their FTP server DNS would tell us where it is……..
DNS servers support something called a Zone Transfer and what this is, is a way of the
DNS server telling someone all the information it has about a certain domain, MX
records, A records, PTR records etc.
There is a catch to this though and that is properly configured DNS servers only support
Zone Transfers to authorised people and sometimes not at all. To go back to the WHOIS
record we found, the very last entry listed is the DNS servers that our target uses:
Quote:
Name servers:
ns0.serve.co.uk
ns0.serve.net.uk
So let us try and see if a Zone Transfer will work on these DNS servers:
Go back to your nslookup prompt:
Code:

Address: 192.168.1.254
>
And type “server ns0.serve.co.uk” (you could even do an nslookup for this and use the IP
address if you wanted to )
Code:
> server ns0.serve.co.uk

Default Server: ns0.serve.co.uk
Address: 212.69.220.10
>
This is telling the nslookup application to query the server you have specified and not
your own default one. (Obviously since this is where the information relating to the
shedstore.co.uk domain is located, it is the server we need to get the info off)
To ask it for all the information it has on the shedstore.co.uk domain (a Zone Transfer),
we use the following command:
Code:
> ls -d shedstore.co.uk
If Zone Transfers are enabled to casual users, and we have the right DNS server for our
domain, it should reply will all of the DNS records it holds:
Code:
> server ns0.serve.co.uk

Default Server: ns0.serve.co.uk
Address: 212.69.220.10
> ls -d shedstore.co.uk
[ns0.serve.co.uk]
shedstore.co.uk. SOA ns0.serve.co.uk hostmaster.dsvr.co.uk. (2
006122800 3600 1800 86400 3600)
shedstore.co.uk. NS ns0.serve.co.uk
shedstore.co.uk. NS ns0.serve.net.uk
shedstore.co.uk. MX 5 mx81.emailfiltering.com
shedstore.co.uk. A 212.69.210.106
ftp CNAME www.shedstore.co.uk
mail CNAME www.shedstore.co.uk
smtp CNAME www.shedstore.co.uk
www A 212.69.210.106
shedstore.co.uk. SOA ns0.serve.co.uk hostmaster.dsvr.co.uk. (2
006122800 3600 1800 86400 3600)
>
** Tip – there will nearly always be two name servers listed on the WHOIS records – if
the first one does not allow Zone Transfers always try the second one too, as this is
usually a backup DNS server and may not be configured the same as the first one.. **
So what have we got?
We have the Start of Authority (SOA) which is the authoritative DNS server for the
shedstore.co.uk domain – the numbers after it are pretty unimportant to us but refer to the
zones serial number, refresh rate, retry rate etc.
The Name Server (NS) records basically tie the domain name to the DNS server. Think of
it a mapping so others can find the correct DNS server.
The MX records which we have already covered refer to where all email should be sent
to for the domain. In our case it looks like Shed Store is outsourcing their email to a
hosting provider of some kind.
The CNAME or Canonical name records are aliases and point back to the A record. They
are usually used when there is more than one type of service using the same IP address.
In this case it is FTP, HTTP and SMTP.
The A record (Address record) is the main DNS record and does the actual mapping of
the domain name to the IP address. The CNAME records referred to above all refer to
this A record. ( if you now do an nslookup for shedstore.co.uk it is this very A record that
will be consulted to return the IP address to you)
The one glaring omission is a PTR record – which handles the rDNS lookup. (the
opposite of the A record so to speak) If you do an nslookup on the IP address
212.69.210.106 you won’t get shedstore.co.uk:
Code:
C:\Documents and Settings\Nokia>nslookup 212.69.210.106

Address: 192.168.1.254
Name: internetdesign.dsvr.co.uk
Address: 212.69.210.106
This is another indication that the website is hosted by a third party, probably called
Internet Design and they have only bothered to update the A record and not the PTR
record. If you go back to the WHOIS record it will back this theory up:
Code:
Registrant's agent:
Thus plc t/a DSVR [Tag = DSVR]
URL: http://www.dsvr.co.uk
If we couple this with the fact the DNS server itself is not configured adequately and we
were able to complete a Zone Transfer we could come up with the conclusion that this is
a very sloppy setup and could mean they are not using as good a web hosting service as
they could do, that they do not understand the DNS implications of their own setup, that
the have never tested their security - hence more proof they may not be very IT savvy…
…
IP Address
Just like domain names are registered and entered on a WHOIS database, IP addresses are
also registered and entered on a database. For Europe and Asia an organisation called
RIPE handles this. (http://www.ripe.net/) and for America ARIN handles it
(http://www.arin.net/index.shtml). If you browse to them and enter the IP address
mentioned in the A record you will find out who it is registered to:
Code:
inetnum: 212.69.210.0 - 212.69.211.255

netname: DSVR
descr: Hosting in iP House
country: GB
admin-c: NOC5587-RIPE
tech-c: NOC5587-RIPE
status: ASSIGNED PA
mnt-by: AS5587-MNT
source: RIPE # Filtered
role: AS5587.NET Network Operations
address: Victoria Building
address: Salford Quays
address: M5 2SP
phone: +44 207 3455256
fax-no: +44 207 3455257
As I said it is not really applicable in this case as it is only for a web server that belongs
to a hosting company. But if it was for an organisation that hosted their web server
internally you would be able to get more contact details for the company from here. In
this case we only get the name and address of the hosting company, which is in Salford
Keys, Manchester. – It may come in handy for a social engineering attempt later on, who
knows but it is worth writing it all down.
Mail Server
Mail servers are a good way of finding information out about a company and what email
addresses are valid in the company. It is possible to telnet to a mail server on both port 25
and 110. When you connect you are greeted with a banner saying the type of mail server
and its version.
Open a command prompt again and type the following:
Code:
C:\Documents and Settings\Nokia>telnet shedstore.co.uk 25
This is telling the telnet application to open a connection to shedstore.co.uk on port 25.
You should now see this:
Code:
220 internetdesign.dsvr.co.uk ESMTP Exim 4.52 Wed, 07 Feb 2007 20:03:06

+0000
The mail server banner is telling us the type of mail server is Exim, and it is located in the
UK. It also tells us that this mail server belongs to the same people who host Shed Stores
web site….but the MX records from the DNS Zone Transfer are for a different company.
The must have a web mail solution and another hosted email solution.
Going by the MX record they also have email hosted with emailfiltering.com So they
may have another domain name in place for email, or it may have something to do with
the Guardian Buildings organisation that they are a part of. It’s hard to tell exactly why
they have another email solution but it is something worth bearing in mind.
Code:
MX 5 mx81.emailfiltering.com
Browse to emailfiltering.com in your browser and see if there is a web site for it.
Yes, there is – but it has a URL redirect in place and takes you to
http://www.emailsystems.com/ . If you put an ‘s’ after the HTTP
(https://www.emailsystems.com/ ) and go to their secure site you are presented with a
logon…….probably where you go to check your emails on line…..
Try telenting to the mail server mentioned in the MX record on port 25……now this is a
seriously locked down mail server……my guess is their email hosting company do know
what they are doing, unlike their web hosting company.
All this information comes in handy when we try to social engineer some information out
of the companies we have discovered are target uses.
FTP
Did anyone notice their was a CNAME record for an FTP server? Let us see if it is active.
Go back to your command prompt and type:
Code:
C:\Documents and Settings\Nokia>ftp shedstore.co.uk
You should be presented with the following:
Code:
C:\Documents and Settings\Nokia>ftp shedstore.co.uk

Connected to shedstore.co.uk.
220 ProFTPD 1.3.0rc2 Server (ProFTPD) [212.69.210.106]
User (shedstore.co.uk:(none)):
It has told us what type of FTP server it is (ProFTPD) and is asking for a user name and
password. At this point DO NOT try and gain access to anything. Remember we are
researching the target passively and do not want to try and connect to anything directly
related to the Shed Store company until we have taken the proper countermeasures to
obscure our own identity and location on the WWW.
Web hosting companies typically provide FTP access for their customers so they can
upload their web site and make any changes that are needed. I pointed out that there is a
members only part to the web site earlier on, my guess would be that members can logon
and maybe buy direct from the company via the user portal? If so all their details are
stored on the server somewhere and if we manage to get FTP access we can also get
access to all of the files and do not have to worry about trying to exploit the web
service….
At this point it is enough for us to just know it is there and how to access it.
*Hey look, we have learnt they have a web site, a mail server and an FTP server and the
IP address of them all…..and we didn’t have to fire up Nmap up once to tell us what
services they have….**
Social Engineering
Social Engineering is the art of interacting with someone with the sole reason of
maliciously soliciting information out of them. The common example is to get a user
name and password, but this is not always the case. I have endless hours of fun teaching
this and getting students to phone places up and trying out what they learn in real life. It
is an incredibly hard skill to master. But once you have mastered it you can save yourself
hours of pain staking work trying to crack user accounts etc the hard way.
Most people think Social Engineering is something reserved for the determined attacker
or for the people carrying out a Pen Test. I would suspect that 99% of the people reading
this have never tried it or are ever likely too……yet they wouldn’t think twice about
firing Nmap up and scanning someone’s system. In my view if you can get some
information out of someone such as a password, well then it saves you having to spend
hours running a dictionary attack or trying to brute force the password which you have
just got hold of in a few minutes via social engineering. NEVER underestimate the Social
Engineering stage of reconnaissance it nearly always pays off and saves you a lot of time
and hassle.
The reason not many people do it is that to carry out an effective Social Engineering
attack you need a rather large set of gonads, a very good reason to want to do it and some
prior information about the person or the persons organisation that you are speaking to.
Social Engineering is not something that can be taught and is more of a skill you pick up
over time. The more you do it, the better you can become at it.
There are a couple of facts about human beings in general that need to be mentioned to
better explain how to carry out effective social engineering attacks:
Humans are very easily programmed and become stuck when something happens out of
the ordinary.
Being extra nice to someone and making that person like you and want to help you, does
pay off sometimes
People generally do not say no to an authoritative figure or to someone who is higher
placed then them in the organisational structure.
It is usually easier to coerce someone into doing something they don’t normally do, than
to coerce them into doing something they do everyday.
Humans are very easily programmed and become stuck when something happens
out of the ordinary.
Think of a normal hand shake; if someone walks up to you and extends their hand in a
motion that signifies to you that they are about to shake yours, you are programmed to lift
your hand up in response.
In certain scenarios such as when meeting someone, this is expected. But what if it
happens in a situation you don’t expect it, i.e. when you are walking down the street and
a perfect stranger walks up to you with an outstretched hand signifying that he wants to
shake hands with you? You still lift your hand to respond to that person, maybe not very
far but you will still do it.
Now what if when meeting someone, and when you expect a hand shake, the person
stops half way through extending their hand and puts it in their pocket? You still extend
yours and when something happens you don’t expect, such as someone putting their hand
in their pocket, your programming breaks down and for a second or two you go into
limbo as you have no idea what to do. Why - Because like as not this will have never
happened to you before so you have no programmed response to it.
Consider this – whilst you are in limbo during this hand shake, if the other person was to
ask you what your phone number is, what would you do? You are programmed to
respond to a question, so whilst your mind is in limbo wondering what the hell to do, the
programmed part of it will respond to the question that has just been directed towards you
and unless you manage to stop yourself in time you will answer the question.
When I was learning about Social Engineering the course was taught by a Psychologist
and not an IT security professional. Half way though one talk the speaker invited a
hypnotist into the seminar. The first thing this hypnotist done was to walk up to someone
near the front of the audience and introduce himself – just as they were about to shake
hands he put his in his pocket and said something to him, in a few seconds this guy was
hypnotised and answered any question the guy asked him. He very effectively utilized the
moment when his mind was wondering what it should do, to hypnotize him.
I’m not suggesting you need to walk around shaking hands with people and hypnotising
them to socially engineer them, but am trying to demonstrate that when something
happens out of the ordinary, people let their guard drop very temporarily and the mind is
very open to external influences.
To apply this psychology to a ‘real life’ social engineering attack – imagine you phone up
the web hosting company that Shed Store use (we know this info from the DNS records
and the WHOIS record), and went through the normal process everyone goes through
when initiating a phone call – the other person says hello, you say hello and state the
reason why you are phoning – the other person will go through the process they have
probably gone through 1000’s of times and asks you for your credentials to authenticate
yourself……… Ooops, we hang up as we can’t do that.
To apply the methodology of breaking someone’s programming you need to do

something unexpected that may have never happened to the other person before.
The list of how to do this is endless – but you have just found out your name server
allows anonymous Zone Transfers right? So your going to be a tad angry – what’s the
odds that if you phone up and instead of saying 'hello' which the poor help desk dude will
be expecting, you start yelling down the phone straight away asking why their DNS
server is miss configured. What you are going to do is put them in a situation they may
have not been in before and do not know how to handle properly (chances are at the help
desk level they will not even know what a DNS Zone Transfer is). So whilst they are
fumbling around trying to make sense of what you are angry about, mention (in a very
pissed off voice) you cant logon to your web server and need to know your details – now
this is something the person will be programmed to do and will understand, so whilst they
are still trying to figure out what the hell a DNS Zone Transfer is and who they can
escalate it too, they will be only too happy to do something they are familiar with (and
which gives them a bit of breathing space) and lookup the details for you.
Of course you don’t have to rant and rave at someone to throw them of their guard. Try
phoning an up-market hotel who do not normally give out the details of who is staying in
a certain room…..when they answer just simply ask if they have the time (be very polite),
I can pretty much guarantee the receptionist will have never had this happen to her
before…so whist she is in the state of registering what you have just asked and what she
should do in response to you, ask her who is staying in room 101 – her programming will
kick in and she may very well divulge the information to you. The trick is to be nice and
extra polite to her.
After you have tried this method a few times you will develop a few methods that usually
work most of the time and stick to them.
Being extra nice to someone and making that person like you and want to help do,
does pay off sometimes
This one kind of speaks for itself and is not something I need to cover in great detail. Use
your charm to try and make someone like you enough to want to help you. This usually
works best when talking to someone of the opposite sex (unless you swing the other
way). The best way to do it is not to try and solicit any information during your first
conversation. Phone up initially, explain who you are (or who you are pretending to be)
and ask an innocent question that will not require her to ask you some questions to
authenticate yourself. Such as:
“Hi, I’m Keith Taylor the Managing Director of Shed Store, well Guardian Buildings but
you have us down as Shed Store. You host one of our web sites called shedstore.co.uk
and I was wondering if you are experiencing any technical difficulties again, as at the
moment we can’t reach it.”.
If we examine that seemingly harmless and everyday initial introduction more closely
you can see what we have just done:
“Hi, I’m Keith Taylor the Managing Director of Shed Store” = Using the name we got
from the WHOIS record we have introduced ourselves to her – putting a name to a voice
on the telephone forces her to automatically construct a mental picture of you, which will
aid us in getting her on our side. We have told her we are very high up in the company,
the MD no less. How many MD’s does she speak to on a daily basis? Not many I bet, so
we will now stick in her mind and she will remember us next time we call. By identifying
the company we are from, we allow her to learn a little more about us by offering her
extra information, which goes in our favour but more importantly we let her know what
company we are from so when we try to extract some information from her later on she
may not feel the need to authenticate us.
“well Guardian Buildings but you have us down as Shed Store” – This again offers her a
little more information to add to her mental picture of us. The second part of this sentence
implies we have contacted them before and have regular dealings with them – again
adding to our authenticity.
“You host one of our web sites called shedstore.co.uk” – Here we have told her what our
web site is and that we are indeed one of their customers. This is important later on when
we ask her for our login details, as she will not need to ask us what our domain name is
which is usually the prelude to asking us to authenticate ourselves – we will be breaking
her programming.
“I was wondering if you are experiencing any technical difficulties again, as at the
moment we can’t reach it” – This reinforces the fact we have spoken to them before as
we mentioned the word ‘again’. But more importantly it is a question that does not
require her to authenticate us and is something she will have to search for, and gives you
that ‘moment of silence’ to make idle chat with her……get to know her….and make her
like and trust you.
She now has a mental image of you, knows who you work for, knows a little more info
about your organisation than she may normally get to find out with most customers
(which could make you stand out amongst others), she knows you are a Managing
Director which again makes you more likely to be remembered by her (and all women
like important men don’t they?), we have let her know that we have phoned up before,
she knows your domain name – which means she won’t have to ask for it, she knows you
are having technical difficulties but are still being nice to her – not many other customers
would be as nice when experiencing technical difficulties, again you will stick out in her
mind because of this.
After this all you can do is use your charm during the ‘moment of silence’ to get to know
her.
Give it a few hours and phone back up, you may have to do this a few times until the
same person answers the phone.
The second conversation could go something like this:
“ Hi <insert her name!> it’s Keith again the MD from shedstore.co.uk. I phoned you
earlier to ask about some technical difficulties, I’m just wondering if you are having some
issues now as we can’t access our site again and are really starting to lose business over
this.”
“ Hi <insert her name!>” – You must use her name here as it tells her we have
remembered her, and everyone likes to be remembered, right? Especially by an MD…
“it’s Keith again the MD from shedstore.co.uk” – This time we just use the first name, to
make the conversation more friendly and social, we reinforce the fact we are an MD and
again we tell her our domain name.
“I phoned you earlier to ask about some technical difficulties, I’m just wondering if you
are having some issues now as we can’t access our site again and are really starting to
lose business over this.” – This last part is designed to make her go off and search for
something again – which will give us another moment of silence to make idle chit chat.
Most important we have no emphasised that this is a serious matter to our business and
needs to be resolved…but we are still being very civil and chatty to her……..this will be
out of the norm for most cases she has experienced when something is going wrong….
and it stresses the fact that we must be an exceptionally nice person if we are still being
nice to her….hell I would want to marry me!
The knack here is to make idle chat but around a subject that you can refer to later on.
The third time you phone up, don’t mention anything work related. Start the conversation
off about the subject you made idle chat about. When you feel the time is right say
something along the line of “Oh I’ve forgot what it is I’m phoning for now….Oh that’s
right, I can’t remember my logon for the shedstore account, can you help us out?” – Or
words to that effect.
If you have done your part right she will know your domain name, be under the
impression you work for Shed Store and may just go right ahead and give you the
credentials you need.
I have provided a theoretical example that only uses three phone calls. In reality it could
take week or even months to gain the trust of someone and it is not always done over the
phone, it can quite easily be done in person. You only get one shot, if you try it to soon
and she asks for credentials, obviously you can’t supply then and have to hang up wasting
what could be weeks of effort in trying to gain her trust.
People generally do not say no to an authoritative figure or to someone who is

higher placed then them in the organisational structure. & It is usually easier to
coerce someone into doing something they don’t normally do, than to coerce them
into doing something they do everyday.
You should have grasped the basics by now. If you can convince them you are important
enough, they maybe willing to skip procedure to accommodate your request. Or, if you
can put them under enough direct ‘managerial’ pressure they may rush the job and again
not authenticate you.
The last one relates to things like the job advert I mentioned further up the page: It will be
easier to get the person filling in for the missing firewall admin to make a change that it
will be to get the regular firewall admin to make the change.
Accidentally phoning the wrong person, when you know the real person is away (maybe
by an OOO reply to a newsgroup) can be a lot more rewarding that phoning the correct
person.
Likewise instead of phoning a hosting company who are trained to authenticate people
before dealing with them, try phoning the target company direct and claiming to be from
the hosting centre…..it maybe easier to coerce an un-trained company employee who has
never had to ask anyone for credentials in their life to part with some logon details.
Prior Information
What ever tactic you decide to use you are always going to need one thing – prior
information about the person/organisation you are trying to imitate. You can’t pretend to
be someone else if you know nothing about them…
What information have we managed to get from all of the above steps?
Company name – An obvious one that we need
Domain name – Handy to guess email addresses, needed for WHOIS lookups and for
social engineering attempts.
Office Opening hours – What better time to attack their network than when they are not
there, or if you want to phone someone claiming to be an employee it is best to do so
when they are not in the office
Telephone number range – People still do use modems. With the phone range we can
Wardial the company looking for them.
Company Address – A post code is often used in authentication steps. We also now know
were to go to look through their rubbish if you are that way inclined
Senior Person from the company – From the WHOIS record we know the name of a
person who is likely to be high up in the company. Also good as a search string in
newsgroups
Name Servers – You have seem why these are important
Mail Servers – In this case the email is outsourced – another avenue for a social engineer
attack, either to the target claiming to be from the email company, or vice versa. The also
may have a second email service for another domain.
Web site hosting company – As above; ideal for Social Engineering attempts. We also
know they host a web mail solution for the company too – more info we can use for our
social engineering. If we did want to social engineer them we also know their address and
phone number from the RIPE record we looked up.
FTP Site – We know they have FTP access to the web site. This can come in very handy
when wanting to try and exploit parts of the web site as all we have to do is find an FTP
logon, we don’t need to spend a lot of time looking for web vulnerabilities.
Caller ID spoofing
You could use all of the information we have gathered together so far and you could use
the very best methods of social engineering and it could all fail. They are not foolproof
methods as they have a huge human element to it, and humans are very unpredictable.
However, there is one final trick in our arsenal that can sometimes work when all other
attempts fail and that is to spoof our caller ID.
If someone was to ring you up at work and say “Hi its Jim, I am filling in for the System
Administrator today.” You may or may not believe him. If he called and said the same
thing but on your caller ID display it came up that he was indeed calling from the Sys
Admins desk then the chances are that you would indeed believe him……unless his desk
is in the same room as you of course.
Think of Caller ID spoofing as instantaneous credibility
It is relatively easy to spoof a caller ID, the hard part is finding what number to spoof it
too.
TeleSpoof: http://www.telespoof.com/ is probably the most popular service to use since

Star38 and Comophone where forced to shutdown due to very negative publicity…
usually CallerID ‘falsification’ services do not stay in business very long but TeleSpoof
seem to be doing a good job of it so far.
You have to pay to use TeleSpoof but it is relatively cheap and is worth trying out on your
friends a few times to get the hang of it all.
If you have a VoIP setup than you can spoof your own caller ID for free, notably the
Asterisk PBX is quite good for doing this and is free…
Once you have learnt of a telephone number, probably via a WHOIS record or a RIPE /
ARIN record, which both usually list the System Administrators of organisation (and
what better person could you pick to pretend to be!) you can spoof away and see who
reveals information to you.
If you can’t find the System Administrators number, usually phoning reception and
asking for it will work…. After all, why would they not give it to you?
Summary
Reconnaissance is not very glamorous, it is tedious, probably not much fun to read about
and is almost never done by Script Kiddies. It is largely based on common sense and
reading publicly available information, However, it is a very important part of the bigger
picture. It puts you 'in tune' with the target so you don't go wondering in blindly
Nmap'ing away. There is not much skill involved in it - which is why I think it puts the
Skiddies off....
I have tried to run through all the steps an attacker may go through when researching
your organisation. I have chosen a real life company as nothing in this paper is illegal to
do. The company I chose looks to be a largely web based company and I have not
revealed anything that could list their internal network presence, although there are a few
ways of finding it out and the more astute of you may be able to do so by utilizing most
of what I have mentioned.
The next part will cover the prelude to gaining access to a network – i.e. network
discovery, mapping out a network, scanning for services, looking for weaknesses, WLAN
scanning etc and will utilize the information we have learnt here. I won’t use Shed Store
for this as they are a real organisation trying to run a business over the Internet and it
would not be right to demonstrate methods of accessing their network, if indeed there are
any.
If someone from Shed Store does read this hopefully they will look at it as a free partial
vulnerability assessment and leave it at that.
Remember to write everything down that you learn about a target, no matter how small
and trivial it maybe. You never know when that little bit of information may come in
handy. Try out your social engineering on a few innocent people in a harmless manner;
maybe try and find out who is staying in a particular hotel room etc. After a while you
will get good at it and be able to use it for more ‘daring’ situations.
Some of you maybe wondering why I have not mentioned Google much at all – that is
because I plan on writing another paper in the near future on how to use Google from a
‘hacking’ prospective.
Please post any questions in this thread or start a new one in the relevant forum; PM’s,
Email’s and MSN messages will not be answered.
Nokia
2007 A Hacking Odyssey: Part Two – Network Scanning & Nmap Part 1
Quote:
Due to post size limits I have had to split this paper into two halves. Please find
the second half here:
http://tazforum.thetazzone.com/viewtopic.php?t=5766
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 file 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/Aircrack_airodump.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):
Code:
C:\Documents and Settings\Nokia>tracert google.com
Tracing route to google.com [72.14.207.99]

over a maximum of 30 hops:
1 95 ms 99 ms 99 ms speedtouch.lan [192.168.1.254]
2 241 ms 256 ms 257 ms brnt-bam-2.inet.ntl.com [194.145.148.7]
3 239 ms 248 ms 251 ms brnt-t3core-1a-ge-110-0.inet.ntl.com [213.105.19
9.85]
4 223 ms 227 ms 245 ms bre-bb-a-so-130-0.inet.ntl.com
[213.105.174.245]
5 240 ms 255 ms 247 ms gfd-bb-b-so-120-0.inet.ntl.com

[213.105.172.150]
6 * 217 ms 226 ms nth-bb-a-so-000-0.inet.ntl.com [62.253.185.97]

7 256 ms 247 ms 245 ms nth-bb-b-so-200-0.inet.ntl.com
[213.105.172.194]
8 279 ms 265 ms 248 ms tele-ic-1-as0-0.inet.ntl.com [62.253.184.2]

9 250 ms 278 ms 268 ms 212.250.14.66
10 245 ms 268 ms 277 ms 72.14.238.244
11 319 ms 316 ms 317 ms 216.239.46.112
12 359 ms 352 ms 356 ms 72.14.233.113
13 344 ms 349 ms 337 ms 66.249.94.96
14 343 ms 341 ms 337 ms 66.249.94.118
15 353 ms 349 ms 343 ms eh-in-f99.google.com [72.14.207.99]
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 ****
instead of an IP address. You could also be unlucky enough to come across a router that
will 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:
Code:
C:\Documents and Settings\Nokia>nmap -sP 72.14.207.0-255
Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-13 20:38 GMT
Standard Time
Host 72.14.207.4 appears to be up.
Host eh-in-f9.google.com (72.14.207.9) appears to be up.
Nmap finished: 256 IP addresses (109 hosts up) scanned in 22.328 seconds
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 a Web 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 – like wise 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; FTP.
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:
Quote:
The port numbers are divided into three ranges: the Well Known Ports,
the Registered Ports, and the Dynamic and/or Private Ports.
The Well Known Ports are those from 0 through 1023.
DCCP Well Known ports SHOULD NOT be used without IANA registration.
The registration procedure is defined in [RFC4340], Section 19.9.
The Registered Ports are those from 1024 through 49151
DCCP Registered ports SHOULD NOT be used without IANA registration.

The registration procedure is defined in [RFC4340], Section 19.9.
The Dynamic and/or Private Ports are those from 49152 through 65535
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:
Code:
Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Nokia>nmap

Nmap 4.03 ( http://www.insecure.org/nmap )
Usage: nmap [Scan Type(s)] [Options] {target specification}
TARGET SPECIFICATION:
Can pass hostnames, IP addresses, networks, etc.
Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
-iL <inputfilename>: Input from list of hosts/networks
-iR <num hosts>: Choose random targets
--exclude <host1[,host2][,host3],...>: Exclude hosts/networks
--excludefile <exclude_file>: Exclude list from file
HOST DISCOVERY:
-sL: List Scan - simply list targets to scan
-sP: Ping Scan - go no further than determining if host is online
-P0: Treat all hosts as online -- skip host discovery
-PS/PA/PU [portlist]: TCP SYN/ACK or UDP discovery to given ports
-PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
-n/-R: Never do DNS resolution/Always resolve [default: sometimes]
--dns-servers <serv1[,serv2],...>: Specify custom DNS servers
--system-dns: Use OS's DNS resolver
SCAN TECHNIQUES:
-sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
-sN/sF/sX: TCP Null, FIN, and Xmas scans
--scanflags <flags>: Customize TCP scan flags
-sI <zombie host[:probeport]>: Idlescan
-sO: IP protocol scan
-b <ftp relay host>: FTP bounce scan
PORT SPECIFICATION AND SCAN ORDER:
-p <port ranges>: Only scan specified ports
Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080
-F: Fast - Scan only the ports listed in the nmap-services file)
-r: Scan ports consecutively - don't randomize
SERVICE/VERSION DETECTION:
-sV: Probe open ports to determine service/version info
--version-intensity <level>: Set from 0 (light) to 9 (try all probes)
--version-light: Limit to most likely probes (intensity 2)
--version-all: Try every single probe (intensity 9)
--version-trace: Show detailed version scan activity (for debugging)
OS DETECTION:
-O: Enable OS detection
--osscan-limit: Limit OS detection to promising targets
--osscan-guess: Guess OS more aggressively
TIMING AND PERFORMANCE:
Options which take <time> are in milliseconds, unless you append 's'
(seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
-T[0-5]: Set timing template (higher is faster)
--min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes
--min-parallelism/max-parallelism <time>: Probe parallelization
--min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies
probe round trip time.
--max-retries <tries>: Caps number of port scan probe retransmissions.
--host-timeout <time>: Give up on target after this long
--scan-delay/--max-scan-delay <time>: Adjust delay between probes
FIREWALL/IDS EVASION AND SPOOFING:
-f; --mtu <val>: fragment packets (optionally w/given MTU)
-D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys
-S <IP_Address>: Spoof source address
-e <iface>: Use specified interface
-g/--source-port <portnum>: Use given port number
--data-length <num>: Append random data to sent packets
--ttl <val>: Set IP time-to-live field
--spoof-mac <mac address/prefix/vendor name>: Spoof your MAC address
--badsum: Send packets with a bogus TCP/UDP checksum
OUTPUT:
-oN/-oX/-oS/-oG <file>: Output scan in normal, XML, s|<rIpt kIddi3,
and Grepable format, respectively, to the given filename.
-oA <basename>: Output in the three major formats at once
-v: Increase verbosity level (use twice for more effect)
-d[level]: Set or increase debugging level (Up to 9 is meaningful)
--packet-trace: Show all packets sent and received
--iflist: Print host interfaces and routes (for debugging)
--log-errors: Log errors/warnings to the normal-format output file
--append-output: Append to rather than clobber specified output files
--resume <filename>: Resume an aborted scan
--stylesheet <path/URL>: XSL stylesheet to transform XML output to HTML
--webxml: Reference stylesheet from Insecure.Org for more portable XML
--no-stylesheet: Prevent associating of XSL stylesheet w/XML output
MISC:
-6: Enable IPv6 scanning
-A: Enables OS detection and Version detection
--datadir <dirname>: Specify custom Nmap data file location
--send-eth/--send-ip: Send using raw ethernet frames or IP packets
--privileged: Assume that the user is fully privileged
-V: Print version number
-h: Print this help summary page.
EXAMPLES:
nmap -v -A scanme.nmap.org
nmap -v -sP 192.168.0.0/16 10.0.0.0/8
nmap -v -iR 10000 -P0 -p 80
SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS,
AND EXAMPLES
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:
Code:
Nmap –sT –P0 80.80.80.80 –p 80 –oN scan.doc
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:
Code:
PORT STATE SERVICE

53/tcp UNfiltered domain
80/tcp UNfiltered http
443/tcp UNfiltered https
1025/tcp UNfiltered NFS-or-IIS
1026/tcp UNfiltered LSA-or-nterm
1027/tcp UNfiltered IIS
1029/tcp UNfiltered ms-lsa
1030/tcp UNfiltered iad1
1033/tcp UNfiltered netinfo
1040/tcp UNfiltered netsaint
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
Code:
C:\Documents and Settings\Nokia>nmap -v -b nokia:si£u31@X.X.X.X

81.80.80.80
Hint: if your bounce scan target hosts aren't reachable from here, remember to u
se -P0 so we don't try and ping them prior to the scan

Stan
dard Time
Resolved ftp bounce attack proxy to X.X.X.X (X.X.X.X).
DNS resolution of 1 IPs took 0.22s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0,
SF:
0, TR: 1, CN: 0]
Attempting connection to ftp://nokia:si£u31@X.X.X.X
Connected:220 ProFTPD 1.2.5rc1 Server (*******************0
Login credentials accepted by ftp server!
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:
Quote:
Your ftp bounce server sucks, it won't let us feed bogus ports!
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 [url=
http://www.tazforum.thetazzone.com/viewtopic.php?t=5445]conduct a reconnaissance
[/url] 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…..
9) Idle Scanning -sI
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 THIS 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:
192.168.5.10 --> 192.168.5.15 TCP; D=80 S=59242 SYN ACK=9995679210

SEQ=153927672 LEN=0 WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=59242 S=80 RST WIN=0 ID=4532
192.168.5.10 --> 192.168.5.15 TCP; D=80 S=61347 SYN ACK=9995679210

SEQ=153927495 LEN=0 WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=61347 S=80 RST WIN=0 ID=4533
If you look at the above [edited] output you can see that 192.168.5.10 sent a packet to
192.168.5.15, the packet was TCP the destination port was 80, the source port was
59242, it was a SYN ACK packet with a sequence number of 153927672
Then as we know a RST packet should be sent in reply to an unsolicited SYN|ACK.
192.168.5.15 sent a packet to 192.168.5.10 which was TCP destined to port 59242 with a
source port of 80, it was a RST packet and had the IP ID of 4532
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.
Learn the IP ID
Code:
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1000) <---<---<-+ +
+++++++++++++ ++++++++++++++
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1001 <---<---<--+ +
+++++++++++++ ++++++++++++++
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1002) <---<---<-+ +
+++++++++++++ ++++++++++++++
If the port is open
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 192.168.5.10)->->+ Target +
+192.168.1.1+ +192.168.5.15+
+ + + +
+++++++++++++ ++++++++++++++
Step 2 SYN|ACK | |
To spoofed IP SYN ^
Responding to ACK |
Our SYN packet | RST---
| | |
++++++++++++++ |
+ +|
+ Zombie + |
+192.168.5.10+ |
+ +|
++++++++++++++ |
|
|---------------------------
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:
Code:
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->--->--->---> SYN|ACK -->-->-->-->-->- + Zombie +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1004) <---<---<-+ +
+++++++++++++ ++++++++++++++
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.
If the port is closed
Code:
+++++++++++++ ++++++++++++++
+ + STEP 1 + +
+ US +->->SYN(Fake source IP 192.168.5.10)->->+ Target +
+192.168.1.1+ +192.168.5.15+
+ + + +
+++++++++++++ ++++++++++++++
Step 2 RST |
To spoofed IP RST
Responding to |
our SYN packet |
as the port is |
closed ++++++++++++++
+ +
+ Zombie +
+192.168.5.10+
+ +
-------------------------------- ++++++++++++++
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 +
+192.168.1.1+ STEP 2 +192.168.5.10+
+ +---<---<---<-RST (IP ID=1003) <---<---<-+ +
+++++++++++++ ++++++++++++++
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 your real IP address. 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 beta.search.microsoft.com.
HPING beta.search.microsoft.com. (eth0 207.46.197.115): S set, 40 headers + 0
data bytes
46 bytes from 207.46.197.115: flags=SA seq=0 ttl=56 id=57645 win=16616
rtt=21.2 ms
rtt=21.4 ms
46 bytes from 207.46.197.115: flags=RA seq=2 ttl=56 id=18574 win=0 rtt=21.3
ms
ms
ms
rtt=21.2 ms
ms
rtt=21.7 ms
rtt=21.6 ms
rtt=21.3 ms
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 192.168.5.10 192.168.5.15
10) Window Scan –sW
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:
192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0

WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST WIN=0 ID=5324
192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0

WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=61513 S=23 RST WIN=0 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 more closely you will see a sort of pattern that the
different packets follow:
Code:
192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0

[b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST [b]WIN=0
[/b]ID=5324
192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0

[b]WIN=3042[/b]
192.168.5.15 --> 192.168.5.10 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:
192.168.5.10 --> 192.168.5.15 TCP; D=80 S=51876 ACK=0 LEN=0

WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=51876 S=80 RST WIN=4096 ID=5378
192.168.5.10 --> 192.168.5.15 TCP; D=8080 S=64281 ACK=0 SEQ LEN=0

WIN=3042
192.168.5.15 --> 192.168.5.10 TCP; D=64281 S=8080 RST WIN=4096
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 80.80.80.80
11) Maimon scan –sM
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 80.80.80.80
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.
12)UDP Scanning
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 80.80.80.80
It is possible to conduct a TCP scan and a UDP scan at the same time:
nmap –sT –sU 80.80.80.80
Version Scanning
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.
Code:
+++++++++++++ ++++++++++
+ + +Firewall+
+ Us +FTP logon request port 54321 + +
+81.81.81.81+--->--->--->--->--->--->-->-->+>--> +
+ + ftp someftpserver.com:54321 + 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 ‘someftpserver.com:54321’. 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 wu-ftpd.org
Code:
C:\Documents and Settings\Nokia>ftp wu-ftpd.org
Once you have successfully connected, you will be greeted with some information:
Code:
Connected to wu-ftpd.org.
220 ftp.wu-ftpd.org FTP server ready.
User (wu-ftpd.org:(none)):
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:
Code:
ftp> user anonymous

331 Guest login ok, send your complete e-mail address as password.
Password:
230-Welcome to the FTP server for the WU-FTPD Development Group
230-
230-This server is the primary distribution site for the WU-FTPD daemon.
230-
230-The pub directory contains the distribution and supporting files.
230-
230-If you are uploading contributions; please place them in the incoming
230-directory and email wuftpd-members@wu-ftpd.org announcing your
upload.
230-
230 Guest login ok, access restrictions apply.
ftp>
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:
Code:
C:\Documents and Settings\Nokia>nmap wu-ftpd.org

Starting Nmap 4.20 ( http://insecure.org ) at 2007-02-24 18:39 GMT Standard
Time
Interesting ports on 67.66.8.211:

Not shown: 1692 closed ports
PORT STATE SERVICE
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 should 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…..how are we going to exploit that? Well we could nip over to the
IANA web site and see what should be running on port 26:
http://www.iana.org/assignments/port-numbers
Quote:
# 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:
Code:
C:\Documents and Settings\Nokia>nmap -sV wu-ftpd.org

St
dard Time

(The 1669 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
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:
Code:
2 services unrecognized despite returning data. If you know the service/version

please submit the following fingerprints at http://www.insecure.org/cgi-bin/s
vicefp-submit.cgi :
==============NEXT SERVICE FINGERPRINT (SUBMIT
INDIVIDUALLY)==============
SF-Port21-TCP:V=4.03%I=7%D=2/24%Time=45E07F1C%P=i686-pc-windows-
windows%r(
SF:GenericLines,27,"220\x20ftp\.wu-ftpd\.org\x20FTP\x20server\x20ready\.\r
SF:\n")%r(Help,4D,"220\x20ftp\.wu-ftpd\.org\x20FTP\x20server\x20ready\.\r\
SF:n530\x20Please\x20login\x20with\x20USER\x20and\x20PASS\.\r\n");
==============NEXT SERVICE FINGERPRINT (SUBMIT
INDIVIDUALLY)==============
SF-Port80-TCP:V=4.03%I=7%D=2/24%Time=45E07F18%P=i686-pc-windows-
windows%r(
SF:GetRequest,FB8,"HTTP/1\.1\x20200\x20OK\r\nDate:\x20Sat,\x2024\x20Feb\x2
SF:02007\x2017:20:17\x20GMT\r\nServer:\x20Froglegs/104\.75\x20\(Unix\)\r\n
SF:Last-Modified:\x20Thu,\x2022\x20Jan\x202004\x2012:51:39\x20GMT\r\nETag:
SF:\x20\"3b034b-ebd-400fc75b\"\r\nAccept-Ranges:\x20bytes\r\nContent-Lengt
SF:h:\x203773\r\nConnection:\x20close\r\nContent-Type:\x20text/html\r\n\r\
SF:n<!DOCTYPE\x20HTML\x20PUBLIC\x20\"-
//W3C//DTD\x20HTML\x203\.2\x20Final/
SF:/EN\">\r\n<html>\r\n\x20<head>\r\n\x20\x20<title>WU-FTPD\x20Development
SF:\x20Group</title>\r\n\x20</head>\r\n\r\n\x20<body\x20BGCOLOR=\"#FFFFFF\"\x20TEXT=\"#000000\"\x20LI
SF:NK=\"#0000FF\"\x20VLINK=\"#000080\"\x20ALINK=\"#FF0000\">\r\n\x20\x20<h
SF:1\x20ALIGN=\"CENTER\">\r\n\x20\x20\x20WU-
FTPD\x20Development\x20Group\r
SF:\n\x20\x20</h1>\r\n\r\n<BLOCKQUOTE>\r\n<hr\x20NOSHADE>\r\n\x20\x20<p>\r
SF:\n<STRONG><EM>SECURITY\x20VULNERABILITY\x20DISCOVERED!</EM>
</STRONG>\r\
SF:n<P>\r\n<STRONG>A\x20vulnerability\x20has\x20been\x20found\x20in\x20the
SF:\x20current\x20versions\x20of\x20WU-FTPD\x20up\x20to\x202\.6\.2\.\x20\r
SF:\nInformation\x20describing\x20the\x20vulnerability\x20is\x20available\
SF:x20from</STRONG>\r\n<ul>\r\n<li><a\x20href=\"http://w")%r(HTTPOptions,A
SF:0,"HTTP/1\.1\x20200\x20OK\r\nDate:\x20Sat,\x2024\x20Feb\x202007\x2017:2
SF:0:17\x20GMT\r\nServer:\x20Froglegs/104\.75\x20\(Unix\)\r\nContent-Lengt
SF:h:\x200\r\nAllow:\x20GET,\x20HEAD,\x20OPTIONS,\x20TRACE\r\nConnection:\
SF:x20close\r\n\r\n")%r(RTSPRequest,1CC,"HTTP/1\.1\x20400\x20Bad\x20Reques
SF:t\r\nDate:\x20Sat,\x2024\x20Feb\x202007\x2017:20:18\x20GMT\r\nServer:\x
SF:20Froglegs/104\.75\x20\(Unix\)\r\nConnection:\x20close\r\nContent-Type:
SF:\x20text/html;\x20charset=iso-8859-1\r\n\r\n<!DOCTYPE\x20HTML\x20PUBLIC
SF:\x20\"-
//IETF//DTD\x20HTML\x202\.0//EN\">\n<HTML><HEAD>\n<TITLE>400\x20
SF:Bad\x20Request</TITLE>\n</HEAD><BODY>\n<H1>Bad\x20Request</H1>\nYou
r\x2
SF:0browser\x20sent\x20a\x20request\x20that\x20this\x20server\x20could\x20
SF:not\x20understand\.<P>\nThe\x20request\x20line\x20contained\x20invalid\
SF:x20characters\x20following\x20the\x20protocol\x20string\.<P>\n<P>\n</BO
SF:DY></HTML>\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 http://www.insecure.org/cgi-bin/servicefp-submit.cgi 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:
Code:
Service detection performed. Please report any incorrect results at http://insec

ure.org/nmap/submit/ .
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 80.80.80.80
Ping Sweeps
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:
Code:
C:\Documents and Settings\Nokia>nmap -sT 80.80.80.80

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:
Code:
C:\Documents and Settings\Nokia>nmap -P0 -sT 80.80.80.80

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)
Not shown: 1696 filtered ports
PORT STATE SERVICE
80/tcp open http
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.
TCP ACK:
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<port numbers>:
nmap 80.80.80.80 –PA25
You can still specify a normal scan option too if you so desire:
nmap –sT 80.80.80.80 –PA25
If you want to ping multiple port simply separate them with a comma.
To prove it works, consider the following output:
Code:
C:\Documents and Settings\Nokia>ping 87.237.61.100
Pinging 87.237.61.100 with 32 bytes of data:
Request timed out.

Request timed out.
Request timed out.
Request timed out.
Ping statistics for 87.237.61.100:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
So something is blocking ICMP from reaching that host; lets try the TCP ACK Ping:
Code:
C:\Documents and Settings\Nokia>nmap 81.80.80.34 -PA80

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)’.
TCP SYN Ping:
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 <ip address> -PS<port numbers>

Again separate multiple port numbers with a comma.
UDP Ping:
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 <ip address> -PU<port numbers>
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 <ip address> -PP
And the syntax for the Mask Ping is:

nmap <ip address> -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.

2007 A Hacking Odyssey

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

2007 A Hacking Odyssey

Hochgeladen von

Copyright:

Verfügbare Formate

2007 A Hacking Odyssey – Reconnaissance

Hacking, Cracking, Hackers and Crackers

So, how do pick a potential target?

In this case the words are ‘Garden Sheds’.

The company I chose is Shed Store.

Research the Target

Targets own web site

What info can we get from here?

Shedstore (A trading division of Guardian Buildings). Unit 1, Southview Park,

During our office hours of 8.30am to 12.00pm, then 1.00pm to 5.00pm -

The also have a members only area of the site.

Jobs advertised on company web sites

All this stems from a seemingly innocent job advert….

Newsgroups are a valuable source of information during the reconnaissance phase of an

A domain name refers to an organisations “Internet presence” and is usually related to

In our case we are told that the domain name is registered:

The answer to your domain search is

Browse to Nominet and enter shedstore.co.uk as the search term:

Domain Name Service – DNS

Microsoft Windows XP [Version 5.1.2600]

C:\Documents and Settings\Nokia>nslookup

At the ‘>’ prompt type google.com:

Now at the prompt type in one of these IP addresses:

If you haven’t guessed it already, it is DNS’s job to do this.

You can find a very good explanation of DNS here:

Go back to your nslookup prompt:

C:\Documents and Settings\Nokia>nslookup

> server ns0.serve.co.uk

> server ns0.serve.co.uk

So what have we got?

C:\Documents and Settings\Nokia>nslookup 212.69.210.106

inetnum: 212.69.210.0 - 212.69.211.255

Open a command prompt again and type the following:

You should now see this:

220 internetdesign.dsvr.co.uk ESMTP Exim 4.52 Wed, 07 Feb 2007 20:03:06

Go back to your command prompt and type:

C:\Documents and Settings\Nokia>ftp shedstore.co.uk

You should be presented with the following:

C:\Documents and Settings\Nokia>ftp shedstore.co.uk

To apply the methodology of breaking someone’s programming you need to do

The second conversation could go something like this:

People generally do not say no to an authoritative figure or to someone who is

Company name – An obvious one that we need

Name Servers – You have seem why these are important

Think of Caller ID spoofing as instantaneous credibility

TeleSpoof: http://www.telespoof.com/ is probably the most popular service to use since

You can find part one here:

Scanning typically involves all or some of the following:

Covered in this paper:

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

Netstumbler (http://www.netstumbler.com/) which is arguably the most popular War

Airodump (http://www.wirelessdefence.org/Contents/Aircrack_airodump.htm) which run

Mapping the Network

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

Here is where the trace part comes in:

C:\Documents and Settings\Nokia>tracert google.com

Tracing route to google.com [72.14.207.99]

5 240 ms 255 ms 247 ms gfd-bb-b-so-120-0.inet.ntl.com

6 * 217 ms 226 ms nth-bb-a-so-000-0.inet.ntl.com [62.253.185.97]

8 279 ms 265 ms 248 ms tele-ic-1-as0-0.inet.ntl.com [62.253.184.2]

C:\Documents and Settings\Nokia>nmap -sP 72.14.207.0-255

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-13 20:38 GMT