1 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Penetration testing tools: what professional testers use, phase by phase, and why the tool is never the test
Every penetration test uses dozens of tools, most of them public and many of them free. What separates a penetration test from a scan is not the software but the person choosing, chaining and interpreting it. This guide catalogues the tooling professionals use at each phase of an engagement, what each category finds, what it misses, and what you should ask a provider about their toolkit.
What penetration testing tools are, and what they are not
Penetration testing tools are software used to discover, enumerate, exploit and document weaknesses in systems during an authorised security test. They range from port scanners and intercepting proxies to exploitation frameworks, password auditors and reporting platforms. Almost all are publicly documented, most are open source, and a distribution such as Kali Linux ships with hundreds pre-installed. None of that makes them a penetration test.
The distinction matters because the market blurs it. A vulnerability scanner produces a list of known weaknesses matched against a signature database. A penetration tester uses that list as one input, then does the work the scanner cannot: confirming which findings are real, chaining three low-rated issues into one critical path, and testing the business logic and authorisation decisions that no signature covers. Tools find the known. Testers find the chained and the logical. If a provider's deliverable is a scanner export with a cover page, you have bought a scan, whatever the invoice says. Our article on manual versus automated testing covers that split; this page stays with the toolkit.
One legal note. Every tool below is lawful to own and to use on systems you are authorised to test. Used without written permission, the same tools constitute computer trespass (in the Netherlands, computervredebreuk under Article 138ab of the Criminal Code). Professional testers work under a signed scope and authorisation letter.
The toolkit by engagement phase
Methodologies such as PTES and NIST SP 800-115 divide a test into phases, and each phase has its own category of tooling. These are the names you will see in a professional report.
Reconnaissance and OSINT
Nmap maps which hosts are live and which services they expose, with version detection that feeds every later phase. Amass and theHarvester enumerate subdomains, hostnames and e-mail addresses from public sources, certificate transparency logs and DNS. Shodan and similar internet-wide search engines show what an attacker already knows about your perimeter before sending a single packet to it.
Web application testing
Burp Suite Professional is the intercepting proxy at the centre of almost every web test: it lets the tester see, modify and replay each request between browser and server. OWASP ZAP is its open-source counterpart. ffuf discovers hidden content and parameters, sqlmap confirms and characterises SQL injection, and Nuclei runs community templates for known misconfigurations and CVEs across many hosts at speed.
Network and Active Directory
Nessus or OpenVAS scan for known vulnerabilities and missing patches. NetExec and the Impacket library speak Windows network protocols to enumerate shares, sessions, policies and trust relationships. BloodHound graphs Active Directory permissions to reveal paths from a standard user to domain administrator. Responder tests whether legacy name-resolution protocols leak credentials on the network. Mimikatz, a credential-extraction tool, appears mostly as something the tester checks your endpoint protection detects.
Exploitation
The Metasploit Framework packages thousands of public exploits and payload handlers behind a consistent interface, so a tester can prove a vulnerability is exploitable rather than merely present. In practice much exploitation is custom: a short script that chains an authorisation flaw with an information leak, or an adaptation of a public proof of concept to the exact version in scope. The framework proves the known; the custom code proves the specific.
Password auditing
Hashcat and John the Ripper test the strength of password hashes recovered during the engagement against wordlists and rules. The output is not a list of passwords for its own sake but evidence about policy: how many accounts fall to a dictionary, how many share a pattern, whether the domain still stores legacy hash formats. That evidence drives password policy and MFA decisions.
Wireless
Aircrack-ng and hcxtools assess Wi-Fi networks: which encryption is in use, whether enterprise authentication is correctly configured, whether guest and corporate networks are truly separated and whether rogue access points are detected. On engagements that include a site visit these tools sit next to physical checks on network ports and badge systems.
Mobile applications
MobSF performs static and dynamic analysis of iOS and Android packages, surfacing hard-coded secrets, insecure storage and weak transport settings. Frida and objection instrument the running app so the tester can inspect what it does at runtime, test certificate pinning and examine how it handles authentication tokens. The backend API behind the app is tested with the web toolkit.
Cloud
Prowler and ScoutSuite audit cloud accounts against security benchmarks and report on identity, logging, storage and network configuration. Pacu is an exploitation framework for AWS that tests whether a misconfiguration is actually usable. ROADtools enumerates Microsoft Entra ID (formerly Azure AD) tenants so the tester can map identities, roles and application permissions.
Reporting and evidence
Collaborative reporting platforms (Ghostwriter and Dradis are open-source examples) hold findings, evidence, screenshots and remediation text in one place so a team writes consistently and a client can track fixes. The FIRST CVSS v4.0 calculator scores severity in a repeatable way. Good reports also cite the tool and version used for each finding so results can be reproduced.
Why the same tool gives different results in different hands
Take Burp Suite Professional. Its automated scanner is competent, and a junior tester who runs it and files the output has done something. A senior tester uses the same product differently: mapping every role and workflow manually first, then testing each authorisation boundary by replaying requests as a different user, then probing the business logic (can a discount be applied twice, can a step be skipped, can an identifier be swapped) that no scanner understands because it has no model of what the application is for. The licence is identical; the findings are not.
The same applies to Active Directory. BloodHound draws the graph for anyone. Deciding which of the thousand edges is realistic in this environment, confirming it without locking out accounts or alerting the SOC, and explaining why a helpdesk group's permissions are the real problem: that is the test. The tool makes the data visible. The tester makes it mean something.
This is why the OWASP Web Security Testing Guide and Mobile Application Security Testing Guide are organised around test cases, not products. A methodology says what must be checked; the toolkit is whatever gets each check done this year.
What each tool category finds, what it misses and who should run it
Use this table to read a proposal. If the provider's method relies only on the first two rows, you are buying scanning, not testing.
| Tool category | What it finds | What it misses | Who should run it |
|---|---|---|---|
| Vulnerability scanners (Nessus, OpenVAS, Nuclei) | Known CVEs, missing patches, default configurations, common misconfigurations | Business-logic flaws, authorisation errors, chained attack paths, anything without a signature | Your own IT or security team, continuously; a tester, as the first pass of an engagement |
| Reconnaissance (Nmap, Amass, theHarvester, Shodan) | Exposed hosts and services, forgotten subdomains, shadow IT, leaked metadata | Whether an exposure is exploitable or matters to the business | Attack-surface management teams and testers; results need human triage |
| Web proxies and fuzzers (Burp Suite Professional, ZAP, ffuf, sqlmap) | Injection, broken access control, hidden endpoints, session weaknesses, logic flaws when driven manually | Everything it is not pointed at; coverage depends entirely on the operator | Trained application testers under authorisation; developers for pre-release checks in test environments |
| AD and network toolkits (NetExec, Impacket, BloodHound, Responder) | Privilege-escalation paths, weak protocol configurations, credential exposure, excessive permissions | Whether the path is realistic under current monitoring; impact needs human judgement | Internal penetration testers and red teams, with the SOC informed or deliberately uninformed per scope |
| Exploitation frameworks and custom code (Metasploit, bespoke scripts) | Proof that a vulnerability is exploitable and what access it yields | Vulnerabilities for which no public exploit exists, unless the tester writes one | Experienced testers only, with rules of engagement and rollback agreed in advance |
| Password auditors (Hashcat, John the Ripper) | Weak and reused passwords, legacy hash formats, policy gaps | Credentials never captured; the phishing resistance of users | Testers during an engagement; internal teams for periodic policy audits on their own hashes |
| Cloud auditors (Prowler, ScoutSuite, Pacu, ROADtools) | Benchmark deviations, over-privileged identities, public storage, missing logging | Application-layer flaws in what runs on the cloud; cross-account logic | Cloud platform teams continuously; testers for exploitability and identity-path review |
| Reporting platforms and CVSS v4.0 | Consistent severity, reproducible evidence, remediation tracking | Nothing by itself; a reporting tool only structures what the tester found | Every provider; ask to see a sample report |
A scanner export is not a penetration test
The most common disappointment in this market is a deliverable listing two hundred findings, most informational, ranked by a scanner's generic severity, with no evidence of exploitation and no narrative. It satisfies no auditor who reads carefully. ISO 27001:2022 control A.8.8 asks for technical vulnerability management, which a scan supports; the evidence auditors expect under A.8.29 is a penetration test with a documented methodology and a human behind it. PCI DSS v4.0.1 makes the distinction explicit by requiring both: vulnerability scans under Requirement 11.3 and penetration testing under 11.4.
The signs of a real test are visible in the report: a scope statement naming the systems and roles tested; a methodology section citing PTES, OWASP WSTG or NIST SP 800-115; findings with reproduction steps and screenshots rather than scanner plugin IDs; an attack narrative that shows how findings connect; and severity that reflects your environment rather than a database default. Our article on penetration test versus vulnerability scan covers the buying implications; both have a place and neither substitutes for the other.
What a buyer should ask about tooling
You do not need to know the tools yourself. You need to know that the provider does, keeps them current, and handles what they produce responsibly.
- Which commercial tools are licensed, and to whom. Burp Suite Professional and Nessus Professional are licensed per tester; a provider that cannot name its licences is using community editions or sharing seats.
- How scanners are kept current. Vulnerability databases and Nuclei templates update daily; a scan run on a stale engine misses the last month of CVEs.
- What the ratio of automated to manual effort is, by phase, and how manual testing is evidenced in the report.
- How evidence is handled: where screenshots, credentials and extracted data are stored during the test, who can access them, how they are encrypted and when they are destroyed.
- Whether exploitation is in scope and how it is controlled: rules of engagement, stop criteria, out-of-hours windows for production systems, and a named contact for escalation.
- Whether custom tooling or exploit code written for your engagement is disclosed, and whether any of it is retained afterwards.
- How severity is scored. CVSS v4.0 is the current standard; ask whether environmental factors are applied or whether scores are copied from a database.
- Whether the report names each tool and version used per finding, so your team can reproduce results and retest after fixes.
How HackersHub works with tooling
Our testers each hold at least OSCP, with OSWE and CREST-certified testers on the team, and each works from a licensed, maintained toolkit: licensed commercial tooling such as Burp Suite Professional for application work, current commercial and open-source scanners for the first pass, and the Active Directory, cloud and mobile toolkits described above where the scope calls for them. Methodology follows PTES, OWASP WSTG and MASTG, and NIST SP 800-115, so the test cases drive the tooling rather than the reverse.
Evidence is handled on encrypted engagement infrastructure, limited to the named testers, and destroyed on a schedule agreed in the contract. Every report carries an executive summary, CVSS-scored findings with reproducible evidence, an attack narrative and prioritised remediation, and includes a verification retest of medium and higher findings within 90 days. Michael van Mameren, Lead Penetration Tester (OSCP), reviews reports for exactly the gap this article describes: a finding that a scanner produced and no one confirmed does not leave the building.
Frequently asked questions
Related reading
- Penetration testing services: scope a test with HackersHub
- What is penetration testing? Meaning, phases and methodology
- Manual vs automated penetration testing
- Penetration test vs vulnerability scan: which do you need?
- What does a penetration tester do?
- OT and ICS penetration testing: a different toolkit for industrial systems
- What a penetration testing report should contain
Want to see the toolkit behind the report?
A scoping call sets out which systems we test, which methods and tools apply to each, who the named testers are and how evidence is handled. Licensed tooling, documented methodology, human judgement. Talk to an expert.