With Kali installed and an isolated lab to practice in (07-01), we open the first major tool in its toolkit. During the TechNova S.L. audit we turned to Metasploit several times: in Module 4 we used it to exploit a vulnerable network service on the 10.10.10.0/24, and in Module 5 its Meterpreter payload gave us the console we used for post-exploitation, pivoting, and privilege escalation. We used it in passing, focused on the method. Now it is time to master it in depth.

This lesson breaks down Metasploit's architecture (msfconsole, the module types, Meterpreter, msfvenom, the database, and workspaces), its canonical workflow (search → use → options → run) applied responsibly against the TechNova lab, the use of Meterpreter for post-exploitation, and its integration with the database and with Nmap. Like any offensive tool, Metasploit is used only against authorized targets or your own lab, and with impact under control: you will see why running check before exploit is a professional habit.

1. What Metasploit is and its editions
2. Architecture: msfconsole, modules, and the database
3. Module types
4. The workflow: search → use → options → run
5. A responsible example against the TechNova lab
6. Meterpreter and post-exploitation
7. msfvenom: generating payloads
8. Integration with Nmap and the database
9. Common Mistakes and Tips
10. Exercises
11. Conclusion

Metasploit Framework is an open-source platform (Rapid7) for developing, testing, and running exploits. Its great contribution is standardization: hundreds of exploits, payloads, and auxiliary modules share the same interface, so learning the workflow once serves you for all of them.

Kali ships with the Framework preinstalled. Everything in this lesson is done with msfconsole, the interactive console.

Metasploit is organized around a console that loads modules and leans on a database to remember the work.

• msfconsole: the main interface. From it you search for, configure, and launch modules.
• Database (PostgreSQL): stores discovered hosts, ports, services, vulnerabilities, and credentials. Workspaces separate work by project (a technova workspace so you do not mix clients).
• msfvenom: a separate tool for generating standalone payloads (an executable, a script).

Start the database and create the engagement's workspace:

Working in one workspace per client is a good organizational practice that ties directly to the documentation from Module 6: everything Metasploit discovers is recorded and exportable.

Understanding the five module types is understanding Metasploit.

Key relationship: an exploit opens the door and delivers a payload; the most powerful payload is Meterpreter; afterward you use post modules. The auxiliary modules are a Swiss army knife and do not always involve exploiting (many just scan or check).

Metasploit's canonical workflow always has the same shape. Master these five steps and you will know how to use any module.

1. search — locate the right module.
2. use — select it.
3. options / info — see what it needs.
4. set — configure the target, payload, and parameters.
5. check / run (exploit) — verify and execute.

The parameters RHOSTS (remote target), LHOST/LPORT (your Kali, where the connection comes back), and payload are the ones you will configure most often. info shows the full description, the CVE, and the module's options.

Responsible use — check before exploit: many exploits offer check, which tests whether the target is vulnerable without actually exploiting it. It is the prudent option: it confirms the diagnosis with minimal impact, something essential in a real engagement where an exploit can take down a production service. First check; only if appropriate and authorized, exploit.

We reproduce, against a VM in our lab that simulates a TechNova server, the kind of network exploitation from Module 4. The victim VM has the IP 10.10.10.20 and Kali 10.10.10.5.

What just happened, step by step:

• db_nmap runs Nmap and dumps the results into the workspace database: hosts and services are recorded without typing anything by hand.
• search with filters (name:, type:) narrows down among thousands of modules.
• check confirms the VM is vulnerable before touching it.
• exploit launches the module and opens a session.

All of this is legal because 10.10.10.20 is a machine that is yours on the host-only lab network. Against a real system, you would need written authorization and impact control.

Meterpreter is Metasploit's flagship payload: an advanced console that lives in the memory of the compromised process, encrypts its communication, and offers dozens of post-exploitation commands without writing binaries to disk. It is what we used in Module 5.

To get it, you select it as the payload before exploiting:

Common Meterpreter commands and what they do:

reverse_tcp means the victim connects back to you (which is why you configure LHOST/LPORT), and this usually gets through outbound firewalls better than a direct connection. With the session in background you can launch post modules or pivot into other subnets, exactly as we did on the 10.10.10.0/24.

msfvenom generates standalone payloads (a .exe, an .elf, a script) for scenarios where there is no direct remote exploit: for example, a file delivered in an authorized social engineering exercise. It combines generation and encoding in a single tool.

• -p selects the payload; LHOST/LPORT indicate where the session comes back.
• -f exe defines the output format; -o the file.

To receive the session that payload generates, you set up a listener with the multi/handler module:

Responsible use: a binary like this is only run in your lab or in an exercise with an authorized scope and explicit consent. Outside of that, distributing a payload is malicious activity. Defensive angle: antivirus/EDR detect unobfuscated msfvenom payloads; understanding this helps the blue team fine-tune its detection rules.

Metasploit's strength in a long engagement is that it remembers. With the database active:

You can also import a scan done outside with db_import scan.xml (Nmap with -oX). All that information (hosts, services, credentials, loot) is exactly what feeds the findings documentation from Module 6: exportable, organized by workspace, and traceable. Metasploit is not just an exploit launcher; it is also the engagement's field notebook.

• Running exploit without check. An exploit can take down a real service. Verify first with check and control the impact.
• Confusing LHOST and RHOST. RHOSTS is the target; LHOST is your Kali (where the session comes back). Swapping them makes the exploit "not work" for no apparent reason.
• Working without a database or workspace. You lose traceability and mix clients. Run msfdb init and create one workspace per engagement.
• A payload incompatible with the target. A Windows payload against a Linux target will not open a session. Match the payload to the platform (options/show payloads).
• Using msfvenom outside the lab. Distributing payloads without authorization is malicious activity. Restrict it to your lab or a signed scope.
• Tip: make info and check a reflex before every exploit. Reading what a module does and confirming that the target is vulnerable is the difference between a professional and someone firing blind.

Exercise 1. In your lab you have a victim VM at 10.10.10.20 and Kali at 10.10.10.5. Write the full msfconsole sequence to: create a technova workspace, scan the victim while importing the result into the database, search for an exploit for the vulnerable service, verify that it is exploitable, and, if so, launch it. State which parameters you configure.

Exercise 2. Explain the difference between an exploit, an auxiliary, and a post module, and give an example of when you would use each during the TechNova audit.

Exercise 3. You want to use msfvenom to generate a Windows executable that gives you back a Meterpreter session on your lab Kali. Write the generation command and the commands to set up the listener that receives the session. Add a sentence about why this is legitimate only in your lab.

Solution 1.

I set RHOSTS to the authorized target (my VM). If the exploit returns a reverse shell, I would also set LHOST 10.10.10.5 and LPORT. db_nmap saves hosts and services in the workspace, and check confirms the vulnerability before exploiting, keeping the impact under control.

Solution 2. An exploit takes advantage of a vulnerability to gain access (e.g., exploiting TechNova's vulnerable network service on the VM). An auxiliary performs tasks without exploiting: scanning ports, fuzzing, or testing credentials (e.g., a scanner to enumerate services). A post module acts after compromise, with a session already open: collecting information, dumping hashes, or preparing to pivot into the 10.10.10.0/24. In the engagement's time order: first auxiliary/recon, then exploit, then post.

Solution 3.

It is legitimate only in my lab (or under a scope authorized in writing with explicit consent) because generating and running a payload that opens a backdoor on another system without permission is a malicious and illegal act.

Metasploit is far more than an exploit launcher: it is a framework with a coherent architecture (msfconsole, five module types, Meterpreter, msfvenom, and a database with workspaces) that standardizes all offensive work under a single workflow: search → use → options → check → run. We saw that workflow applied responsibly against the TechNova lab, how Meterpreter enables the post-exploitation we did in Module 5, how msfvenom generates standalone payloads, and how the integration with Nmap and the database turns Metasploit into the engagement's field notebook, feeding directly into the Module 6 report. And one habit that sums it all up: check before exploit, because controlling the impact is as professional as the attack's success.

Having mastered the framework for exploiting networks and systems, we change terrain. The store tienda.technova.lab was a web application, and to audit it thoroughly you need a different instrument: an intercepting proxy. In the next lesson we study the industry standard, Burp Suite.