Network Enumeration with Nmap
Host Discovery
When you need to conduct an internal pentest for the entire network of a company, then you should, first of all, get an overview of which systems are online that you can work with. To actively discover such systems on the network, you can use various nmap host discovery options. There are many options nmap provides to determine whether your target is alive or not. The most effective host discovery method is to use ICMP echo requests.
It is always recommended to store every single scan. This can later be used for comparison, documentation, and reporting. After all, different tools may produce different results. Therefore it can be beneficial to distinguish which tool procudes which result.
Scan Network Range
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -sn -oA tnet | grep for | cut -d" " -f5
10.129.2.4
10.129.2.10
10.129.2.11
10.129.2.18
10.129.2.19
10.129.2.20
10.129.2.28
# 10.129.2.0/24: target network range
# -sn: disables port scanning
# -oA tnet: stores the results in all formats starting with the name 'tnet'
This scanning method works only if the firewall of the hosts allow it. Otherwise, you can use other scanning techniques to find out if the hosts are active or not.
Scan IP List
During an internal pentest, it is not uncommon for you to be provided with an IP list with the host you need to test. Nmap also gives you the option of working with lists and reading the hosts from this list instead of manually defining or typing them in.
Such a list could look something like this:
d41y@htb[/htb]$ cat hosts.lst
10.129.2.4
10.129.2.10
10.129.2.11
10.129.2.18
10.129.2.19
10.129.2.20
10.129.2.28
If you use the same scanning technique on the predefined list, the command will look like this:
d41y@htb[/htb]$ sudo nmap -sn -oA tnet -iL hosts.lst | grep for | cut -d" " -f5
10.129.2.18
10.129.2.19
10.129.2.20
# -iL: performs defined scans against targets in provided 'hosts.txt' list
In this example, you see that only 3 of 7 hosts are active. This may mean that the other hosts ignore the default ICMP echo requests because of their firewall configuration. Since nmap does not receive a response, it marks those hosts as inactive.
Scan Multiple IPs
It can also happen that you only need to scan a small part of a network. An alternative to the method you used last time is to specify mulitple IP addresses.
d41y@htb[/htb]$ sudo nmap -sn -oA tnet 10.129.2.18 10.129.2.19 10.129.2.20| grep for | cut -d" " -f5
10.129.2.18
10.129.2.19
10.129.2.20
If these IP addresses are next to each other, you can also define the range in the respective octet.
d41y@htb[/htb]$ sudo nmap -sn -oA tnet 10.129.2.18-20| grep for | cut -d" " -f5
10.129.2.18
10.129.2.19
10.129.2.20
Scan Single IP
Before you scan a single host for open ports and its services, you first have to determine if it is alive or not.
d41y@htb[/htb]$ sudo nmap 10.129.2.18 -sn -oA host
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-14 23:59 CEST
Nmap scan report for 10.129.2.18
Host is up (0.087s latency).
MAC Address: DE:AD:00:00:BE:EF
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
If you disable port scan, nmap automatically ping scans with ICMP echo requests. Once such a request is sent, you usually expect an ICMP reply if the pinged host is alive. The more interesting fact is that your previous scans did not do that because before nmap could send an ICMP echo request, it would send an ARP ping resulting in an ARP reply. You can confirm this with the --packet-trace option. To ensure that ICMP echo requests are sent, you also define the option -PE for this.
d41y@htb[/htb]$ sudo nmap 10.129.2.18 -sn -oA host -PE --packet-trace
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 00:08 CEST
SENT (0.0074s) ARP who-has 10.129.2.18 tell 10.10.14.2
RCVD (0.0309s) ARP reply 10.129.2.18 is-at DE:AD:00:00:BE:EF
Nmap scan report for 10.129.2.18
Host is up (0.023s latency).
MAC Address: DE:AD:00:00:BE:EF
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
# --packet-trace: shows all packets sent and received
Another way to determine why nmap has your target marked as “alive” is with the --reason option.
d41y@htb[/htb]$ sudo nmap 10.129.2.18 -sn -oA host -PE --reason
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 00:10 CEST
SENT (0.0074s) ARP who-has 10.129.2.18 tell 10.10.14.2
RCVD (0.0309s) ARP reply 10.129.2.18 is-at DE:AD:00:00:BE:EF
Nmap scan report for 10.129.2.18
Host is up, received arp-response (0.028s latency).
MAC Address: DE:AD:00:00:BE:EF
Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds
# --reason: displays the reason for specific result
You can see here that nmap does indeed detect whether the host is alive or not through the ARP request and ARP reply alone. To disable ARP requests and scan you target with the desired ICMP echo request, you can disable ARP pings by setting the --disable-arp-ping option. Then you can scan your target again and look at the packets sent and received.
d41y@htb[/htb]$ sudo nmap 10.129.2.18 -sn -oA host -PE --packet-trace --disable-arp-ping
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 00:12 CEST
SENT (0.0107s) ICMP [10.10.14.2 > 10.129.2.18 Echo request (type=8/code=0) id=13607 seq=0] IP [ttl=255 id=23541 iplen=28 ]
RCVD (0.0152s) ICMP [10.129.2.18 > 10.10.14.2 Echo reply (type=0/code=0) id=13607 seq=0] IP [ttl=128 id=40622 iplen=28 ]
Nmap scan report for 10.129.2.18
Host is up (0.086s latency).
MAC Address: DE:AD:00:00:BE:EF
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
Host and Port Scannnig
There are a total of 6 different states for a scanned port you can obtain:
| State | Description |
|---|---|
open | indicates that the connection to the scanned port has been established; these connections can be TCP connections, UDP datagrams, as well as SCTP associations |
closed | when the port is shown as closed, TCP protocol indicates that the packet you received back contains an RST flag; this scanning method can also be used to determine if your target is alive or not |
filtered | nmap cannot correctly identify whether the scanned port is open or closed because either no response is returned from the target for the port or you get an error code from the target |
unfiltered | this state of port only occurs during the TCP-ACK scan and means that the port is accessible, but it cannot be determined whether it is open or closed |
open|filtered | if you do not get a response for a specific port, nmap will set it to that state; this indicates that a firewall or packet filter may protect the port |
closed|filtered | this state only occurs in the IP ID idle scans and indicates that it was impossible to determine if the scanned port is closed or filtered by a firewall |
Discovering Open TCP Ports
Scanning Top 10 TCP Ports
d41y@htb[/htb]$ sudo nmap 10.129.2.28 --top-ports=10
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 15:36 CEST
Nmap scan report for 10.129.2.28
Host is up (0.021s latency).
PORT STATE SERVICE
21/tcp closed ftp
22/tcp open ssh
23/tcp closed telnet
25/tcp open smtp
80/tcp open http
110/tcp open pop3
139/tcp filtered netbios-ssn
443/tcp closed https
445/tcp filtered microsoft-ds
3389/tcp closed ms-wbt-server
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 1.44 seconds
# --top-ports=10: scans the specified top ports that have been defined as most frequent
You see that you only scanned the top 10 TCP ports of your target, and nmap displays their state accordingly. If you trace the packets nmap sends, you will see the RST flag on TCP port 21 that your target sends back to you.
Nmap - Trace the Packets
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 21 --packet-trace -Pn -n --disable-arp-ping
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 15:39 CEST
SENT (0.0429s) TCP 10.10.14.2:63090 > 10.129.2.28:21 S ttl=56 id=57322 iplen=44 seq=1699105818 win=1024 <mss 1460>
RCVD (0.0573s) TCP 10.129.2.28:21 > 10.10.14.2:63090 RA ttl=64 id=0 iplen=40 seq=0 win=0
Nmap scan report for 10.11.1.28
Host is up (0.014s latency).
PORT STATE SERVICE
21/tcp closed ftp
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
# --packet-trace: shows all packets sent and received
# --disable-arp-ping: disables arp ping
# -n: disables DNS resolution
You can see from the SENT line that you sent a TCP packet with the SYN flag to your target. In the next RCVD line, you can see that the target responds with a TCP packet containing the RST and ACK flags. RST and ACK flags are used to acknowledge receipt of the TCP packet and to end the TCP session.
Connect Scan
… uses the TCP three-way handshake to determine if a specific port on a target host is open or closed. The scan sends a SYN packet to the target port and waits for a response. It is considered open if the target port responds with a SYN-ACK packet and closed if it responds with a RST packet.
The Connect scan is highly accurate because it completes the three-way handshake, allowing you to determine the exact state of a port. However, it is not the most stealthy. In fact, the Connect scan is one of the least stealthy techniques, as it fully establishes a connection, which creates logs on most systems and is easily detected by modern IDS/IPS solutions. That said, the Connect scan can still be useful in certain situations, particularly when accuracy is a priority, and the goal is to map the network without causing significant disruption to services. Since the scan fully establishes a TCP connection, it interacts cleanly with services, making it less likely to cause service errors or instability compared to more intrusive scans. While it is not the most stealthy method, it is sometimes considered a more “polite” scan because it behaves like a normal client connection, thus having minimal impact on the target services.
It is also useful when the target host has a firewall that drops incoming packets but allows outgoing packets. In this case, a Connect scan can bypass the firewall and accurately determine the state of the target ports. However, it is important to note that the Connect scan is slower than other types because it requires the scanner to wait for a response from the target after each packet it sends, which could take some time if the target is busy or unresponsive.
Scans like the SYN scan are generally considered more stealthy because they do not complete the full handshake, leaving the connection incomplete after sending the initial SYN packet. This minimizes the chance of triggering connection logs while still gathering port state information. Advanced IDS/IPS systems, however, have adapted to detect even these subtle techniques.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 443 --packet-trace --disable-arp-ping -Pn -n --reason -sT
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 16:26 CET
CONN (0.0385s) TCP localhost > 10.129.2.28:443 => Operation now in progress
CONN (0.0396s) TCP localhost > 10.129.2.28:443 => Connected
Nmap scan report for 10.129.2.28
Host is up, received user-set (0.013s latency).
PORT STATE SERVICE REASON
443/tcp open https syn-ack
Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
# -sT: TCP Connect scan
Filtered Ports
When a port is shown as filtered, it can have several reasons. In most cases, firewalls have certain rules set to handle specific connections. The packets can either be dropped, or rejected. When a packet gets dropped, nmap receives no response from your target, and by default, the retry rate (--max-retries) is set to 10. This means nmap will resend the request to the target port to determine if the previous packet was accidently mishandled or not.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 139 --packet-trace -n --disable-arp-ping -Pn
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 15:45 CEST
SENT (0.0381s) TCP 10.10.14.2:60277 > 10.129.2.28:139 S ttl=47 id=14523 iplen=44 seq=4175236769 win=1024 <mss 1460>
SENT (1.0411s) TCP 10.10.14.2:60278 > 10.129.2.28:139 S ttl=45 id=7372 iplen=44 seq=4175171232 win=1024 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up.
PORT STATE SERVICE
139/tcp filtered netbios-ssn
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 2.06 seconds
# -Pn: disables ICMP echo requests
You see in the last scan that nmap sent two TCP packets with the SYN flag. By the duration of the scan, you can recognize that it took much longer than the previous ones. The case is different if the firewall rejects the packets.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 445 --packet-trace -n --disable-arp-ping -Pn
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 15:55 CEST
SENT (0.0388s) TCP 10.129.2.28:52472 > 10.129.2.28:445 S ttl=49 id=21763 iplen=44 seq=1418633433 win=1024 <mss 1460>
RCVD (0.0487s) ICMP [10.129.2.28 > 10.129.2.28 Port 445 unreachable (type=3/code=3) ] IP [ttl=64 id=20998 iplen=72 ]
Nmap scan report for 10.129.2.28
Host is up (0.0099s latency).
PORT STATE SERVICE
445/tcp filtered microsoft-ds
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
As a response, you receive an ICMP reply with type 3 and error code 3, which indicates that the desired port is unreachable. Nevertheless, if you know that the host is alive, you can strongly assume that the firewall on this port is rejecting the packets, and you will have to take a closer look at this port later.
Discovering Open UDP Ports
Some system admins sometimes forget to filter the UDP ports in addition to the TCP ones. Since UDP is a stateless protocol and does not require a three-way handshake like TCP. You do not receive any acknowledgment. Consequently, the timeout is much longer, making the whole UDP scan (-sU) much slower than the TCP scan (-sS).
UDP Port Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -F -sU
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 16:01 CEST
Nmap scan report for 10.129.2.28
Host is up (0.059s latency).
Not shown: 95 closed ports
PORT STATE SERVICE
68/udp open|filtered dhcpc
137/udp open netbios-ns
138/udp open|filtered netbios-dgm
631/udp open|filtered ipp
5353/udp open zeroconf
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 98.07 seconds
# -F: scans the top 100 ports
Another disadvantage of this is that you often do not get a response back because nmap sends empty datagrams to the scanned UDP ports, and you do not receive any response. So you cannot determine if the UDP packet has arrived at all or not. If the UDP port is open, you only get a response if the application is configured to do so.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -sU -Pn -n --disable-arp-ping --packet-trace -p 137 --reason
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 16:15 CEST
SENT (0.0367s) UDP 10.10.14.2:55478 > 10.129.2.28:137 ttl=57 id=9122 iplen=78
RCVD (0.0398s) UDP 10.129.2.28:137 > 10.10.14.2:55478 ttl=64 id=13222 iplen=257
Nmap scan report for 10.129.2.28
Host is up, received user-set (0.0031s latency).
PORT STATE SERVICE REASON
137/udp open netbios-ns udp-response ttl 64
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
If you get an ICMP response with error code 3, you know that the port is closed.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -sU -Pn -n --disable-arp-ping --packet-trace -p 100 --reason
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 16:25 CEST
SENT (0.0445s) UDP 10.10.14.2:63825 > 10.129.2.28:100 ttl=57 id=29925 iplen=28
RCVD (0.1498s) ICMP [10.129.2.28 > 10.10.14.2 Port unreachable (type=3/code=3) ] IP [ttl=64 id=11903 iplen=56 ]
Nmap scan report for 10.129.2.28
Host is up, received user-set (0.11s latency).
PORT STATE SERVICE REASON
100/udp closed unknown port-unreach ttl 64
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
For all other ICMP respones, the scanned ports are marked as open|filtered.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -sU -Pn -n --disable-arp-ping --packet-trace -p 138 --reason
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 16:32 CEST
SENT (0.0380s) UDP 10.10.14.2:52341 > 10.129.2.28:138 ttl=50 id=65159 iplen=28
SENT (1.0392s) UDP 10.10.14.2:52342 > 10.129.2.28:138 ttl=40 id=24444 iplen=28
Nmap scan report for 10.129.2.28
Host is up, received user-set.
PORT STATE SERVICE REASON
138/udp open|filtered netbios-dgm no-response
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 2.06 seconds
Another handy method for scanning ports is the -sV option which is used to get additional available information from the open ports. This method can identify versions, service names, and details about your target.
Version Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -Pn -n --disable-arp-ping --packet-trace -p 445 --reason -sV
Starting Nmap 7.80 ( https://nmap.org ) at 2022-11-04 11:10 GMT
SENT (0.3426s) TCP 10.10.14.2:44641 > 10.129.2.28:445 S ttl=55 id=43401 iplen=44 seq=3589068008 win=1024 <mss 1460>
RCVD (0.3556s) TCP 10.129.2.28:445 > 10.10.14.2:44641 SA ttl=63 id=0 iplen=44 seq=2881527699 win=29200 <mss 1337>
NSOCK INFO [0.4980s] nsock_iod_new2(): nsock_iod_new (IOD #1)
NSOCK INFO [0.4980s] nsock_connect_tcp(): TCP connection requested to 10.129.2.28:445 (IOD #1) EID 8
NSOCK INFO [0.5130s] nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [10.129.2.28:445]
Service scan sending probe NULL to 10.129.2.28:445 (tcp)
NSOCK INFO [0.5130s] nsock_read(): Read request from IOD #1 [10.129.2.28:445] (timeout: 6000ms) EID 18
NSOCK INFO [6.5190s] nsock_trace_handler_callback(): Callback: READ TIMEOUT for EID 18 [10.129.2.28:445]
Service scan sending probe SMBProgNeg to 10.129.2.28:445 (tcp)
NSOCK INFO [6.5190s] nsock_write(): Write request for 168 bytes to IOD #1 EID 27 [10.129.2.28:445]
NSOCK INFO [6.5190s] nsock_read(): Read request from IOD #1 [10.129.2.28:445] (timeout: 5000ms) EID 34
NSOCK INFO [6.5190s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 27 [10.129.2.28:445]
NSOCK INFO [6.5320s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 34 [10.129.2.28:445] (135 bytes)
Service scan match (Probe SMBProgNeg matched with SMBProgNeg line 13836): 10.129.2.28:445 is netbios-ssn. Version: |Samba smbd|3.X - 4.X|workgroup: WORKGROUP|
NSOCK INFO [6.5320s] nsock_iod_delete(): nsock_iod_delete (IOD #1)
Nmap scan report for 10.129.2.28
Host is up, received user-set (0.013s latency).
PORT STATE SERVICE REASON VERSION
445/tcp open netbios-ssn syn-ack ttl 63 Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
Service Info: Host: Ubuntu
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.55 seconds
# -sV: performs a service scan
More on scanning techniques here.
Saving the Results
While you run various scans, you should always save the results. You can use these later to examine the differences between the different scanning methods you have used. Nmap can save the results in 3 different formats:
- normal output (
-oN) with the .nmap file extension - grepable output (
-oG) with the .gnmap file extension - XML output (
-oX) with the .xml file extension
You can also specify the option -oA to save the result in all formats.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p- -oA target
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-16 12:14 CEST
Nmap scan report for 10.129.2.28
Host is up (0.0091s latency).
Not shown: 65525 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 10.22 seconds
If no full path is given, the results will be stored in the dir you are currently in.
Output Examples
Normal Output
d41y@htb[/htb]$ cat target.nmap
# Nmap 7.80 scan initiated Tue Jun 16 12:14:53 2020 as: nmap -p- -oA target 10.129.2.28
Nmap scan report for 10.129.2.28
Host is up (0.053s latency).
Not shown: 4 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
# Nmap done at Tue Jun 16 12:15:03 2020 -- 1 IP address (1 host up) scanned in 10.22 seconds
Grepable Output
d41y@htb[/htb]$ cat target.gnmap
# Nmap 7.80 scan initiated Tue Jun 16 12:14:53 2020 as: nmap -p- -oA target 10.129.2.28
Host: 10.129.2.28 () Status: Up
Host: 10.129.2.28 () Ports: 22/open/tcp//ssh///, 25/open/tcp//smtp///, 80/open/tcp//http/// Ignored State: closed (4)
# Nmap done at Tue Jun 16 12:14:53 2020 -- 1 IP address (1 host up) scanned in 10.22 seconds
XMl Output
d41y@htb[/htb]$ cat target.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE nmaprun>
<?xml-stylesheet href="file:///usr/local/bin/../share/nmap/nmap.xsl" type="text/xsl"?>
<!-- Nmap 7.80 scan initiated Tue Jun 16 12:14:53 2020 as: nmap -p- -oA target 10.129.2.28 -->
<nmaprun scanner="nmap" args="nmap -p- -oA target 10.129.2.28" start="12145301719" startstr="Tue Jun 16 12:15:03 2020" version="7.80" xmloutputversion="1.04">
<scaninfo type="syn" protocol="tcp" numservices="65535" services="1-65535"/>
<verbose level="0"/>
<debugging level="0"/>
<host starttime="12145301719" endtime="12150323493"><status state="up" reason="arp-response" reason_ttl="0"/>
<address addr="10.129.2.28" addrtype="ipv4"/>
<address addr="DE:AD:00:00:BE:EF" addrtype="mac" vendor="Intel Corporate"/>
<hostnames>
</hostnames>
<ports><extraports state="closed" count="4">
<extrareasons reason="resets" count="4"/>
</extraports>
<port protocol="tcp" portid="22"><state state="open" reason="syn-ack" reason_ttl="64"/><service name="ssh" method="table" conf="3"/></port>
<port protocol="tcp" portid="25"><state state="open" reason="syn-ack" reason_ttl="64"/><service name="smtp" method="table" conf="3"/></port>
<port protocol="tcp" portid="80"><state state="open" reason="syn-ack" reason_ttl="64"/><service name="http" method="table" conf="3"/></port>
</ports>
<times srtt="52614" rttvar="75640" to="355174"/>
</host>
<runstats><finished time="12150323493" timestr="Tue Jun 16 12:14:53 2020" elapsed="10.22" summary="Nmap done at Tue Jun 16 12:15:03 2020; 1 IP address (1 host up) scanned in 10.22 seconds" exit="success"/><hosts up="1" down="0" total="1"/>
</runstats>
</nmaprun>
Style Sheets
With the XML output, you can easily create HTML reports that are easy to read, even for non-technical people. This is later very useful for documentation, as it presents your results in a detailed and clear way. To convert the stored results from XML format to HTML, you can use the tool xsltproc.
d41y@htb[/htb]$ xsltproc target.xml -o target.html
More on output formats here.
Service Enumeration
Service Version Detection
It is recommended to perform a quick port scan first, which gives you a small overview of the available ports. This causes significantly less traffic, which is advantageous for you because otherwise you can be discovered and blocked by the security mechanisms. You can deal with these first and run a port scan in the background, which shows all open ports. You can use the version scan to scan the specific ports for services and their versions.
A full port scan takes quite a long time. To view the scan status, you can press [Space Bar] during the scan, which will cause nmap to show you the scan status.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p- -sV
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 19:44 CEST
[Space Bar]
Stats: 0:00:03 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 3.64% done; ETC: 19:45 (0:00:53 remaining)
# -sV: performs service version detection on specified ports
Another option (--stats-every=5s) that you can use is defining how periods of time the status should be shown. You can specify (s)econds or (m)inutes.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p- -sV --stats-every=5s
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 19:46 CEST
Stats: 0:00:05 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 13.91% done; ETC: 19:49 (0:00:31 remaining)
Stats: 0:00:10 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 39.57% done; ETC: 19:48 (0:00:15 remaining)
You can also increse the verbosity level, which will show you the open ports directly when nmap detects them.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p- -sV -v
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 20:03 CEST
NSE: Loaded 45 scripts for scanning.
Initiating ARP Ping Scan at 20:03
Scanning 10.129.2.28 [1 port]
Completed ARP Ping Scan at 20:03, 0.03s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 20:03
Completed Parallel DNS resolution of 1 host. at 20:03, 0.02s elapsed
Initiating SYN Stealth Scan at 20:03
Scanning 10.129.2.28 [65535 ports]
Discovered open port 995/tcp on 10.129.2.28
Discovered open port 80/tcp on 10.129.2.28
Discovered open port 993/tcp on 10.129.2.28
Discovered open port 143/tcp on 10.129.2.28
Discovered open port 25/tcp on 10.129.2.28
Discovered open port 110/tcp on 10.129.2.28
Discovered open port 22/tcp on 10.129.2.28
<SNIP>
# -v: increases the verbosity
Banner Grabbing
Once the scan is complete, you will see all TCP ports with the corresponding service and their versions that are active on the system:
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p- -sV
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-15 20:00 CEST
Nmap scan report for 10.129.2.28
Host is up (0.013s latency).
Not shown: 65525 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
25/tcp open smtp Postfix smtpd
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
110/tcp open pop3 Dovecot pop3d
139/tcp filtered netbios-ssn
143/tcp open imap Dovecot imapd (Ubuntu)
445/tcp filtered microsoft-ds
993/tcp open ssl/imap Dovecot imapd (Ubuntu)
995/tcp open ssl/pop3 Dovecot pop3d
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Service Info: Host: inlane; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 91.73 seconds
Primarily, nmap looks at the banners of the scanned ports and prints them out. If it cannot identify versions through the banners, nmap attempts to identify them through a signature-based matching system, but this significantly increases the scan’s duration. One disadvantage to nmap’s presented results is that the automatic scan can miss some information because sometimes nmap does not know how to handle it.
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p- -sV -Pn -n --disable-arp-ping --packet-trace
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-16 20:10 CEST
<SNIP>
NSOCK INFO [0.4200s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 18 [10.129.2.28:25] (35 bytes): 220 inlane ESMTP Postfix (Ubuntu)..
Service scan match (Probe NULL matched with NULL line 3104): 10.129.2.28:25 is smtp. Version: |Postfix smtpd|||
NSOCK INFO [0.4200s] nsock_iod_delete(): nsock_iod_delete (IOD #1)
Nmap scan report for 10.129.2.28
Host is up (0.076s latency).
PORT STATE SERVICE VERSION
25/tcp open smtp Postfix smtpd
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Service Info: Host: inlane
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds
If you look at the results from nmap, you can see the port’s status, service name, and hostname. Nevertheless, look at this line:
- NSOCK INFO [0.4200s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 18 [10.129.2.28:25] (35 bytes): 220 inlane ESMTP Postfix (Ubuntu)..
Then you see that the SMTP server on your target gave you more information than nmap showed you. Because here, you see that it is the Linux distro Ubuntu. It happens because, after a successful three-way handshake, the server often sends a banner for identification. This serves to let the client know which service it is working with. At the network level, this happens with a PSH flag in the TCP header. However, it can happen that some services do not immediately provide such information. It is also possible to manipulate the banners from the respective services. If you manually connect to the SMTP server using nc, grab the banner, and intercept the network traffic using tcpdump, you can see what nmap did not show you.
Tcpdump
d41y@htb[/htb]$ sudo tcpdump -i eth0 host 10.10.14.2 and 10.129.2.28
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
Nc
d41y@htb[/htb]$ nc -nv 10.129.2.28 25
Connection to 10.129.2.28 port 25 [tcp/*] succeeded!
220 inlane ESMTP Postfix (Ubuntu)
Tcpdump - Intercepted Traffic
18:28:07.128564 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [S], seq 1798872233, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 331260178 ecr 0,sackOK,eol], length 0
18:28:07.255151 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [S.], seq 1130574379, ack 1798872234, win 65160, options [mss 1460,sackOK,TS val 1800383922 ecr 331260178,nop,wscale 7], length 0
18:28:07.255281 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], ack 1, win 2058, options [nop,nop,TS val 331260304 ecr 1800383922], length 0
18:28:07.319306 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [P.], seq 1:36, ack 1, win 510, options [nop,nop,TS val 1800383985 ecr 331260304], length 35: SMTP: 220 inlane ESMTP Postfix (Ubuntu)
18:28:07.319426 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], ack 36, win 2058, options [nop,nop,TS val 331260368 ecr 1800383985], length 0
The first three lines show you the three-way handshake.
After that, the target SMTP server sends you a TCP packet with the PSH and ACK flags, where PSH states that the target server is sending data to you and with ACK simultaneously informs you that all required data has been sent.
The last TCP packet that you sent confirms the receipt of the data with an ACK.
Nmap Scripting Engine (NSE)
… is another handy feature of nmap. It provides you with the possibility to create scripts in Lua for interaction with certain services. There are a total of 14 categories into which these scripts can be divided.
| Category | Description |
|---|---|
| auth | determination of authentication creds |
| broadcast | scripts, which are used for host discovery by broadcasting and the discovered hosts, can be automatically added to the remaining scans |
| brute | executes scripts that try to log in to the respective service by brute-forcing with credentials |
| default | default script executed by the -sC option |
| discovery | evaluation of accessible services |
| dos | used to check services for DoS vulns and are used less as it harms the service |
| exploit | tries to exploit known vulns for the scanned port |
| external | scripts that use external services for further processing |
| fuzzer | identify vulns and unexpected packet handling by sending different fields, which can take much time |
| intrusive | intrusive scripts that could negatively affect the target system |
| malware | checks if some malware infects the target system |
| safe | defensive scripts that do not perform intrusive and destructive access |
| version | extension for service detection |
| vuln | identification of specific vulns |
Script Defining
Default Scripts
d41y@htb[/htb]$ sudo nmap <target> -sC
Specific Scripts Category
d41y@htb[/htb]$ sudo nmap <target> --script <category>
Defined Scripts
d41y@htb[/htb]$ sudo nmap <target> --script <script-name>,<script-name>,...
For example, keep working with the target SMTP port and see the results you get with two defined scripts.
Example - Specifying Scripts
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 25 --script banner,smtp-commands
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-16 23:21 CEST
Nmap scan report for 10.129.2.28
Host is up (0.050s latency).
PORT STATE SERVICE
25/tcp open smtp
|_banner: 220 inlane ESMTP Postfix (Ubuntu)
|_smtp-commands: inlane, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8,
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
You see that you can recognize the Ubuntu distro of Linux by using the “banner” script. The “smtp-commands” script shows you which commands you can use by interacting with the target SMTP server.
Nmap also gives you the ability to scan your target with the aggressive option -A. This scans the target with multiple options as service detection -sV, OS detection -O, traceroute --traceroute, and with the default NSE scripts -sC.
Example - Aggressive Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 80 -A
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-17 01:38 CEST
Nmap scan report for 10.129.2.28
Host is up (0.012s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-generator: WordPress 5.3.4
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: blog.inlanefreight.com
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 2.6.32 (96%), Linux 3.2 - 4.9 (96%), Linux 2.6.32 - 3.10 (96%), Linux 3.4 - 3.10 (95%), Linux 3.1 (95%), Linux 3.2 (95%),
AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Synology DiskStation Manager 5.2-5644 (94%), Netgear RAIDiator 4.2.28 (94%),
Linux 2.6.32 - 2.6.35 (94%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 11.91 ms 10.129.2.28
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.36 seconds
Vuln Assessment
Nmap - Vuln Category
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 80 -sV --script vuln
Nmap scan report for 10.129.2.28
Host is up (0.036s latency).
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-enum:
| /wp-login.php: Possible admin folder
| /readme.html: Wordpress version: 2
| /: WordPress version: 5.3.4
| /wp-includes/images/rss.png: Wordpress version 2.2 found.
| /wp-includes/js/jquery/suggest.js: Wordpress version 2.5 found.
| /wp-includes/images/blank.gif: Wordpress version 2.6 found.
| /wp-includes/js/comment-reply.js: Wordpress version 2.7 found.
| /wp-login.php: Wordpress login page.
| /wp-admin/upgrade.php: Wordpress login page.
|_ /readme.html: Interesting, a readme.
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
| http-wordpress-users:
| Username found: admin
|_Search stopped at ID #25. Increase the upper limit if necessary with 'http-wordpress-users.limit'
| vulners:
| cpe:/a:apache:http_server:2.4.29:
| CVE-2019-0211 7.2 https://vulners.com/cve/CVE-2019-0211
| CVE-2018-1312 6.8 https://vulners.com/cve/CVE-2018-1312
| CVE-2017-15715 6.8 https://vulners.com/cve/CVE-2017-15715
<SNIP>
# --script vuln: uses all related scripts from specified category
The scripts used for the last scan interact with the webserver and its web app to find out more information about their versions and check various databases to see if there are known vulns.
Performance
Scanning performance plays a significant role when you need to scan an extensive network or are dealing with low network bandwith. You can use various options to tell nmap how fast, with which frequency, which timeouts the test packets should have, how many packets should be sent simultaneously, and with the number of retries for the scanned ports the target should be scanned.
Timeouts
When nmap sends a packet, it takes some time (Round-Trip-Time-RTT) to receive a response from the scanned port. Generally, nmap starts with a high timeout (--min-RTT-timeout) of 100ms.
Default Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F
<SNIP>
Nmap done: 256 IP addresses (10 hosts up) scanned in 39.44 seconds
Optimized RTT
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F --initial-rtt-timeout 50ms --max-rtt-timeout 100ms
<SNIP>
Nmap done: 256 IP addresses (8 hosts up) scanned in 12.29 seconds
# --initial-rtt-timeout 50ms: sets the specified time value as initial RTT timeout
# --max-rtt-timeout 100ms: sets the specified time value as maximum RTT timeout
When comparing the two scans, you can see that you found two hosts less with the optimized scan, but the scan took only a quarter of the time. From this, you can conclude that setting the initial RTT timeout to too short a time period may cause you to overlook hosts.
Max Retries
Another way to increase scan speed is by specifying the retry rate of sent packets (--max-retries). The default value is 10, but you can reduce it to 0. This means if nmap does not receive a response for a port, it won’t send any more packets to that port and will skip it.
Default Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F | grep "/tcp" | wc -l
23
Reduced Retries
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F --max-retries 0 | grep "/tcp" | wc -l
21
Again, you recognize that accelerating can also have a negative effect on your results, which means you can overlook important information.
Rates
During a white-box pentest, you may get whitelisted for the security systems to check the systems in the network for vulns and not only test the protection measures. If you know the network bandwith, you can work with the rate of packets sent, which significantly speeds up your scans with nmap. When setting the minimum rate (--min-rate) for sending packets, you tell nmap to simultaneously send the specified number of packets. It will attempt to maintain the rate accordingly.
Default Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F -oN tnet.default
<SNIP>
Nmap done: 256 IP addresses (10 hosts up) scanned in 29.83 seconds
Optimized Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F -oN tnet.minrate300 --min-rate 300
<SNIP>
Nmap done: 256 IP addresses (10 hosts up) scanned in 8.67 seconds
Default Scan - Found Open Ports
d41y@htb[/htb]$ cat tnet.default | grep "/tcp" | wc -l
23
Optimized Scan - Found Open Ports
d41y@htb[/htb]$ cat tnet.minrate300 | grep "/tcp" | wc -l
23
Timing
Because such settings cannot always be optimized manually, as in a black-box pentest, nmap offers six different timing templates for you to use. These values determine the aggressiveness of your scans. This can also have negative effects if the scan is too aggressive, and security systems may block you due to the produced network traffic. The default timing template used when you have defined nothing else is the normal.
-T 0/-T paranoid-T 1/-T sneaky-T 2/-T polite-T 3/-T normal-T 4/-T aggressive-T 5/-T insane
These templates contain options that you can also set manually, and have seen some of them already. The devs determined the values set for these templates according to their best results, making it easier for you to adapt your scans to the corresponding network environment.
Default Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F -oN tnet.default
<SNIP>
Nmap done: 256 IP addresses (10 hosts up) scanned in 32.44 seconds
Insane Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.0/24 -F -oN tnet.T5 -T 5
<SNIP>
Nmap done: 256 IP addresses (10 hosts up) scanned in 18.07 seconds
Default Scan - Found Open Ports
d41y@htb[/htb]$ cat tnet.default | grep "/tcp" | wc -l
23
Insane Scan - Found Open Ports
d41y@htb[/htb]$ cat tnet.T5 | grep "/tcp" | wc -l
23
Firewall and IDS/IPS Evasion
Firewalls
A firewall is a security measure against unauthorized connection attempts from external networks. Every firewall security system is based on a software component that monitors network traffic between the firewall and incoming data connections and decides how to handle the connection based on the rules that have been set. It checks whether individual network packets are being passed, ignored, or blocked. This mechanism is designed to prevent unwanted connections that could be potentially dangerous.
IDS/IPS
Like the firewall, the IDS/IPS are also software-based components. IDS scans the network for potential attacks, and reports any detected attacks. IPS complements IDS by taking defensive measures if a potential attack should have been detected. The analysis of such attacks is based on pattern matching and signatures. If specific patterns are detected, such as a service detection scan, IPS may prevent the pending connection attempts.
Determine Firewalls and their Rules
You already know that when a port is shown as filtered, it can have several reasons. In most cases, firewalls have certain rules set to handle specific connections. The packets can either be dropped, or rejected. The dropped packets are ignored, and no response is returned from the host.
This is different for rejected packets that are returned with an RST flag. These packets contain different types of ICMP error codes or contain nothing at all:
Such errors can be:
- Net Unreachable
- Net Prohibited
- Host Unreachable
- Host Prohibited
- Port Unreachable
- Proto Unreachable
Nmap’s TCP ACK scan method is much harder to filter for firewalls and IDS/IPS system than regular SYN or Connect scans because they only send a TCP packet with only the ACK flag. When a port is closed or open, the host must respond with an RST flag. Unlike outgoing connections, all connection attempts from external networks are usually blocked by firewalls. However, the packets with the ACK flag are often passed by the firewall because the firewall cannot determine whether the connection was first established from the external network or the internal network.
SYN Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 21,22,25 -sS -Pn -n --disable-arp-ping --packet-trace
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 14:56 CEST
SENT (0.0278s) TCP 10.10.14.2:57347 > 10.129.2.28:22 S ttl=53 id=22412 iplen=44 seq=4092255222 win=1024 <mss 1460>
SENT (0.0278s) TCP 10.10.14.2:57347 > 10.129.2.28:25 S ttl=50 id=62291 iplen=44 seq=4092255222 win=1024 <mss 1460>
SENT (0.0278s) TCP 10.10.14.2:57347 > 10.129.2.28:21 S ttl=58 id=38696 iplen=44 seq=4092255222 win=1024 <mss 1460>
RCVD (0.0329s) ICMP [10.129.2.28 > 10.10.14.2 Port 21 unreachable (type=3/code=3) ] IP [ttl=64 id=40884 iplen=72 ]
RCVD (0.0341s) TCP 10.129.2.28:22 > 10.10.14.2:57347 SA ttl=64 id=0 iplen=44 seq=1153454414 win=64240 <mss 1460>
RCVD (1.0386s) TCP 10.129.2.28:22 > 10.10.14.2:57347 SA ttl=64 id=0 iplen=44 seq=1153454414 win=64240 <mss 1460>
SENT (1.1366s) TCP 10.10.14.2:57348 > 10.129.2.28:25 S ttl=44 id=6796 iplen=44 seq=4092320759 win=1024 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up (0.0053s latency).
PORT STATE SERVICE
21/tcp filtered ftp
22/tcp open ssh
25/tcp filtered smtp
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
ACK Scan
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 21,22,25 -sA -Pn -n --disable-arp-ping --packet-trace
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 14:57 CEST
SENT (0.0422s) TCP 10.10.14.2:49343 > 10.129.2.28:21 A ttl=49 id=12381 iplen=40 seq=0 win=1024
SENT (0.0423s) TCP 10.10.14.2:49343 > 10.129.2.28:22 A ttl=41 id=5146 iplen=40 seq=0 win=1024
SENT (0.0423s) TCP 10.10.14.2:49343 > 10.129.2.28:25 A ttl=49 id=5800 iplen=40 seq=0 win=1024
RCVD (0.1252s) ICMP [10.129.2.28 > 10.10.14.2 Port 21 unreachable (type=3/code=3) ] IP [ttl=64 id=55628 iplen=68 ]
RCVD (0.1268s) TCP 10.129.2.28:22 > 10.10.14.2:49343 R ttl=64 id=0 iplen=40 seq=1660784500 win=0
SENT (1.3837s) TCP 10.10.14.2:49344 > 10.129.2.28:25 A ttl=59 id=21915 iplen=40 seq=0 win=1024
Nmap scan report for 10.129.2.28
Host is up (0.083s latency).
PORT STATE SERVICE
21/tcp filtered ftp
22/tcp unfiltered ssh
25/tcp filtered smtp
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
Pay attention to the RCVD packets and its set flag you receive from your target. With the SYN scan your target tries to establish the TCP connection by sending a packet back with the SYN-ACK flags set and with the ACK scan you get the RST flag because TCP port 22 is open. For the TCP port 25, you do not receive any packets back, which indicates that the packets will be dropped.
Detect IDS/IPS
Unlike firewalls and their rules, the detection of IDS/IPS system is much more difficult because these are passive traffic monitoring systems. IDS systems examine all connections between hosts. If the IDS finds packets containing the defined contents or specifications, the admin is notified and takes appropriate action in the worst case.
IPS systems take measures configured by the admin independently to prevent potential attacks automatically. It is essential to know that IDS and IPS are different applications and that IPS serves as a complement to IDS.
Several virtual private servers with different IP addresses are recommended to determine whether such systems are on the target network during a pentest. If the admin detects such a potential attack on the target network, the first step is to block the IP address from which the potential attack comes. As a result, you will no longer be able to access the network using that IP address, and your ISP will be contacted and blocked from all access to the internet.
Consequently, you know that you need to be quieter with your scans, in the best case, disguise all interactions with the target network and its services.
Decoys
There are cases in which admins block specific subnets from different regions in principle. This prevents any access to the target network. Another example is when IPS shoud block you. For this reason, the decoy scanning method (-D) is the right choice. With this method, nmap generates various random IP addresses inserted into the IP header to disguise the origin of the packet sent. With this method, you can generate random a specific number of IP addresses separated by a colon. Your real IP address is then randomly placed between the generated IP addresses. In the next example, your real IP address is therefore placed in the second position. Another critical point is that the decoys must be alive. Otherwise, the service on the target may be unreachable due to SYN-flooding security mechanisms.
Scan by Using Decoys
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p 80 -sS -Pn -n --disable-arp-ping --packet-trace -D RND:5
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 16:14 CEST
SENT (0.0378s) TCP 102.52.161.59:59289 > 10.129.2.28:80 S ttl=42 id=29822 iplen=44 seq=3687542010 win=1024 <mss 1460>
SENT (0.0378s) TCP 10.10.14.2:59289 > 10.129.2.28:80 S ttl=59 id=29822 iplen=44 seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 210.120.38.29:59289 > 10.129.2.28:80 S ttl=37 id=29822 iplen=44 seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 191.6.64.171:59289 > 10.129.2.28:80 S ttl=38 id=29822 iplen=44 seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 184.178.194.209:59289 > 10.129.2.28:80 S ttl=39 id=29822 iplen=44 seq=3687542010 win=1024 <mss 1460>
SENT (0.0379s) TCP 43.21.121.33:59289 > 10.129.2.28:80 S ttl=55 id=29822 iplen=44 seq=3687542010 win=1024 <mss 1460>
RCVD (0.1370s) TCP 10.129.2.28:80 > 10.10.14.2:59289 SA ttl=64 id=0 iplen=44 seq=4056111701 win=64240 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up (0.099s latency).
PORT STATE SERVICE
80/tcp open http
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
The spoofed packets are often filtered out by ISPs and routers, even though they come from the same network range. Therefore, you can also specify your VPS servers’ IP addresses and use them in combination with IP ID manipulation in the IP headers to scan the target.
Another scenario would be that only individual subnets would not have access to the server’s specific services. So you can also manually specify the source IP address (-S) to test if you get better results with this one. Decoys can be used for SYN, ACK, ICMP scans, and OS detection scans.
Testin Firewall Rules
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -n -Pn -p445 -O
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-22 01:23 CEST
Nmap scan report for 10.129.2.28
Host is up (0.032s latency).
PORT STATE SERVICE
445/tcp filtered microsoft-ds
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.14 seconds
# -D RND:5: generates five random IP addresses that indicates the source IP address the connection comes from
Scan by Using Different Source IP
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -n -Pn -p 445 -O -S 10.129.2.200 -e tun0
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-22 01:16 CEST
Nmap scan report for 10.129.2.28
Host is up (0.010s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 2.6.32 (96%), Linux 3.2 - 4.9 (96%), Linux 2.6.32 - 3.10 (96%), Linux 3.4 - 3.10 (95%), Linux 3.1 (95%), Linux 3.2 (95%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (94%), Synology DiskStation Manager 5.2-5644 (94%), Linux 2.6.32 - 2.6.35 (94%), Linux 2.6.32 - 3.5 (94%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 4.11 seconds
# -S [IP]: scans the target by using different source IP address
# -e tun0 send all requests through the specified interface
DNS Proxying
By default, nmap performs a reverse DNS resolution unless otherwise specified to find more important information about your target. These DNS queries are also passed in most cases because the given web server is supposed to be found and visited. The DNS queries are made over the UDP port 53. The TCP port 53 was previously only used for the so-called “zone transfers” between the DNS servers or data transfer larger than 512 bytes. More and more, this is changing due to IPv6 and DNSSEC expansions. These changes cause many DNS requests to be made via TCP port 53.
However, nmap still gives you a way to specify DNS servers yourself (--dns-server <ns>,<ns>). This method could be fundamental to you if you are in a demilitarized zone. The company’s DNS servers are usually more trusted than those from the Internet. So, for example, you could use them to interact with the hosts of the internal network. As another example, you can use TCP port 53 as a source port (--source-port) for your scans. If the admins uses the firewall to control this port and does not filter IDS/IPS properly, your TCP packets will be trusted and passed through.
SYN-Scan of a Filtered Port
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p50000 -sS -Pn -n --disable-arp-ping --packet-trace
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-21 22:50 CEST
SENT (0.0417s) TCP 10.10.14.2:33436 > 10.129.2.28:50000 S ttl=41 id=21939 iplen=44 seq=736533153 win=1024 <mss 1460>
SENT (1.0481s) TCP 10.10.14.2:33437 > 10.129.2.28:50000 S ttl=46 id=6446 iplen=44 seq=736598688 win=1024 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up.
PORT STATE SERVICE
50000/tcp filtered ibm-db2
Nmap done: 1 IP address (1 host up) scanned in 2.06 seconds
SYN-Scan From DNS Port
d41y@htb[/htb]$ sudo nmap 10.129.2.28 -p50000 -sS -Pn -n --disable-arp-ping --packet-trace --source-port 53
SENT (0.0482s) TCP 10.10.14.2:53 > 10.129.2.28:50000 S ttl=58 id=27470 iplen=44 seq=4003923435 win=1024 <mss 1460>
RCVD (0.0608s) TCP 10.129.2.28:50000 > 10.10.14.2:53 SA ttl=64 id=0 iplen=44 seq=540635485 win=64240 <mss 1460>
Nmap scan report for 10.129.2.28
Host is up (0.013s latency).
PORT STATE SERVICE
50000/tcp open ibm-db2
MAC Address: DE:AD:00:00:BE:EF (Intel Corporate)
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
# --source-port 53: performs the scans from specified source port
Now that you have found out that the firewall accepts TCP port 53, it is very likely that IDS/IPS filters might also be configured much weaker than others. You can test this by trying to connect to this port by using NetCat.
Connect to the Filtered Port
d41y@htb[/htb]$ ncat -nv --source-port 53 10.129.2.28 50000
Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Connected to 10.129.2.28:50000.
220 ProFTPd