Metasploit for confirming a finding, not for the demo

A vulnerability scanner produces a report with a hundred findings, each with a severity and a confidence level, and the organisation triages them by the number in the severity column. Three months later the same findings are in the next report, because a number on a page does not create urgency.

The finding that gets fixed is the one where someone demonstrated, in a controlled way and with authorisation, what an attacker actually gets. That is what an exploitation framework is for: not to break in for its own sake, but to convert a theoretical finding into a concrete, prioritised one. Everything below assumes an authorised engagement with written scope, because without that this is not a workflow, it is a crime.

Authorisation first, and it is not a formality

Before any of the technical content, the boundary that makes this legitimate.

You need written authorisation that names the systems in scope, the time window, the techniques permitted, and the people who can stop the test. For a cloud estate, add the provider's position: most cloud providers permit testing of your own resources without prior approval but prohibit certain techniques such as denial of service, and testing infrastructure you do not own, including shared managed services, is out of bounds. Read the provider's current testing policy rather than assuming.

Keep the authorisation reachable during the test, log every action with a timestamp, and have a named contact who can call it off. This is the same discipline as the emulation rules in your detections are untested until you generate the behaviour, and it exists for the same reason: real attacker behaviour on real systems needs a documented boundary.

Where it fits in an assessment

Exploitation is one phase, and not the first.

Reconnaissance and scanning come before it, establishing what exists and what is probably vulnerable, which is the perimeter work in Nmap against a cloud perimeter. Exploitation confirms a subset of those findings. Post-exploitation and lateral movement establish what the confirmed access actually reaches. Reporting turns all of it into prioritised, fixable work.

Metasploit is strongest in the middle of that sequence. It is a framework for organising exploits, payloads and post-exploitation modules with a consistent interface, a session manager, and a database that records what you found and what you accessed. The value is the organisation and the record, not any single exploit.

Most assessments use a fraction of it. A handful of modules, the session handler, and the post-exploitation tooling cover the majority of real engagements.

Confirming rather than just detecting

The distinction that makes this worth doing is between "the scanner thinks this is vulnerable" and "this is exploitable and here is the access it grants".

A scanner flags a service at a version with a known vulnerability. That version string might be wrong, the vulnerable code path might not be reachable, a compensating control might block it, or the finding might be a false positive. Controlled exploitation resolves the ambiguity: either the access is obtained, which makes the finding real and its priority obvious, or it is not, which is itself useful because it tells you the compensating control works.

Use the safe, confirmation-oriented modules rather than the aggressive ones where possible. Many modules have a check function that validates exploitability without full exploitation, and a check that confirms vulnerability without dropping a payload is often all the evidence a report needs. Reserve full exploitation for the findings where demonstrating the impact is what will get it fixed.

Post-exploitation is where the real finding is

Getting a session on a host is rarely the interesting part. What that access reaches is.

From a foothold, the questions that matter are: what credentials are on this host, what can this host reach that the perimeter cannot, what identity does this host carry, and does that identity grant more. On a cloud instance, the highest-value target is almost always the metadata endpoint, because an instance role reachable from a compromised host is the route from one machine to the cloud account. That is the same path argued against in a Kubernetes Secret is base64 and it is worth demonstrating precisely because the fix, workload identity and metadata restrictions, is concrete.

This is where an exploitation framework earns its place over a single exploit script: the session management, credential collection and pivoting are organised, and the database records the chain so the report can show how one finding led to the next. A chain of three medium findings that together reach the customer database is a more persuasive artefact than three separate medium findings, and it is the chain that changes priorities.

Running it without causing an incident

Controlled means controlled.

Test against non-production first where the environment allows it, because exploits can crash the service they target and some payloads leave state behind. Understand what a module does before running it, particularly whether it is a memory-safe check or something that writes to disk or modifies configuration.

Clean up. A payload, a created account, an uploaded tool or a modified file left behind is both a professional failure and a real security risk, because you have added an access path. The framework tracks much of what a session did, which helps, but verify the system state afterwards rather than trusting the record.

Coordinate with the defensive side. If the organisation has detection, your activity will generate alerts, and either you have told them so a genuine incident is not declared, or you are deliberately testing their response and at least one person knows. Uncoordinated exploitation that triggers a real out-of-hours incident response wastes an evening and damages trust.

Turning it into something that gets fixed

The exploitation is worthless if the report reads like the scanner output it was meant to improve on.

For each confirmed finding, state the concrete access obtained, the chain that led to it, the specific fix, and the priority justified by the demonstrated impact rather than by a generic severity score. "This internet-facing service allowed remote code execution, from which the instance role granted read access to the customer data bucket" is a sentence that gets budget. "Critical severity finding, CVSS 9.8" is a sentence that gets filed.

Feed the confirmed findings back into detection. Every technique you used successfully is a technique your detection should have caught, and the ones it missed are the gaps to close, which is the loop described in detection as code. An assessment that improves both the vulnerabilities and the detection coverage is worth more than one that only lists holes.

The things people forget

• Scope creep is the classic failure. A pivot that reaches a system outside the authorised scope is a breach regardless of intent. Verify scope at every hop.
• Exploits can be destructive. Some crash the target. Know which before you run them against anything you cannot afford to lose.
• The framework itself is a target. A listener and a database of collected credentials is a valuable thing to leave running. Secure it and tear it down after.
• Collected credentials are sensitive data. Handle and dispose of them with the same care as any secret found in secret scanning with Gitleaks and TruffleHog.
• A failed exploit is a result. It confirms a control works, which belongs in the report as evidence rather than being discarded.
• Automated exploitation at scale is not this. Mass, unattended exploitation is neither controlled nor an assessment, and it is where authorised testing shades into something else.

What to do this week

Take the single highest-severity finding from your last vulnerability scan and answer one question with your assessment partner: has anyone confirmed it is actually exploitable, or is it a version string and a CVSS score. If nobody has confirmed it, that is the finding to validate first, because either it is real and under-prioritised, or it is a false positive consuming attention. We run controlled exploitation as part of the assessment phase of a security engagement, always within written scope.