Exploit Modules
Now that we are acquainted with basic MSF usage
and the usage of auxiliary modules,
let’s dig deeper into the business end of MSF: exploit modules.
Exploit modules most commonly contain exploit code
for vulnerable applications and services.
Metasploit currently contains over 2200 exploits.
Each was meticulously developed and tested,
making MSF capable of successfully exploiting a wide variety
of vulnerable services.
These exploits are invoked in much the same way as auxiliary modules.
In this example, we’ll leverage one of the exploit modules
to get access to the target system WEB18.
Let’s assume we identified
that the system runs a version of an Apache web server
that is vulnerable to CVE-2021-42013 with a vulnerability scan.
We’ll attempt to use Metasploit and its exploit modules
to exploit this vulnerability and get code execution.
Let’s create a new workspace for this section,
and search Metasploit for modules related to “Apache 2.4.49”.
The output shows that our search resulted in two matching modules.
Index 1 refers to an auxiliary module
that checks if one or more target systems are vulnerable
to the previously mentioned vulnerability.
Index 0 refers to the corresponding exploit module.
Let’s use the exploit module and enter info to review its description.
The output contains several important pieces of information
in the context of this exploit module.
Before we blindly set our target and run an exploit module,
we should always understand what the module is doing
by reviewing the module’s information.
The output starts with general information about the exploit
such as the name, platform, and architecture.
The output also contains information
about potential side effects of running this exploit module,
such as Indicators of compromise entries in log solutions,
and, in this example, artifacts on disk.
This and the module stability,
help us predict if we may crash a target system
or what information defenders may obtain from us using this exploit module.
The module reliability determines if we can run the exploit more than once.
In our example, the output states repeatable-session.
This is important as some exploit modules will only work once.
The Available targets area of the output
commonly contains different target specifications
of vulnerable targets by the exploit module.
Often these targets range from different operating systems
and application versions to command execution methods.
Most modules provide the Automatic target, which Metasploit tries to identify
either by itself or by using the default operation specified by the module.
Check supported determines if we can use the check command
to dry-run the exploit module and confirm if a target is vulnerable
before we actually attempt to exploit it.
Description provides us a text-based explanation of the module’s purpose.
According to the output of this module’s description,
it seems to be the correct module for the vulnerability
identified by the hypothetical vulnerability scan.
Now that we have an understanding of what the exploit module does
and what implications the execution of it has,
we can display its options.
The options shown are similar to the options
available for the auxiliary modules from the previous section.
However, for exploit modules,
there is an additional option section named Payload options.
If we don’t set this, the module will select a default payload.
The default payload may not be what we want or expect,
so it’s always better to set our options
explicitly to maintain tight control of the exploitation process.
We’ll cover different payloads in the next Learning Unit,
but for now we set it to a regular TCP reverse shell.
We can select a payload with set payload and the payload name,
in our case payload/linux/x64/shell_reverse_tcp.
In addition, we enter the IP address of our Kali machine for LHOST.
The output shows that the entered payload is now active for the exploit module.
There are two options for this payload named LHOST,
the local host IP address or interface, and LPORT,
the local port, these are used for the reverse shell to connect to.
By default, most exploit modules use the port
4444 in the LPORT payload option.
Depending on our machine’s configuration,
Metasploit may already set the LHOST value for us.
We should always double-check this value,
especially if our machine contains multiple interfaces,
because Metasploit may reference the wrong interface to set this value.
We should note that we don’t need to start a listener manually
with tools such as Netcat
to receive the incoming reverse shell.
Metasploit automatically sets up a listener matching the specified payload.
Now, let’s set the options SSL to false,
and RPORT to 80
since the target Apache web server runs on port 80 without HTTPS.
Then, we set RHOSTS to the target IP and enter run.
Once launched, the exploit module first starts a listener on port 4444
and uses the previously shown auxiliary module
to check if the target is indeed vulnerable.
In our case, it is vulnerable as shown in the output.
Then, the vulnerability is exploited and the payload is sent.
The console states that a session is opened,
and we have obtained command execution.
Before we head to the next section,
let’s explore the concept of sessions and jobs in Metasploit.
Sessions are used to interact and manage access
to successfully exploited targets,
while jobs are used to run modules or features in the background.
When we launched the exploit with run,
a session was created and we obtained an interactive shell.
We can send the session to the background
by pressing Control z and confirming the prompt.
Once the session is sent to the background,
we can use sessions -l to list all active sessions.
The output provides information about the target and payload in use.
This makes it easy for us to identify
which session manages access to which target.
We can interact with the session again by passing the session ID to sessions -i.
The output shows that we can again enter commands in the interactive shell.
We can kill a session with sessions -k and the ID as argument.
However, in our case we will kill all sessions with capitol K.
Instead of launching an exploit module
and sending the resulting session to the background,
we can use run -j to launch it in the context of a job.
This way, we’ll still find the output of launching the exploit module,
but we’ll need to interact with the resulting session before we can access it.
Let’s zoom out here for a moment and discuss why working with sessions and jobs
is vital in a real penetration test.
In an assessment, we’ll face numerous targets
and it is very easy to lose track of machines we already have access to.
Using an exploit framework like Metasploit helps us manage access to these machines.
If we want to execute commands on a specific system,
we don’t have to search through various terminals to find the correct
Netcat listener, we can just interact with the specific session.
We can launch exploit modules with run -j in the background and Metasploit will
automatically create a session for us while we already work on the next target.
In addition, Metasploit also stores information about targets, module results,
and vulnerabilities in the database, which are invaluable for further steps
in a penetration test and writing the report for the client.