#nmap #enumeration #network #hacking [source](https://academy.hackthebox.com/module/19/section/99) `Enumeration` is the most critical part of all. The art, the difficulty, and the goal are not to gain access to our target computer. Instead, it is identifying all of the ways we could attack a target we must find. It is not just based on the tools we use. They will only do much good if we know what to do with the information we get from them. The tools are just tools, and tools alone should never replace our knowledge and our attention to detail. Here it is much more about actively interacting with the individual services to see what information they provide us and what possibilities they offer us. It is essential to understand how these services work and what syntax they use for effective communication and interaction with the different services. This phase aims to improve our knowledge and understanding of the technologies, protocols, and how they work and learn to deal with new information and adapt to our already acquired knowledge. Enumeration is collecting as much information as possible. The more information we have, the easier it will be for us to find vectors of attack. Imagine the following situation: Our partner is not at home and has misplaced our car keys. We call our partner and ask where the keys are. If we get an answer like "in the living room," it is entirely unclear and can take much time to find them there. However, what if our partner tells us something like "in the living room on the white shelf, next to the TV, in the third drawer"? As a result, it will be much easier to find them. It's not hard to get access to the target system once we know how to do it. Most of the ways we can get access we can narrow down to the following two points: - `Functions and/or resources that allow us to interact with the target and/or provide additional information.` - `Information that provides us with even more important information to access our target.` When scanning and inspecting, we look exactly for these two possibilities. Most of the information we get comes from misconfigurations or neglect of security for the respective services. Misconfigurations are either the result of ignorance or a wrong security mindset. For example, if the administrator only relies on the firewall, Group Policy Objects (GPOs), and continuous updates, it is often not enough to secure the network. `Enumeration is the key`. That's what most people say, and they are right. However, it is too often misunderstood. Most people understand that they haven't tried all the tools to get the information they need. Most of the time, however, it's not the tools we haven't tried, but rather the fact that we don't know how to interact with the service and what's relevant. That's precisely the reason why so many people stay stuck in one spot and don't get ahead. Had these people invested a couple of hours learning more about the service, how it works, and what it is meant for, they would save a few hours or even days from reaching their goal and get access to the system. `Manual enumeration` is a `critical` component. Many scanning tools simplify and accelerate the process. However, these cannot always bypass the security measures of the services. The easiest way to illustrate this is to use the following example: Most scanning tools have a timeout set until they receive a response from the service. If this tool does not respond within a specific time, this service/port will be marked as closed, filtered, or unknown. In the last two cases, we will still be able to work with it. However, if a port is marked as closed and Nmap doesn't show it to us, we will be in a bad situation. This service/port may provide us with the opportunity to find a way to access the system. Therefore, this result can take much unnecessary time until we find it.#nmap #network #hacking #enumeration [source](https://academy.hackthebox.com/module/19/section/100) Network Mapper (`Nmap`) is an open-source network analysis and security auditing tool written in C, C++, Python, and Lua. It is designed to scan networks and identify which hosts are available on the network using raw packets, and services and applications, including the name and version, where possible. It can also identify the operating systems and versions of these hosts. Besides other features, Nmap also offers scanning capabilities that can determine if packet filters, firewalls, or intrusion detection systems (IDS) are configured as needed. --- ## Use Cases The tool is one of the most used tools by network administrators and IT security specialists. It is used to: - Audit the security aspects of networks - Simulate penetration tests - Check firewall and IDS settings and configurations - Types of possible connections - Network mapping - Response analysis - Identify open ports - Vulnerability assessment as well. --- ## Nmap Architecture Nmap offers many different types of scans that can be used to obtain various results about our targets. Basically, Nmap can be divided into the following scanning techniques: - Host discovery - Port scanning - Service enumeration and detection - OS detection - Scriptable interaction with the target service (Nmap Scripting Engine) --- ## Syntax The syntax for Nmap is fairly simple and looks like this: ```shell-session tr01ax@htb[/htb]$ nmap ``` --- ## Scan Techniques Nmap offers many different scanning techniques, making different types of connections and using differently structured packets to send. Here we can see all the scanning techniques Nmap offers: ```shell-session tr01ax@htb[/htb]$ nmap --help SCAN TECHNIQUES: -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 : Customize TCP scan flags -sI : Idle scan -sY/sZ: SCTP INIT/COOKIE-ECHO scans -sO: IP protocol scan -b : FTP bounce scan ``` For example, the TCP-SYN scan (`-sS`) is one of the default settings unless we have defined otherwise and is also one of the most popular scan methods. This scan method makes it possible to scan several thousand ports per second. The TCP-SYN scan sends one packet with the SYN flag and, therefore, never completes the three-way handshake, which results in not establishing a full TCP connection to the scanned port. - If our target sends an `SYN-ACK` flagged packet back to the scanned port, Nmap detects that the port is `open`. - If the packet receives an `RST` flag, it is an indicator that the port is `closed`. - If Nmap does not receive a packet back, it will display it as `filtered`. Depending on the firewall configuration, certain packets may be dropped or ignored by the firewall. Let us take an example of such a scan. ```shell-session tr01ax@htb[/htb]$ sudo nmap -sS localhost Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-11 22:50 UTC Nmap scan report for localhost (127.0.0.1) Host is up (0.000010s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 5432/tcp open postgresql 5901/tcp open vnc-1 Nmap done: 1 IP address (1 host up) scanned in 0.18 seconds ``` In this example, we can see that we have four different TCP ports open. In the first column, we see the number of the port. Then, in the second column, we see the service's status and then what kind of service it is.#nmap #firewall #hacking #network More strategies about host discovery can be found at: [https://nmap.org/book/host-discovery-strategies.html](https://nmap.org/book/host-discovery-strategies.html) # Host Discovery --- When we need to conduct an internal penetration test for the entire network of a company, for example, then we should, first of all, get an overview of which systems are online that we can work with. To actively discover such systems on the network, we can use various `Nmap` host discovery options. There are many options `Nmap` provides to determine whether our target is alive or not. The most effective host discovery method is to use **ICMP echo requests**, which we will look into. 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 produces which results. #### Scan Network Range Scan Network Range ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`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 firewalls of the hosts allow it. Otherwise, we can use other scanning techniques to find out if the hosts are active or not. We will take a closer look at these techniques in "`Firewall and IDS Evasion`". --- ## Scan IP List During an internal penetration test, it is not uncommon for us to be provided with an IP list with the hosts we need to test. `Nmap` also gives us 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: Scan Network Range ```shell-session s1rsapp3rl0t@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 we use the same scanning technique on the predefined list, the command will look like this: Scan Network Range ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`-sn`|Disables port scanning.| |`-oA tnet`|Stores the results in all formats starting with the name 'tnet'.| |`-iL`|Performs defined scans against targets in provided 'hosts.lst' list.| In this example, we see that only 3 of 7 hosts are active. Remember, this may mean that the other hosts ignore the default **ICMP echo requests** because of their firewall configurations. Since `Nmap` does not receive a response, it marks those hosts as inactive. --- ## Scan Multiple IPs It can also happen that we only need to scan a small part of a network. An alternative to the method we used last time is to specify multiple IP addresses. Scan Network Range ```shell-session s1rsapp3rl0t@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, we can also define the range in the respective octet. Scan Network Range ```shell-session s1rsapp3rl0t@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 we scan a single host for open ports and its services, we first have to determine if it is alive or not. For this, we can use the same method as before. Scan Network Range ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.18`|Performs defined scans against the target.| |`-sn`|Disables port scanning.| |`-oA host`|Stores the results in all formats starting with the name 'host'.| If we disable port scan (`-sn`), Nmap automatically ping scan with `ICMP Echo Requests` (`-PE`). Once such a request is sent, we usually expect an `ICMP reply` if the pinging host is alive. The more interesting fact is that our 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`. We can confirm this with the "`--packet-trace`" option. To ensure that ICMP echo requests are sent, we also define the option (`-PE`) for this. Scan Network Range ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.18`|Performs defined scans against the target.| |`-sn`|Disables port scanning.| |`-oA host`|Stores the results in all formats starting with the name 'host'.| |`-PE`|Performs the ping scan by using 'ICMP Echo requests' against the target.| |`--packet-trace`|Shows all packets sent and received| --- Another way to determine why Nmap has our target marked as "alive" is with the "`--reason`" option. Scan Network Range ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.18`|Performs defined scans against the target.| |`-sn`|Disables port scanning.| |`-oA host`|Stores the results in all formats starting with the name 'host'.| |`-PE`|Performs the ping scan by using 'ICMP Echo requests' against the target.| |`--reason`|Displays the reason for specific result.| --- We 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 our target with the desired `ICMP echo requests`, we can disable ARP pings by setting the "`--disable-arp-ping`" option. Then we can scan our target again and look at the packets sent and received. Scan Network Range ```shell-session s1rsapp3rl0t@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 ``` We have already mentioned in the "`Learning Process`," and at the beginning of this module, it is essential to pay attention to details. An `ICMP echo request` can help us determine if our target is alive and identify its system. #nmap #ports #hacking #network #hostname More information about port scanning techniques we can find at: [https://nmap.org/book/man-port-scanning-techniques.html](https://nmap.org/book/man-port-scanning-techniques.html) # Host and Port Scanning --- It is essential to understand how the tool we use works and how it performs and processes the different functions. We will only understand the results if we know what they mean and how they are obtained. Therefore we will take a closer look at and analyze some of the scanning methods. After we have found out that our target is alive, we want to get a more accurate picture of the system. The information we need includes: - Open ports and its services - Service versions - Information that the services provided - Operating system There are a total of 6 different states for a scanned port we can obtain: |**State**|**Description**| |---|---| |`open`|This 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, the TCP protocol indicates that the packet we received back contains an `RST` flag. This scanning method can also be used to determine if our 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 we get an error code from the target.| |`unfiltered`|This state of a 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 we 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 By default, `Nmap` scans the top 1000 TCP ports with the SYN scan (`-sS`). This SYN scan is set only to default when we run it as root because of the socket permissions required to create raw TCP packets. Otherwise, the TCP scan (`-sT`) is performed by default. This means that if we do not define ports and scanning methods, these parameters are set automatically. We can define the ports one by one (`-p 22,25,80,139,445`), by range (`-p 22-445`), by top ports (`--top-ports=10`) from the `Nmap` database that have been signed as most frequent, by scanning all ports (`-p-`) but also by defining a fast port scan, which contains top 100 ports (`-F`). #### Scanning Top 10 TCP Ports Scanning Top 10 TCP Ports ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`--top-ports=10`|Scans the specified top ports that have been defined as most frequent.| --- We see that we only scanned the top 10 TCP ports of our target, and `Nmap` displays their state accordingly. If we trace the packets `Nmap` sends, we will see the `RST` flag on `TCP port 21` that our target sends back to us. To have a clear view of the SYN scan, we disable the ICMP echo requests (`-Pn`), DNS resolution (`-n`), and ARP ping scan (`--disable-arp-ping`). #### Nmap - Trace the Packets Nmap - Trace the Packets ```shell-session s1rsapp3rl0t@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 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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p 21`|Scans only the specified port.| |`--packet-trace`|Shows all packets sent and received.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| --- We can see from the SENT line that we (`10.10.14.2`) sent a TCP packet with the `SYN` flag (`S`) to our target (`10.129.2.28`). In the next RCVD line, we can see that the target responds with a TCP packet containing the `RST` and `ACK` flags (`RA`). `RST` and `ACK` flags are used to acknowledge receipt of the TCP packet (`ACK`) and to end the TCP session (`RST`). #### Request |**Message**|**Description**| |---|---| |`SENT (0.0429s)`|Indicates the SENT operation of Nmap, which sends a packet to the target.| |`TCP`|Shows the protocol that is being used to interact with the target port.| |`10.10.14.2:63090 >`|Represents our IPv4 address and the source port, which will be used by Nmap to send the packets.| |`10.129.2.28:21`|Shows the target IPv4 address and the target port.| |`S`|SYN flag of the sent TCP packet.| |`ttl=56 id=57322 iplen=44 seq=1699105818 win=1024 mss 1460`|Additional TCP Header parameters.| #### Response |**Message**|**Description**| |---|---| |`RCVD (0.0573s)`|Indicates a received packet from the target.| |`TCP`|Shows the protocol that is being used.| |`10.129.2.28:21 >`|Represents targets IPv4 address and the source port, which will be used to reply.| |`10.10.14.2:63090`|Shows our IPv4 address and the port that will be replied to.| |`RA`|RST and ACK flags of the sent TCP packet.| |`ttl=64 id=0 iplen=40 seq=0 win=0`|Additional TCP Header parameters.| #### Connect Scan The Nmap [TCP Connect Scan](https://nmap.org/book/scan-methods-connect-scan.html) (`-sT`) uses the TCP three-way handshake to determine if a specific port on a target host is open or closed. The scan sends an `SYN` packet to the target port and waits for a response. It is considered open if the target port responds with an `SYN-ACK` packet and closed if it responds with an `RST` packet. The `Connect` scan is useful because it is the most accurate way to determine the state of a port, and it is also the most stealthy. Unlike other types of scans, such as the SYN scan, the Connect scan does not leave any unfinished connections or unsent packets on the target host, which makes it less likely to be detected by intrusion detection systems (IDS) or intrusion prevention systems (IPS). It is useful when we want to map the network and don't want to disturb the services running behind it, thus causing a minimal impact and sometimes considered a more polite scan method. It is also useful when the target host has a personal 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 of scans 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. #### Connect Scan on TCP Port 443 Connect Scan on TCP Port 443 ```shell-session s1rsapp3rl0t@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 ``` --- ## 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 our target, and by default, the retry rate (`--max-retries`) is set to 1. This means `Nmap` will resend the request to the target port to determine if the previous packet was not accidentally mishandled. Let us look at an example where the firewall `drops` the TCP packets we send for the port scan. Therefore we scan the TCP port **139**, which was already shown as filtered. To be able to track how our sent packets are handled, we deactivate the ICMP echo requests (`-Pn`), DNS resolution (`-n`), and ARP ping scan (`--disable-arp-ping`) again. Connect Scan on TCP Port 443 ```shell-session s1rsapp3rl0t@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 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 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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p 139`|Scans only the specified port.| |`--packet-trace`|Shows all packets sent and received.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| |`-Pn`|Disables ICMP Echo requests.| --- We see in the last scan that `Nmap` sent two TCP packets with the SYN flag. By the duration (`2.06s`) of the scan, we can recognize that it took much longer than the previous ones (`~0.05s`). The case is different if the firewall rejects the packets. For this, we look at TCP port `445`, which is handled accordingly by such a rule of the firewall. Connect Scan on TCP Port 443 ```shell-session s1rsapp3rl0t@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 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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p 445`|Scans only the specified port.| |`--packet-trace`|Shows all packets sent and received.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| |`-Pn`|Disables ICMP Echo requests.| As a response, we receive an `ICMP` reply with `type 3` and `error code 3`, which indicates that the desired host is unreachable. Nevertheless, if we know that the host is alive, we can strongly assume that the firewall on this port is rejecting the packets, and we will have to take a closer look at this port later. --- ## Discovering Open UDP Ports Some system administrators 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. We do not receive any acknowledgment. Consequently, the timeout is much longer, making the whole `UDP scan` (`-sU`) much slower than the `TCP scan` (`-sS`). Let's look at an example of what a UDP scan (`-sU`) can look like and what results it gives us. #### UDP Port Scan UDP Port Scan ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-F`|Scans top 100 ports.| |`-sU`|Performs a UDP scan.| --- Another disadvantage of this is that we often do not get a response back because `Nmap` sends empty datagrams to the scanned UDP ports, and we do not receive any response. So we cannot determine if the UDP packet has arrived at all or not. If the UDP port is `open`, we only get a response if the application is configured to do so. UDP Port Scan ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-sU`|Performs a UDP scan.| |`-Pn`|Disables ICMP Echo requests.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| |`--packet-trace`|Shows all packets sent and received.| |`-p 137`|Scans only the specified port.| |`--reason`|Displays the reason a port is in a particular state.| --- If we get an ICMP response with `error code 3` (port unreachable), we know that the port is indeed `closed`. UDP Port Scan ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-sU`|Performs a UDP scan.| |`-Pn`|Disables ICMP Echo requests.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| |`--packet-trace`|Shows all packets sent and received.| |`-p 100`|Scans only the specified port.| |`--reason`|Displays the reason a port is in a particular state.| --- For all other ICMP responses, the scanned ports are marked as (`open|filtered`). UDP Port Scan ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-sU`|Performs a UDP scan.| |`-Pn`|Disables ICMP Echo requests.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| |`--packet-trace`|Shows all packets sent and received.| |`-p 138`|Scans only the specified port.| |`--reason`|Displays the reason a port is in a particular state.| 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 our target. #### Version Scan Version Scan ```shell-session s1rsapp3rl0t@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 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 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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-Pn`|Disables ICMP Echo requests.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| |`--packet-trace`|Shows all packets sent and received.| |`-p 445`|Scans only the specified port.| |`--reason`|Displays the reason a port is in a particular state.| |`-sV`|Performs a service scan.| #nmap #network #enumeration #hacking [source](https://academy.hackthebox.com/module/19/section/104) ## Different Formats While we run various scans, we should always save the results. We can use these later to examine the differences between the different scanning methods we 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 We can also specify the option (`-oA`) to save the results in all formats. The command could look like this: ```shell-session tr01ax@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p-`|Scans all ports.| |`-oA target`|Saves the results in all formats, starting the name of each file with 'target'.| If no full path is given, the results will be stored in the directory we are currently in. Next, we look at the different formats `Nmap` has created for us. ```shell-session tr01ax@htb[/htb]$ ls target.gnmap target.xml target.nmap ``` #### Normal Output   Normal Output ```shell-session tr01ax@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   Grepable Output ```shell-session tr01ax@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   XML Output ```shell-session tr01ax@htb[/htb]$ cat target.xml
``` --- ## Style sheets With the XML output, we 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 our results in a detailed and clear way. To convert the stored results from XML format to HTML, we can use the tool `xsltproc`.   XML Output ```shell-session tr01ax@htb[/htb]$ xsltproc target.xml -o target.html ``` If we now open the HTML file in our browser, we see a clear and structured presentation of our results. #### Nmap Report ![image](https://academy.hackthebox.com/storage/modules/19/nmap-report.png) More information about the output formats can be found at: [https://nmap.org/book/output.html](https://nmap.org/book/output.html)#nmap #services #network #hacking #enumeration # Service Enumeration --- For us, it is essential to determine the application and its version as accurately as possible. We can use this information to scan for known vulnerabilities and analyze the source code for that version if we find it. An exact version number allows us to search for a more precise exploit that fits the service and the operating system of our target. --- ## Service Version Detection It is recommended to perform a quick port scan first, which gives us a small overview of the available ports. This causes significantly less traffic, which is advantageous for us because otherwise we can be discovered and blocked by the security mechanisms. We can deal with these first and run a port scan in the background, which shows all open ports (`-p-`). We can use the version scan to scan the specific ports for services and their versions (`-sV`). A full port scan takes quite a long time. To view the scan status, we can press the `[Space Bar]` during the scan, which will cause `Nmap` to show us the scan status. ```shell-session s1rsapp3rl0t@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) ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p-`|Scans all ports.| |`-sV`|Performs service version detection on specified ports.| --- Another option (`--stats-every=5s`) that we can use is defining how periods of time the status should be shown. Here we can specify the number of seconds (`s`) or minutes (`m`), after which we want to get the status. ```shell-session s1rsapp3rl0t@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) ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p-`|Scans all ports.| |`-sV`|Performs service version detection on specified ports.| |`--stats-every=5s`|Shows the progress of the scan every 5 seconds.| --- We can also increase the `verbosity level` (`-v` / `-vv`), which will show us the open ports directly when `Nmap` detects them. ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p-`|Scans all ports.| |`-sV`|Performs service version detection on specified ports.| |`-v`|Increases the verbosity of the scan, which displays more detailed information.| --- ## Banner Grabbing Once the scan is complete, we will see all TCP ports with the corresponding service and their versions that are active on the system. ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p-`|Scans all ports.| |`-sV`|Performs service version detection on specified ports.| --- 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. Let us look at an example of this. ```shell-session s1rsapp3rl0t@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 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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p-`|Scans all ports.| |`-sV`|Performs service version detection on specified ports.| |`-Pn`|Disables ICMP Echo requests.| |`-n`|Disables DNS resolution.| |`--disable-arp-ping`|Disables ARP ping.| |`--packet-trace`|Shows all packets sent and received.| --- If we look at the results from `Nmap`, we can see the port's status, service name, and hostname. Nevertheless, let us look at this line here: - `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 we see that the SMTP server on our target gave us more information than `Nmap` showed us. Because here, we see that it is the Linux distribution `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 remove or manipulate the banners from the respective services. If we `manually` connect to the SMTP server using `nc`, grab the banner, and intercept the network traffic using `tcpdump`, we can see what `Nmap` did not show us. #### Tcpdump Tcpdump ```shell-session s1rsapp3rl0t@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 Nc ```shell-session s1rsapp3rl0t@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 Tcpdump - Intercepted Traffic ```shell-session 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 us the three-way handshake. |||| |---|---|---| |1.|`[SYN]`|`18:28:07.128564 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [S], `| |2.|`[SYN-ACK]`|`18:28:07.255151 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [S.], `| |3.|`[ACK]`|`18:28:07.255281 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], `| After that, the target SMTP server sends us a TCP packet with the `PSH` and `ACK` flags, where `PSH` states that the target server is sending data to us and with `ACK` simultaneously informs us that all required data has been sent. |||| |---|---|---| |4.|`[PSH-ACK]`|`18:28:07.319306 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [P.], `| The last TCP packet that we sent confirms the receipt of the data with an `ACK`. |||| |---|---|---| |5.|`[ACK]`|`18:28:07.319426 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], `|#nmap #nse #hacking #network More information about NSE scripts and the corresponding categories we can find at: [https://nmap.org/nsedoc/index.html](https://nmap.org/nsedoc/index.html) # Nmap Scripting Engine --- Nmap Scripting Engine (`NSE`) is another handy feature of `Nmap`. It provides us 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 credentials.| |`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 scripts executed by using the `-sC` option.| |`discovery`|Evaluation of accessible services.| |`dos`|These scripts are used to check services for denial of service vulnerabilities and are used less as it harms the services.| |`exploit`|This category of scripts tries to exploit known vulnerabilities for the scanned port.| |`external`|Scripts that use external services for further processing.| |`fuzzer`|This uses scripts to identify vulnerabilities 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 vulnerabilities.| We have several ways to define the desired scripts in `Nmap`. #### Default Scripts Default Scripts ```shell-session s1rsapp3rl0t@htb[/htb]$ sudo nmap -sC ``` #### Specific Scripts Category Specific Scripts Category ```shell-session s1rsapp3rl0t@htb[/htb]$ sudo nmap --script ``` #### Defined Scripts Defined Scripts ```shell-session s1rsapp3rl0t@htb[/htb]$ sudo nmap --script ,,... ``` For example, let us keep working with the target SMTP port and see the results we get with two defined scripts. #### Nmap - Specifying Scripts Nmap - Specifying Scripts ```shell-session s1rsapp3rl0t@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) ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p 25`|Scans only the specified port.| |`--script banner,smtp-commands`|Uses specified NSE scripts.| We see that we can recognize the **Ubuntu** distribution of Linux by using the' banner' script. The `smtp-commands` script shows us which commands we can use by interacting with the target SMTP server. In this example, such information may help us to find out existing users on the target. `Nmap` also gives us the ability to scan our 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`). #### Nmap - Aggressive Scan Nmap - Aggressive Scan ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p 25`|Scans only the specified port.| |`-A`|Performs service detection, OS detection, traceroute and uses defaults scripts to scan the target.| With the help of the used scan option (`-A`), we found out what kind of web server (`Apache 2.4.29`) is running on the system, which web application (`WordPress 5.3.4`) is used, and the title (`blog.inlanefreight.com`) of the web page. Also, `Nmap` shows that it is likely to be `Linux` (`96%`) operating system. --- ## Vulnerability Assessment Now let us move on to HTTP port 80 and see what information and vulnerabilities we can find using the `vuln` category from `NSE`. #### Nmap - Vuln Category Nmap - Vuln Category ```shell-session s1rsapp3rl0t@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 ``` |**Scanning Options**|**Description**| |---|---| |`10.129.2.28`|Scans the specified target.| |`-p 80`|Scans only the specified port.| |`-sV`|Performs service version detection on specified ports.| |`--script vuln`|Uses all related scripts from specified category.| The scripts used for the last scan interact with the webserver and its web application to find out more information about their versions and check various databases to see if there are known vulnerabilities. More information about NSE scripts and the corresponding categories we can find at: [https://nmap.org/nsedoc/index.html](https://nmap.org/nsedoc/index.html)#nmap #network #enumeration #hacking [source](https://academy.hackthebox.com/module/19/section/105) Scanning performance plays a significant role when we need to scan an extensive network or are dealing with low network bandwidth. We can use various options to tell `Nmap` how fast (`-T <0-5>`), with which frequency (`--min-parallelism `), which timeouts (`--max-rtt-timeout