Penetration Testing Tools: The Stack We Actually Use

Ask ten pentesters what's in their kit and you'll get ten slightly different answers — but the overlap is huge, and it's smaller than most buyers expect. The penetration testing tools that matter aren't the ones with the flashiest dashboards. They're the handful you reach for on every engagement, in a specific order, because they map to how an attack actually unfolds: find the surface, poke it by hand, scan it wide, prove the hit, write it up. This is the stack we actually use — organized the way we use it, not alphabetized into a listicle you'll forget by lunch.

One thing up front, because it changes how you should read the rest: a tool is not a test. A scanner matches signatures. A pentester — or an autonomous agent doing the same job — chains findings into proven impact. Keep that distinction in your head and the whole toolchain snaps into focus.

A tool matches a signature; a tester builds a chain

Here's the mental model. Most pentest tools are pattern matchers. nuclei fires a template, gets a response, says "this looks like CVE-2023-whatever." That's a signature match. Useful. Fast. Also completely blind to whether the finding means anything in your environment.

The value a human (or a good agent) adds is chaining. A lone finding — an exposed .git directory, a verbose error, a user-controllable id parameter — is often a shrug on its own. The exposed .git leaks a config file. The config has an internal S3 bucket name. The bucket is misconfigured. Now you're reading other tenants' invoices. None of those four steps is a "critical" by itself. Together they're a breach, and no scanner will hand you that story. It'll hand you four unranked line items and let you figure it out.

A pentest is the connective tissue between findings. Tools produce the raw material; the test is what you build out of it.

So when I walk through the stack below, notice how each phase feeds the next. Recon output becomes scanner input. Scanner hits become manual targets. Manual targets become exploitation candidates. Exploitation becomes evidence. That flow is the pentest. The tools are just what you use to move through it.

Recon and OSINT: you can't test what you can't see

Every real engagement starts here, and it's the phase amateurs skip. If you point Burp at one hostname and start clicking, you've already lost — the interesting bugs are almost always on the subdomain nobody remembered to decommission.

Amass and Subfinder are the two I run first, together, because they cover each other's blind spots. Subfinder is fast and passive — it pulls from certificate transparency logs, DNS aggregators, and a stack of public sources without touching the target. Amass goes deeper, does active enumeration and DNS bruteforcing, and builds an actual graph of the attack surface. Run subfinder -d target.com to get a quick list, then let Amass grind for the long tail. The forgotten staging-api.target.com that still trusts a 2019 JWT secret? That's an Amass find.

Nmap is the tool everyone knows and half of them use wrong. It's not just nmap target.com. Service and version detection (-sV), the NSE scripts (--script), sensible timing (-T4 on a network you're allowed to be loud on, slower when you're not) — that's the difference between "port 443 is open" and "port 443 is a decade-old Apache with a known deserialization path." Nmap stays in the kit because port and service reality is the foundation everything else stands on. Underrated flag: -sC for default scripts on a first pass; it catches more low-hanging config issues than people give it credit for.

Rounding out recon: httpx to probe which of your hundred discovered hosts actually serve web content and what they respond with, and Shodan when you want to know what the internet already knows about your target before you send a single packet yourself. For network penetration testing specifically, this external view is the whole game — you're modeling exactly what an outside attacker sees.

The output of this phase isn't a report. It's a target list. Everything downstream runs against it.

Web proxying and manual testing: where the real bugs live

If I had to keep one category, it'd be this one. The intercepting proxy is where a pentester spends the most hours, because it's where the findings a scanner can't reach come from — broken access control, business-logic flaws, IDOR, auth bypass. The bugs that actually get companies breached. Which tools you reach for depends on scope — see how they fit a full web application penetration testing engagement.

Burp Suite is the incumbent for a reason. The Professional edition's Repeater and Intruder are muscle memory for anyone who's done this seriously — intercept a request, tamper with it, replay it, watch what changes. The BApp store extends it endlessly (Autorize for access-control testing, Param Miner for hidden parameters). Is it overrated? No — but the Community edition is close to useless for real work because it throttles Intruder into uselessness, and the Pro license is a genuine cost. Be honest about that when you're pricing a DIY toolchain.

Caido is the underrated challenger I tell people to actually try. It's a modern, Rust-based proxy — faster, lighter, a cleaner project/workflow model, and a far friendlier license than Burp Pro. For a lot of web app work it's already there, and the gap closes every release. If you're assembling a kit in 2026 and reflexively budgeting for Burp Pro, at least trial Caido first. You might not need the license.

What matters more than which proxy: this is manual work. Testing whether user A can read user B's data by swapping an id isn't something you automate away with a template. You reason about the application's intent and then violate it. That's the part of a pentest no tool does for you — and the part where an agent that can actually reason about responses, rather than pattern-match them, changes the economics.

Automated scanning: fast coverage, careful triage

Now the tools that go wide. These earn their place by finding the known-bad quickly so your manual hours go to the interesting stuff — but every one of them will hand you false positives, and triage is on you.

nuclei is the one I'd fight to keep. It's a template-based scanner with thousands of community-maintained checks for known CVEs and misconfigurations. Feed it your recon output (nuclei -l hosts.txt) and it'll sweep the whole surface in minutes. It's fast, open-source, and the template ecosystem is genuinely excellent. It's also exactly the "signature matcher" I warned about — a nuclei hit is a lead, not a finding, until you've confirmed it.

ffuf is the fuzzer I use for content discovery and parameter fuzzing. ffuf -u https://target/FUZZ -w wordlist.txt to find the admin panel nobody linked to; parameter fuzzing to surface hidden inputs. Underrated for how often it turns up the endpoint that everything else missed.

sqlmap is narrow and lethal. When you suspect SQL injection, nothing automates the confirmation and exploitation better — it'll enumerate the database, dump tables, and prove the impact. Overrated as a "run it on everything" tool (it's noisy and slow when pointed broadly); irreplaceable when you've already found a suspicious parameter and need to demonstrate what it leaks.

OWASP ZAP is the open-source proxy-plus-scanner. I'm honest about it: as a manual proxy it trails Burp and Caido, but as a free, automatable, CI-friendly scanner it's legitimately good — and its baseline scan is one of the better ways to bolt some security testing into a build pipeline without a license. For a team with no budget, ZAP plus nuclei plus ffuf gets you a real distance.

Notice what these have in common: they all produce volume. Coverage is their whole point. Which is also why the phase after them — deciding what's real — is where DIY toolchains quietly fall apart.

Exploitation: proving impact instead of asserting it

This is the phase that separates a vulnerability list from a penetration test. Anyone can say "you might be vulnerable." A pentest says "we exploited it, here's the proof."

Metasploit is still the framework of record for this. A vast library of exploit modules, payloads, and post-exploitation tooling, all in one place — use exploit/..., set your target, fire, catch a session. Is it overhyped in movies and undersold in practice? Both. Metasploit is heavy and its modules go stale, but for turning a known-vulnerable service into a working shell with evidence you can screenshot, it's still the fastest path. For black-box work, the modules that matter are the ones targeting the external-facing services your recon actually found.

Worth naming alongside it: Sliver as a modern, open-source command-and-control framework (the go-to since Cobalt Strike went expensive and heavily-flagged), and the credential category — Hashcat and John the Ripper for cracking hashes you've captured, Hydra for online brute-forcing where it's in scope. These are post-access tools. They matter once you're in, to answer "how far does this go" — which is exactly the question a real engagement has to answer and a scanner never asks.

The rule here: exploitation is where you must be careful and controlled. You're proving impact without breaking production. That judgment — how hard to push, when to stop — is the human part. It's also, notably, the part a well-instrumented autonomous system can do repeatably without fatigue or scope creep.

Reporting: the deliverable nobody's tool writes for them

Here's the dirty secret of the toolchain: none of it writes your report. And the report is the product. A client isn't paying for a Burp project file and a nuclei log — they're paying for a document their engineers can act on and their auditors will accept.

That means, for every finding: a clear title, a CVSSv3 score, reproduction steps, a working proof-of-concept, business impact in plain language, and a specific remediation. Mapping to a framework where relevant — OWASP Top 10, OWASP API Top 10, and for compliance work the controls in a proper methodology aligned to NIST SP 800-115 or the PTES phases. This is hours of writing per engagement, and it's the single biggest reason a manual pentest takes 4–6 weeks. Not the hacking. The writing.

There's no great open-source tool for this because it's fundamentally a synthesis problem — connecting technical findings to business meaning — and synthesis is where automation historically fell down. Historically.

The phase → tool map

Here's the whole stack in one view. This is roughly the order of a real engagement, and roughly what I reach for at each step:

Phase	What you're doing	Go-to tools	Open source?
Recon / OSINT	Map the full attack surface	Amass, Subfinder, Nmap, httpx, Shodan	Yes (Shodan freemium)
Web proxy / manual	Find logic & access-control bugs by hand	Burp Suite, Caido	Partly (Burp Pro paid)
Automated scanning	Sweep for known-bad, wide coverage	nuclei, OWASP ZAP, sqlmap, ffuf	Yes
Exploitation	Prove impact, get access, chain findings	Metasploit, Sliver, Hashcat/John, Hydra	Yes (Metasploit Pro paid)
Reporting	Turn findings into an actionable, scored report	(mostly manual)	—

The pattern jumps out: almost every phase has a genuinely excellent open-source option, and the paid tiers (Burp Pro, Metasploit Pro) buy convenience and support, not capability you can't get otherwise.

Open source vs commercial: what's overrated, what's underrated

My honest take after years of this: for the tooling itself, open source has basically won. nuclei, ffuf, sqlmap, ZAP, Amass, Metasploit's free framework — that's a complete, professional-grade offensive kit for the price of the hardware to run it. The open-source pentest toolchain is not a compromise; it's what most of us actually run.

What commercial tools sell you is time and polish. Burp Pro's Intruder saves you hours. Nessus (which I left off the core stack on purpose — it's a solid vulnerability scanner but it's a scanner, not a pentest tool, and people confuse the two constantly) gives you a maintained, supported CVE feed and clean output. Those are real conveniences. They are not the thing that makes a test good.

Overrated: any product marketed as "automated pentesting" that's really just a scanner with a nicer PDF export. Underrated: the boring open-source recon tools, because coverage — knowing your real attack surface — is worth more than any single fancy exploit and nobody sells it as a shiny SKU.

The trap DIY buyers fall into: they price the licenses and think that's the cost. The actual cost is the person who runs all of it, triages the false positives, chains the findings, and writes the report. The tools are cheap. The expertise and the hours are not.

Why a toolbox is not a test — and where AI changes the math

Put it all together and the gap is obvious. You can buy or download every tool above for close to nothing. What you can't download is the operator who runs recon, feeds it to the scanners, triages a hundred noisy hits down to the ten that matter, manually confirms the access-control bugs no scanner sees, exploits them into proven impact without breaking production, and then writes it all up mapped to the standards your auditor cares about. That labor is the pentest. The toolbox is just the toolbox.

This is exactly the seam autonomous AI pentesting is built into. Instead of one operator running one tool at a time, a swarm of agents orchestrates the same categories of tooling in parallel, at machine scale — recon feeding scanning feeding exploitation feeding validation, continuously, without the operator becoming the bottleneck. The agents don't just fire signatures; they reason across findings and chain them, which is precisely the part that was never a tooling problem in the first place.

That's what we built BackDoor to do. It runs an autonomous black-box pentest from the outside — no source code, no backend access, same vantage point as a real attacker — and returns a full report with proven exploits and working PoC, CVSSv3 scoring, and step-by-step fixes, mapped to SOC 2, ISO 27001, NIST CSF, GDPR Art. 32, and PCI DSS v4.0. Roughly five hours instead of four-to-six weeks, from €5,100. Zero data retention; NDA and DPA available.

I'll be straight about the limits, because the guide-not-hype rule cuts both ways: a fast autonomous scan is outstanding for coverage, for continuous testing, and for pre-audit readiness — but it is not a replacement for a human red team on the hardest, most creative engagements, and it is not a regulatory attestation like DORA TLPT. Compliance here means mapping your results to a framework, not us issuing a certificate. Anyone who tells you their scanner "certifies" you to ISO 27001 is selling something.

What to actually do next

If you're a practitioner assembling a kit: start with recon (Amass, Subfinder, Nmap), get comfortable in an intercepting proxy (try Caido before you pay for Burp), add nuclei and ffuf for coverage, keep Metasploit and sqlmap for proving impact, and accept that the report is manual and it's the hard part. That open-source stack is genuinely enough to do real work.

If you're a buyer deciding between building a toolchain and buying an outcome: the tools are the cheap part, and stitching them into a validated, written, standards-mapped report is the expensive part you were actually trying to avoid. That's the whole pitch for buying the outcome instead of the toolbox. Scan your target and get a proven-exploit report in ~5 hours from €5,100 — or read a sample report first and see exactly what "proven, not asserted" looks like on the page.

Tools find things. A pentest proves what they mean. Don't confuse owning the first for having done the second.