Penetration Testing Frameworks
Plan authorized penetration tests with rules of engagement, safe framework use, evidence chains, validation, and remediation retests.
What are penetration testing frameworks?
A penetration testing framework is a controlled workbench for discovering, validating, and documenting security weaknesses during an authorized assessment. It organizes reusable modules, target settings, sessions, evidence, and reporting so an assessor can repeat a test instead of improvising every action.
In plain language: a scanner may say that something looks weak; a penetration test asks whether the weakness is real, what approved boundary it affects, and what evidence supports that claim. The framework helps execute and record that work, but it does not decide what is legal, safe, or in scope.
The core invariant is every action must remain inside the written target, technique, time, data, and stop boundaries. A module being available does not authorize its use, and a successful command does not automatically prove business impact.
Review Red Teaming Fundamentals first if rules of engagement, test authorization, or red-team responsibilities are unfamiliar.
Authorize
Define the boundary
Name targets, identities, actions, time windows, prohibited behavior, and stop authority.
Validate
Prove the narrow claim
Use the least-impacting approved action that can confirm or reject the hypothesis.
Evidence
Make it reproducible
Preserve target, precondition, action, result, cleanup, confidence, and owner.
Retest
Close the loop
Repeat the same bounded case after remediation and compare the expected control behavior.
Separate methodology from tooling
A methodology defines how an assessment is planned, executed, analyzed, and reported. A framework provides execution mechanics. Confusing the two encourages teams to treat a module list as a complete testing program.
Process
Assessment methodology
Defines objectives, scope, roles, assumptions, limitations, evidence, reporting, and remediation follow-up. NIST SP 800-115 describes planning, execution, and post-execution activities for technical security assessments.
Execution workbench
Testing framework
Organizes modules, payloads, options, sessions, routes, and records. Metasploit is a prominent example, but its technical capability remains subordinate to the engagement contract.
One bounded job
Point tool
Solves a narrower task such as service discovery, HTTP interception, source review, or password auditing. A good assessment composes tools around a test objective instead of forcing one platform onto every layer.
Decision record
Evidence system
Connects raw observations to a claim, affected asset, confidence, cleanup proof, remediation owner, and retest condition. Framework output is input to this record, not the final report by itself.
Use the NIST SP 800-115 publication for general assessment planning and the OWASP Web Security Testing Guide for current web testing categories and techniques. Pin the guide version used by an engagement because the latest OWASP content can change.
Bound the engagement before choosing modules
An engagement envelope is the smallest explicit set of conditions under which test activity is allowed. It combines the target boundary, access assumptions, validation depth, concurrency, evidence needs, stop conditions, and cleanup expectations.
Use the lab to compare an isolated lab, a production canary, and a broad production segment. Change the access profile and validation depth, then increase parallelism. The work model, execution waves, evidence volume, review effort, and safety decision update together.
Read the arithmetic, not just the status
- Planned test cases equal targets multiplied by access cases and the selected depth factor. These are transparent lesson assumptions, not an industry coverage score.
- Execution waves show how concurrency changes immediate blast radius without changing the number of approved targets.
- Evidence items expose the review burden created by deeper testing and additional evidence sources.
- Review effort is an illustrative planning input. Replace it with measured team data before using a similar model operationally.
Follow a gated assessment lifecycle
A gate is a decision point that must pass before the next class of action is allowed. Framework automation should make the gates easier to enforce and audit, not skip them.
1 Authorization
Plan the claim
Name the system, hypothesis, allowed access, validation depth, owners, window, prohibited actions, data handling, stop conditions, and success evidence.
2 Observation
Map the surface
Identify approved hosts, services, roles, entry points, and execution paths. Keep reachability, version inference, and candidate weakness as separate observations.
3 Controlled action
Validate minimally
Select the least-impacting test that can confirm or reject the claim. Verify prerequisites, target compatibility, options, expected effects, cleanup, and the operator stop path.
4 Evidence
Report and retest
Separate confirmed findings from hypotheses, preserve reproducible evidence, verify cleanup, assign an owner, and define the condition for a bounded retest.
NIST SP 800-115 treats an assessment as a managed project with goals, scope, roles, limitations, schedule, and deliverables. Those controls remain necessary even when a framework makes execution fast.
Trace validation depth and stop conditions
Validation depth is how far an assessor is authorized to move from observation toward demonstrated impact. The right depth is the minimum needed to answer the engagement question, not the maximum a framework can technically reach.
Switch among exposure-only, controlled-validation, approved-path, and stop-at-boundary scenarios. The active route, affected component, and evidence claim change together. Select a node to inspect its responsibility.
Keep claim strength aligned with evidence
- A reachable service supports an exposure observation, not an exploit claim.
- A least-impacting proof may support a confirmed weakness for the exact target, role, state, and request tested.
- A bounded session or pivot may support an attack-path claim only when that route and destination are explicitly authorized.
- A route toward an unlisted target remains an unvalidated hypothesis until the engagement owner changes scope in writing.
Finding a possible path does not expand authorization. Stop before crossing the boundary, preserve the non-invasive evidence, and request a scope decision through the agreed process.
Use Metasploit modules deliberately
A Metasploit module is a packaged implementation with metadata, options, target assumptions, and behavior. Different module categories answer different questions, and not every module supports the same safety checks.
Observe or operate
Auxiliary modules
Commonly gather information or perform an action without using the exploit-and-payload flow. Their effects still require review; "auxiliary" does not mean harmless.
Create execution
Exploit and payload modules
An exploit targets a vulnerability; a compatible payload defines what runs after successful exploitation. Verify the tested target, options, preconditions, payload behavior, and cleanup before use.
Operate after access
Sessions and post modules
A session represents access to a target. Post modules build on that session, so platform, privilege, side effects, data access, and session cleanup become part of the authorization boundary.
Reach another network
Routes and pivots
A compatible session can provide a route to another network. That technical reach must never be mistaken for permission to contact the newly reachable targets.
The official Metasploit documentation explains the current module categories, module review workflow, and pivoting behavior.
Read the documentation shipped for the installed version and inspect the exact module rather than relying on a copied command.
The check command is not a universal harmless probe. Metasploit documents that support and behavior vary by module, and some checks validate a bug by exercising it. Recreate a representative target when possible and review the module documentation, targets, options, and source before execution.
Encode the contract and evaluate results offline
The framework-neutral plan keeps authorization review independent of a product API. The evaluator reads fictional observations, refuses to confirm incomplete claims, and halts when an observation names an out-of-scope asset. It does not connect to a network or execute a security test.
Validate the file with python3 -m json.tool engagement-plan.json. A real plan should also name legal and business owners, exact dates, contacts, credentials, sensitive-data handling, and emergency procedures in the organization's approved system of record.
Run python3 evaluate-assessment.py. The standard-library script loads the co-located fictional result fixture, checks scope and evidence invariants, and prints a review decision.
The sample decision is halt-and-review: one confirmed in-scope finding is releasable, one in-scope hypothesis still needs evidence, and one observation names a target outside the authorized list.
Write findings as decision records
A finding is a supported claim that an owner can reproduce, prioritize, remediate, and retest. Raw console output, a framework severity label, or a successful session is not enough by itself.
For every confirmed finding, record:
- the affected in-scope asset, role, state, and observation time;
- the security objective and control that failed;
- the preconditions and least-impacting approved validation action;
- the observed result, evidence references, and confidence;
- the demonstrated impact without accessing unnecessary data;
- cleanup and target-health verification;
- the remediation owner, recommended control change, and bounded retest condition.
Keep separate queues for:
- confirmed findings, where evidence supports the exact claim;
- suspected findings, where a plausible weakness still needs approved validation;
- informational observations, where exposure or configuration matters but exploitability is not claimed;
- scope decisions, where a potential path requires new authorization before further testing.
Operate with explicit safeguards
Before execution:
- Obtain written authorization and verify the latest target inventory with system owners.
- Review every module's documentation, target list, options, advanced settings, expected behavior, and cleanup.
- Rehearse high-impact actions in a representative isolated environment.
- Confirm monitoring, backups, emergency contacts, service health signals, and an independent stop authority.
During execution:
- Keep concurrency and retries bounded; a timeout does not prove that a target-side action failed.
- Record correlation IDs and UTC timestamps across framework output, target telemetry, and operator notes.
- Stop on scope drift, unexpected privilege, sensitive-data exposure, service degradation, or failed cleanup.
- Avoid collecting credentials or records that are not required to prove the approved claim.
After execution:
- Verify cleanup and target health independently of the framework's success status.
- Remove test accounts, payloads, routes, sessions, files, and temporary policy changes through reviewed procedures.
- Protect evidence according to its sensitivity and retain only what the decision requires.
- Retest the same bounded claim after remediation, then close it only when the expected control behavior is observed.