#readwise # Network Enumeration with Nmap - Service Enumeration ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article1.be68295a7e40.png) ## Metadata - Author: [[Hack The Box]] - Full Title: Network Enumeration with Nmap - Service Enumeration - URL: https://academy.hackthebox.com/module/19/section/103 ## Summary Service enumeration is important for identifying application versions to find vulnerabilities. A quick port scan helps minimize traffic and avoid detection. Nmap can be used to scan all ports and detect service versions, showing progress during the scan. By examining banners and using tools like `nc` and `tcpdump`, we can gather more detailed information about services running on the target. ## Highlights 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`). ([View Highlight](https://read.readwise.io/read/01jp31q87x8a32r0ycy86j7yzv)) ^s0am0x --- 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. ([View Highlight](https://read.readwise.io/read/01jp31qa6hz5w5kcskgb2ywgsc)) ^uulzwt --- 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. ([View Highlight](https://read.readwise.io/read/01jp31qq9qgmtsyy093rgvy490)) ^fzqp2w --- 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. ([View Highlight](https://read.readwise.io/read/01jp31s7rs73pyqtvd74s00hwm)) ^007kxj --- 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. ^9hunmb ```sh sudo tcpdump -i eth0 host 10.10.14.2 and 10.129.2.28 ``` ^5j7os0 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ```sh nc -nv 10.129.2.28 25 ``` ^qkihr8 (`-n` suppresses DNS lookup) ^hlkbsr > `Connection to 10.129.2.28 port 25 [tcp/*] succeeded!` > `220 inlane ESMTP Postfix (Ubuntu)` > `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. `[SYN]` `18:28:07.128564 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [S], <SNIP>` `[SYN-ACK]` `18:28:07.255151 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [S.], <SNIP>` `[ACK]` `18:28:07.255281 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], <SNIP>` 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. `[PSH-ACK]` `18:28:07.319306 IP 10.129.2.28.smtp > 10.10.14.2.59618: Flags [P.], <SNIP>` The last TCP packet that we sent confirms the receipt of the data with an `ACK`. `[ACK]` `18:28:07.319426 IP 10.10.14.2.59618 > 10.129.2.28.smtp: Flags [.], <SNIP>` ([View Highlight](https://read.readwise.io/read/01jp31zgkv6y030qpwb9x32s6n)) ---