~/tutorials/043-the-framework-question.md

043: The framework question

Metasploit is a framework, not a skill. Once you understand the work it does, using it and doing that work by hand are the same knowledge at different speeds. The question is what the speed costs.

What it gives you

The largest tested exploit library in the world. Reliable payloads, a handler that just works, a database that tracks your hosts, and post exploitation modules that turn a foothold into a census in one command. For a lab, for learning the shape of an engagement, and for the first hours of a real test where time is billed, it is genuinely the fastest path from a bug to a shell.

What it costs

Artifacts. Everyone has seen the default payloads. Defender products, honeypots, and blue team runbooks know the meterpreter handshake, the default certificate, the characteristic process names. Using the framework with its defaults on a monitored network is announcing yourself in a registered dialect.

Confidence. A module rated excellent against a version that matches, in an environment that matches the lab it was tested in, works. The real target is not that environment. The module fails, and the operator who never did the work by hand cannot say why.

That second cost is the one that matters for you. The framework wraps the skills this tier taught. Recon, enumeration, exploitation, the callback. Run those by hand first, then use the framework with its defaults, then use it with its defaults changed. You will know at which of those three stages you are.

The honest split

Reach for it when the goal is the destination: a foothold in your lab, a proof of concept for a known bug, a test of a control that should stop a known pattern.

Stay by hand when the goal is the skill: a class of bug you are learning, an environment the modules do not know, an assessment whose detection story you care about, or the first time doing anything.

The snapshot in the jail below shows what a framework answer looks like when it is honest about where it came from:

nmap -sC 127.0.0.1

Nmap scan report for localhost (127.0.0.1)
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
|_http-title: l1ackers.com
443/tcp open  ssl/http
| ssl-cert: Subject: commonName=l1ackers.com
|_http-title: l1ackers.com

Answered from a snapshot of this host rather than a live scan: this shell cannot
execute anything, which is also the reason a stranger typing into it is safe.

The real script engine answers with real findings against your own host. This one tells you its own limits instead, which is the more useful lesson of the two.

Try it

1. In your lab, exploit one service by hand. The full path: find, verify, build, fire.
2. Exploit the same service with a module. Compare what you learned with what you got.
3. Read the module's source. It is open. Find where it does the step you did by hand, and note what it does differently.

Then answer the question per engagement, not as an identity. The people who identify as framework users and the people who identify as manual purists are both paying a tax somebody set for them.