Using databases in Metasploit

It is always a better approach to store the results automatically alongside when you conduct a penetration test. Making use of databases will help us build a knowledge base of hosts, services, and the vulnerabilities in the scope of a penetration test. To achieve this functionality, we can use databases in Metasploit. Connecting a database to Metasploit also speeds up searching and improves response time. The following screenshot depicts a search when the database is not connected:

We saw in the installation phase how we can initialize the database for Metasploit and start it. To check if Metasploit is currently connected to a database or not, we can just type the db_status command, as shown in the following screenshot:

There might be situations where we want to connect to a separate database rather than the default Metasploit database. In such cases, we can make use of db_connect command, as shown in the following screenshot:

To connect to a database, we need to supply a username, password, and a port with the database name along with the db_connect command.

Let's see what other core database commands are supposed to do. The following table will help us understand these database commands:

Starting a new penetration test, it is always good to separate previously scanned hosts and their respective data from the new pentest so that it doesn't get merged. We can do this in Metasploit before starting a new penetration test by making use of the workspace command, as shown in the following screenshot:

To add a new workspace, we can issue the workspace -a command, followed by an identifier. We should keep identifiers as the name of the organization currently being evaluated, as shown in the following screenshot:

We can see that we have successfully created a new workspace using the -a switch. Let's switch the workspace by merely issuing the workspace command followed by the workspace name, as shown in the preceding screenshot. Having the workspace sorted, let's quickly perform a Nmap scan over the target IP and see if we can get some exciting services running on it:

The scan results are frankly heartbreaking. No services are running on the target except on port 80.

By default, Nmap scans the top 1000 ports only. We can use -p- switch to scan all the 65535 ports.

Since we are connected to the Metasploit database, everything we examine gets logged to the database. Issuing services commands will populate all the scanned services from the database. Also, let's perform a version detection scan through db_nmap using the -sV switch, as shown in the following screenshot:

The previous Nmap scan found port 80 and logged it in the database. However, the version detection scan found the service running on port 80 which is Apache 2.4.7 Web Server, found the MAC address, the OS type, and updated the entry in the database, as shown in the preceding screenshot. Since gaining access requires explicitly the exact exploit targeting a particular version of the software, it's always good to perform a double check on the version information. Metasploit contains an inbuilt auxiliary module for HTTP version fingerprinting. Let's make use of it, as shown in the following screenshot:

To launch the http_version scanner module, we issue the use command followed by the path of the module, which in our case is auxiliary/scanner/http/http_version. All scanning-based modules have the RHOSTS option to incorporate a broad set of IP addresses and subnets. However, since we are only testing a single IP target, we specify RHOSTS to the target IP address, which is 192.168.174.132 by using the set command. Next, we just make the module execute using the run command, as shown in the following screenshot:

This version of Apache is precisely the version we found in the previous Nmap scan. This version of Apache web server running on the target is secure, and none of the public exploits are present at exploit databases such as exploit-db.com and 0day.today. Hence, we are left with no other option than looking for vulnerabilities in the web application, if there are any. Let's try browsing this IP address and see if we can find something:

Well! We have an index page, but there is no content. Let's try to look for some known directories by making use of the dir_scanner module from Metasploit, as we can see following screenshot:

After loading the auxiliary/scanner/http/dir_scanner module, let's provide it with a dictionary file containing a list of known directories by setting the path in the DICTIONARY parameter. Also, we can speed up the process by increasing the number of threads by setting the THREADS parameter to 20 from 1. Let's run the module and analyze the output:

The space character between the inpidual directory entries has yielded a lot of false positives. However, we got 302 response code from a phpcollab directory, which indicated that while trying to access phpcollab directory, the module got a response to redirect (302). The response is interesting; let's see what we get when we try to open the phpcollab directory from the browser:

Nice! We have a PHP-based application running. Hence, we got a 302 response in the Metasploit module.