YanoSec
Progress0 of 152 lessons complete

Course / 12 Testing / Lesson 03 of 11

What Metasploit is

Estimated time: 14 min reading · 14 min activity

A framework organizes reusable testing components. A module is one component with a particular job. Metasploit includes auxiliary modules for tasks such as gathering information, exploit modules that use a weakness to run code, payloads that carry that code’s intended work, and post modules used after a compromise.

A session is an ongoing interaction with a target. Module names and version matches are leads: reasons to ask a narrower question, not proof that a module works safely. Configuration, patches, dependencies and side effects can differ. This lesson reads proposals without opening a console or creating a session.

Before you begin

Estimated time
14 min reading, 14 min activity. Setup and optional practice may take longer.
Where you work
Use only the supplied North Desk fictional cards and source in a desktop or mobile browser. Keep predictions in private notes. No login attempt, recovery tool, framework module, permission change, domain setup or target connection is required. Optional later lab setup has a separate budget.
Without a lab
All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.

After this lesson you can:

  • Name auxiliary, exploit, payload, and post from the getting-started definitions.
  • Treat a version match as a lead until behavior is checked inside a grant.
  • Refuse proposal M-1 because the checklist names no target.

01Example

Fresh authored proposal, with no executable settings or target connection.

Proposal W: component names resemble a documented module.
Missing: configuration, behavior check, impact estimate, target grant.
Decision: retain as a lead; do not execute.
Next work: obtain appropriate scope and define a bounded confirmation method.

02A label is not a test

A banner is text a service reports about itself. It can be incomplete, misleading or unaffected by a backported patch. Matching a banner to a module’s description does not establish the required conditions.

Auxiliary is a module category, not a guarantee of harmlessness; administrative or discovery actions may still alter a system or exceed a grant. Before any later real use, read the exact component’s behavior, prerequisites and cleanup needs, and check that the target and action are explicitly permitted.

Evaluate a framework proposal from scope and behavior rather than assuming a matching version makes it safe.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Keep module resemblance as a leadExecute the module now

Proposal W

Proposal W: component names resemble a documented module.
Selected evidence · Original fictional teaching evidence

Missing verification facts

Missing: configuration, behavior check, impact estimate, target grant.
Source evidence · Original fictional teaching evidence
supported

Keep module resemblance as a lead

Names resemble a documented module, which supplies a lead only.

No behavior or target permission follows from names.

Original fictional teaching evidence

Names resemble a documented module, which supplies a lead only. No behavior or target permission follows from names.

Follow the explanation

  1. Names resemble a documented module, which supplies a lead only. No behavior or target permission follows from names.
  2. Configuration, confirmation, impact and grant are all missing. Obtain appropriate scope and define bounded confirmation before any use.
Read every state and value

1. Names resemble a documented module, which supplies a lead only. No behavior or target permission follows from names.

Evidence selected
Proposal W
Current claim
lead
Source origins
Original fictional teaching evidence

2. Configuration, confirmation, impact and grant are all missing. Obtain appropriate scope and define bounded confirmation before any use.

Evidence selected
Proposal W · Missing verification facts
Current claim
execute
Source origins
Original fictional teaching evidence
A framework/module label supplies neither verification nor permission; no module is executed.

03Decide on proposal M-1

Proposal M-1 pairs a version 2.3 banner with a similar module name. The checklist authorizes reading only and names no target.

Framework card
Label: original fictional card. No console was opened. No module was loaded.

A module is a packaged component a framework can run.
The Metasploit getting-started page names these common types:
auxiliary: the page says these do not exploit a target, and that they can gather data or do administrative tasks.
exploit: written so the framework can run a payload on a target.
payload: code an exploit would run.
post: used after a compromise.

This card does not name a module path, a payload, or a host.
A version banner is not printed here.
The page's console sample is an old documentation banner, not a local install.
Stop: do not install the framework and do not run a module.
Some auxiliary tasks can still change or disrupt a machine. "Not an exploit" is not a safety proof.

Download the module-type card

Module checklist
Label: original fictional grant. No module was run.

Grant: read this card.
Target: none.
Allowed action: decide whether the grant supports running a module.
Time: this reading.
Excluded: every host, including 127.0.0.1, until a later grant names one.
Stop: no target means do not run.

Proposal M-1: a banner says version 2.3, and a module list contains a similar name.
Record: M-1 has a version lead and no grant. Decision: do not run.
A version match does not show configuration, a patch, or what the module would do.

Download the module checklist

  1. Copy the permission: read the card, with no module execution or target action.
  2. List the evidence M-1 actually gives: a version label and a name similarity. List missing behavior and environment facts separately.
  3. Record do not run under the current grant. Explain that a better version match would still not create authorization.
  4. Stop after the decision note. No framework installation or payload configuration is required.

04Optional challenge

In about twelve optional minutes, write a future approval brief with a defined behavior to confirm, one named target/action, expected side effects and an explicit stop/cleanup plan. Leave it a private draft; this worksheet supplies no execution grant.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Module card A: fictional component descriptionsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

M1 gathers information without exploiting a target.
M2 uses a weakness so the framework can run code.
M3 is the code intended to run through an exploit.
M4 operates after a compromise.
Descriptions are role models, not executable module settings.

Lead card BOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

B7: a service reports version 4.2. A catalog includes a similarly named module.
No behavior, patch state, compatibility test or side-effect evidence is supplied.

Grant card COwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

This fictional grant permits reading the saved inventory for host lab-spruce.invalid only.
C1 proposes reading that saved inventory.
C2 proposes running an auxiliary component against lab-spruce.invalid.
C3 proposes reading a neighbor host inventory.
No module execution or neighboring host is included.

06Explain the evidence and its limit

Optional self-check: explain the difference between a version lead, a permitted action and a compatibility check.

Review your explanation: keep all three separate, mention possible side effects for auxiliary work, and avoid claiming an execution occurred.

07Common mistakes

If a module category is treated as safe, inspect the actual action rather than its name.

If a version label is treated as proof, list configuration and patch facts it does not establish.

If an installed tool seems to create a target grant, return to the scope document; availability and authority are separate.

References