The Difference Between Finding a Vulnerability and Exploiting It Responsibly

Nmap returned the service version in the scan output. I already knew the CVE number — it was in the version's known vulnerability list. The Metasploit module existed. I could have run it in the next thirty seconds.

I did not run it yet.

That pause — between finding a vulnerability and deciding to exploit it — is where assessment methodology lives. Most tutorials skip it entirely. They go from "scan shows open port" to "module running" in two steps. Real engagement work is what happens in between.

What black-box actually means

A black-box assessment starts from zero. No documentation, no architecture diagrams, no list of services. The only thing provided is an IP range. Everything else — what is running, how it is configured, what is reachable — has to be discovered.

This constraint matters because it changes how you think. When you know nothing about a target, you cannot skip reconnaissance. Every assumption has to be earned from evidence. The discipline of starting with passive OSINT before touching the target, of running Nmap with version detection before looking up CVEs, of mapping what you find before deciding what to do with it — that discipline is the methodology. Without the constraint, it is easy to skip straight to exploitation and miss what the real attack surface looks like.

The step between finding and exploiting

Finding a vulnerability means identifying a service version with a known CVE, or a web endpoint with unsanitised input, or a misconfigured permission. That is the discovery phase. It tells you something may be exploitable.

Exploiting it is different. Exploitation converts a potential finding into demonstrated impact — proof that the vulnerability is real, reachable, and produces a specific outcome. A finding without exploitation is an unverified hypothesis. Exploitation without a finding is just running modules and hoping.

The responsible part is what connects them: evidence at every step.

Before running the exploit, the finding is documented — service version, CVE reference, MITRE ATT&CK technique ID, evidence screenshot. The mapping is done before the exploit runs, not after. The reason is straightforward: if exploitation succeeds, you need to be able to show exactly how you got there. If it fails, you need to understand why — whether the service is actually patched, whether the version fingerprint was wrong, whether there is a control in place that the scan did not surface.

During the engagement this looked like:

Finding: vsftpd 2.3.4 identified on port 21
CVE: CVE-2011-2523 — backdoor command execution
MITRE: T1190 Exploit Public-Facing Application → T1059 Command and Scripting Interpreter
Evidence: Nmap version scan output, service banner
Decision: exploit to confirm initial access

Running the module confirmed the backdoor — a reverse shell. That confirmation is what turns a finding into a verified vulnerability in the report.

MITRE ATT&CK as a thinking tool

ATT&CK is not a checklist of things to try. Used as a checklist, it becomes noise — a list of techniques to run through until something works. Used as a thinking tool, it asks a different question: what would an adversary do next from here, and why?

When initial access is established via an exploit, the next question is not "what other modules can I run" — it is "what does a real attacker prioritise after gaining a foothold?" The ATT&CK framework answers that with data from real-world adversary behaviour: privilege escalation, persistence, lateral movement, data collection, exfiltration. Each technique has a specific purpose in the attack chain.

Mapping findings to TTPs forces precision. T1548 Abuse Elevation Control Mechanism is not "I got root somehow" — it is a specific category of technique with specific sub-techniques, each with specific detection and prevention controls. When the finding maps to a TTP, the defensive question becomes concrete: do the controls on this system detect or prevent this technique? If not, that is a detection gap, and the report can say so explicitly.

Two audiences, one engagement

The output of the engagement was two documents: a technical security report and an executive presentation for a CISO-level audience.

The technical report documents every finding with evidence, CVE references, MITRE ATT&CK mappings, and specific remediation guidance. It is written for the person who will implement the fixes — precise, actionable, and complete.

The executive presentation translates the same findings into business risk language. Not "vsftpd 2.3.4 CVE-2011-2523" — but "unauthenticated remote access to the server is possible via a known backdoor in the FTP service, rated Critical, remediation: update or replace the service." Risk severity, business impact, remediation priority. Written for the person who will decide where to allocate remediation budget.

Writing both from the same engagement forces clarity about what actually matters. If a finding cannot be explained in business terms, its severity rating is probably wrong.

The takeaway

The gap between finding a vulnerability and exploiting it responsibly is not a technical gap. It is a methodological one: evidence before action, ATT&CK mapping before exploitation, and a report that tells two completely different audiences exactly what they need to know. The exploit is the smallest part of the work.