Metasploit practice questions

Set RHOST to the target IP address

Why it fails: In a reverse TCP listener, the handler acts as a server waiting for an incoming connection, so setting RHOST is irrelevant. RHOST is typically used in exploit modules to define the destination target, but the handler module only needs to know where to bind locally for incoming connections.

Execute the exploit with the -e flag

Why it fails: The -e flag is not a standard command for the handler module. While encoding is a feature in Metasploit, it is handled during the payload generation phase, not by the handler listener. Adding this flag will cause the command to fail because the handler module does not recognize it.

Set the TARGET architecture to x64 only

Why it fails: While architecture is important, forcing x64 is not a requirement for a handler. The handler can accept connections from various architectures depending on the payload chosen. Restricting it to x64 would prevent successful connections from x86 targets, leading to failed exploitation attempts and unnecessary troubleshooting during the engagement.

post/windows/gather/hashdump

Why it fails: While this module dumps the local SAM database, it only provides NTLM hashes, which must be cracked or used for pass-the-hash attacks. It is effective for local accounts but lacks the capability to retrieve cleartext credentials from memory, which is often required for moving laterally across a modern Windows domain.

exploit/windows/local/bypassuac

Why it fails: This module is used for privilege escalation by bypassing User Account Control, not for gathering credentials. While it is a necessary step to gain the permissions required to dump credentials, it does not perform the actual extraction of passwords or hashes from the system memory or registry.

auxiliary/scanner/smb/smb_login

Why it fails: This module is designed for password spraying or credential brute-forcing against SMB services. It is an active scanning tool used during the reconnaissance phase, not a post-exploitation module used to extract credentials from a system where a Meterpreter session has already been established by the penetration tester.

Enable persistent backdoor installation

Why it fails: While there are scripts to install persistence, 'persistent backdoor installation' is not a native single command in Meterpreter. It requires specific post-modules or manual configuration of registry keys and services. Treating it as a single native command is incorrect and ignores the complexity of setting up reliable system persistence.

Update the host operating system

Why it fails: Meterpreter cannot update the host's operating system. Its purpose is to provide control for exploitation, not to perform administrative patching tasks. Attempting to run system update commands through a shell will usually fail due to permission restrictions or the lack of an interactive update service accessible via shell.

PAYLOAD

Why it fails: Payloads are irrelevant for auxiliary modules because these modules do not exploit the target. A payload is only needed when using an exploit module to establish a shell. Adding a payload to an auxiliary scanner is unnecessary and could potentially cause configuration errors or module execution failures.

SESSION

Why it fails: The SESSION setting is only used by post-exploitation modules to specify which active session the commands should be executed against. Auxiliary scanners operate over the network, independently of any established session, so providing a session ID would be incorrect and would likely prevent the scan from executing altogether.

ENCODER

Why it fails: Encoders are used to obfuscate payloads to evade antivirus detection during exploitation. They have no place in auxiliary scanning modules, which send standard, non-malicious protocol probes to identify services or vulnerabilities. Using an encoder here would likely corrupt the protocol probes and result in inaccurate or incomplete scan data.

execute -f powershell.exe -a "-Command"

Why it fails: Using execute -f powershell.exe -a "-Command" launches a new PowerShell process on the target, but the command string must be provided locally on the target. It does not natively pull a script from the attacker's machine, so the tester would need to embed the entire script in the command line or stage it to disk, which violates the no-disk-write requirement.

powershell_import

Why it fails: The powershell_import command loads a PowerShell script into the current session so that its functions can be called later, but it does not execute the script or run it in memory by itself. The tester would still need to invoke a function from the imported script, which does not meet the requirement of executing the script directly from the attacker's machine without writing to disk.

upload

Why it fails: The upload command transfers a file from the attacker's machine to the target's filesystem, which explicitly writes the script to disk. This contradicts the requirement to avoid writing the script to disk on the target, and it also does not execute the script after uploading it.

portfwd add -l 10.10.20.0 -p 24 -r 10.10.20.0

Why it fails: portfwd forwards a single TCP or UDP port from the attacker to a specific host and port through the session. It does not add a network route, and its syntax expects a local port and a remote host/port, not a CIDR subnet. Using portfwd for an entire subnet is impractical because you would need one forward per port per host.

autoroute 10.10.20.0/24

Why it fails: autoroute is a Meterpreter script that can automatically add routes for networks reachable from the compromised host, but it requires a specific session context and does not accept a bare subnet argument the way the question describes. The direct, built-in command for manually adding a route is route add, not autoroute, which is often used as a convenience wrapper.

ip route add 10.10.20.0/24 via <session_id>

Why it fails: ip route add is a Linux command used to modify the attacker's own operating system routing table, not Metasploit's internal route table. Even if run on the attacker host, it would not direct Metasploit modules through the Meterpreter session, because Metasploit uses its own routing mechanism inside the framework rather than relying on the host OS routes.

portfwd add -l 10.10.10.0 -p 255.255.255.0 -r 1

Why it fails: The portfwd command forwards a specific TCP or UDP port from the attacker to a target host, not an entire subnet. The syntax provided is invalid because -l expects a local port number, not a network address, and -p expects a port, not a netmask. It cannot route traffic for a whole subnet and will fail.

run autoroute -s 10.10.10.0/24

Why it fails: The run autoroute command is used inside a Meterpreter session to execute the autoroute script, but it requires the -s flag with a subnet, and it must be run after the session is active. However, the autoroute script is deprecated in favor of the post/multi/manage/autoroute module, and the command syntax shown may not work in current Metasploit versions. It is less reliable than the module approach.

route add 10.10.10.0 255.255.255.0 1

Why it fails: The route add command adds a route to the Metasploit routing table, but it must be run from the msfconsole prompt after backgrounding the session, not inside the Meterpreter session. Running it inside Meterpreter will produce an error because route is not a valid Meterpreter command. The syntax also requires the session ID, which is correct here, but the context is wrong.

powershell_import

Why it fails: powershell_import is used to load a PowerShell script into the current Meterpreter session's memory so it can be invoked with powershell_execute or similar. It does not execute a script file that already resides on the target filesystem at a given path, so it does not meet the requirement of running C:\\Tools\\enum.ps1 from disk.

load powershell

Why it fails: load powershell loads the PowerShell extension into the Meterpreter session, enabling related commands such as powershell_execute and powershell_import. By itself it does not execute any script, so it does not run C:\\Tools\\enum.ps1. It is a preparatory step, not the execution command.

run post/windows/manage/powershell/exec_powershell

Why it fails: The post/windows/manage/powershell/exec_powershell module can execute PowerShell, but it is a post module run from the Metasploit console, not a Meterpreter command. It requires specifying SESSION and other options, and it is not the direct Meterpreter command used to run a local script file on the target in the current session.

The LHOST and LPORT were set with the -o option instead of the required --lhost and --lport flags.

Why it fails: msfvenom uses LHOST and LPORT as payload options, typically set with the -o option? Actually, msfvenom uses -o for output file, and payload options are set with the -p payload and then options like LHOST= and LPORT= after the payload name, or via --payload-options. There is no --lhost flag. The scenario says the tester wants the payload to connect back, implying LHOST and LPORT were set, but even if set incorrectly, the payload might still execute and just fail to connect, not fail to run.

The -e encoder option was omitted, so the payload was not encoded and therefore blocked by Windows Defender.

Why it fails: The scenario explicitly states there is no antivirus on the target, so encoding to evade antivirus is irrelevant. While encoders can sometimes help with bad characters, they are not required for basic execution. Omitting an encoder would not cause a payload to fail to execute on a system without antivirus; the issue is more likely architecture or format related.

The -f exe format option was not specified, so the output was not a valid executable.

Why it fails: If the -f option were omitted, msfvenom would default to a raw format, and the file would likely not be a valid PE executable. However, the scenario states the tester generated a Windows executable payload, implying the format was set. While format errors can cause execution failure, the more common and subtle issue in this scenario is the architecture mismatch, which is not addressed by the format option.

Set the PAYLOAD option to windows/meterpreter/reverse_tcp.

Why it fails: The windows/meterpreter/reverse_tcp payload uses plain TCP, not HTTPS. While it is a reverse payload, it does not provide the HTTPS encapsulation needed to bypass egress filtering that inspects traffic. The scenario specifically requires reverse HTTPS, so this payload is inappropriate and would likely be blocked.

Set the RHOST option to the target's IP address.

Why it fails: RHOST specifies the target's IP address for the exploit module. While it is necessary for the exploit to run, it is not directly related to configuring the reverse HTTPS payload's callback. The question focuses on ensuring the payload connects back correctly, which depends on LHOST and LPORT, not RHOST.

Set the ExitOnSession option to false.

Why it fails: ExitOnSession controls whether the handler exits after a session is established. Setting it to false keeps the listener running for multiple sessions, which is useful for handling multiple targets, but it is not required for the initial reverse HTTPS connection to succeed. It does not affect the payload's ability to connect back.

Background the Meterpreter session and use the autoroute post-exploitation module.

Why it fails: The autoroute module can automatically add routes for networks reachable from the session, but it is not strictly required if you manually add routes with route add. Moreover, autoroute is typically run from the Metasploit console after backgrounding the session, but the question asks for actions to enable routing; route add is the direct method. Using autoroute is an alternative, but not a mandatory step in addition to route add.

Configure a SOCKS proxy server using the auxiliary/server/socks4a module and set the Proxies option in the scanning module.

Why it fails: While a SOCKS proxy can be used to route traffic from external tools, Metasploit modules themselves use the internal route table, not a SOCKS proxy, for pivoting. Setting up a SOCKS proxy is an extra step for using non-Metasploit tools, but it is not required for Metasploit modules to route through the session. The question specifically asks about enabling Metasploit modules, so this is not needed.

Set the RHOSTS option of the scanning module to the target subnet and set the Proxies option to the Meterpreter session.

Why it fails: Metasploit modules do not use a Proxies option to specify a Meterpreter session for routing. Routing is handled by the framework's route table, not by per-module proxy settings. While you do set RHOSTS to the target subnet, you do not set a Proxies option to the session; that would be incorrect and would not enable pivoting.

execute -f powershell.exe -a "-File C:\Temp\cleanup.ps1"

Why it fails: The execute command can launch powershell.exe with arguments, but this spawns a separate PowerShell process and does not integrate with Meterpreter's PowerShell extension. It bypasses the intended in-session scripting interface and may trigger additional process creation events. For loading a local script into the current session, the dedicated extension load is preferred.

import C:\Temp\cleanup.ps1

Why it fails: import is not a valid Meterpreter command in this context; it is not a built-in session command for loading PowerShell files. Even after the PowerShell extension is loaded, the correct subcommand is powershell_import, not a bare import. Using import alone would produce an unknown command error, so it cannot execute the script.

run post/windows/manage/powershell/exec_powershell

Why it fails: This post module exists but is designed to execute PowerShell code or a script via a new process and does not directly load a local .ps1 path as a built-in command. It also spawns a separate PowerShell process rather than loading the script in the current session context, and it is a module invocation, not a Meterpreter command. For simply loading an existing script file the dedicated load command is the intended tool.

exploit

Why it fails: While exploit modules can target local vulnerabilities, they are typically used for remote exploitation. Local privilege escalation in Metasploit is usually handled by post-exploitation modules that run within an existing session. Using a standalone exploit module would require separate configuration and may not integrate with the current session.

auxiliary

Why it fails: Auxiliary modules perform scanning, fuzzing, and other tasks but do not exploit vulnerabilities to gain access or escalate privileges. They cannot execute a payload or provide a shell. Therefore, they are not suitable for local privilege escalation on a compromised host.

payload

Why it fails: Payload modules are the code that runs on the target after exploitation, such as Meterpreter or a shell. They do not themselves perform privilege escalation; they provide the session that post modules can then use. A payload alone cannot exploit a local vulnerability to escalate privileges.

set RHOSTS 10.10.10.0/24

Why it fails: set assigns a value only to the currently active module's datastore, not globally. If used before a module is selected, it may fail or apply to the wrong context. Because the requirement is to apply the target range across all modules, the global variant setg is needed instead. This option is a plausible but incorrect substitute.

run auxiliary/scanner/portscan/tcp

Why it fails: The run command in a resource script executes the currently selected module; it does not accept a module path as an argument in the way this option suggests. To launch a specific module you must first use use with the full module path, then issue run. This option misuses run and would not correctly start the intended auxiliary scanner.

loadportscan

Why it fails: loadportscan is not a valid Metasploit resource script command. The load command is used for extensions such as powershell, not for launching scanners. This option is a fabricated command that would produce an error if placed in a resource script, so it cannot fulfill either requirement.

exploit -j

Why it fails: The -j flag runs an exploit as a background job, but it does not interact with existing sessions. While it prevents the console from being blocked by a specific task, it does not provide the interactive command line interface necessary to control the compromised host after the initial payload activation.

run -s

Why it fails: The run command is typically used to execute internal scripts or modules against a session, but it is not the mechanism for switching the console focus to an interactive session. Using this flag incorrectly will likely result in an error as the console expects specific module arguments instead.

use -session

Why it fails: There is no 'use -session' command in Metasploit. The 'use' command is exclusively reserved for selecting exploit, auxiliary, or post modules. Attempting to use this syntax will return a module not found error because the framework does not recognize this as a valid session management directive.

The RHOSTS value is configured incorrectly

Why it fails: The RHOSTS value is clearly set to the target IP address. The scanner successfully connected to that IP and confirmed the vulnerability. Therefore, the connection is not the issue; the failure resides within the exploit payload's interaction with the target's specific system state during the final execution phase.

The exploit module requires an active session

Why it fails: Exploit modules like EternalBlue are designed to create the initial session, not rely on existing ones. Requiring an active session before running this module is illogical. The error message indicates a failure to trigger the vulnerability, which is a common occurrence with complex memory-corruption exploits in production environments.

The listener port is already in use by another process

Why it fails: If the listener port were in use, Metasploit would throw a specific socket binding error immediately upon starting the exploit. The output shows the listener started successfully, meaning the conflict is not with the local network configuration but with the target's response to the exploit attempt itself.

To perform network scanning

Why it fails: Network scanning is handled by auxiliary modules, not the Meterpreter payload. Meterpreter is the result of a successful exploit; its primary function is to provide post-exploitation control over the target system, such as executing commands, stealing files, or migrating processes, rather than conducting discovery scans on other network hosts.

To encode payloads for bypass

Why it fails: Payload encoding is a technique used to obfuscate code to evade antivirus, and it is usually done with tools like msfvenom. While Meterpreter can be encoded, the payload itself is not a tool for encoding; it is the final code that executes after the initial exploit has successfully delivered it.

To generate shellcode for hardware

Why it fails: Meterpreter does not generate shellcode for hardware; it is a specific payload that must be delivered to a target. Shellcode generation for specific architectures is typically performed during the exploit development or payload creation phase using utilities like msfvenom, but that is a separate process from the Meterpreter payload itself.

The SMB credentials provided are incorrect

Why it fails: If the credentials were incorrect, the error message would typically be 'Access Denied' or 'Authentication Failed'. A 'Connection reset by peer' implies the connection was successfully established but then terminated, which points towards a security control or network device actively killing the session rather than a simple authentication rejection.

The listener port is blocked by the target firewall

Why it fails: If the listener port were blocked on the host, the exploit might hang or time out while trying to establish the reverse shell, but it wouldn't necessarily reset the SMB connection during the authentication phase. The reset occurs during the initial SMB handshake, suggesting the target's SMB service is the culprit.

The payload architecture does not match the target

Why it fails: A payload mismatch would cause the exploit to succeed in uploading but fail when attempting to execute the binary. The error here occurs during the initial phase where the exploit tries to gain access via SMB, meaning the payload has not yet been executed on the target's operating system.

To act as a central vulnerability database

Why it fails: Msfvenom is a payload generator, not a database. Vulnerability information is managed through the Metasploit framework's internal module documentation and external sources like CVE databases. Confusing a command-line tool for a database misrepresents the architecture of the Metasploit Framework and how it organizes its exploit modules for users.

To automate the exploitation of remote services

Why it fails: Exploitation automation is handled by the main msfconsole interface, which loads and executes exploit modules. Msfvenom is strictly for creating the payload itself, which is then delivered to the target through a separate exploitation mechanism, such as a web server, a phishing email, or a direct exploit module.

To manage active sessions and post-exploitation

Why it fails: Session management is performed inside the Meterpreter environment once a target has been successfully exploited. Msfvenom is a pre-exploitation tool used to craft the initial payload, and it has no capability to interact with running sessions or perform post-exploitation tasks once the payload has been deployed to the target.

It defines the target's listening port

Why it fails: LHOST defines the attacker's IP, not a port on the target. The target does not listen; it initiates a connection to the attacker. Confusing these terms leads to significant configuration errors during the payload setup, as the attacker must correctly identify their own interface address for the target to reach them.

It is used to scan the local network

Why it fails: The LHOST parameter is not related to network scanning. Scanning is performed by auxiliary modules that use RHOSTS to define the target range. Attributing scanning functionality to the listener configuration is incorrect and indicates a misunderstanding of how the Metasploit framework differentiates between payload configuration and scanning modules.

It defines the exploit's remote host target

Why it fails: The remote target is defined by RHOSTS, not LHOST. LHOST is strictly for the reverse connection back to the attacker. Confusing RHOSTS and LHOST is a common error that prevents the exploit from reaching the target or the listener from being properly configured to catch the incoming connection.