Pentesting Tools & Technology Explained
A plain-English guide to pentesting tools: what they do, how they fit into a legal engagement, and the core categories from recon to reporting.
What Are Pentesting Tools?
Pentesting tools are software and hardware technologies used by authorised security professionals to identify, exploit, and document vulnerabilities in computer systems, networks, and applications during a structured penetration testing engagement. They are instruments within a governed methodology, not standalone products to be picked up and run against any target of choice.
Vulnerability scanners sit in a related but distinct category: they identify known weaknesses through automated signature matching but do not attempt exploitation. Monitoring tools observe network or system behaviour for anomalies but play no offensive role. Security testing platforms bundle scanning, reporting, and workflow features but still rely on a tester's judgement to interpret and act on results. Pentesting tools differ from all three because they are used to actively probe, exploit, and prove that a weakness is real and impactful, not merely theoretical.
Ownership and use of these tools are legal in the UK and most jurisdictions. What makes their use lawful is authorisation: a signed scope of work, defined rules of engagement, and written permission from the system owner before a single scan or exploit attempt is run. The tools themselves carry no criminal weight; the authority to point them at a specific target does.
A professional toolchain is sequenced rather than random. Each category below feeds the next, and which tools get used, in what order, and for how long, is decided by the engagement's scope rather than a tester's personal preference.
| Tool Category | What It Does | When Used in an Engagement |
|---|---|---|
| Reconnaissance | Gathers information about the target without direct interaction (domains, employees, infrastructure footprint) | Before any active scanning begins |
| Scanning and enumeration | Identifies live hosts, open ports, running services, and software versions | Immediately after reconnaissance, before exploitation |
| Exploitation | Attempts to actively leverage a discovered weakness to gain access or prove impact | Once a viable vulnerability has been confirmed |
| Post-exploitation | Maintains access, escalates privileges, and tests lateral movement across the environment | After initial access has been achieved |
| Password cracking | Recovers plaintext credentials from captured hashes or attempts brute-force authentication | Wherever credential material is obtained during the test |
| Traffic analysis | Captures and inspects network packets to reveal protocols, data flows, and weaknesses in transit | Throughout the engagement, particularly during exploitation and post-exploitation |
| Reporting | Consolidates screenshots, logs, and tool output into a structured, evidenced record | At the close of active testing, ahead of delivery |
How Tools Are Combined Across the Pentesting Process
Professional pentesting engagements move through a fixed sequence of phases, and each phase calls for a different combination of tools rather than one tool run in isolation. Scoping and intelligence gathering set the target boundary, reconnaissance builds the attack surface picture, scanning and enumeration confirm live services, exploitation proves impact, post-exploitation tests the blast radius, and reporting turns everything into evidence. Re-testing closes the loop once fixes are applied.
Tool orchestration is the tester's judgement at work: deciding which tool runs next depends on what the previous tool revealed. A closed port removes a line of attack; an exposed admin panel opens three more. This is why a pentest cannot be reduced to a single automated pass, no matter how comprehensive that pass appears on paper.
| Phase | Tool Category | Representative Tools | Purpose |
|---|---|---|---|
| Scoping & intelligence gathering | OSINT | Shodan, theHarvester, manual research | Confirm target boundary and build initial context |
| Reconnaissance | Passive & active recon | Nmap, Recon-ng, OSINT frameworks | Map the visible attack surface |
| Scanning & enumeration | Network and vulnerability scanning | Nmap, Nessus, OpenVAS | Identify live hosts, services, and known weaknesses |
| Exploitation | Exploitation frameworks | Metasploit, Burp Suite, custom scripts | Prove that a vulnerability can be leveraged |
| Post-exploitation | Privilege escalation & persistence | Metasploit, Empire, Cobalt Strike | Test lateral movement and the extent of compromise |
| Reporting | Evidence consolidation | Dradis, Faraday, screenshots and logs | Convert raw output into an actionable report |
| Re-testing | Targeted verification | Same tools used against remediated issues | Confirm fixes have closed the original weakness |
Every screenshot, log entry, and packet capture generated during active testing becomes part of the evidence chain that the final report relies on. A finding without supporting evidence is an assertion; a finding backed by tool output, timestamps, and reproduction steps is something a development team can actually act on.
The Core Tool Categories and What They Achieve
Each tool category solves one specific problem within an engagement and none of them substitute for the others. Understanding what each category cannot do is as important as knowing what it can, because over-trusting one category is a common source of gaps in weaker engagements.
Reconnaissance and OSINT tools
Reconnaissance tools gather publicly available information about a target, including subdomains, exposed metadata, and employee footprints, without touching the target system directly.
They do not confirm exploitability; they only build the map that later phases act on.
Network scanning and enumeration tools
Network scanning tools discover live hosts, open ports, and running services across an infrastructure, with Nmap as the category anchor.
They cannot determine whether a discovered service is actually vulnerable, only that it exists and is reachable.
Vulnerability scanners
Vulnerability scanners such as Nessus, OpenVAS, and Qualys automatically check systems against databases of known CVEs and misconfigurations.
They cannot find logic flaws, business-rule bypasses, or anything outside their signature database, which is why automated scan output always needs human validation before it reaches a report.
Web application testing tools
Web application testing tools such as Burp Suite and OWASP ZAP intercept, modify, and fuzz HTTP traffic to test input validation and session handling.
They cannot understand a business workflow well enough to spot a logic bypass on their own; that interpretation is a human task.
Exploitation frameworks
Exploitation frameworks such as Metasploit, Cobalt Strike, and Core Impact structure and execute known exploit code against confirmed vulnerabilities.
They frequently fail against patched, modern systems, and their real value in skilled hands is in chaining smaller weaknesses together rather than firing a single canned exploit.
Password cracking and brute-force tools
Password cracking tools such as John the Ripper and Hashcat recover plaintext credentials from captured hashes using dictionary and brute-force methods.
They only work once credential material has already been obtained elsewhere in the engagement.
Traffic analysis and packet inspection tools
Traffic analysis tools such as Wireshark and tcpdump capture and dissect network packets to reveal protocol behaviour and unencrypted data.
They are passive by design and cannot exploit anything themselves, only reveal what is happening on the wire.
Post-exploitation and C2 tools
Post-exploitation and command-and-control tools such as Empire, Metasploit, and Cobalt Strike maintain access and test lateral movement after an initial compromise.
They cannot decide when to stop; that boundary is set by the rules of engagement and the tester's judgement, not the tool.
Reporting and evidence tools
Reporting tools such as Faraday and Dradis consolidate scan output, screenshots, and notes into a structured record ready for write-up.
They organise evidence but cannot prioritise findings by business risk on their own, which remains a tester's responsibility.
The Classic Tools Every Pentester Uses
Certain tools recur across almost every professional engagement regardless of scope, and understanding what each one actually does, and does not do, gives a non-technical reader a working baseline for judging provider capability.
Kali Linux
- What it does: Kali Linux is a Debian-based operating system that packages several hundred pentesting tools into a single, pre-configured environment rather than being a tool itself.
- Why it matters: It gives testers a standardised, consistent platform, removing setup inconsistency between engagements.
- Where it's used: It is used across virtually all engagement types as the base operating environment.
- Limitation: It provides no capability by itself; the value lies entirely in the tools installed on it and the skill applying them.
Nmap
- What it does: Nmap is a network scanning utility that discovers live hosts, open ports, and running services across an IP range.
- Used for: It is used in professional engagements to build the initial map of exposed infrastructure before exploitation begins.
- Engagement types: Network and infrastructure engagements rely on it most heavily.
- Limitation: It cannot confirm whether an exposed service is genuinely vulnerable, only that it is present and reachable.
Burp Suite
- What it does: Burp Suite is an interception proxy used to capture, inspect, and modify HTTP and HTTPS traffic between a browser and a web application.
- Used for: Professional testers use it to manipulate requests, test input validation, and probe authentication and session handling.
- Engagement types: Web application engagements depend on it more than any other single tool.
- Limitation: It requires significant manual configuration and tester expertise; unattended, its automated scanner alone misses most business logic issues.
OWASP ZAP
- What it does: OWASP ZAP is an open-source web application security scanner that intercepts traffic in a similar way to Burp Suite.
- Used for: It is commonly used for automated web scanning inside CI/CD pipelines where continuous, lower-cost coverage is needed alongside manual testing.
- Engagement types: Web and DevSecOps-adjacent engagements use it most.
- Limitation: Its limitation mirrors other scanners: it flags known patterns well but cannot reliably identify custom logic flaws.
Wireshark
- What it does: Wireshark is a network protocol analyser that captures and inspects packet-level traffic in detail.
- Used for: Testers use it to verify what data is actually transmitted in the clear, confirm protocol behaviour, and troubleshoot findings from other tools.
- Engagement types: Network and infrastructure engagements use it most frequently.
- Limitation: It is passive analysis only; it cannot exploit anything, it can only show what is happening.
Metasploit
- What it does: Metasploit is an exploitation framework containing a large, maintained database of known exploits, payloads, and post-exploitation modules.
- Used for: Professional testers use it to execute and chain exploits against confirmed vulnerabilities and to test post-exploitation scenarios such as privilege escalation.
- Engagement types: Network, infrastructure, and internal engagements rely on it heavily.
- Limitation: Out-of-the-box exploits frequently fail against patched, modern systems; the real skill is in adapting or chaining modules rather than firing them unmodified.
John the Ripper and Hashcat
- What they do: John the Ripper and Hashcat are password cracking tools that recover plaintext credentials from captured password hashes.
- Used for: John the Ripper supports a wide range of hash formats and is often used for its flexibility, while Hashcat is GPU-accelerated and used where raw cracking speed matters more than format breadth.
- Engagement types: Both appear across nearly every engagement type once credential material has been captured.
- Limitation: Their shared limitation is that they only work on hashes already obtained elsewhere; neither tool captures credentials on its own.
| Tool | Primary function | Most common engagement types | Key limitation |
|---|---|---|---|
| Kali Linux | Pre-configured OS bundling pentesting tools | All engagement types (base environment) | No capability on its own; value comes from tools and tester skill |
| Nmap | Host discovery, port scanning, service enumeration | Network and infrastructure | Cannot confirm actual exploitability, only presence of a service |
| Burp Suite | Interception proxy for web traffic manipulation | Web application | Requires manual configuration and expertise; automated scan alone misses logic flaws |
| OWASP ZAP | Open-source web application scanning | Web and DevSecOps/CI/CD | Cannot reliably identify custom logic flaws |
| Wireshark | Packet-level traffic capture and protocol analysis | Network and infrastructure | Passive analysis only; cannot exploit |
| Metasploit | Exploitation framework with exploit and payload database | Network, infrastructure, and internal | Out-of-the-box exploits often fail against patched systems |
| John the Ripper / Hashcat | Password hash cracking | Nearly all engagement types once credentials are captured | Only works on hashes already obtained elsewhere |
Tool selection in a professional engagement is driven by what the scope requires, not by which brand a tester prefers. A capable provider will justify why a particular tool is being used against a particular target rather than defaulting to a fixed personal toolkit.
Modern Tooling for Cloud, APIs, Containers, and Mobile
Modern engagements increasingly test infrastructure that classic tools were never designed to reach, including cloud platforms, containerised workloads, and API-driven applications. A provider still relying solely on Nmap and Burp Suite is unlikely to be testing these environments properly.
Cloud security testing tools
Cloud testing tools audit configuration and privilege paths across cloud platforms rather than exploiting traditional network services.
- ScoutSuite audits security posture across AWS, Azure, and GCP configurations.
- Prowler runs AWS-specific security and compliance checks.
- Pacu is an AWS exploitation framework used to test what an attacker could actually achieve after gaining a foothold.
Equivalent tooling exists for Azure and GCP identity and configuration review.
Container and Kubernetes testing tools
Container testing tools examine container images and orchestration layers for misconfiguration and runtime risk.
- kube-hunter probes Kubernetes clusters for exploitable weaknesses.
- kube-bench checks cluster configuration against CIS benchmarks.
- Trivy scans container images for known vulnerabilities.
- Falco monitors runtime behaviour for suspicious activity.
These matter because a securely written application can still run on a misconfigured cluster.
API testing tools
API testing tools focus on authentication, authorisation, and rate-limiting behaviour rather than the visual application layer.
- Postman is widely used to construct and manipulate API requests during testing.
- Burp Suite extends into API testing through its proxy and repeater functions.
Testing whether one user can access another user's data through an API endpoint is a routine, high-value check in this category.
Mobile application testing tools
Mobile engagements require traffic interception and binary analysis tooling in addition to standard web testing tools, because a mobile app usually has both a client-side binary and a server-side API to assess. This adds genuine complexity compared with a standard web test, since both sides need separate scrutiny.
Most modern engagements are hybrid by necessity: classic infrastructure and web tools handle the parts of the environment that behave conventionally, while cloud, container, or API-specific tools cover the parts that do not.
How Tools Are Matched to Engagement Scope
Tool selection follows the engagement type, not the other way round, and a provider that arrives with an identical toolkit regardless of what is being tested is a warning sign worth noticing during procurement.
| Engagement Type | Primary Tool Categories | Representative Tools | Typical Objectives |
|---|---|---|---|
| Network | Scanning, exploitation, password cracking | Nmap, Wireshark, Metasploit | Infrastructure discovery, exploitation, lateral movement testing |
| Web application | Interception, fuzzing, scripting | Burp Suite, OWASP ZAP, custom scripts | Input validation, session handling, business logic testing |
| Mobile application | Traffic interception, binary analysis | Burp Suite, mobile-specific interception tools | Client-side binary review and server-side API testing |
| Cloud infrastructure | Configuration auditing, privilege-path analysis | ScoutSuite, Prowler, Pacu | Identity and access management review, misconfiguration detection |
| API | Interception, fuzzing | Burp Suite (API mode), Postman | Authentication, authorisation, input validation testing |
A network penetration test, a web application penetration test, a mobile application penetration test, and a cloud penetration test each demand a different tool priority list, decided during scoping rather than fixed in advance. This is the point in a procurement conversation where it is worth asking a provider directly which tools they intend to use for your specific environment and why.
Manual Testing Versus Automated Tooling
Automated tooling is good at breadth, speed, and repeatability: it can scan thousands of hosts for known CVEs in a fraction of the time a human would take, and it does so consistently every run. Manual testing is good at everything automation structurally cannot reach: chaining unrelated weaknesses together, spotting a flawed business rule, and judging what actually matters to the organisation being tested.
| Capability | Automated Tooling | Manual Testing |
|---|---|---|
| Known vulnerability detection | Fast and consistent | Slower, but validates false positives |
| Logic flaw detection | Cannot reliably detect | Core strength |
| Chaining multiple weaknesses | Not capable | Core strength |
| Business context judgement | None | Core strength |
| Coverage at scale | Core strength | Limited by time |
Claims of "fully automated pentesting" should be treated with caution: even tool vendors themselves, such as Pentest-Tools.com, generally position their platforms as a complement to human testers rather than a replacement. If a provider offers no human validation step at all, some findings in that report have likely never been proven exploitable, only flagged.
Is Pentesting Legal?
Pentesting tools are legal to own and use, and professional penetration testing is legal when it is conducted with proper written authorisation from the system owner. Running the same tools against systems you do not own, or without documented permission, is a criminal offence under the Computer Misuse Act 1990 in the UK.
Authorisation is not a formality; it is the document that defines which systems are in scope, which techniques may be used, and what the tester is permitted to do if they gain access. Professional engagements are governed by signed contracts, agreed rules of engagement, and defined scope precisely so that both parties know where the legal and technical boundary sits before testing starts.
What makes a pentest legal?
A written scope agreement, signed authorisation from the system owner, and defined rules of engagement together make a penetration test legal.
What makes running these tools illegal?
Running pentesting tools against a system without the owner's written permission is what makes the activity illegal, regardless of intent.
How do I make sure my organisation is tested legally?
Hiring a professional provider who works to a signed scope and documented rules of engagement is the standard way to ensure testing is conducted legally, safely, and within agreed boundaries.
The Role of Human Expertise in Using Pentesting Tools
A tool list is not a capability statement, and the quality of a pentest is determined far more by the tester operating the tools than by which tools appear on the invoice.
Skilled testers bring:
- Knowledge of application architecture
- An understanding of business logic
- Creativity in designing attack paths that no scanner configuration can replicate
Automated tools produce a meaningful amount of noise, including false positives that look like findings but are not exploitable in practice. Professional testers manually validate every finding before it reaches a report, which is the step that separates a credible pentest from a raw scan export.
Exploitation also requires judgement calls that tools cannot make:
- Knowing when a technique risks operational disruption
- How far to escalate a proof of concept
- When enough evidence has been gathered to demonstrate impact without causing harm to live systems
This is a professional and often contractual boundary, not a technical limit of the tool itself.
The clearest sign of expertise is what happens after the tools stop running. Turning raw scan output, packet captures, and exploitation logs into a prioritised, remediation-ready report is where professional judgement adds the value that tooling alone cannot supply.