NMAP 3.48 Tutorial - Lesson 4 - Stealth Scans
NMAP v3.48 tutorial lesson 4 of ? rev 1.0 by TheHorse13
PREFACE ***PLEASE READ AND UNDERSTAND THIS*** (Will be repeated at the top of each lesson)
======================
I'd like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped.
***I will be borrowing verbage (in some cases)*** from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense.
NOTE: TheHorse13 takes no responsibility in regards to your use of the information presented in the NMAP tutorial series. If you get into trouble, then obviously you aren’t as 31337 as you thought.
Bold text - Command syntax
Underlined text – Important information
PREREQUISIT
======================
Please read the past three tutorials if you are new to NMAP. They are all in the Anti-Online tutorials forum.
IN THIS LESSON
=====================
Now that you know how to use NMAP we are going to cover some advanced functionality along with what kind of footprints the application leaves behind. As you may have guessed, one of the topics in this tutorial is how to hide the source of your NMAP footprints. You will benefit from this info because you will see what types of scans NMAP users may use against you and you will also see what results are returned (or logged) when you attempt to enumerate networks. You will also see why NMAP can be most effective in mapping trust relationships on hosts between filtering devices such as firewall and/or routers.
I will be using a default install of Snort 2.0.0 build 72 on Red Hat 9 as a component in this tutorial. I will not be covering any features of Snort but rather what an admin will see if you hit a box that is running Snort. I could have used my own IDS setup but that would require another tutorial along with this series. Besides, I don’t want anyone seeing exactly how my IDS infrastructure responds to scans.
NOTE: Unless otherwise specified, assume that you are in a switched network environment.
Let’s start by just throwing a basic scan at a host that happens to have Snort running. Your IP is 192.168.1.100.
[haxor@localhost]# NMAP –v –sV -O -p 22 192.168.1.254
Snort will generate several alerts, including this one:
[**] SCAN nmap TCP [**]
11/07-01:33:18.752219 192.168.1.100:55464 -> 192.168.1.254:22
TCP TTL:46 TOS:0x0 ID:12633 IpLen:20 DgmLen:60
***A**** Seq: 0x18D5EF65 Ack: 0x0 Win: 0xC00 TcpLen: 40
TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Hmmmm, notice the first line. [**]SCAN nmap TCP[**]. Then notice the source, 192.168.1.100:55464. Well folks, you’ve been made. Game over. Or is it?
Let’s try this again only let’s make a small change to our command. Again, your IP is 192.168.1.100
[haxor@localhost]# NMAP –v –sV –O –D 192.168.2.10 -p 22 192.168.1.254
Notice that we used the –D switch for decoy. This generates the following log entry in Snort:
[**] SCAN nmap TCP [**]
11/07-12:01:08.582551 192.168.2.10:35522 -> 192.168.1.254:22
TCP TTL:46 TOS:0x0 ID:1902 IpLen:20 DgmLen:60
***A**** Seq: 0x2B740381 Ack: 0x0 Win: 0xC00 TcpLen: 40
TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
Notice how Snort thinks the traffic source IP was the decoy you specified, 192.168.2.10, not your true IP address of 192.168.1.100.
One additional thing you can do is add multiple decoys so that it appears that traffic is coming from a number of decoys.
[haxor@localhost]# NMAP –v –sV –O –D 192.168.2.10, 192.168.3.10 -p 22 192.168.1.254
This will generate log entries in Snort that show NMAP scans coming from the two decoys you specified.
Important: Be sure that your decoy machine(s) is/are up otherwise you may end up SYN flooding the target.
Another crafty way to hide yourself is with the –b FTP bounce option. Now, this issue has been addressed years ago and is rare in the wild but you can still find vulnerable FTP servers out there that will gladly bounce traffic for you. Because this is not really popular anymore, I’ll give you a quick explanation on how it works.
Because the RFC for FTP has proxy support, you are able to use an FTP server to bounce traffic. As *Hobbit* wrote back in 1995, this protocol flaw "can be used to post virtually untraceable mail and news, hammer on servers at various sites, fill up disks, try to hop firewalls, and generally be annoying and hard to track down at the same time." What we will exploit this for is to (surprise, surprise) scan TCP ports from a "proxy" ftp server. Thus you could connect to an ftp server behind a firewall, and then scan ports…”.
The syntax is simple:
[haxor@localhost]# NMAP –v –sV –O –b anonymous:[email protected]:21 -p 22 192.168.1.254
You will see NMAP connect up and begin to proxy out traffic. Also, NMAP will inform you if a server is able to conduct this type of proxy operation. Typically, when you hit a server that will not do this, NMAP will tell you that the FTP server sucks and cannot be used for this purpose. The actual syntax looks something like this:
Hint: if your bounce scan target hosts aren't reachable from here, remember to use -P0 so we don't try and ping them prior to the scan
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-11-10 12:54 EST
Resolved ftp bounce attack proxy to 10.10.10.112 (Crack-House).
Host 192.168.1.254 appears to be up ... good.
Attempting connection to ftp://anonymous:[email protected]:21
Connected:220-Microsoft FTP Service
220 Crack House - Da Masta Gangstaz
Login credentials accepted by ftp server!
Initiating TCP ftp bounce scan against 192.168.1.254 at 12:54
Your ftp bounce server sucks, it won’t let us feed bogus ports!
Anyway, this is the message you will see 99% of the time. I just wanted to include the syntax and output for learning purposes.
IDLESCANNING: THE NMAP HOLY GRAIL
=========================
Of all the features that NMAP has, this one is my favorite. This scan allows you to gather information about target hosts *without* sending packets. Yes, you read correctly. The most important thing to note is that NMAP reports vulnerability info based on the zombie’s perspective, that is, the machine you are using to idlescan the target. The benefit of this is that the zombie host may have a trust relationship with a target behind a router or firewall, while you, the attacker (or security auditor) obviously has no trust. For more information, along with a diagram, see http://www.insecure.org/nmap/idlescan.html
Let’s go to work here. The scenario is that I am auditing the perimeter defenses of a subnet that has a router sitting between my subnet and the target subnet. There are about 50 hosts on my network and one of the boxes has a trust relationship with a box on another subnet.
Because we don’t want to be identified by the crafty folks watching the IDS logs, we’re going to use the idlescan technique. Now, the IDS will still log a hit but it will appear to come from the zombie host, not you. This may or may not raise attention based on how you probe the target host. Here we go.
First, let’s assume that you found the host that has the trust relationship. This is a paper on to itself so just bear with me. Now, Snort is positioned on the same network as the target machine.
You = 192.168.1.100
Zombie = 192.168.1.50
Target = 192.168.10.10
Snort = 192.168.10.5
[haxor@localhost]# NMAP –v –P0 –p 1-65535 -sI 192.168.1.50 192.168.10.10
Important: To be sure that an initial ping is not sent by using the –P0 switch, which tells NMAP not to send out an ICMP request to the target host.
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-11-10 12:54 EST
Idlescan using zombie 192.168.1.50 (192.168.1.50:80); Class: Incremental
Interesting ports on 192.168.10.10:
(The 65522 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
135/tcp open loc-srv
443/tcp open https
1027/tcp open IIS
1030/tcp open iad1
2306/tcp open unknown
5631/tcp open pcanywheredata
7937/tcp open unknown
7938/tcp open unknown
36890/tcp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 2594.472 seconds
Can you guess what Snort shows after this scan? Nada, zippo, nothing. It also appears that 192.168.1.50 has permit ACLs on the router as we suspected. All that is left is to compromise this host (which would be a joke for a number of reasons, but again, that’s another tutorial).
NOTE: If the box running Snort and the zombie are hooked up to the same hub as your host running NMAP then you are owned before you begin. Even with the –P0 switch, NMAP will send ICMP traffic to the zombie, which will result in every port on the hub seeing the traffic. This includes the box running Snort. Snort will immediately see this as NMAP activity and will nail you as the source. Be sure you understand networking before you decide to be cute with this application.
NOTE: There are plenty of things you can do to prevent this type of attack. This technique is shown here so that you can see how mis-configured hardware can easily lead to complete compromise. Also, how to use NMAP to identify mis-configured networking hardware.
Next lesson will show how NMAP can be used to identify mis-configured firewalls and how to determine which ACLs are in use.
