TheTAZZone - Internet Chaos

Tutorial – NMAP 3.48 Lesson 5 – Fingerprinting & scannin


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

Code: Select all
This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

NMAP v3.48 tutorial lesson 5 of 5 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

Please read the past four tutorials if you are new to NMAP. They are all in the Anti-Online tutorials forum.

You have seen basic, intermediate and advanced scanning techniques used thus far. You have also seen some of the footprints left behind by NMAP and how to avoid doing so. Building on this information, there will be times when you conduct scans with NMAP and the application will return something that looks like a giant pile of crypto babble. We will go over what this really is and what to do with the information. We will also use some other less used NMAP scans to quietly probe network devices for vulnerabilities as well as some logging features.

This is the final lesson in the NMAP series. I covered what I feel are useful features although there are others that I have not hit upon. As many of you know Fyoder is going to write a book on the application. That should tell you what this tool is capable of doing. I hope that this short series of tutorials have been helpful to both beginners and advanced users.

NMAP Fingerprints – What is This?

From time to time, you will scan a particular host and you will receive output that looks like cryptobabble. Let’s look at an example.

[haxor@localhost]# NMAP -v -sV -O -p 1-1024

Starting nmap 3.48 (

) at 2003-11-20 09:05 EST
Interesting ports on
(The 1017 ports scanned but not shown below are in state: closed)
21/tcp open ftp Microsoft ftpd 5.0
80/tcp open http Microsoft IIS webserver 5.0
135/tcp open msrpc Microsoft Windows msrpc
139/tcp open netbios-ssn
443/tcp open ssl Microsoft IIS SSL
445/tcp open microsoft-ds Microsoft Windows 2000 microsoft-ds
1024/tcp open kdm?
No exact OS matches for host (If you know what OS is running on it, see

TCP/IP fingerprint:

Nmap run completed — 1 IP address (1 host up) scanned in 23.524 seconds.

Hmmmm, what could this mess be? This mess is what NMAP uses to try and fingerprint the stack. You see, certain stack implementations respond differently when presented with an improper TCP flag, etc.. NMAP has a database of stack fingerprints which is based on RFCs for proper responses and also how specific proprietary stacks respond to the probes that NMAP makes when fingerprinting. What each of these lines represents is a tutorial by itself but if anyone is interested, here is a link that explains it:…ng-article.html

NOTE: To view the content of the NMAP stack fingerprints file, open it in a text editor of your choice. The locations are:
WIN32: %NMAP directory%nmap-os-fingerprints
*NIX: default install directory: /usr/local/share/nmap/nmap-os-fingerprints

Now then, as you can see, NMAP is having a small issue identifying a Windows box. I have included this example on purpose to reinforce the fact that the NMAP fingerprinting feature is *NOT* fool proof.

Now, if you know what kind of box you are hitting and NMAP does not recognize it, you can send the fingerprint to Fyodor (NMAP developer) and it will be added to the fingerprint file in future builds. If you want it right away, you can add it to the nmap-os-fingerprints file on your local machine. Just follow the format of the other entries and you are good to go. This method is also helpful if you don’t want others outside your organization to see how a specific device responds to NMAP fingerprinting. Developers and the like would most likely want to keep this information hush hush for as long as possible.One thing to note is that NMAP will overwrite the fingerprints file when you install a newer release, so keep that in mind if you choose to add entries locally.

Here is the link to submit NMAP fingerprints:

NOTE: Per the application developer, ¡§Be careful to not submit fingerprints generated when scanning through firewalls, NAT devices (on your end!) or load balancers without telling that in the Notes section.¡¨


NMAP is capable of logging in several different formats. Personally, I use the human readable format but you do have the option of XML and grepable format. Without getting too deep into this, here are the appropriate switches for each logging method. They can be added anywhere in the NMAP command you issue.
-oN <logfilename> This logs the results of your scans in a normal
human readable form into the file you specify as an argument.

-oX <logfilename> This logs the results of your scans in XML form
into the file you specify as an argument.

-oG <logfilename> This logs the results of your scans in a grepable
form into the file you specify as an argument.

-oA <basefilename> This tells Nmap to log in ALL the major formats
(normal, grepable, and XML). You give a base for the filename, and the output files will be base.nmap, base.gnmap, and base.xml.

-oS <logfilename> thIs l0gz th3 r3suLtS of YouR ScanZ iN a s|<ipT
kiDd|3 f0rM iNto THe fiL3 U sPecfy 4s an arGuMEnT! U kAn gIv3 the 4rgument “-” (wItHOUt qUOteZ) to sh00t output iNT0 stDouT!@!!. Just a note that this option is more for fun than anything else. The developer has a sense of humor and it is pretty funny to add this switch just to see what the output looks like. ƒº


OK, let’s say that you are auditing a network because, of course, you wouldn’t be attacking one. The firewall admin says that they have a tight firewall and nothing can get around it. However, you notice a CHUBB institute certificate on his wall so already you know that he barely knows which shoe goes on the right foot. You setup shop outside the network and you begin to probe the network. Now, even though you know that one dumdum is working at the company, there could be smarter people lurking around so your paranoia will serve you well. The first thing we do is a port scan to determine if the firewall allows inbound DNS connections for whatever purpose (Zone transfers, etc.).

[haxor@localhost]# NMAP -v -sS -g 53 -p 53

Let’s look at the command. We specified s SYN scan with a source port of 53 (DNS) and a destination port of 53 on the host specified. Note that I didn’t try to hide my identity because this is an audit, not an attack. We could have easily used a decoy or zombie scan (covered in earlier tutorials). Now, a decent firewall will immediately dump this source routed traffic. It will examine the contents to determine if this is malicious traffic and typically black hole the traffic.

Let’s say that this turns up nothing. Hmmm, let’s try something else.

[haxor@localhost]# NMAP -v -sU -g 53 -p 53

Notice that we are now using the UDP scan switch here. Let’s say that again, we are shot down. Not to worry, there are other avenues. Let’s try this:

[haxor@localhost]# NMAP -v -sS -g 20 -p 23

You’ll notice that I now specified an FTP data channel source port. Success!! We will assume that the IP address we hit is a static NAT address which will dump us to a box that sits on the inside of the network. Static NATing to internal addresses is much more common than you may think. If the box is listening, we can *easily* begin to chip away at it and eventually gain access. If we are able to, then GAME OVER. We can safely download a rootkit and anything else we like to the host. We can even go as far as setting up a reverse telnet session using Netcat (but that’s another story). So we now know that the device being used to guard the perimeter of this network is vulnerable to source routed packets that seem to be coming from a legitimate FTP session. This is hole #1. Let’s continue.

OK, so here we are, and we now tell the admin that not only can we poke holes in his network, we now tell him that it will be very difficult if at all possible to see us do it. We tell him that he can watch the logs and we still will be able to sneak under the radar screen.

Let’s make some assumptions. First, let’s say you were doing some traffic analysis and you have a pretty good idea what normal traffic looks like. There are many ways to do this, but different tools are involved. Now, let’s say that all of our precision scans turned up nothing so we’re gonna have to scan the entire class C range that we know is registered to them (because we did a whois on the domain and got all kinds of juicy info). Now, we’re not going to scan the ENTIRE class C range in one sweep. This would be like driving a bus through a library while trying to sneak out. Let’s be a bit more clever. Again, we can use the zombie or decoy switches learned earlier but for this example, we’re going to leave them out.

[haxor@localhost]# NMAP -v -n -T Paranoid -data_length 64 –randomize_hosts -oN haxor -sV -p 1-65535

OK, what we’ve done here is tell NMAP to never do a reverse DNS lookup (-n) and use Paranoid scans ( -T Paranoid serializes scans and waits 5 minutes between scans before continuing to the next host in hopes of not triggering an IDS) and we specified a data length consistent with normal traffic (–data_length 64) and we want it to randomize hosts (–randomize_hosts) and we want it logged in human readable format (-oN)to haxor and we specified a service scan for the entire IANA range for the host range of 198-203.

WHEW!!! Now, go relax and have a nice glass of beer while NMAP writes a nice file with any available goodies for further review.

I have covered quite a few commands and scenarios but there are many more that I have not. I could write a book on the many features NMAP has to offer (like it has a TCP dump type feature using the (-packet_trace switch). Like I mentioned, a book is coming out on its use. My tutorials are designed to give you a solid understanding of its use along with some very handy scan techniques. I hope you enjoyed the series.

I didn’t get a change to really clean up the formatting, so if something bothers you let me know. Also, if there is something you wanted covered but I didn’t hit on it, let me know and I will post a mini tut on the feature or technique.


One Response to Tutorial – NMAP 3.48 Lesson 5 – Fingerprinting & scannin

  1. Pingback: Vulnerability Assessment tools « Eikonal Blog

Leave a Reply

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


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

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

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

Donations can be made through the page ' Donate '.