Home > Articles

  • Print
  • + Share This
This chapter is from the book


The following sections provide details about the different network scanning concepts and scanning tools. You also learn different techniques for host discovery, port and service discovery, operating system (OS) discovery (banner grabbing/OS fingerprinting), and scanning beyond the intrusion detection system (IDS) and firewall.


Host Discovery

Attackers will want to know whether machines are alive before they attempt to attack. One of the most basic methods of identifying active machines is to perform a ping sweep. Just because ping can be blocked does not mean it is. Although many organizations have restricted ping, you should still check to see if it is available. Ping uses ICMP and works by sending an echo request to a system and waiting for the target to send an echo reply back. If the target device is unreachable, a request timeout is returned. Ping is a useful tool to identify active machines and to measure the speed at which packets are moved from one host to another or to get details like the TTL. Figure 3-9 shows a capture of ping packets from a Linux system using the Wireshark packet capture (sniffer) tool. If you examine the ASCII decode at the bottom, you will notice that the data in the ping packet is composed of different hexadecimal values; in other systems (like Windows), this may be different. The reason is that the RFC that governs ping doesn’t specify what’s carried in the packet as payload. Vendors fill in this padding as they see fit. Unfortunately, this can also serve hackers as a covert channel. Hackers can use a variety of programs to place their own information in place of the normal padding. Tools like Loki and IcmpSendEcho are designed for just this purpose. Then what appear to be normal pings are actually a series of messages entering and leaving the network.


Figure 3-9 Ping Capture

Ping does have a couple of drawbacks: First, only one system at a time is pinged, and second, not all networks allow ping. To ping a large number of hosts, a ping sweep is usually performed. Programs that perform ping sweeps usually sweep through a range of devices to determine which ones are active. Programs that will perform ping sweeps include the following:


Port and Service Discovery

Port scanning is the process of connecting to TCP and UDP ports for the purpose of finding what services and applications are running on the target device. After discovering running applications, open ports, and services, a hacker can then determine the best way to attack the system.

As discussed in Chapter 2, “The Technical Foundations of Hacking,” there are a total of 65,535 TCP and UDP ports. These port numbers are used to identify a specific process that a message is coming from or going to. Table 3-6 lists some common port numbers.

Table 3-6 Common Ports and Protocols





































As you have probably noticed, some of these applications run on TCP, others on UDP. Although it is certainly possible to scan for all 65,535 TCP and 65,535 UDP ports, many hackers will not. They will concentrate on the first 1,024 ports. These well-known ports are where we find most of the commonly used applications. You can find a list of well-known ports at http://www.iana.org/assignments/port-numbers. This is not to say that high-order ports should be totally ignored, because hackers might break into a system and open a high-order port, such as 31337, to use as a backdoor. So, is one protocol easier to scan for than the other? The answer to that question is yes. TCP offers more opportunity for the hacker to manipulate than UDP. Let’s take a look at why.

TCP offers robust communication and is considered a connection protocol. TCP establishes a connection by using what is called a three-way handshake. Those three steps proceed as follows:

  1. The client sends the server a TCP packet with the sequence number flag (SYN flag) set and an initial sequence number (ISN).

  2. The server replies by sending a packet with the SYN/ACK flag set to the client. The synchronize sequence number flag informs the client that it would like to communicate with it, and the acknowledgment flag informs the client that it received its initial packet. The acknowledgment number will be one digit higher than the client’s ISN. The server generates an ISN, as well, to keep track of every byte sent to the client.

  3. When the client receives the server’s packet, it creates an ACK packet to acknowledge that the data has been received from the server. At this point, communication can begin.

The TCP header contains a 1-byte field for the flags. Table 3-7 describes the six most common flags.


Table 3-7 TCP Flag Types




Synchronize and initial sequence number (ISN)


Acknowledgment of packets received


Final data flag used during the four-step shutdown of a session


Reset bit used to close an abnormal connection


Push data bit used to signal that data in the packet should be pushed to the beginning of the queue; usually indicates an urgent message


Urgent data bit used to signify that urgent control characters are present in this packet that should have priority

At the conclusion of communication, TCP terminates the session by using a four-step shutdown:

  1. The client sends the server a packet with the FIN/ACK flags set.

  2. The server sends a packet ACK flag set to acknowledge the client’s packet.

  3. The server then generates another packet with the FIN/ACK flags set to inform the client that it also is ready to conclude the session.

  4. The client sends the server a packet with the ACK flag set to conclude the session.

The TCP system of communication makes for robust communication but also allows a hacker many ways to craft packets in an attempt to coax a server to respond or to try to avoid detection of an intrusion detection system (IDS). Many of these methods are built in to Nmap and other port-scanning tools. Before we take a look at those tools, though, some of the more popular port-scanning techniques are listed here:

  • TCP full connect scan: This type of scan is the most reliable, although it is also the most detectable. It is easily logged and detected because a full connection is established. Open ports reply with a SYN/ACK, and closed ports respond with an RST/ACK.

  • TCP SYN scan: This type of scan is known as half open because a full TCP three-way connection is not established. This type of scan was originally developed to be stealthy and evade IDSs, although most now detect it. Open ports reply with a SYN/ACK, and closed ports respond with an RST/ACK.

  • TCP FIN scan: Forget trying to set up a connection; this technique jumps straight to the shutdown. This type of scan sends a FIN packet to the target port. An open port should return no response. Closed ports should send back an RST/ACK. This technique is usually effective only on UNIX devices or those compliant to RFC 793.

  • TCP NULL scan: Sure, there should be some type of flag in the packet, but a NULL scan sends a packet with no flags set. If the OS has implemented TCP per RFC 793, open ports send no reply, whereas closed ports will return an RST.

  • TCP ACK scan: This scan attempts to determine access control list (ACL) rule sets or identify if a firewall or simply stateless inspection is being used. A stateful firewall should return no response. If an ICMP destination is unreachable, and a communication administratively prohibited message is returned, the port is considered to be filtered. If an RST is returned, no firewall is present.

  • TCP XMAS scan: Sorry, there are no Christmas presents here, just a port scan that has toggled on the FIN, URG, and PSH flags. Open ports should provide no response. Closed ports should return an RST. Systems must be designed per RFC 793 for this scan to work, as is common for Linux. It does not work against Windows computers.

Certain operating systems have taken some liberties when applying the TCP/IP RFCs and do things their own way. Because of this, not all scan types work against all systems. Results will vary, but full connect scans and SYN scans should work against all systems.

These are not the only types of possible scans; there are other scan types. Some scanning techniques can be used to obscure attackers and help hide their identity. One such technique is the idle or zombie scan. Before we go through an example of idle scanning, let’s look at some basics on how TCP/IP connections operate. IP makes use of an identification number known as an IPID. This counter helps in the reassembly of fragmented traffic. TCP offers reliable service; it must perform a handshake before communication can begin. The initializing party of the handshake sends a SYN packet to which the receiving party returns a SYN/ACK packet if the port is open. For closed ports, the receiving party returns an RST. The RST acts as a notice that something is wrong, and further attempts to communicate should be discontinued. RSTs are not replied to; if they were replied to, we might have a situation in which two systems flood each other with a stream of RSTs. This means that unsolicited RSTs are ignored. When these characteristics are combined with IPID behavior, a successful idle scan is possible.

An open port idle scan works as follows:

  • Step 1. An attacker sends an IDIP probe to the idle host to solicit a response. Suppose, for example, that the response produces an IPID of 12345.

  • Step 2. Next, the attacker sends a spoofed packet to the victim. This SYN packet is sent to the victim but is addressed from the idle host. An open port on the victim’s system will then generate a SYN ACK. Because the idle host was not the source of the initial SYN packet and did not at any time want to initiate communication, it responds by sending an RST to terminate communications. This increments the IPID by one to 12346.

  • Step 3. Finally, the attacker again queries the idle host and is issued an IPID response of 12347. Because the IPID count has now been incremented by two from the initial number of 12345, the attacker can deduce that the scanned port on the victim’s system is open.

Figure 3-10 provides an example of this situation.


Figure 3-10 IPID Open Port

But what if the target system has its port closed? In that situation, the scan starts the same way as previously described:

  • Step 1. An attacker makes an initial query to determine the idle host’s IPID value. Note that the value returned was 12345.

  • Step 2. The attacker sends a SYN packet addressed to the victim but spoofs it to appear that it originated from the idle host. Because the victim’s port is closed, it responds to this query by issuing an RST. Because RSTs don’t generate additional RSTs, the communication between the idle host and the victim ends here.

  • Step 3. The attacker again probes the idle host and examines the response. Because the victim’s port was closed, we can see that the returned IPID was 12346. It was only incremented by one because no communication had taken place since the last IPID probe that determined the initial value.

Figure 3-11 provides an example of this situation.


Figure 3-11 IPID Port Closed

Although not perfect, this scanning technique enables attackers to obscure their true address. However, limitations apply to the capability of an idle scan. First, the system designated to play the role of the idle host must truly be idle. A chatty system is of little use because the IPID will increment too much to be useful. There is also the fact that not all operating systems use an incrementing IPID. For example, some versions of Linux set the IPID to zero or generate a random IPID value. Again, these systems are of little use in such an attack. Finally, these results must be measured; by this, we mean that several passes need to be performed to validate the results and be somewhat sure that the attacker’s conclusions are valid. Although the concept of idle scanning is interesting, there are a few other scan types worth briefly noting:

  • ACK scan: Sends an ACK probe with random sequence numbers. ICMP type 3 code 13 responses may mean that stateless firewalls are being used, and an RST can mean that the port is not filtered.

  • FTP bounce scan: Uses an FTP server to bounce packets off and make the scan harder to trace.

  • RPC scan: Attempts to determine whether open ports are RPC ports.

  • Window scan: Similar to an ACK scan but can sometimes determine open ports. It does so by examining the TCP window size of returned RST packets. On some systems, open ports return a positive window size and closed ones return a zero window size.

Now let’s look at UDP scans. UDP is unlike TCP. TCP is built on robust connections, but UDP is based on speed. With TCP, the hacker can manipulate flags in an attempt to generate a TCP response or an error message from ICMP. UDP does not have flags, nor does UDP issue responses. It’s a fire-and-forget protocol! The most you can hope for is a response from ICMP.

If the port is closed, ICMP attempts to send an ICMP type 3 code 3 port unreachable message to the source of the UDP scan. But, if the network is blocking ICMP, no error message is returned. Therefore, the response to the scans might simply be no response. If you are planning on doing UDP scans, plan for unreliable results.

Next, we discuss some of the programs that can be used for port scanning.


Nmap was developed by a hacker named Fyodor Yarochkin. It is probably the most widely used port scanner ever developed. It can do many types of scans and OS identification. It also enables you to control the speed of the scan from slow to insane. Its popularity can be seen by the fact that it’s incorporated into other products and was even used in the movie The Matrix. Nmap can be installed as a GUI or command-line program in Linux, Windows, and macOS; and it is installed by default in Linux distributions such as Kali Linux, Parrot Security OS, BlackArch, Pentoo, and others. You can download Nmap from https://nmap.org. Example 3-6 shows results from Nmap with the help option so that you can review some of its many switches.

Example 3-6 Displaying Nmap Switches

#nmap -h
Nmap 7.80 ( https://nmap.org )
Usage: nmap [Scan Type(s)] [Options] {target specification}
  Can pass hostnames, IP addresses, networks, etc.
  Ex: scanme.nmap.org, microsoft.com/24,; 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
  -sL: List Scan - simply list targets to scan
  -sn: Ping Scan - disable port scan
  -Pn: Treat all hosts as online -- skip host discovery
  -PS/PA/PU/PY[portlist]: TCP SYN/ACK, UDP or SCTP discovery to given
  -PE/PP/PM: ICMP echo, timestamp, and netmask request discovery
  -PO[protocol list]: IP Protocol Ping
  -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
  --traceroute: Trace hop path to each host
  -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
  -sU: UDP Scan
  -sN/sF/sX: TCP Null, FIN, and Xmas scans
  --scanflags <flags>: Customize TCP scan flags
  -sI <zombie host[:probeport]>: Idle scan
  -sO: IP protocol scan
  -b <FTP relay host>: FTP bounce scan
  -p <port ranges>: Only scan specified ports
    Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080,S:9
  --exclude-ports <port ranges>: Exclude the specified ports from
  -F: Fast mode - Scan fewer ports than the default scan
  -r: Scan ports consecutively - don't randomize
  --top-ports <number>: Scan <number> most common ports
  --port-ratio <ratio>: Scan ports more common than <ratio>
  -sV: Probe open ports to determine service/version info
  --version-intensity <level>: Set from 0 (light) to 9 (try all
  --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)
  -sC: equivalent to --script=default
  --script=<Lua scripts>: <Lua scripts> is a comma separated list of
            directories, script-files or script-categories
  --script-args=<n1=v1,[n2=v2,...]>: provide arguments to scripts
  --script-args-file=filename: provide NSE script args in a file
  --script-trace: Show all data sent and received
  --script-updatedb: Update the script database.
  --script-help=<Lua scripts>: Show help about scripts.
            <Lua scripts> is a comma-separated list of script-files or
  -O: Enable OS detection
  --osscan-limit: Limit OS detection to promising targets
  --osscan-guess: Guess OS more aggressively
  Options which take <time> are in seconds, or append 'ms'
  's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g.
  -T<0-5>: Set timing template (higher is faster)
  --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes
  --min-parallelism/max-parallelism <numprobes>: Probe parallelization
  --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>:
      probe round trip time.
  --max-retries <tries>: Caps number of port scan probe
  --host-timeout <time>: Give up on target after this long
  --scan-delay/--max-scan-delay <time>: Adjust delay between probes
  --min-rate <number>: Send packets no slower than <number> per second
  --max-rate <number>: Send packets no faster than <number> per second
  -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
  --proxies <url1,[url2],...>: Relay connections through HTTP/SOCKS4
  --data <hex string>: Append a custom payload to sent packetsç
  --data-string <string>: Append a custom ASCII string to sent
  --data-length <num>: Append random data to sent packets
  --ip-options <options>: Send packets with specified ip options
  --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/SCTP checksum
  -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 -vv or more for greater effect)
  -d: Increase debugging level (use -dd or more for greater effect)
  --reason: Display the reason a port is in a particular state
  --open: Only show open (or possibly open) ports
  --packet-trace: Show all packets sent and received
  --iflist: Print host interfaces and routes (for debugging)
  --append-output: Append to rather than clobber specified output
  --resume <filename>: Resume an aborted scan
  --stylesheet <path/URL>: XSL stylesheet to transform XML output to
  --webxml: Reference stylesheet from Nmap.Org for more portable XML
  --no-stylesheet: Prevent associating of XSL stylesheet w/XML output
  -6: Enable IPv6 scanning
  -A: Enable OS detection, version detection, script scanning, and
  --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
  --unprivileged: Assume the user lacks raw socket privileges
  -V: Print version number
  -h: Print this help summary page.
  nmap -v -A scanme.nmap.org
  nmap -v -sn
  nmap -v -iR 10000 -Pn -p 80
SEE THE MAN PAGE (https://nmap.org/book/man.html) FOR MORE OPTIONS AND

The Nmap Scripting Engine (NSE) is one of Nmap’s most powerful and flexible features. It allows users to create and use simple scripts to automate a wide variety of networking tasks. You can use the Linux locate command to find where the NSE scripts are located in your system (as demonstrated in Example 3-7). In Parrot Security OS and Kali Linux, the default location is /usr/share/nmap/scripts.

Example 3-7 Locating NSE Scripts

#locate *.nse
<output omitted for brevity>

Nmap’s output provides the open port’s well-known service name, number, and protocol. Ports can either be open, closed, or filtered. If a port is open, it means that the target device will accept connections on that port. A closed port is not listening for connections, and a filtered port means that a firewall, filter, or other network device is guarding the port and preventing Nmap from fully probing it or determining its status. If a port is reported as unfiltered, it means that the port is closed, and no firewall or router appears to be interfering with Nmap’s attempts to determine its status.

To run Nmap from the command line, type nmap, followed by the switch, and then enter a single IP address or a range. Example 3-8 shows how the -sT option is used; it performs a full three-step TCP connection.

Example 3-8 Performing a Three-Step Connection with Nmap

#nmap -sT
Starting Nmap 7.80 ( https://nmap.org )
Nmap scan report for
Host is up (0.0028s latency).
Not shown: 994 closed ports
22/tcp   open  ssh
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs
3128/tcp open  squid-http
Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds

The output shows several interesting ports found on this computer, including 80 and 139. Example 3-9 shows the results returned after running a UDP scan performed with the -sU switch.

Example 3-9 UDP Scan with Nmap

#nmap -sU
Starting nmap 7.80 (https://nmap.org/ )
Interesting ports on Server (
(The 1653 ports scanned but not shown below are in state: filtered)
Nmap run completed -- 1 IP address (1 host up) scanned in
843.713 seconds

For a quick trick to use the most common NSE scripts that are relevant to the ports that are open, you can use the nmap -sC command, as demonstrated in Example 3-10. Here, you can see additional details about the system (a Linux server running SSH, RPC, Samba, NFS, and a Squid HTTP proxy).

Example 3-10 nmap –sC Results

#nmap -sC
Starting Nmap 7.80 ( https://nmap.org )
Nmap scan report for
Host is up (0.0017s latency).
Not shown: 994 closed ports
22/tcp   open ssh
| ssh-hostkey:
|   2048 79:81:aa:61:d5:bb:9e:35:21:e3:a4:82:9b:3f:a6:49 (RSA)
|   256 ae:72:9b:ee:4d:ee:04:62:af:20:22:f9:06:07:06:8c (ECDSA)
|_  256 8a:c9:d3:dc:a3:57:99:9b:4f:cf:6b:c9:3f:07:59:cf (ED25519)
111/tcp  open  rpcbind
| rpcinfo:
|   program version    port/proto  service
|   100000  2,3,4        111/tcp    rpcbind
|   100000  2,3,4        111/udp    rpcbind
|   100000  3,4          111/tcp6   rpcbind
|   100000  3,4          111/udp6   rpcbind
|   100003  3           2049/udp    nfs
|   100003  3           2049/udp6   nfs
|   100003  3,4         2049/tcp    nfs
|   100003  3,4         2049/tcp6   nfs
|   100005  1,2,3      37524/udp    mountd
|   100005  1,2,3      42643/tcp6   mountd
|   100005  1,2,3     51869/tcp     mountd
|   100005  1,2,3     52545/udp6    mountd
|   100021  1,3,4     36149/tcp6    nlockmgr
|   100021  1,3,4     41338/udp     nlockmgr
|   100021  1,3,4     44907/tcp     nlockmgr
|   100021  1,3,4     48342/udp6    nlockmgr
|   100024  1         40980/udp     status
|   100024  1         50831/udp6    status
|   100024  1         52407/tcp     status
|   100024  1         57769/tcp6    status
|   100227  3          2049/tcp     nfs_acl
|   100227  3          2049/tcp6    nfs_acl
|   100227  3          2049/udp     nfs_acl
|_  100227  3          2049/udp6    nfs_acl
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs_acl
3128/tcp open  squid-http
Host script results:
|_clock-skew: mean: 1h39m52s, deviation: 2h53m12s, median: -7s
|_nbstat: NetBIOS name: POSEIDON, NetBIOS user: <unknown>, NetBIOS
MAC: <unknown> (unknown)
| smb-os-discovery:
|   OS: Windows 6.1 (Samba 4.9.5-Debian)
|   Computer name: poseidon
|   NetBIOS computer name: POSEIDON\x00
|   Domain name: ohmr.org
|   FQDN: poseidon.ohmr.org
|_  System time: 2021-02-12T21:53:46-05:00
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode:
|   2.02:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2021-02-13T02:53:46
|_  start_date: N/A
Nmap done: 1 IP address (1 host up) scanned in 28.64 seconds


SuperScan is written to run on Windows machines. It’s a versatile TCP/UDP port scanner, pinger, and hostname revolver. It can perform ping scans and port scans using a range of IP addresses, or it can scan a single host. It also has the capability to resolve or reverse-lookup IP addresses. It builds an easy-to-use HTML report that contains a complete breakdown of the hosts that were scanned. This includes information on each port and details about any banners that were found. It’s free; therefore, it is another tool that all ethical hackers should have.


THC-Amap is another example of a tool that is used for scanning and banner grabbing. One problem that traditional scanning programs have is that not all services are ready and eager to give up the appropriate banner. For example, some services, such as Secure Sockets Layer (SSL), expect a handshake. Amap handles this by storing a collection of responses that it can fire off at the port to interactively elicit it to respond. Amap was the first to perform this functionality, but it has been replaced by Nmap. One technique is to use this program by taking the greppable format of Nmap as an input to scan for those open services. Defeating or blocking Amap is not easy, although one technique would be to use a port-knocking technique. Port knocking is similar to a secret handshake or combination. Only after inputting a set order of port connections can a connection be made. For example, you may have to first connect on 80, 22, and 123 before connecting to 443. Otherwise, the port will show as closed.


Hping is another very useful ethical hacking tool that can perform both ping sweeps and port scans. Hping works on Windows and Linux computers and can function as a packet builder. You can find the Hping tool at http://www.hping.org or download the Linux Backtrack distribution, which also contains Hping. Hping2 and 3 can be used for firewall testing, identifying honeypots, and port scanning. Here are some other Hping3 syntax examples of note:

  • ICMP pings: hping3 -C IP_Address

  • SYN scan: hping3 -S IP_Address

  • ACK scan: hping3 -A IP_Address

  • XMAS scan: hping3 -X IP_Address

Port Knocking

Port knocking is a method of establishing a connection to a host that does not initially indicate that it has any open ports. Port knocking works by having the remote device send a series of connection attempts to a specific series of ports. It is somewhat analogous to a secret handshake. After the proper sequence of port knocking has been detected, the required port is opened, and a connection is established. The advantage of using a port-knocking technique is that hackers cannot easily identify open ports. The disadvantages include the fact that the technique does not harden the underlying application. Also, it isn’t useful for publicly accessible services. Finally, anyone who has the ability to sniff the network traffic will be in possession of the appropriate knock sequence.

OS Discovery (Banner Grabbing/OS Fingerprinting) and Scanning Beyond IDS and Firewall


At this point in the information-gathering process, the hacker has made some real headway. IP addresses, active systems, and open ports have been identified. Although the hacker might not yet know the types of systems he is dealing with, he is getting close. Fingerprinting is the primary way to identify a specific system. Fingerprinting works because each vendor implements the TCP/IP stack in different ways. For example, it’s much the same as when you text a specific friend who typically says something like, “Hey, what’s up?” while another friend simply says, “Hi.” There are two ways in which the hacker can attempt to identify the targeted devices. The hacker’s first choice is passive fingerprinting. The hacker’s second choice is to perform active fingerprinting, which basically sends malformed packets to the target in the hope of eliciting a response that will identify it. Although active fingerprinting is more accurate, it is not as stealthy as passive fingerprinting.

Passive fingerprinting is really sniffing, because the hacker is sniffing packets as they come by. These packets are examined for certain characteristics that can be pointed out to determine the OS. The following four commonly examined items are used to fingerprint the OS:

  • IP TTL value: Different operating systems set the TTL to unique values on outbound packets.

  • TCP window size: OS vendors use different values for the initial window size.

  • IP DF option: Not all OS vendors handle fragmentation in the same way. A common size with Ethernet is 1500 bytes.

  • IP Type of Service (TOS) option: TOS is a 3-bit field that controls the priority of specific packets. Again, not all vendors implement this option in the same way.

These are just four of many possibilities that can be used to passively fingerprint an OS. Other items that can be examined include IP identification number (IPID), IP options, TCP options, and even ICMP. Ofir Arkin wrote an excellent paper on this, titled “ICMP Usage in Scanning.” An example of a passive fingerprinting tool is the Linux-based tool P0f. P0f attempts to passively fingerprint the source of all incoming connections after the tool is up and running. Because it’s a truly passive tool, it does so without introducing additional traffic on the network. P0fv2 is available at http://lcamtuf.coredump.cx/p0f.tgz.

Active fingerprinting is more powerful than passive fingerprint scanning because the hacker doesn’t have to wait for random packets, but as with every advantage, there is usually a disadvantage. This disadvantage is that active fingerprinting is not as stealthy as passive fingerprinting. The hacker actually injects the packets into the network. Active fingerprinting has a much higher potential for being discovered or noticed. Like passive OS fingerprinting, active fingerprinting examines the subtle differences that exist between different vendor implementations of the TCP/IP stack. Therefore, if hackers probe for these differences, the version of the OS can most likely be determined. One of the individuals who has been a pioneer in this field of research is Fyodor Yarochkin. He has an excellent chapter on remote OS fingerprinting at https://nmap.org/book/osdetect.html. Listed here are some of the basic methods used in active fingerprinting:

  • The FIN probe: A FIN packet is sent to an open port, and the response is recorded. Although RFC 793 states that the required behavior is not to respond, many operating systems such as Windows will respond with an RST.

  • Bogus flag probe: As you might remember from Table 3-7, the flag field is only 1 byte in the TCP header. A bogus flag probe sets one of the used flags along with the SYN flag in an initial packet. Linux will respond by setting the same flag in the subsequent packet.

  • Initial sequence number (ISN) sampling: This fingerprinting technique works by looking for patterns in the ISN. Although some systems use truly random numbers, others, such as Windows, increment the number by a small fixed amount.

  • IPID sampling: Many systems increment a systemwide IPID value for each packet they send. Others, such as older versions of Windows, do not put the IPID in network byte order, so they increment the number by 256 for each packet.

  • TCP initial window: This fingerprint technique works by tracking the window size in packets returned from the target device. Many operating systems use exact sizes that can be matched against a database to uniquely identify the OS.

  • ACK value: Again, vendors differ in the ways they have implemented the TCP/IP stack. Some operating systems send back the previous value +1, whereas others send back more random values.

  • Type of service: This fingerprinting type tweaks ICMP port unreachable messages and examines the value in the TOS field. Whereas some use 0, others return different values.

  • TCP options: Here again, different vendors support TCP options in different ways. By sending packets with different options set, the responses will start to reveal the server’s fingerprint.

  • Fragmentation handling: This fingerprinting technique takes advantage of the fact that different OS vendors handle fragmented packets differently. RFC 1191 specifies that the maximum transmission unit (MTU) is normally set between 68 and 65535 bytes. This technique was originally discovered by Thomas Ptacek and Tim Newsham.

Active Fingerprinting Tools

One of the first tools to be widely used for active fingerprinting back in the late 1990s was Queso. Although no longer updated, it helped move this genre of tools forward. Nmap is the tool of choice for active fingerprinting and is one of the most feature-rich free fingerprint tools in existence today. Nmap’s database can fingerprint literally hundreds of different operating systems. Fingerprinting with Nmap is initiated by running the tool with the -O option. When started with this command switch, Nmap probes port 80 and then ports in the 20 to 23 range. Nmap needs one open and one closed port to make an accurate determination of what OS a particular system is running.

Example 3-11 demonstrates how fingerprinting works with Nmap.

Example 3-11 Fingerprinting with Nmap

#nmap -O
Starting Nmap 7.80 ( https://nmap.org )
Nmap scan report for
Host is up (0.0013s latency).
Not shown: 994 closed ports
22/tcp   open  ssh
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
2049/tcp open  nfs
3128/tcp open  squid-http
No exact OS matches for host (If you know what OS is running on it,
see https://nmap.org/submit/ ).
TCP/IP fingerprint:
Network Distance: 2 hops
OS detection performed. Please report any incorrect results at
https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.79 seconds

You might also want to try Nmap with the -v or -vv switch. There are devices such as F5 Load Balancer that will not identify themselves using a normal -O scan but will reveal their ID with the -vv switch. Just remember that with Nmap or any other active fingerprinting tool, you are injecting packets into the network. This type of activity can be tracked and monitored by an IDS. Active fingerprinting tools, such as Nmap, can be countered by tweaking the OS’s stack. Anything that tampers with this information can affect the prediction of the target’s OS version.

Nmap’s dominance of active fingerprinting is being challenged by several other tools. One such tool is Xprobe2, a Linux-based active OS fingerprinting tool with a different approach to OS fingerprinting. Xprobe is unique in that it uses a mixture of TCP, UDP, and ICMP to slip past firewalls and avoid IDS systems. Xprobe2 relies on fuzzy signature matching. In layman’s terms, this means that targets are run through a variety of tests. These results are totaled, and the user is presented with a score that tells the probability of the targeted machine’s OS—for example, 75 percent Windows 10 and 1 percent Windows Vista.

Fingerprinting Services

If there is any doubt left as to what a particular system is running, this next step of information gathering should serve to answer those questions. Knowing what services are running on specific ports enables a hacker to formulate and launch application-specific attacks. One way to ensure success at this pre-attack stage is to know the common default ports and services and to use tools such as Telnet and Netcat.

Default Ports and Services

A certain amount of default information and behavior can be gleaned from any system. For example, if a hacker discovers a Windows 2012 server with port 80 open, he can assume that the system is running IIS 8.0, just as a Linux system with port 25 open is likely to be running Sendmail. Although it’s possible that the Windows 2012 machine might be running another version or type of web server, that most likely is not a common occurrence.

Keep in mind that at this point, the attacker is making assumptions. Just because a particular port is active or a known banner is returned, you cannot be certain that information is correct. Ports and banners can be changed, and assumptions by themselves can be dangerous. Additional work will need to be done to verify what services are truly being served up by any open ports.

Finding Open Services


The scanning performed earlier in the chapter might have uncovered other ports that were open. Most scanning programs, such as Nmap and SuperScan, report what common services are associated with those open ports. This easiest way to determine what services are associated with the open ports that were discovered is by banner grabbing.

Banner grabbing takes nothing more than the Telnet and FTP client built in to the Windows and Linux platforms. Banner grabbing provides important information about what type and version of software is running. Many servers can be exploited with just a few simple steps if the web server is not properly patched. Telnet is an easy way to do this banner grabbing for FTP, SMTP, HTTP, and others. The command issued to banner grab with the Linux curl command would contain the following syntax: curl IP_Address port as demonstrated in Example 3-12. This banner-grabbing attempt was targeted against a web server.

Example 3-12 Banner Grabbing with curl

> curl -I
HTTP/1.1 200 OK
Server: nginx/1.17.2
Date: 14 Feb 2022 01:10:04 GMT
Content-Type: text/html
Content-Length: 8381
Last-Modified: Mon, 10 May 2021 07:24:47 GMT
Connection: keep-alive
ETag: "5eb8fdbf-20bd"
Accept-Ranges: bytes

After the curl -I command was entered,, the output (aka “banner”) indicates that the web server is running nginx version 1.17.2.

You can use many other tools to perform banner grabbing. For instance, you can even use the telnet command, as shown in Example 3-13.

Example 3-13 Banner Grabbing with Telnet

> telnet 80
Connected to
Escape character is '^]'.
HTTP/1.1 400 Bad Request
Server: nginx/1.17.2
Content-Type: text/html
Content-Length: 157
Connection: close
<head><title>400 Bad Request</title></head>
<center><h1>400 Bad Request</h1></center>
Connection closed by foreign host.

In Example 3-13, the telnet command is followed by the IP address of the target host and the port (port 80 in this example). After you press Enter, you can type GET to send an HTTP GET request to the server.

These tools are not your only option for grabbing banners; HTTPrint is another choice. It is available for both Windows and Linux distributions. It is not a typical banner-grabbing application, however, in that it can probe services to determine the version of services running. Its main fingerprinting technique has to do with the semantic differences in how web servers or applications respond to various types of probes. Example 3-14 provides an example of a scan.

Example 3-14 Banner Grabbing with HTTPrint

./httprint -h -s signatures.txt
httprint - web server fingerprinting tool
Finger Printing on
Finger Printing Completed on
Derived Signature:
Apache/2.2.0 (RedHat)
Banner Reported: Apache/2.2.0 (RedHat)
Banner Deduced: Apache/2.0.x
Score: 140
Confidence: 84.31------------------------

Netcat can also be used for banner grabbing. Netcat is shown here to introduce you to its versatility. It is called the “Swiss-army knife of hacking tools” because of its many uses. To banner grab with Netcat, you issue the following command from the command line:

nc -v -n IP_Address Port

This command gives you the banner of the port you asked to check. Netcat is available for Windows and Linux. If you haven’t downloaded Netcat, don’t feel totally left behind; FTP is another choice for banner grabbing. Just FTP to the target server and review the returned banner.

Another good tool is whatweb. It can enumerate additional information in the target system, as demonstrated in Example 3-15.

Example 3-15 whatweb Enumeration

> whatweb [200 OK] Country[RESERVED][ZZ],
HTML5, HTTPServer[nginx/1.17.2], IP[], JQuery,
MetaGenerator[Mobirise v4.10.1, mobirise.com], Script, Title[WebSploit
Mayhem], X-UA-Compatible[IE=edge], nginx[1.17.2]

Most all port scanners, including those discussed in this chapter, also perform banner grabbing. However, the security professional can use lots of tools to analyze open ports and banners. Some of the more notable ones you may want to review include the following:

Although changing banner information is not an adequate defense by itself, it might help to slow a hacker. In a Linux environment, you can change the ServerSignature line in the httpd.conf file to ServerSignature off. In a Windows environment, you can install the UrlScan security tool. UrlScan contains the RemoveServerHeader feature, which removes or alters the identity of the server from the “Server” response header in response to the client’s request.

Draw Network Diagrams

Once you discover and enumerate the hosts in the targeted network, you should immediately start building your own network diagrams. Doing so allows you to create an “attack plan” to not only potentially exploit any vulnerabilities found but also perform post-exploitation activities such as lateral movement and pivoting. These network diagrams should not be static.

The more devices, hosts, and applications you discover (even after exploitation), the more you should document the findings, including IP addresses, the operating systems running in the hosts, the services and ports open, and any discovered software versions. Figure 3-12 shows a simple network diagram.


Figure 3-12 A Network Diagram of Discovered Devices and Applications

Mapping the network provides the hacker with a blueprint of the organization. There are manual and automated ways to compile this information. Manual and automated tools are discussed in the following paragraphs.

If you have been documenting findings, the matrix you began at the start of this chapter should be overflowing with information. This matrix should now contain domain name information, IP addresses, DNS servers, employee info, company location, phone numbers, yearly earnings, recently acquired organizations, email addresses, the publicly available IP address range, open ports, wireless access points, modem lines, and banner details.

If you prefer a more automated method of mapping the network, multiple tools are available. Visual traceroute programs, such as the SolarWinds Network Topology Mapper (http://www.solarwinds.com/network-topology-mapper), can help you map out the placement of these servers. You can even use Nmap scripts to trace a route and map the geolocation of a target. As an example, nmap --traceroute --script traceroute-geolocation.nse -p 80 example.com would perform a traceroute and provide geolocation data for each hop along the way. Geolocation allows you to identify information such as country, region, ISP, and the like. Examples of geolocation tools include IP Location Finder (https://tools.keycdn.com) and Maxmind (https://www.maxmind.com/en/geoip-demo).

Automatic mapping can be faster but might generate errors or sometimes provide erroneous results. Table 3-8 reviews some of the primary steps we have discussed.

Table 3-8 The Seven Steps of the Pre-Attack Phase




Common Tools


Information gathering


www.domaintools.com, ARIN, IANA, Whois, Nslookup


Determining network range




Identifying active machines


Ping, traceroute, SuperScan, Angry IP Scanner


Finding open ports and access points


Nmap, Hping, Angry IP Scanner, SuperScan


OS fingerprinting


Nmap, P0f, Xprobe2


Fingerprinting services


Nmap, Telnet, FTP, Netcat


Mapping the network attack surface


CartoReso, traceroute, Network Topology Mapper

NLog is one option to help keep track of your scanning and mapping information. NLog enables you to automate and track the results of your Nmap scans. It allows you to keep all your Nmap scan logs in a database, making it possible to easily search for specific entries. It’s browser based, so you can easily view the scan logs in a highly customizable format. You can add your own extension scripts for different services, so all hosts running a certain service will have a hyperlink to the extension script. NLog is available at http://nlog-project.org/.

CartoReso is another network mapping option. If run from the Internet, the tool will be limited to devices that it can contact. These will most likely be devices within the demilitarized zone (DMZ). Run internally, it will diagram a large portion of the network. In the hands of a hacker, it’s a powerful tool because it uses routines taken from a variety of other tools that permit it to perform OS detection port scans for service detection and network mapping using common traceroute techniques. You can download it from https://sourceforge.net/projects/cartoreso/.

A final item worth discussing is that the attacker will typically attempt to hide her activity while actively probing a victim’s network. This can be attempted via anonymizers and proxies. The concept is to try to obscure the true source address. Examples of tools that are available for this activity include the following:

  • Proxy Switcher

  • Proxy Workbench

  • CyberGhost

  • Tor

  • + Share This
  • 🔖 Save To Your Account

Pearson IT Certification Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Pearson IT Certification and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Pearson IT Certification products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.pearsonitcertification.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020