Target mapping
The traditional nmap of the entire port range, with service discovery, is always a good place to start when gathering information on a target. Nmap is the network scanning tool of choice and has been for many years. It is still very powerful and very relevant. It is available on most platforms, including Kali, BlackArch, and even Windows.
Metasploit Framework (MSF) is a penetration testing framework commonly used by security professionals. Besides being a fantastic collection of easy-to-deliver exploits, it can also help to organize engagements. For target mapping specifically, you can leverage the workspace feature and neatly store your Nmap scan results in a database.
If the Kali Linux instance is fresh or Metasploit was recently installed, the database may need a kick to get it going.
In the Kali console prompt, start the PostgreSQL service using the service command. If successful, there should be no message returned:
root@kali:~# service postgresql start root@kali:~#
Metasploit can then be started using the msfconsole command, which will drop us into a sub-prompt, prefixed with msf instead of the traditional bash prompt:
root@kali:~# msfconsole [...] msf > db_status [*] postgresql selected, no connection msf >
The preceding series of commands will start the PostgreSQL database service, which Metasploit uses for storage. The Metasploit console is launched and we can check the database status using MSF's db_status command.
We can use the exit command to return to the bash terminal:
msf > exit
root@kali:~#
We can now use the Metasploit msfdb command to help us initialize (init) the database:
root@kali:~# msfdb init Creating database user 'msf' Enter password for new role: Enter it again: Creating databases 'msf' and 'msf_test' Creating configuration file in /usr/share/metasploit-framework/config/database.yml Creating initial database schema root@kali:~#
The msfdb command creates all of the necessary configuration files for Metasploit to be able to connect to the database. Once again, we can start the Metasploit console using the msfconsole command in the Linux prompt:
root@kali:~# msfconsole
[...]
msf >
The YML database configuration file, created with the msfdb init command, can be passed to the db_connect Metasploit console command as with the -y switch:
msf > db_connect -y /usr/share/metasploit-framework/config/database.yml
[*] Rebuilding the module cache in the background...
msf > db_status
[*] postgresql connected to msf
msf >
We can now create a workspace for the target application, which will help us to organize results from various MSF modules, scans, or exploits:
msf > workspace -a target1 [*] Added workspace: target1 msf > workspace default * target1
The workspace command without any parameters will list the available workspaces, marking the active one with an asterisk. At this point, we can start an Nmap scan from within MSF. The db_nmap MSF command is a wrapper for the Nmap scanning tool. The difference is that the results of the scan are parsed and stored inside the Metasploit database for easy browsing.
MSF's db_nmap takes the same switches as the normal nmap. In the following example, we are scanning for common ports and interrogating running services.
The target for this scan is an internal host, 10.0.5.198. We are instructing Nmap to perform a service scan (-sV) without pinging hosts (-Pn), and using verbose output (-v):
msf > db_nmap -sV -Pn -v 10.0.5.198
[...]
[*] Nmap: Scanning 10.0.5.198 [1000 ports]
[*] Nmap: Discovered open port 3389/tcp on 10.0.5.198
[*] Nmap: Discovered open port 5357/tcp on 10.0.5.198
[*] Nmap: Completed SYN Stealth Scan at 19:50, 12.05s elapsed (1000 total ports)
[*] Nmap: Initiating Service scan at 19:50
[...]
Once the scan completes, the results can be queried and filtered using the services command. For example, we can look for all HTTP services discovered by using the -s switch:
msf > services -s http Services ======== host port proto name state info ---- ---- ----- ---- ----- ---- 10.0.5.198 5357 tcp http open Microsoft HTTPAPI httpd 2.0 SSDP/UPnP
Note
Take note of the scope provided by the client. Some will specifically constrain application testing to one port, or sometimes even only one subdomain or URL. The scoping call is where the client should be urged not to limit the attack surface available to the tester.
Masscan
Nmap is fully featured, with a ton of options and capabilities, but there is one problem: speed. For large network segments, Nmap can be very slow and sometimes can fail altogether. It's not unusual for clients to request a penetration test on a huge IP space with little time allotted for the mapping and scanning phase.
The claim to fame of masscan is that it can scan the internet IP space in about six minutes. This is an impressive feat and it is certainly one of the fastest port scanners out there.
During an engagement, we may wish to target web applications first and masscan can quickly return all open web ports with just a couple of switches.
The familiar -p switch can be used to specify a series, or range, of ports to look for. The --banners switch will attempt to retrieve some information about any open ports that are discovered. For larger IP spaces, where time is of the essence, we can use the --rate switch to specify a large packet per second number, such as a million or more:
Figure 2.1: A masscan of the 10.0.0.0/8 network
We can see that the preceding scan was cancelled early with the Ctrl + C interrupt, and masscan saved its progress in a paused.conf file, allowing us to resume the scan at a later time. To pick up where we left off, we can use the --resume switch, passing the paused.conf file as the parameter:
Figure 2.2: Resuming a masscan session
Masscan's results can then be fed into either Nmap for further processing, or a web scanner for more in-depth vulnerability discovery.
WhatWeb
Once we've identified one or more web applications in the target environment with masscan or Nmap, we can start digging a bit deeper. WhatWeb is a simple, yet effective, tool that can look at a particular web application and identity what technologies have been used to develop and run it. It has more than 1,000 plugins, which can passively identify everything from what content management system (CMS) is running on the application, to what version of Apache or NGINX is powering the whole thing.
The following diagram shows a more aggressive (-a 3) scan of bittherapy.net with WhatWeb. The sed command shown will format the output to something a bit easier to read:
Figure 2.3: Running WhatWeb and filtering the results
A level-3 aggression scan will perform several more requests to help to improve the accuracy of results.
WhatWeb is available on Kali Linux and most other penetration testing distributions. It can also be downloaded from https://github.com/urbanadventurer/WhatWeb.
Nikto
Nikto provides value during the initial phases of the engagement. It is fairly non-intrusive and with its built-in plugins, it can provide quick insight into the application. It also offers some more aggressive scanning features that may yield success on older applications or infrastructure.
If the engagement does not require the attackers to be particularly stealthy, it doesn't hurt to run through the noisier Nikto options as well. Nikto can guess subdomains, report on unusual headers, and check the robots.txt file for interesting information:
Figure 2.4: A standard scan of the example.com domain
Nikto outputs information on the HTTPS certificate, the server banner, any security-related HTTP headers that may be missing, and any other information that may be of interest. It also noticed that the server banner had changed between requests, indicating that a WAF may be configured to protect the application.
Nikto can be downloaded from https://github.com/sullo/nikto. It is also available in most penetration testing-focused Linux distributions, such as Kali or BlackArch.
CMS scanners
When the target is using a CMS, such as Joomla, Drupal, or WordPress, running an automated vulnerability testing tool should be your next step.
WordPress is a popular CMS because it provides plugins for almost any type of site, making it very customizable and widely-adopted, but also complex, with a large attack surface. There are tons of vulnerable plugins, and users typically don't upgrade them frequently.
During a test, you may find a remotely exploitable vulnerability in one of the plugins that provides a shell, but more often than not, WordPress is a treasure trove of information. Usernames can be enumerated, passwords are often weak and easily brute-forced, or directory indexing may be enabled. The WordPress content folder sometimes also contains sensitive documents uploaded "temporarily" by the administrator. In later chapters, we will see how an improperly configured WordPress instance can be leveraged to attack the application server and move laterally through the network.
WordPress is not alone in this space. Joomla and Drupal are also very popular and sport many of the same vulnerabilities and configuration issues that are seen in WordPress installations.
There are a few scanners available for free that aim to test for low-hanging fruit in these CMSs:
- WPScan (aimed at testing WordPress installations
- JoomScan (CMS scanner specializing in Joomla testing
- droopescan (scanner with some support for Joomla
- CMSmap (supporting WordPress, Joomla, and Drupal
Note
Before proceeding with a WordPress scan, make sure that it is hosted inside the engagement scope. Some CMS implementations will host the core site locally, but the plugins or content directories are on a separate content delivery network (CDN). These CDN hosts may be subject to a penetration testing notification form before they can be included in the test.
We will cover CMS assessment tools, such as WPScan, in more detail in later chapters.