Juuso Kalliomäki
BlogGitHub

Pentest week 4, Active recon

Penetration testing week 4

This week's focus on the course is active recon and the tools used for it.

Links to exercise sections

z) Reading/listening/video summary

Santos et al: The Art of Hacking (Video Collection): [..] 4.3 Surveying Essential Tools for Active Reconnaissance

  • Active reconnaissance
    • actually sending data to the target machine to gather data
    • port scanning, vulnerability scanning
    • can be detected
  • port scanning tools
    • nmap
      • versatile
    • masscan
      • fast
    • udpprotoscanner
      • udp scanning
  • web service review tools
    • EyeWitness
      • takes pictures of webservices from specified ip range
      • creates a report page

Lyon 2009: Nmap Network Scanning: Chapter 1. Getting Started with Nmap

  • Start with network discovery
    • use -sL to do a reverse-DNS lookup on expected target ip ranges to be sure of their ownership
      • revealed host names can also hint towards vulnerabilities
  • Then portscan and version scan the network
  • Evaluate the found open ports and services running on them
  • nmap scanning phases
    • script pre-scanning: special-purpose scripts for example dhcp-discover
    • target enumeration: nmap researches user provided host specifiers (IP addresses, DNS names, CIDR notation...)
    • host discovery: check which hosts on the network are online
    • reverse-DNS resolution: looking up the host names for all online hosts
    • port scanning: core nmap functionality of probing ports to see if they are open/closed/filtered and much more
    • version detection: sending probes to found open ports and comparing responses for known service signatures
    • OS detection: measuring differences on how operating systems implement network standards by comparing responses against known responses
    • traceroute: optional optimized nmap traceroute implementation for finding network routes to hosts
    • script scanning: scripts that run usually once per target host/port and usually are used to detect vulnerabilities, malware or do some more thorough investigation on services
    • output: writing all found information to screen and/or a file
    • script post-scanning: optional user-included scripts to process result data
  • nmap sould only be used on targets that have given written authorization or you yourself own the target and network

Lyon 2009: Nmap Network Scanning: Chapter 15. Nmap Reference Guide

  • Port Scanning Basics
    • port states
      • open: an application is actively accepting TCP connections on port
      • closed: port is accessible but there is no application listening for traffic
      • filtered: port cannot be determined to be oipen or closed due to traffic being filtered and dropped by a firewall or router rules
  • Port Scanning Techniques
    • TCP SYN scan -sS
      • a half-open scan where a SYN packet is sent
      • based on response (SYN/ACK, RST, no response) port is set open/closed/filtered
      • no further packets are sent, making scanning fast
    • TCP connect scan -sT
      • used when SYN scan is not an option due to user not having raw packet privileges
      • uses a system call to establish a full connection to target
      • requires more packets -> slower and more likely to be logged
    • UDP scans -sU
      • sends a UDP packet to every target port
      • if an error response is received, port is marked filtered or closed based on error type
      • open ports often don't respond, making detection difficult

nmap scans

In this section I ran many different nmap scans and captured the traffic with wireshark to analyze what is happening "behind the scenes". I'm scanning a Metasploitable machine running on a network with just it and my Kali vm connected.

ping-sweep

nmap a) TCP connect scan -sT

Ran with the command sudo nmap -sT -p80 192.168.56.103. The Kali machine (102.168.56.101) starts with an ARP request to get the mac-address of target machine (102.168.56.103). After receiving a response from target machine Kali sent a TCP packet with the SYN flag set, requesting a connection. Then the target machine responded with the SYN and ACK flags set, acknowledging the connection. Now the Kali responded with an ACK flagged packet due to running a full connect scan, establishing the connection. Though the connection is immediately shut down by Kali by sending a RST packet, indicating that connection should be terminated immediately. Target machine also sends an ARP request after the exchange even though it should already have it from the initial arp request by Kali.

nmap-sT

sniff-sT

nmap b) TCP SYN scan -sS

Ran with the command sudo nmap -sS -p80 192.168.56.103. Starts the same way as the -sT scan but the connection is immediately terminated by Kali after receiving the ACK response. The nmap report is the same for this scan except for a time difference of about 0.00005s. The time differential would be more significant in larger scans.

sniff-sS

nmap c) ping sweep -sn

Ran with the command sudo nmap -sn 192.168.56.0/24. The network is flooded with ARP requests for every ip in the specified range. The requests are sent multiple times and the picture contains a response from the target machine. The scan also found the VirtualBox DHCP server that wasn't found on an earlier scan for some reason.

nmap-sn

sniff-sn

nmap d) don't ping -Pn

Doesn't ping the target hosts and treats all of them as online. Slower but allows finding machines behind firewalls with just some ports open. I ran it with sudo nmap -Pn -p80 192.168.56.100-120 but then realized that there is no difference in using -Pn on a local network as there is no need to ping the machines and they are found with just the ARP protocol. I don't have a target machine on a remote network to scan so I won't be able to test this further now.

sniff-Pn

nmap e) version detection -sV

Ran with the command sudo nmap -sV -p80 192.168.56.103. It seems that nmap starts by checking the port with a half-open connection and then starts a full connection. The target retransmits the SYN ACK packet for some reason, but I think it is not important here why. Then nmap starts sending different kinds of TCP packets and HTTP requests that would somehow identify the service and version running on the port I guess. At least it is verified that there actually is a website running as the target responds to HTTP requests with web pages.

nmap-sV

sniff-sV

nmap f) port selection

Ran with the command sudo nmap -p80-100 192.168.56.103. Nmap sends SYN packets to all specified ports and when receiving an ACK packet immediately sends a RST packet to shut down the connection. The target sends immediate RST ACK, acknowledging the packet but immediately closing the connection. Nmap then marks the port as closed.

nmap-sV

sniff-sV

nmap g) ip range

Ran with the command sudo nmap -p80 192.168.56.100-120. Nmap sends ARP request for all the IPs and for those that respond it attempts a half-open connection.

nmap-ip

sniff-ip

nmap h) output files -oA

Running nmap with the -oA flag writes the scan results in three files .gnmap (greppable), .nmap (same as cli output) and .xml. It requires a filename to be given and the files will then begin with that.

nmap-oA

nmap j) OS fingerprint, version detection, scripts, traceroute -A

Ran with the command sudo nmap -p80 -A 192.168.56.103. Nmap sends all kinds of packets, TCP, UDP, ICMP and HTTP. The differences to a -sV scan are that there are UDP and ICMP packets sent. Nmap also seems to try a lot more different HTTP request methods and URLs. I think that the section with many TCP half-connections has to do with OS detection as it is done by comparing responses to a known database. Lastly nmap runs a traceroute to the destination, which in this case is not very useful as the machines are literally in the same local network.

nmap-A

sniff-A

nmap k) runtime interaction

I ran the command sudo nmap -Pn -p- 192.168.56.0/24 to have some more time to try the nmap runtime interaction. Pressing s will give a status report of the scan and pressing v will increase the verbosity of the scan. Increasing verbosity started giving reports on each host as the status was found and for each open port found after starting SYN scan.

nmap-runtime

nmap-verbose

nmap l) with and without sudo

Running nmap without sudo makes it so that the TCP connections are not dropped halfway into the handshake, but completed fully before dropping them. I don't really know why the target machine terminates the connection straight away in the first connection, but maybe it has to do with how nmap sends two SYN packets in rapid succession without waiting for response. Then the second three-way-handshake is fully completed and then Kali terminates it.

nmap-nosudo

Running with sudo is the same as running a -sS scan. Though the flag requires sudo to run anyway because it requires messing with how the connections are handled.

nmap-sudo

nmap m) comparing -sV and -A

check -A flag section

d) How stealthy is nmap?

For this I set up a Debian 11 VM with just Apache2 installed and then set it to be only connected to the VBox host-only network so that I could reach it from my Kali machine. I then started a sudo nmap -sV 192.168.56.107 (Debian's IP) with Wireshark listening in on the traffic. Here are screencaps of both the Wireshark and Apache access logs. Nmap identified the Apache version correctly.

apache-log

apache-sV

apache-nmap

As there is no other traffic to the Apache server (other than a localhost curl) the traffic captured by Wireshark correspond one-to-one to the access log. I think that nmap wouldn't leave that noticable of a trace it has been used if you just changed the user-agent name for the scripts. But even then, if you know what to look for you could maybe recognize the pattern of tried URL endpoints as I guess they hardly change much on the default version detection scripts.

e) Interesting services found with UDP scans

Scanning ports with the UDP protocol may yield results in finding for example DNS, SNMP, and DHCP services running on target machine according to nmap.org.

f) Why is UDP scanning unreliable

According to this blog post doing UDP port scans can be unreliable due to many services requiring a correctly formed application message to be sent, if you want a response. Many ports will thus not respond at all, making it hard to differentiate open and filtered ports. If the port is closed the you may get an ICMP error message back allowing to at least distinguish those. But ICMP error messages are nowadays rate limited to around 1 error per second, making UDP scans painfully slow.

h) ffuf

"Ffuf is an open source web fuzzing tool, inteded for discovering elements and content within web applications, or web servers", codingo.

I tried running ffuf targeting the Metasploitable 2 machine. I ran the command ffuf -c -w /usr/share/seclists/Discovery/Web-Content/common.txt -u http://192.168.56.103/FUZZ and this was my result. Ffuf found a few paths, some forbidden, some redirects and a few 200 responses.

ffuf

i) nikto

"Nikto is a free software command-line vulnerability scanner that scans webservers for dangerous files/CGIs, outdated server software and other problems.", Wikipedia. I ran nikto with nikto -host http://192.168.56.103 -output meta-nikto.txt. This produced a text file containing some info about the Metasploitable webserver. It tells that Apache is outdated and it found some interesting directories that could be further investigated (phpMyAdmin, test, phpinfo).

nikto

j) EyeWitness

EyeWitness is used to take screenshots of websites and to create a report allowing finding interesting pages faster. I created a list of URLs from the results of running ffuf and nikto to give as input for eyewitness. I then ran eyewitness -f meta-pages.txt and got this as a result. EyeWitness separated the found pages into directory listings and undefined. It also gives some basic info of the request next to the image along with a link to the page's source code. I can see that this could be used along with the other tools to generate useful reports from interesting sites fast.

eyewitness-run

eyewitness-report-1

eyewitness-report-2

Sources