Case study – reaching the domain controller
Recalling the basics of Metasploit, we are all set to perform our first penetration test with Metasploit. Let's consider an on-site scenario where we are asked to test an IP address and check if it's vulnerable to an attack. The sole purpose of this test is to ensure all the proper checks are in place. This scenario is quite straightforward. We will presume that all the pre-interactions have been carried out with the client and that the actual testing phase is going to start.
Please refer to the Revisiting the case study section if you want to perform the hands-on exercise while reading the case study, as this will help you emulate the entire case study with exact configuration and network details.
Gathering intelligence
As we discussed earlier, the gathering intelligence phase revolves around collecting as much information as possible about the target. This includes performing active and passive scans, which include port scanning, banner grabbing, and various other scans. The target under the current scenario is a single IP address, so here, we can skip gathering passive information gathering and continue with the active information gathering methodology only.
Let's start with the footprinting phase, which includes port scanning; banner grabbing; ping scans, to check whether the system is live or not; and service detection scans.
To conduct footprinting and scanning, Nmap proves to be one of the most excellent tools available. Reports generated by Nmap can be easily imported into Metasploit. However, Metasploit has built-in Nmap functionalities that can be used to perform Nmap scans from within the Metasploit Framework console and store the results in the database.
Tip
Refer to https://nmap.org/bennieston-tutorial/ for more information on Nmap scans.
You can refer to an excellent book on Nmap at https://www.packtpub.com/networking-and-servers/nmap-6-network-exploration-and-security-auditing-cookbook.
Using databases in Metasploit
It is always a better approach to store the results automatically 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. Using databases in Metasploit also speeds up searching and improves response time. Metasploit 5.0 relies heavily on data services such as the PostgreSQL database and web service.
In the installation phase, we learned how to initialize the database and web service for Metasploit. To check if Metasploit is currently connected to a database or a web service, we can just type in the db_status command, as shown in the following screenshot:
Figure 1.19 – Checking database connectivity status
There might be situations where we want to connect to a separate database or web service rather than the default Metasploit database. In such cases, we can make use of the db_connect -h command, as shown in the following screenshot:
Figure 1.20 – Database connect help
Let's see what other core database commands are supposed to do. The following table will help us understand these database commands:
When starting a new penetration test, it is always good to separate previously scanned hosts and their respective data from the new penetration test so that they don'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:
Figure 1.21 – Workspace overview
To add a new workspace, we can issue the workspace -a command, followed by an identifier. We should keep the identifier's name that same as that of the organization currently being evaluated, as shown in the following screenshot:
Figure 1.22 – Adding a new workspace
Here, 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. We can verify the current workspace using the workspace command, where the workspace should be in red and have * as a prefix, meaning that the workspace is in use. We will use the Chapter1 workspace in the upcoming exercises. To exploit a vulnerable target, we need to identify open ports, the services running on them, and find/develop an exploit to gain access. We'll learn how to identify open ports using Nmap within Metasploit using the db_nmap command in the next section.
Conducting a port scan with Metasploit
Using the db_nmap -sV 192.168.188.129 command, we can conduct an Nmap scan on the target system, as shown in the following screenshot:
Figure 1.23 – Conducting a port scan with Nmap from Metasploit
Here, we can see that we ran the db_nmap command twice because when we ran it the first time, the target blocked our ping request. Hence, we had to set the –Pn switch in the nmap command, which denotes a "no ping" scan. We can see we have also defined a –sV switch, which denotes a version scan. Having several services up and running, we can see that the target has port 445 open, which denotes a Windows 7-Windows 10 operating system. In the past, we have seen that exploits such as EternalBlue/EternalRomance have proven to be very successful against Windows 7, Windows Server 2008, and so on. For now, we can see that we have successfully scanned the system using the db_nmap command, which has populated the msf database with hosts and services details.
Let's view the host information using the hosts command and services with the services command, as follows:
Figure 1.24 – Port scan information saved to the database
Since we are not sure about the operating system, we can run Nmap scripts, which can aid in identifying operating systems. Luckily, we have port 445 open, which can be used to identify an OS with ease. Here, we can issue the db_nmap -Pn -p445 –script smb-os-discovery 192.168.188.129 command, as shown in the following screenshot:
Figure 1.25 – Using OS detection NSE scripts in db_nmap
As we can see, we used the smb-os-discovery script while using the –script switch in the nmap command. We can see that we have not only retrieved the OS details but the domain, forest name, FQDN, and computer name as well. Let's check if the target is vulnerable to the EternalBlue vulnerability. We can do this using Nmap scripts, Metasploit auxiliary modules, or the check mechanism in the exploit itself. Let's use the smb-vuln-ms17-010 nmap NSE script first, as follows:
Figure 1.26 – Using the SMB vulnerability detection script in db_nmap
Yeah! The target is vulnerable. We can use this exploit to gain access to the target. At this point, we have conducted a port scan, and have found many open ports, one of which is port 445. Using nmap scripts within Metasploit, we came to know that the target machine is running Windows 7 Ultimate SP1 and is vulnerable to the ms17-010 remote code execution vulnerability, which has a CVE identifier of CVE-2017-0143. We'll use these details in the next section to find a matching exploit.
Modeling threats
From the intelligence gathering phase, we know that the target is vulnerable to CVE-2017-0143, which is a remote code execution vulnerability in the SMB protocol. Let's make use of the search utility by issuing the search cve:2017-0143 command in Metasploit, as follows:
Figure 1.27 – Searching using the CVE parameter in Metasploit
We have a couple of modules for this vulnerability. We should always choose modules based on the following criteria:
- Excellent: The module will never crash the service and is generally the case for SQLi vulnerabilities, command execution, remote file inclusion, and local file inclusion.
- Great: The module has a default target setting or may automatically detect the appropriate target and use the correct configurations after performing a version check.
- Good: The module has a default target, and the vulnerability is quite common.
- Normal: The module is reliable but depends on a specific version.
- Average: The module is generally unreliable or may be difficult to exploit.
- Low: The module's exploitability is less than 50%, which means it is nearly impossible to exploit under default conditions.
Keeping these points in mind, we can see that we have an auxiliary module that identifies whether the system is vulnerable or not. Let's use auxiliary/scanner/smb/smb_ms17_010 and confirm the vulnerability once again:
Figure 1.28 – SMB vulnerability checking module in Metasploit
We can see that we loaded the module for our use with the use command and used 192.168.188.129 as the remote host by using the set RHOSTS command. We can run a module using the run command, as shown in the preceding screenshot. We can see that the target is vulnerable to the exploit.
A fundamental question here is that we already used an nmap script to confirm the vulnerability, so why are we doing this again? The answer is relatively simple; we used Metasploit-based modules because they log all the findings to the database, which isn't done by nmap. Even when we ran the OS detection script and vulnerability checking script, nothing went to the database. However, when we used the preceding module, we could see that the vulnerabilities were added to the database using the vulns command, as follows:
Figure 1.29 – The vulns and services commands in Metasploit
At this point, we have a confirmed vulnerability in the target that we can exploit to gain access to the system. Before we do this, however, let's understand the vulnerability.
Vulnerability analysis
According to the National Vulnerability Database (NVD), the SMBv1 server in some of the Microsoft Windows versions can allow remote attackers to execute arbitrary code via a crafted packet. The information is very generic and doesn't deliver any insights. Let's gain some insight from the Metasploit module, as follows:
Important Note
For more insights on the vulnerability, refer to the excellent post at: https://blog.checkpoint.com/2017/05/25/brokers-shadows-analyzing-vulnerabilities-attacks-spawned-leaked-nsa-hacking-tools/.
Exploitation and gaining access
Having read through the references, we are now ready to exploit the vulnerability. Let's load the ms17_010_eternalblue exploit module using the exploit/windows/smb/ms17_010_eternalblue command, as shown in the following screenshot:
Figure 1.30 – Configuring the EternalBlue exploit
Here, we can see that we have set the RHOSTS option to 192.168.188.129 using the set RHOSTS 192.168.188.129 command and set the payload with the windows/x64/shell/reverse_tcp command, which will provide us with a reverse connect TCP shell of the target once the target is exploited successfully:
Figure 1.31 – Configuring the EternalBlue payload handler
Here, we can see all the options required to initiate the module when using the show options command. We can see that the LHOST option is missing. We will set the LHOST option to our IP address as this option is required by the reverse TCP payloads to connect back to our system. If it doesn't know the IP to connect back, we won't be able to gain access. Since we have successfully set all the required options, let's exploit the target using the exploit –j command. Here, –j denotes that the exploit will run as a background job, as shown in the following screenshot:
Figure 1.32 – Launching the EternalBlue exploit against Windows 7
Now that the exploit is running, we will soon gain shell access, as shown in the following screenshot:
Figure 1.33 – Gaining shell access on the target Windows 7 system
With that, we have successfully gained a command shell. However, since we have gained access through the EternalBlue exploit, which can sometimes show unexpected behavior such as the shell dying, commands not running as intended, and so on, it would be better to move onto a more stable shell such as a Meterpreter shell. In Metasploit, we can upgrade a shell to Meterpreter using the sessions –u command, followed by the session ID, as shown in the following screenshot:
Figure 1.34 – From shell to Meterpreter
Here, we can see that if we issue the sessions command, we will be able to see our existing shell with the ID 1. We upgraded it using the sessions –u 1 command and can see that a new Meterpreter shell was spawned. Additionally, we can also see the access on the Meterpreter shell, which is NT AUTHORITY\SYSTEM, which is the highest level of access on the target machine.
At this point, we have port scanned a system, verified it for known vulnerabilities, and exploited it with existing Metasploit exploit module to gain a SYSTEM-level shell on the target. Remember the Nmap NSE scan that identified the OS details? It also gave us details of the Active Directory (AD) domain and forest. Now, let's dive deep into the post-exploitation phase and try to gain access to the domain controller.
Post-exploitation kung fu
Let's interact with our newly gained Meterpreter session and make our access more concrete. We can interact with a session using the session command, followed by the session identifier, which is 2 for the Meterpreter session, as shown in the following screenshot:
Figure 1.35 – Interacting with Meterpreter
We can see our user identifier using the getuid command, which is NT AUTHORITY\SYSTEM, and can also see the process ID that our Meterpreter session resides in, which is 2652. Issuing a ps command will list all the running processes on the target, as shown in the following screenshot:
Figure 1.36 – List of processes running on the target using the ps command
We can see that our current process ID is of a powershell.exe process. If an administrator sees a PowerShell process running, they can kill the process, thus killing our access as well. It's good to migrate to a process that is less likely to be killed, such as explorer.exe or any other, such as conhost.exe. Let's migrate to the conhost.exe process, which has a process ID of 2336, by issuing the migrate 2336 command, as follows:
Figure 1.37 – Migrating from the current process to a new process
We can see that using the migrate command, followed by 2336, allowed us to migrate our session to the conhost.exe process. We can confirm the current PID using the getpid command. Let's now jump into gaining access to the AD Domain Controller. First, let's gather details about the AD environment using the enum_domain post-exploitation module. However, to load this module, we need to jump outside of the Meterpreter session, which we can do using the bkground command:
Figure 1.38 – Putting Meterpreter into the background using the background command
Let's use the enum_domain module by issuing the use post/windows/gather/enum_domain command, as follows:
Figure 1.39 – Domain harvesting module in Metasploit
We only need to set one option for this module; that is, the SESSION identifier. We know that our Meterpreter session identifier is 2, so let's set this option using the set SESSION 2 command and run the module using the run command, as follows:
Figure 1.40 – Running the domain harvesting module on the target
From these results, we can see that the domain is masteringmetasploit and that the Domain Controller is WIN_DVP1KMN8CRK, where the IP address is 192.168.248.10. An interesting point to take note of here is that the IP range we are testing is 192.168.188.x and not 192.168.248.x. Also, if we try to ping or run a port scan on the 192.168.248.x range, we will get a host not reachable error. This means that we need to somehow divert all our traffic through the Meterpreter shell we gained. By interacting with the Meterpreter session again and issuing the arp command, we will see the following IP-to-MAC bindings:
Figure 1.41 – Finding IP to MAC bindings using the arp command
We can see addresses from both the ranges in the preceding results. This confirms the fact that the compromised system can communicate on both of these ranges. All we need to do now is route traffic through this compromised machine to gain further access to the network. We can use the autoroute module from Metasploit to add a route to the otherwise inaccessible range through the compromised host. We can issue the use multi/manage/autoroute command for this, as follows:
Figure 1.42 – Adding a route to the Domain Controller
Again, we only need to set the SESSION option and run the module. We can see that a route to the 192.168.188.x range, the 192.168.248.x range, and the 169.254.x.x range was automatically added by the module. We can now easily communicate with the devices on these ranges.
Sometimes, we don't need to test the systems located deep in an AD environment. Instead, we can make some smart moves to compromise them with ease. Remember when we used the ps command, which listed all the processes running on the target? You can go back to the page and locate any processes that are running with domain administrator rights:
Figure 1.43 – Administrator processes running on the compromised machine
We will see two processes running with domain administrator rights, which are powershell.exe and conhost.exe. This means that we can compromise the administrator account using the token stealing method and impersonate the domain administrator. Metasploit offers a great plugin called incognito, which allows us to list and impersonate tokens. Let's load the plugin using the load incognito command, as follows:
Figure 1.44 – Loading the incognito plugin in Meterpreter
Once the plugin has loaded, we can issue the help command and view the newly added commands at the end of the help menu, as follows:
Figure 1.45 – Incognito plugin commands overview
Since we already know that there are few of the domain administrator privileged processes running on the compromised target, we can issue the list_tokens -u command, as follows:
Figure 1.46 – Listing tokens from the compromised machines
We can see that by using the list_tokens command, followed by the –u switch, to list tokens with a unique name, we get all the delegation tokens. We can now impersonate any one of them using the impersonate_token command. Let's issue the impersonate_token MASTERINGMETASP\Administrator command, as follows:
Figure 1.47 – Impersonating administrator token
We can see that before token impersonation, our UID was NT AUTHORITY\SYSTEM. We impersonated the token using the impersonate_token command, followed by the delegation token itself, which is MASTERINGMETASP\Administrator. Issuing the impersonate_token command, we successfully impersonated the Administrator's delegation token. Issuing the getuid command again, we see that we are now the domain administrator.
To gain access to the domain controller machine, we can use the local_ps_exec post-exploitation module by issuing the use windows/local/local_ps_exec command, as shown in the following screenshot:
Figure 1.48 – Using the psexec module
Next, we will set the required options, such as SESSION, RHOSTS, and a payload, as follows:
Figure 1.49 – Configuring the psexec module
We used the bind TCP payload here since reverse TCP payloads can sometimes cause problems in the pivoting. This is because our IP is not directly in the range of the target. Let's set the payload options, as follows:
Figure 1.50 – Gaining access to the Domain Controller machine using the psexec module
We can see that we set the RHOST option to the target internal IP and ran the module. We can see that we have successfully gained Meterpreter shell access to the Domain Controller system through the 192.168.188.129 system.
Let's issue the getuid command and see what access level we have:
Figure 1.51 – Checking the UID on the Domain Controller
We are NT AUTHORITY\SYSTEM and can probably do almost anything on the target machine. Using the ipconfig command, we can view the network IP details of the target, as follows:
Figure 1.52 – Using the ipconfig command
Next, we can dump all the password hashes for all the users of the Active Directory using the smart_hashdump module by issuing the use post/windows/gather/smart_hashmp command, as follows:
Figure 1.53 – Dumping password hashes from the Domain Controller
We only needed to set the SESSION option for the preceding module. Here, we can see we have dumped all the password hashes. At this point, we can also try to gain access to the clear password credentials by dumping them from memory using either the mimikatz or kiwi plugin from the Metasploit Framework, as follows:
Figure 1.54 – Loading the mimikatz and kiwi plugins in Meterpreter
The load mimikatz command loaded the mimikatz plugin. It also suggests that we use the kiwi plugin. We can load kiwi using the load kiwi command, as shown in the preceding screenshot. Successfully loaded plugins will have their options added to the help menu, as we saw previously with the incognito plugin.
Let's see what options we have by issuing the help command, as follows:
Figure 1.55 – Mimikatz and kiwi commands overview
We can see that both plugins added several commands to the help menu. Let's try running the kerberos command from the mimikatz menu (one at the top), as follows:
Figure 1.56 – Dumping passwords in clear test using the kerberos command
Here, we can see that the user Apex has a password of Nipun@nipun18101988. Using the creds_all command from the kiwi plugin will also populate a variety of credentials, as follows:
Figure 1.57 – Dumping passwords in clear text using the creds_all command
Throughout this exercise, we saw how we could gain access to a Domain Controller on a completely separate network range through a compromised machine in the Active Directory environment. We saw how we could verify the presence of a particular vulnerability through the Nmap and Metasploit modules. We covered pivoting to an internal Domain Controller by making use of the compromised machine as a launchpad.
Furthermore, we saw how we could enumerate credentials in plain text. We could have done more. For example, we could have tested all the ports we initially found in the Nmap scan and could have scanned the Domain Controller as well. I leave this as an exercise for you to complete as covering all the vulnerabilities in the target host will push us beyond the scope of this book. However, we will be performing a complete penetration test to find all the hidden services and exploit them in Chapter 6, Virtual Test Grounds and Staging. Now, let's recap what we performed.