How to choose pentesting tools that fit the job

Every example here assumes written authorization, a defined scope, a controlled target, and explicit rate limits. This is practical security guidance for a lab or authorized engagement, never permission to scan or exploit arbitrary systems.

Use Nmap for exposed services, ffuf for reachable web content, and Burp Suite for request behavior. Use sqlmap to investigate a credible SQL injection hypothesis. Use Metasploit for known-vulnerability validation and authorized post-exploitation. The point is the handoff: you’ll carry Nmap XML into Metasploit, move ffuf discoveries into Burp, and preserve a Burp request for bounded sqlmap testing.

A pentest is not a tour of Kali Linux. The useful tool answers the next question raised by your evidence. This guide follows a small engagement from scope and reconnaissance through web discovery, manual validation, bounded SQL injection testing, and known-vulnerability validation.

In this article

• Start with scope, not a command
• Pick tools by the question you need answered
• Nmap tells you what is exposed, not what is exploitable
• ffuf expands the web surface before you test it
• Burp turns a discovered endpoint into a testable request
• sqlmap automates confirmation after you understand the request
• Metasploit is for reliable validation, not magical stealth
• The handoffs matter more than the individual tools
• Choose the smallest stack that answers the next question

Start with scope, not a command

Before opening a terminal, clarify the testing window, permitted exploit classes, traffic limits, and evidence handling in the rules of engagement. Then define success in observable terms. Identify exposed services, map the reachable web surface, validate material findings, and produce reproducible evidence.

ShieldOperations frames an engagement across reconnaissance, exploitation, post-exploitation, and reporting. Use that as a useful mental model, then attach every command to one of those jobs. Keep raw requests, scan output, timestamps, and notes together. Stop when the scope ends or the next action would exceed it.

Pick tools by the question you need answered

Penetration testing tools work as a chain. Each one leaves an artifact that answers the next question.

Question	First tool	What it gives you	What it does not prove
Which hosts and services are exposed?	Nmap	Ports, service/version observations, selected script results	That a service is exploitable
What web paths or files are reachable?	ffuf	Candidate directories, routes, parameters, or files	That a discovered path is vulnerable
How does the application behave?	Burp Suite	Captured requests, responses, parameters, and authorization observations	That an automated alert is valid
Is a parameter injectable through SQL?	Burp, then sqlmap	A manually understood request and bounded SQLi confirmation	Permission to dump data or reach the operating system
Does a known vulnerability apply?	Metasploit	Module checks and, when authorized, repeatable exploitation or session workflows	Stealth or a universal exploit path

But this chain won’t cover every engagement. Cloud identity, Active Directory, mobile apps, and authenticated vulnerability scanning need different tools. I’d measure coverage against the scope before calling five tools sufficient.

Nmap tells you what is exposed, not what is exploitable

Ask the least invasive question first. What answers on the approved target?

For the fictional engagement below, the in-scope staging host is staging.acme.test, with app.acme.test and an approved internal test network also included. Begin with service and version detection, default scripts, and one XML artifact you can reuse:

nmap -sV -sC -oX /tmp/acme-nmap.xml staging.acme.test

-sC means --script=default. Nmap’s XML file becomes the structured handoff for later tooling. A version string remains evidence to verify, not a definitive product identity.

Nmap’s NSE is Lua-based, runs scripts in parallel, and supports discovery, version detection, vulnerability detection, and exploitation, according to the official NSE documentation. That range is useful, and it’s exactly why restraint matters. Nmap is reconnaissance first and a lightweight verifier second. Running --script "all" because it is easy is careless testing: the official documentation says that category includes exploit, brute-force, and denial-of-service scripts.

Use a named script when you have a named question. To inspect available HTTP scripts and their arguments without running them:

nmap --script-help "http-*"

Then select the script and port deliberately:

nmap -p 443 --script <script-name> --script-args <key=value> staging.acme.test

The Nmap NSE documentation portal lists script arguments. Review the script before execution; Nmap warns that “Scripts are not run in a sandbox and thus could accidentally or maliciously damage your system or invade your privacy.”

Suppose the scan identifies HTTP, HTTPS, and an additional service. That raises three separate questions: which web application is listening, which routes are reachable, and whether the extra service has a version-specific issue. ffuf and Burp handle the web questions. A narrowly selected NSE script may help with the service question.

Nmap’s XML import populates hosts, services, and related findings in Metasploit; it does not prove that a Metasploit module applies. If you need broad authenticated vulnerability coverage, use a dedicated scanner under its own scope. NSE remains targeted verification.

ffuf expands the web surface before you test it

A web server can expose an administration path, API endpoint, report directory, or forgotten backup that the homepage never links. Find that surface before spending an hour testing the wrong entry point.

For a bounded content-discovery run, place FUZZ where each wordlist entry should go:

ffuf -u https://staging.acme.test/FUZZ \
  -w /path/to/approved-wordlist.txt \
  -mc 200,204,301,302,307,401,403 \
  -fs <baseline-size> \
  -rate 10

The placeholders matter. Measure the ordinary nonexistent-path response first, replace <baseline-size> with its response size, and use a wordlist approved for the engagement. -mc matches selected status codes, -fs filters a known response size, and -rate 10 caps the request rate at ten requests per second. Check the installed ffuf version with ffuf -h; flags and output details should match the version you will run.

Record candidate paths, status codes, response sizes, redirects, and timestamps. If the run finds /reports/, preserve that URL and send it into Burp. The route’s existence is a discovery result. Its security significance comes from what the application does with it.

Do not fuzz outside the permitted host and path scope. A wordlist is not a license to test every virtual host you can guess.

Burp turns a discovered endpoint into a testable request

The useful moment in web testing is an ordinary request you can reproduce and explain. For illustration, treat the value below as a placeholder:

GET /reports/view?id=<record-id> HTTP/1.1
Host: staging.acme.test
Cookie: <authorized-session>

Capture the discovered route through Burp’s proxy, then send a copy to Repeater. Change one input at a time. Observe validation, object access, authorization boundaries, error handling, and response differences. Preserve the request, response, and session notes as evidence.

Pentest.ae identifies Burp’s intercepting proxy, Repeater, Intruder, active scanner, and BApp extension store as its main components. That combination is why I prefer Burp when manual request analysis is the bottleneck: the judgment stays close to the request.

Burp Pro is worth paying for when manual request analysis is your bottleneck. If your job is mostly scheduled DAST in CI, paying for an interactive workbench is the wrong optimization; use ZAP and spend the budget on review.

OWASP ZAP is free software under the Apache 2.0 license and fits automated DAST pipelines. The project is commonly called OWASP ZAP and is now reported as stewarded by Checkmarx. Comparisons generally favor Burp Pro for interactive manual work and scanner accuracy. ZAP’s advantage is free automation and CI/CD integration; treat that as a comparative judgment, not a benchmark.

An active scanner may surface an interesting response. Authorization logic, business logic, and manual confirmation still require you.

sqlmap automates confirmation after you understand the request

First identify a credible candidate manually. Understand the parameter, normal response, authentication requirements, and impact boundary. Database support across MySQL, PostgreSQL, Microsoft SQL Server, Oracle, and SQLite does not make every application or injection technique equally testable. Identify the request behavior before escalating.

Save the captured request as /tmp/request.txt, then use sqlmap’s request-file syntax:

sqlmap -r /tmp/request.txt -p <parameter> --batch

-r reads the full HTTP request from a file, while -p limits testing to the parameter you selected. Check that the file contains the correct host, path, cookies, method, and content type. Remove unrelated credentials where possible, and confirm that the request still targets the authorized system.

A bounded sequence looks like this:

1. Test one manually understood parameter.
2. Confirm whether injection is reproducible.
3. Enumerate database names or tables only when the rules allow it.
4. Extract the minimum data needed to demonstrate impact.
5. Stop before operating-system access unless that capability is explicitly authorized and necessary.

EthicalHacking.ai documents options such as --dbs, --tables, and --dump. Treat higher --level and --risk values as deliberate escalation controls, never as a starting preset.

Options such as --os-shell and --file-read can access systems or data beyond the original parameter. Use them only with explicit approval and a demonstrated need. A WAF response also needs interpretation: tamper scripts such as space2comment, between, randomcase, charunicodeencode, equaltolike, and greatest address particular filtering behavior. Trying one does not establish a bypass or prove the underlying issue.

sqlmap can test the parameter you give it; it cannot decide whether that parameter represents an authorization flaw, a business-logic bug, or an acceptable test boundary. Stop when the evidence is reproducible and the report has enough impact data.

Metasploit is for reliable validation, not magical stealth

Metasploit enters after reconnaissance produces a service, version, or vulnerability hypothesis worth testing. Give each engagement its own workspace. Import the same Nmap artifact:

workspace -a <client_name>
db_import /tmp/acme-nmap.xml
hosts
services
vulns

Select a module only when it matches the evidence. Exploit modules attempt a vulnerability. Auxiliary modules perform checks or support other actions. Post modules operate through an established session. Payloads define what runs after exploitation; encoders transform the payload representation. Inspect the module’s options and description, then run check before exploit when available. That extra step is boring, and it can prevent a guessed version from triggering an unnecessary attempt.

Post modules may collect hashes or credentials, suggest local exploits, or extend a session. Treat credential collection and hash extraction as data access, with explicit approval, a collection limit, and secure evidence handling.

Metasploit Framework is useful for repeatable validation, session management, and authorized post-exploitation. Metasploit Pro is a separate commercial product; secondary planning material places its approximate cost around $15,000 per year, so treat that as an estimate rather than a universal price.

RingSafe reports that modern AV catches default Meterpreter signatures within 24 hours and that encoding alone is insufficient. That is practitioner guidance, not an independently verified universal detection statistic. Use that finding to reject default payloads as evidence of endpoint weakness; do not turn this guide into an evasion recipe.

Metasploit is strongest for known vulnerabilities, repeatable checks, session-management infrastructure, and post-exploitation automation. Leading-edge stealth requires a separately authorized and reviewed approach.

The handoffs matter more than the individual tools

A small authorized run might produce this chain:

1. Nmap identifies HTTP, HTTPS, and an additional service on staging.acme.test. Write the result to /tmp/acme-nmap.xml.
2. ffuf finds /reports/. You preserve the exact URL, timestamp, status, response size, and redirect behavior.
3. Burp captures a request to that route and shows a parameter whose behavior deserves testing. You preserve the raw request, response, and session notes.
4. sqlmap receives that request only if the parameter supports a credible SQL injection hypothesis. It may confirm the issue, or it may produce no useful result.
5. Metasploit imports the Nmap XML only if service evidence matches a known vulnerability worth validating. It may never be appropriate.

The sequence can move backward. A Burp response may send you back to ffuf for a related API path. A service version may justify targeted NSE before Metasploit. A clean sqlmap result may end that branch entirely.

Keep the artifacts connected: scan output, discovered URL, captured request, confirmation result, and validated module. This continuity makes the assessment defensible.

Choose the smallest stack that answers the next question

Testing need	Choose	Next artifact
Network inventory	Nmap	Service list and XML output
Targeted service verification	Selected Nmap NSE scripts	Script result tied to a hypothesis
Hidden web content	ffuf	Candidate URL and response metadata
Manual web behavior	Burp Suite	Reproducible request, response, and session notes
Free automated web testing and CI	ZAP	DAST result for manual review
Suspected SQL injection	Burp first, sqlmap second	Bounded confirmation result
Known CVE validation	Metasploit	Module check and authorized validation evidence
Modern endpoint evasion	A separately authorized, reviewed method	Documented scope and test result

Before every command, write four things: the question, the scope, the expected artifact, and the stop condition. If you can’t fill in all four, don’t run it.