VAPT Tools: What a Tester Uses at Each Phase, and Where Each One Stops

A VAPT runs on a dozen or so tools, and every one of them is available to anybody. The tools are the cheap part of a test. What you are paying for is the person deciding which tool to point where, reading what comes back, and carrying on when the tool runs out of ideas.

Seeing the tools phase by phase is the quickest way to understand both halves of that sentence. A penetration test moves through five working phases: reconnaissance, mapping, scanning, manual exploitation and reporting. Each has its tools, and each tool has a point beyond which it can tell you nothing.

Reconnaissance: finding what is there

Before anything is tested, the tester works out what exists. For an internet-facing scope that means the domains, subdomains, address ranges and services that belong to you. Subdomain enumeration tools such as Amass and Subfinder pull names from DNS, certificate transparency logs and public datasets. Nmap then establishes which hosts answer and which ports and services they expose.

Where it stops: these tools produce a list of names and open ports. They cannot tell you which of those assets you still own, which one a developer stood up for a weekend and forgot, or which one holds the data that matters. The tester has to reconcile the list against what you say is in scope, and the gap between the two is often the first finding.

Mapping: learning how the application works

For a web application or API, mapping is where the test actually starts. An intercepting proxy, almost always Burp Suite or ZAP, sits between the tester's browser and your application and records every request. The tester walks the application as each user role, and the proxy builds a map of every endpoint, parameter and state change.

Where it stops: a crawler reaches the pages it can find by following links. It does not complete a checkout, approve a payment, or move between roles the way your users do. The multi-step and role-dependent parts of an application, which are where the serious flaws live, are only mapped because a person drove the proxy through them.

Scanning: checking for what is already known

Scanners compare what they find against what is already catalogued. On the network side that means Nessus or OpenVAS, matching service versions and configurations against databases of known vulnerabilities. On the web side, the scanner in Burp Suite Professional or ZAP's active scan sends known attack payloads at every parameter the map discovered, and Nikto checks web servers for known misconfigurations.

Where it stops: a scanner detects what it has a signature for. It cannot see an access control flaw, because nothing about the response looks wrong to it, and it cannot judge whether a finding matters in your context. Scan output also carries false positives that somebody has to rule out before they reach a report. What a scanner finds, and what it cannot sets out both lists.

Manual exploitation: proving what is real

This is the phase the engagement is priced on, and the tools change character. They become instruments in the tester's hands instead of things that run on their own. Burp Repeater and Intruder let a tester replay and modify individual requests, which is how an access control flaw or a business logic error is confirmed. sqlmap confirms and exploits SQL injection once a tester has found a likely parameter. The Metasploit Framework provides exploit modules for known vulnerabilities on the network side.

Other targets bring their own kit. A mobile test uses MobSF for static analysis, jadx to decompile an Android build, and Frida to instrument the running app and step around its defences; mobile testing covers the method. A cloud review uses Prowler or ScoutSuite to read account configuration. An internal network test uses BloodHound to chart how one ordinary account becomes domain administrator.

Where it stops: every one of these confirms something a tester already suspected. None of them decides what to suspect. The flaw that lets one customer read another customer's invoices is found by a person who understood what the application is for.

Reporting: turning results into decisions

The last phase uses the least interesting tools: a CVSS calculator, a reporting template, and the firm's own platform for tracking findings through to retest. The tooling here is about consistency. Severity in context is a judgement: a medium-rated finding on a system holding card data can matter more than a critical one on a test server nobody uses. What is inside a VAPT report goes through what a good one contains.

The tools a tester uses, and where each one stops

What to ask a vendor about tools

Four questions sort a real test from a scan with a cover page:

• Which tools will you run, in which phase, and are the commercial ones licensed? A web test run on Burp Suite Community Edition has no automated scanner behind it.
• How many of the tester-days are manual work against the mapped application, and how many are scanning?
• Who triages the scanner output before it reaches the report?
• Will the report show the request and response behind each finding, so your team can reproduce it?

A vendor who answers those clearly is selling the half of the work the tools cannot do. Writing a VAPT RFP turns the same questions into requirements.

When you know what you want tested, scope your test with the same questions a tester asks before quoting.