30 — Vulnerability Scanning and Exploitation Tools

Level: Advanced · Time: ~22 min · Prerequisites: Lesson 29 — Recon and Scanning Tools

Why this matters

There is a difference between a tool saying something looks wrong and you knowing that it is wrong, and almost every beginner report fails because the author could not tell the two apart. A scanner finding is a hypothesis. A verified finding is a fact with evidence behind it. A proven finding is a demonstration that something specific happens when you send something specific. The credibility of your entire security function rests on never presenting the first as the third.

This lesson covers how the tooling fits together — the scanning platform, the web application scanner, the templated checker, the exploitation framework, the intercepting proxy — and then the part that actually gets vulnerabilities fixed: the report. The offensive material here is taught for one purpose: to validate your own findings in a lab or an authorised test, so that you can hand somebody evidence that survives scrutiny.

The mental model: suspected, verified, proven

Stage	What you have	What you may claim	What it requires
Suspected	an automated check matched a signature, a version or a pattern	"the scanner reports this as potentially vulnerable"	a scan, and the honesty to call it a hypothesis
Verified	you reproduced the condition by hand and confirmed the version, configuration or response	"this host runs the affected version and the vulnerable feature is enabled"	manual confirmation, the raw request or response, and a timestamp
Proven	you demonstrated the impact safely, in a lab or a formally scoped test	"an unauthenticated attacker can read this record"	authorisation, a controlled technique, and a complete record of what was run

Most reports stop at stage one and are written as if they were at stage three. That is how credibility is lost: one refuted "critical" and the next real one is argued about for a week.

Vulnerability scanning platforms

A modern open-source scanner is an assembly of parts, and knowing the parts tells you where the failures come from.

Component	What it does	Why it matters to you
A feed of checks	a signed, regularly updated set of tests for known weaknesses	results are only as current as the feed — a scanner running a feed from last year reports last year's world
A scan engine	runs the checks against targets and interprets responses	some checks are network probes, some are local version lookups after authentication — they have different accuracy
A database	stores targets, credentials, results and history	this is where your evidence lives, so back it up and restrict access
A scheduler	runs scans on a cadence and in a window	this is how continuous scanning stays continuous when nobody remembers it
Credentials	log in to targets so the engine can read the local package inventory	the difference between a guess and a fact

Greenbone Community Edition, the open-source descendant of OpenVAS, is the canonical example: a manager daemon (gvmd), a scanner daemon (ospd-openvas), the scanner itself, a PostgreSQL database, Redis for feed and queue coordination, and a web interface that listens on port 9392 by default. Its setup involves pulling the community feed before the first scan, because an empty feed produces an empty report.

Scan mode	How it works	Consequence
Unauthenticated	probes from the network and infers versions from behaviour and banners	fast, works on anything, and it is guessing
Authenticated	logs in over SSH or SMB (or queries a management API) and reads the actual installed versions	slower to set up; dramatically fewer false positives and many more real findings

Reading a report honestly means knowing the five ways a scanner lies:

Failure mode	What it looks like	How to handle it
False positive from a back-ported patch	the vendor kept the old version string while fixing the flaw; a banner-based check reports the CVE anyway	this is common on long-term-support distributions. Confirm the package revision, not the version string
False negative from custom code	nothing is reported because the weakness is in code the scanner cannot see	pair scanning with application testing and code review
Technically true, operationally irrelevant	a vulnerable component is installed but never loaded, or sits behind a control that removes the path	mark it, justify it, and do not spend the week on it
Policy findings presented as vulnerabilities	weak TLS ciphers, missing headers, self-signed certificates	real, but they are configuration and belong in a separate, lower queue
Reachability ignored	a score treats an internal-only service as if it were internet-facing	apply the exposure questions from Lesson 27

Scheduling and scope. Run scans in an agreed window, tell the owners of the targets, and keep an exclusion list for fragile systems — a legacy device that crashes under a burst of probes is a self-inflicted outage. Record the target list, the credential set and the scan configuration with the report, so that any finding can be reproduced and any result can be explained a year later. Scanning is intended to be safe by design, but "intended" is not an authorisation, and it is not a promise about a twenty-year-old appliance.

Web application scanning and templated checks

Passive and active are different tools wearing the same name. A passive web scanner inspects traffic that already passed through it — usually through a proxy you configured — and reports what it observes: cookies without the HttpOnly flag, missing security headers, version disclosure, comments left in the source. It sends nothing new, so it is safe to run against production. An active scanner sends thousands of crafted requests: it injects parameters, fuzzes inputs and explores endpoints. On a well-built application it is informative; on a fragile one it can create records, send emails or corrupt data. Run active scanning against a copy, or in a window with the owners watching.

A web security scanner systematically cannot find:

Business-logic flaws — the discount code that can be applied twice, the workflow step that can be skipped. There is no signature for "this is wrong here".
Authorisation bugs — access control that depends on your application's own rules rather than on a filter the scanner can test. Lesson 10 covers why these are the most common serious web flaw and the least automatable.
Anything behind authentication it was not given, or behind a multi-step flow it cannot reason about.

That is why web findings need a human: the scanner produces the raw material and the human decides what it means.

Tools in this family, briefly: OWASP ZAP for proxying and both modes of scanning, including a command-line baseline mode that runs a passive pass and exits with a report; Nikto for quick, noisy checking of a web server's configuration and known paths; Wapiti for black-box fuzzing of forms and parameters; mitmproxy as the scriptable intercepting proxy. Commands look like this, aimed at an application you own:

# Passive baseline against your own application, then a report you can read
zap-baseline.py -t https://app.lab.internal -r zap-baseline.html

# A quick server-level check: paths, default files, headers, TLS
nikto -h https://app.lab.internal -o nikto.html -Format htm

# Active fuzzing of an application you own, in an agreed window
wapiti -u https://app.lab.internal -f html -o wapiti-report

Templated checks are a third approach, and the most useful one for a small team. A community-maintained template library describes a specific known exposure as a set of request-and-match conditions, and a runner executes them at speed against a list of targets. Nuclei is the established runner for this:

# Update the template library first — a stale library checks for a stale world
nuclei -update-templates

# Run a targeted subset against your own inventory, and keep the output
nuclei -l internal-hosts.txt -severity high,critical -o nuclei-findings.txt

# A single template family, rate limited to avoid hammering a fragile host
nuclei -u https://app.lab.internal -t http/cves/ -rl 20 -jsonl -o app-cves.jsonl

The trade is straightforward. Templated checking is fast, low-noise for the exposures it covers, and trivially automatable across a fleet. It is also narrow: it finds only what somebody has written a template for, a match can be a false positive when a generic error page satisfies the condition, and a match proves the response matched, not that the flaw is exploitable. Verify by hand before reporting.

Verification, exploitation and intercepting proxies

An exploitation framework exists in a legitimate assessment to do three jobs: prove that an unpatched service really is exploitable, demonstrate impact convincingly enough to justify a fix, and test whether your detections fire when somebody does this to you. It is not a shortcut to a finding; it is the evidence for one.

The discipline is what separates a professional from a beginner:

It happens in a lab or inside a formally scoped test — never against a production system because "it is only a check".
You record exactly what you ran. The framework module name and version, the target, the payload or options, the timestamp, the result. If it left a session, a file or an account behind, you record that too, and you clean it up with the owner watching.
You use the module's own verification capability first. Many modules can send a check and report whether the target is vulnerable without running the exploit at all — that gives you a verified finding with no side effects, which is usually all the report needs.
You never validate in production what you have not validated in the lab. A module that pops a shell on your test copy may crash the production service, and "we were only confirming the finding" is not a sentence you want to write.

# The shape of a verification, rather than a live exploit
msfconsole
  search <product> <version>        # find a module that matches the suspected flaw
  use <module>                      # select it
  show options                      # read the required settings
  set RHOSTS 10.30.0.12             # the target — in your lab, or the agreed scope
  set RPORT 8080
  check                             # verify without exploiting, where the module supports it
  exploit                           # only in a lab, or an explicitly authorised window

Two supporting tools belong in the same drawer. searchsploit searches a local copy of a public exploit database for a product and version, which is the fastest way to answer "does a public exploit exist for this?" — the second of the four triage questions from Lesson 27. And the same scripting checks from Lesson 29 are a middle ground: a targeted NSE script can confirm a condition safely, and an NSE result of "likely vulnerable" is still a hypothesis, not a proof.

Intercepting proxies are the tool beginners undervalue, because they are the best way to learn how an application actually behaves. What is the point of a proxy? You see the requests the browser makes and the responses it receives, and you can modify them before they leave or before they arrive: change a parameter, change an identifier, change a role, and watch what the server does. Two solid open-source options are OWASP ZAP and mitmproxy, and both do the same essential job — sit between client and server, show the traffic, let you edit it.

The single most instructive exercise is an access-control test on an application you own: log in as user A, capture the request that fetches A's record, change the record identifier to one belonging to user B, resend it, and see whether the application returns B's data. When it does, you have found the class of bug Lesson 10 warned about — the one no scanner reliably finds and the one that appears in real breach reports again and again. That is the return on learning a proxy: you stop reading about access control bugs and start recognising them.

Reporting: where beginners fail

A finding gets fixed when somebody else can act on it without asking you anything. That is the whole standard.

Field	What belongs in it
Title	one line naming the weakness and the asset — not "security issue"
Asset and component	hostname, address, service, and the exact affected version or package revision
Evidence	the raw request and response, the command and its output, or the scanner line, with a timestamp and the tool version used
Business impact in plain language	what somebody could do and what it would cost — written for a manager, not for a peer
Reproduction steps	numbered, minimal, and complete enough that another administrator gets the same result
Severity and justification	the score, which version of the scoring system it came from, and why it applies here — including the exposure
Remediation	a concrete action: upgrade to this version, disable this feature, apply this configuration — plus the compensating control if a fix is not yet possible
Verification method	the exact check that will show it is fixed, so closure is provable

Here is the difference in practice.

BEFORE — unusable
Critical: server is vulnerable
The web server is vulnerable to a critical issue. Please patch it. CVSS 9.8.

AFTER — actionable
Unpatched web server on the public front end, exploitable without authentication
Asset: web01.internal (203.0.113.10), nginx 1.18.0, package revision 1.18.0-0ubuntu1.2
Evidence: version probe 2026-09-18 14:22 UTC, `nmap -sV -p 443` output attached;
          follow-up request/response captured in ZAP, saved as finding-014-session.mitm
Impact: an unauthenticated attacker on the internet can execute arbitrary commands as the
        web service account, which has read access to the customer database
Steps: 1) connect to 203.0.113.10:443  2) confirm the banner on /status
       3) run the included check from the lab  4) observe the command output
Severity: 9.8 with CVSS v3.1 — network vector, no privileges, no user interaction,
          and this host is reachable from the internet, which is why it is first in the queue
Remediation: upgrade to 1.18.0-0ubuntu1.6 or later. Until the change window on 21 Sep,
          the /status path is blocked at the edge firewall (rule FW-4471) and the service
          account has been moved to a read-only database role
Verification: re-scan with the same probe and confirm the version changes; the check is
          `nmap -sV -p 443 203.0.113.10` plus the lab validation script

The second version takes fifteen minutes longer to write and is the difference between a fix this week and an argument next month.

Authorisation checklist

[!WARNING] Nothing in this lesson may be run without satisfying all of the following. It is a hard requirement, not a formality: an unverified finding costs you credibility, but an unauthorised exploit attempt costs you your job, and in France it can cost you a criminal record, because unauthorised access to or interference with an automated data processing system is an offence regardless of intent or outcome.

Item	What it must contain
Written scope	the specific hosts and addresses, the specific dates and hours, and the techniques permitted — signed by somebody who has the authority to give it
Named contact	the person who answers questions before and during the test, and who can authorise a deviation
Agreed window	when you may run the noisy and destructive-capable tests, and when you must stop for business reasons
Out-of-hours contact	somebody reachable at 22:00 who can tell you to stop
Stop condition	the event that ends testing immediately — a production outage, an unintended effect, discovering live attacker activity, or the contact saying stop
Emergency plan	what you do if a test causes an outage, and who notifies whom

In your own lab, every line of that checklist is trivially satisfied, which is exactly why Lesson 37 exists. Build the lab, break it there, verify what you find, and practise writing the report. Then, and only then, the same skills are safe — and useful — on systems somebody has asked you to test.

Attack it / Defend it

The attack	How it works	The control that stops it
Exploiting a verified, unpatched service	a public exploit is run against a version the scanner already flagged	fix internet-facing criticals within days, not quarters (Lesson 27)
Trusting an unverified scanner finding	a false positive is reported as critical, and the team stops believing the next one	verify every finding before reporting, and say which stage you reached
Attacking through a web application's logic	no signature exists, so no scanner sees it: the workflow itself is abused	manual application testing with a proxy, threat modelling, code review
Broken object-level authorisation	an identifier in a request is changed to another user's	server-side authorisation checks on every object, and testing with a proxy before release
Weaponised template exploitation at scale	community templates are run against internet-wide ranges to find unpatched hosts	patch, minimise public surface, and monitor your own assets (Lesson 29)
Blind-spot exploitation	the weakness is in custom code, so nothing is reported and nothing is fixed	software composition analysis, code review, and application testing by a human
Exploiting fragility during a scan	an aggressive scan or exploit attempt crashes a legacy system, and the outage is the attack	agreed windows, exclusion lists, rate limits, and non-destructive check modes
Abusing the scanner's credentials	the scanning platform holds logins for everything	least-privilege read-only accounts, management-network placement, protected database
Testing production without telling anyone	an unauthorised test creates records, sends mail, or breaks a service	written scope, named contact, agreed window — every time
Reporting noise as a breach to gain attention	unverified findings are escalated, damaging trust in the security function	a report template that forces evidence, impact and reproduction steps

Key takeaways

Suspected, verified, proven. Say which stage a finding has reached, and never let the report claim more than the evidence supports.
Authenticated scanning is the difference between guessing and knowing; unauthenticated results are a hypothesis with a version number attached.
Scanners cannot find logic or authorisation flaws. That is human work with a proxy, and it is where the serious web bugs live.
Exploitation tooling is for proving impact in a lab or a scoped test — with a complete record of what was run, when, and against what.
A finding gets fixed when somebody else can act on it without asking you anything. Evidence, impact, steps, fix and verification — every time.

Check yourself

Your scanner reports a critical vulnerability on a host running a long-term-support distribution, and the administrator says the patch was back-ported. How do you settle the question?
Name two classes of flaw a web application scanner will not find reliably, and the technique you would use instead.
Why does an authenticated scan produce fewer false positives than an unauthenticated one?
You are asked to "just run the exploit to check" against a production server outside any agreed window. What do you do, and what do you offer instead?
Rewrite this finding so it is actionable: "High: web application vulnerable to access control issue, needs fixing".