---
title: Performing port scans
course: intro_pentest
section: Scanning
layout: lesson
---

Now that you’ve a list of targets, we can continue our examination by scanning
the ports on each of the IP addresses we found. Recall that the goal of port
scanning is to identify which ports are open and determine what services are
available on our target system. A service is a specific job or task that the
computer performs like e-mail, FTP, printing or providing webpages. Port
scanning is like knocking on the various doors and windows of a house and seeing
who answers. For example, if we find that port 80 is open, we can attempt a
connection to the port and oftentimes get specific information about the
webserver that is listening on that port.

There are a total of 65536 (0-65535) ports on every computer. Ports can be
either TCP or UDP depending on the service utilizing the port or nature of the
communication occurring on the port. We scan computers to see what ports are in
use or open. This gives us a better picture of the purpose of the machine,
which, in turn, gives us a better idea about how to attack the box.

If you had to choose only one tool to conduct port scanning, you’d undoubtedly
choose Nmap. Nmap was written by Gordon “Fyodor” Lyon and is available for free
and is built into many of today’s Linux distributions including BlackArch.
Although it’s possible to run Nmap from a graphical user interface (GUI), we’re
going to focus on using the terminal to run our port scans. People who are new
to security and hacking often ask why they should learn to use the command line
or terminal version of a tool rather than relying on a GUI. These same people
complain that using the terminal is not at easy. The response is very simple.
First, using the command-line version of a tool will allow you to learn the
parameters and options that change the behaviour of your tool. This gives you
more flexibility, more granular control and a better understanding of the tool
you’re running. Second (and maybe more importantly), rarely does hacking work
like it’s portrayed in the movies. Finally, the command line can be scripted.
Scripting and automation become key when you want to advance your skillset to
the next level.

Remember the movie swordfish where Hugh Jackman is creating a virus? He’s
dancing and drinking wine, and apparently building a virus in a very graphical,
GUI-driven way. The point is that this is just not realistic. Most people who
are new to hacking assume that hacking is a very GUI-oriented task: that once
you take over a machine you’re presented with a desktop and control of the mouse
and screen. Although it scenario is possible, it’s rarely the case. In most
jobs, your main goal will be to get an administrative shell or backdoor access
to the machine. This shell is literally a terminal that allows you to control
the target PC from the command-line. It looks and feels just like the terminals
we’ve been working with, except a remote shell allows you to enter the commands
on your computer terminal and have them executed on the target machine. So
learning the command line version of your tools is critical because once you’ve
control of a machine you’ll need to upload your tools and interact with the
target through a command prompt, not through a GUI.

Let us assume you still refuse to learn the command line. Let us also assume
that with the several tools you were able to gain access to a target system.
When you gain access to that system, you won’t be presented with a GUI but
rather with a command prompt. If you don’t know how to copy files, add users,
modify documents and make other changes through the command line, your work of
owning the target will have been in vain. You’ll be stuck, like Moses who was
able to see the promised land but not allowed to enter.

When we conduct a port scan, our tool will literally create a packet and send it
to each designated port on the machine. The goal is to determine what kind of a
response we get from the target port. Different types of port scans can produce
different results. It’s important to understand the type of scan you’re running
as well as the expected output of that scan.

## TCP Scan

The first scan we’ll look at is called the TCP Connect Scan. This scan is
considered the most basic and stable of all the port scans because Nmap attempts
to complete the three-way handshake on each port specified in the Nmap command.
Because this scan actually completes the three-way handshake and then tears down
the connection gracefully, there’s a little chance that you’ll flood the target
system and cause it to crash.

If you don’t specify a specific port range. Nmap will scan the 1000 most common
ports. Unless you’re in a great hurry, it’s always recommended specifying all
ports. The reason is that oftentimes crafty administrators will attempt to
obscure a service by running it on a nonstandard port. You can scan all the
ports by specifying "`-p`" when running Nmap. Using the "`-Pn`" switch with
every Nmap scan is recommended. Utilizing the "`-Pn`" switch will cause Nmap to
disable host discovery and force the tool to scan every system as if it were
alive. This is extremely useful for discovering additional systems and ports
that otherwise may be missed.

To run a TCP connect, we issue the following command from a terminal:

```
nmap -sT -p- -Pn 216.58.222.206
```

Take a moment to review this command. The first "`nmap`" cases the Nmap port
scanner to start. The second command "`-sT`" tells Nmap to run a TCP Connect
Scan. Specifically, to break this switch down even further, the "`-s`" is used
to tell Nmap what kind of scan we want to run. The "`-T`" in the "`-sT`" is used
to run a scan type of TCP Connect. We use the "`-p-`" to tell Nmap to scan all
the ports not just the default 1000. We use the "`-PN`" switch to skip the host
discovery phase and scan all the addresses as if the system were alive and
responding to ping requests. Finally, we specify the target IP address;
obviously, your target’s IP address will be different from the one shown in the
previous example!.

Oftentimes, we need to run our scans against an entire subnet, or range of IP
addresses. When this is the case, we can instruct Nmap to scan a continuous
range of IPs by simply appending the last octet of the ending IP address onto
the scan like so:

```
nmap -sT -p- -PN 192.168.1.1-254
```

Issuing this command will cause Nmap to port scan all the hosts between the IP
addresses 192.168.1.1 and 192.168.1.254. Just like ping sweeps, this is a very
powerful technique that can greatly improve the productivity of your scanning
life!

If you need to scan a series of hosts that ain’t in sequential order, you can
create a text file and list each host IP address on a single line. The add the
"`-iL path_to_the_text_file`" switch to your Nmap command. Doing this allows you
to scan all of your target hosts from a single command. Whenever possible,
always try to create a single text file containing all of your target IPs. Most
of the tools we discuss have a switch or mechanism for loading this text file,
which saves the effort of retyping, but more importantly, reduces the number of
times you’ll type each IP address and therefore reduces the change that you’ll
fat-finger the IP address and scan the wrong target.

## SYN Scan

The SYN Scan is arguably the most popular Nmap port scan. There are many reasons
for its popularity, including that it happens to be the default Nmap scan. If
  you run the Nmap command without specifying a scan type (using the "`-s`"
  switch), Nmap will use the SYN scan by default.

Aside from the fact that the SYN scan is the default choice, it’s also popular
because it’s faster than the TCP connect and yet remains quite safe, with little
chance of DOS’ing or crashing the target system. SYN scans are faster because
rather than completing the entire three-way handshake, it only completes the
first two steps.

In a SYN scan, the scanning machine sends a SYN packet to the target and the
target responds with a SYN/ACK (assuming the ports is in use and not filtered)
just like it did when we ran a TCP Connect Scan. However, at this point, rather
than sending the traditional ACK packet, the scanning machine sends an RST
(reset) packet to the target. The reset packet tells the target machine to
disregard any previous packets and close the connection between the two
machines. It should be clear that the speed advantage of the SYN scan over the
TCP Connect Scan comes from the fact that there are fewer packets sent between
the hosts when using a SYN Scan rather than a TCP Connect Scan. Although a few
packets may not sound like a bid advantage, it can add up quickly when scanning
multiple hosts.

If we consider the example of comparing the three-way handshake to a phone call,
SYN scans would be like calling someone up, having the receiver pick up the
phone and saying “Hello?”, and then simply hanging up on the person without a
single word.

Another advantage to the SYN scan is that in some instances, it provides a level
of obscurity or stealth. Because of this feature, the SYN scan is often referred
as the “Stealth Scan”. The stealth portion of this scan comes from the fact that
because the three-way handshake is never fully completed, the official
connection was never 100 per cent established. There are applications and log
files that require the connection of the three-way handshake before they begin
recording activity. As a result, if a log file only records completed
connections and the SYN Scan never officially completes a single connection,
this scan may be undetected by some applications. Please note, this is the
exception and not the rule. All modern firewalls and intrusion detection systems
in use today will detect and report a SYN scan!.

Because the SYN scan is the default Nmap Scan, we don’t technically need to
specify the scan type with the "`-s`" switch. However, because this course
focuses on the basics, it’s worth the effort to get into the habit of specifying
your scan type.

To run a SYN Scan, you can open a terminal window and run the following command:

```
nmap -sS -p- -PN 192.168.1.7
```

This command is exactly the same as the previous example with one exception
(rather than using an "`-sT`" we used an "`-sS`"). This instructs Nmap to run a
SYN scan rather than a TCP Connect Scan. The Scan types are easy to remember
because a TCP Connect Scan begins with the letter “T”, whereas the SYN Scan
begins with the letter “S”. Each of the other switches was explained in the
previous lesson. Please review the “Using Nmap to Complete a TCP Connect Scan”
for a detailed breakdown of the switches in this command.

Take a moment to compare the total run time between the two scans (TCP and SYN).
Even against a single host, the SYN scan completed its execution faster.

## UDP Scan

One of the most common port scanning mistakes of new penetration testers is that
they overlook UDP. These aspiring hackers oftentimes fire up Nmap, run a single
scan (usually a SYN scan), and move onto vulnerability scanning. Don’t neglect
to scan UDP ports! Failing to scan your target for open UDP ports is like
reading the Cliff Notes version of a book. You’ll probably have a solid
understanding of the story, but you’re likely to miss many of the details.

It’s important to understand that both TCP Connect Scans and SYN scans use TCP
as the basis for their communication. TCP is an acronym for Transmission Control
Protocol. UDP is an acronym for User Data gram Protocol. Computers can
communicate with each other using either TCP or UDP; however, there are several
key differences between the two protocols.

TCP is considered a “Connection oriented protocol” because it requires that the
communication between both of the sender and the receiver stays in sync. This
process ensures that the packets sent from one computer to another arrive at the
receiver intact and in the order they were sent. On the other hand, UDP is said
to be “connectionless” because the sender simply sends packets to the receiver
with no mechanism for ensuring that the packets arrive at the destination. There
are many advantages and disadvantages to each of the protocols including speed,
reliability and error checking. To truly master port scanning, you’ll need to
have solid understanding of these protocols. Take some time and learn about each
of them.

Recall the earlier the three-way handshake process was described by comparing
the process to a phone call. The three-way handshake is a key component of TCP
communication that allows the sender and the receiver to stay in sync. Because
UDP is connectionless, this type of communication is most often compared to
dropping a letter in a mailbox. In most cases, the sender simply writes an
address on an envelope, puts a stamp on the letter, and puts the letter in the
mailbox. Eventually, the mailman comes along and picks up the letter where it’s
entered into the mail routing system. In this example, there is no return
receipt or delivery information for the sender. Once the mailman takes the
letter, the sender has no guarantee that the letter will get to its final
destination.

Now that you’ve a very simple understanding between the difference between TCP
and UDP, it’s important to remember that not every service utilizes TCP. Several
prominent services make use of UDP including DHCP, DNS (for individual lookups),
SNMP and TFTP. One of the most important traits for a pentester to have is
thoroughness. It’ll be quite embarrassing to you if you overlook or miss a
service because you forgot to run a UDP Scan against your target.

Both the TCP Connect Scan and the SYN Scan use TCP as the basis for their
scanning techniques. If we want to discover services utilizing UDP, we need to
instruct Nmap to create scans using UDP packets. Fortunately, Nmap makes this
process very simple. To run a UDP scan against our target, we’d enter the
following command in a terminal:

```
nmap -sU 192.168.1.7
```

Notice the difference between this command and the others we’ve learned. First,
we specify the Nmap UDP scan by using the "`-sU`" command. Astute readers will
also notice that the "`-p-`" and the "`-pN`" switches have been dropped from the
scan. The reason for this is simple. UDP scans are very slow; running even a
basic UDP scan on the default 1000 ports can take 20-30 minutes.

It’s important to remember that UDP communication doesn’t require a response
from the receiver. If the target machine doesn’t send back a reply saying a
packet was received, how can Nmap differentiate between an opened port and a
filtered (firewalled) port? In other words, it a service is available and
accepting UDP packets, the normal behavior for this service is to simply accept
the packet but not send a message back to the receiver saying “GOT IT!”.
Likewise, a common firewall strategy is to simply absorb the packet and not send
a response back to the sender. In this example, although one packet went through
and one packet was blocked, because no packets were returned to the sender,
there’s no way of knowing if the packet was accepted by a service or dropped by
the firewall.

This conundrum makes it very difficult for Nmap to determine if a UDP port is
open or filtered. As a result, when Nmap doesn’t receive a response from a UDP
scan, it returns the following message for the port "`open | filtered`". It’s
important to note that on rare occasions a UDP service will send a response back
to the original source. In these cases, Nmap is smart enough to understand that
there is clearly a service listening and responding to requests and will mark
those ports as “open”.

As was discussed earlier, oftentimes people who are new to port scanning
overlook UDP scans. This is probably due in part to the fact that most ordinary
UDP port scans provide very little information and mark nearly every port as "`open | filtered`"
After seeing the same output on several different hosts, it’s easy to become
disillusioned with UDP scans. However, all ain’t lost! The fine folks who wrote
Nmap provide us with a way to draw more accurate results from our UDP Scans.

To elicit a more useful response from our target, we can add the "`-sV`" switch
to our UDP Scan. The "`-sV`" switch is used for version scanning, but, in this
case, can also help us narrow the results of our UDP Scan.

When version scanning is enabled, Nmap sends additional probes to every "`open |
filtered`" port that is reported by the scan. These additional probes attempt to
identify services by sending specifically crafted packets. These specially
crafted packets are often much more successful in provoking a response from the
target. Oftentimes, this will change the reported results from "`open | filtered`" to "`open`".

As mentioned above, the simplest way to add version scanning to an UDP probe is
to include the "`-sV`" switch. Please note that because we’re already using the
"`-sU`" switch to specify the type of scan, we can simply append the capital "`V`"
onto back of the "`-sU`". As a result, our new command becomes:

```
nmap -sUV 192.168.1.7
```

## X-Mas scan

In the computer world, an RFC is a document that contains either notes or the
technical specifications covering a given technology or standard. RFCs can
provide us with a tremendous amount of detail about the inner workings of a
particular system. Because RFCs describe the technical details of how a system
should work, attackers and hackers will often review RFCs looking for potential
weaknesses or loopholes described in the documentation. Xmas Tree Scans and Null
Scan exploit just such a loophole.

Xmas Tree Scans get their name from the fact that the FIN, PSH and URG packet
flags are set to "`on`"; as a result, the packet has so many flags turned on and
the packet is often described as being “lit up like a Christmas tree”. Given
what we already know about TCP communications and the three-way handshake, it
should be clear that an Xmas Tree packet is highly unusual because neither the
SYN nor ACK flags are set. However, this unusual packet has a purpose. If the
system we’re scanning has followed the TCP RFC implementation, we can send one
of these unusual packets to determine the current state of the port.

The TCP RFC says if a closed port receives a packet that doesn’t have a SYN, ACK
or RST flag set (i.e., the type of packet that is created from an Xmas Tree
Scan), the port should respond with an RST packet of its own. Furthermore, the
RFC states that if the port is open and it receives a packet without a SYN, ACK
or RST flag set the packet should be ignored. Take a moment to reread the last
two sentences, as they’re critical to understanding the response we get from
these scans.

Assuming the operating system of the target fully complies with the TCP RFC,
Nmap is able to determine the port state without completing or even initializing
a connection to the target system. The word “assuming” was used because not
every operating system on the market today is fully RFC compliant. In general,
the Xmas Tree and Null scans work against Unix and Linux machines but not
Windows. As a result, Xmas Tree and Null scans are rather ineffective against
Microsoft targets.

To execute an Xmas Tree scan, we simply replace the "`-sU`" switch from our last
example with an "`-sX`". To run the full scan in the terminal, we'd issue:

```
nmap -sX -p- -PN 192.168.1.7
```

## Null Scan

Null scans, like Xmas Tree scans, are probes made with packets that violate
traditional TCP communication. In many ways, the Null scan is the exact opposite
of an Xmas Tree scan because the Null scan utilizes packets that are devoid of
any flags (completely empty).

Target systems will respond to Null scans in the exact same way they respond to
Xmas Tree Scans. Specifically, an open port on the target system will send no
response back to Nmap, whereas a closed port will respond with an RST packet.
It’s important to remember that these scans are only reliable for operating
systems that comply 100 per cent with the TCP RFC.

One of the main advantages of running Xmas Tree and Null scans is that in some
cases, you’re able to bypass simple filters and Access Control Lists (ACLs).
Some of these primitive filters work by blocking inbound SYN packets. The
thought with this type of filter is that by preventing the SYN packet from
entering the system, it ain’t possible for the three-way handshake to occur. If
the three-way handshake doesn’t occur, there can be no TCP communication streams
between the systems, or more precisely, no TCP communications can be originated
from outside the filter.

It’s important to understand that neither the Xmas Tree nor the Null scans seek
to establish any type of communication channel. The whole goal of these scans is
to determine if a port is open or closed.

With the previous two paragraphs in mind, consider the following example. Assume
that our Network Admin Ben Owned puts a simple firewall in from of his system to
prevent anyone outside his network from connecting to the system. The firewall
works by simply dropping any external communications that begin with a SYN
packet. Ben hires his buddy, the ethical hacker, to scan his system. The ethical
hacker’s initial TCP Connect Scans show nothing. However, being a seasoned
penetration tester, the ethical hacking follows up his initial scan with UDP,
Xmas Tree and Null scans. The ethical hacker smiles when he discovers that both
his Xmas Tree Scans and Null Scans reveal open ports on Ben’s system.

This scenario is possible because Nmap creates packets without the SYN flag set.
Because the filter is only dropping incoming packets with the SYN flag, the Xmas
Tree and Null packets are allowed through. To run a Null Scan, we issue the
following command in a terminal:

```
nmap -sN -p- -PN 192.168.1.7
```

## Wrapping up the port scan

Now that we’ve covered the basics of port scanning, there are a few additional
switches that need to be covered. These switches that need to be covered. These
switches provide additional functionality that may be useful to you as you
progress in your penetration testing career.

As mentioned earlier, the "`-sV`" switch is used for version scanning. When
conducting version scanning, Nmap send probes to the open port in an attempt to
determine specific information about the service that is listening. When
possible, Nmap will provide details about the service including version numbers
and other banner information. This information should be recorded in your notes.
It’s recommended that you use the "`-sV`" switch whenever possible, especially
on unusual or unexpected ports, because a wily administrator may have moved his
web server to port 34623 in an attempt to obscure the service.

Nmap includes an option to change the speed of your port scan. This is done with
the "`-T`" switch. The timing switch ranges on a numeric scale from 0 to 5, with
0 being the slowest scan and 5 being the fastest. Timing options are useful if
you’re attempting to avoid detection by sending your scan more slowly; or if
you’ve many IPs to scan and you’ve a limited time to complete the scan where
faster scans would be more appropriate. Please be aware that by using the
fastest scans possible, Nmap may provide less accurate results.

Lastly, the "`-O`" switch can be useful for fingerprinting the operating system.
This handy for determining if the target you’ve attacking is a Windows, Linux or
any other type of machine. Knowing the operating system of your target will save
you time by allowing you to focus your attacks to known weaknesses of that
system. There’s no use in exploring for a Linux machine if your target is
running Windows.

Once we’ve completed port scanning on our target, we should have a list of open
ports and services. This information should be documented and reviewed closely.
While reviewing the Nmap output, you should take a few moments to attempt to log
into any remote access services that were discovered in your port scan. The next
chapter will address running a brute force tool to attempt log in. For the time
being, you can attempt to log in using default usernames and passwords. You
could also try logging in using any information, username or e-mail addresses
you found during reconnaissance. It’s possible to complete a penetration test by
simply discovering an open remote connection and logging into the box with a
default username and password. Telnet and SSH are great remote services that you
should try to connect to. You can do this from the command line by typing:

```
telnet target_ip
ssh root@target_ip
```

In this example, the “target_ip” is the IP address of your victim. Most likely
these will fail, but on the rare occasion when you’re successful, these are an
absolute home run.
