Penetration testing, often shortened to pen‑test, is the practice of probing a system for weaknesses before the bad guys do. If you run a web app—or manage one for a client—knowing how to perform a basic, repeatable test can save you from costly breaches. In this guide we’ll walk through a six‑step process that covers everything from reconnaissance to reporting, using free, widely‑available tools. By the end you’ll have a solid, repeatable workflow you can adapt to any small‑to‑medium web application.
What You’ll Need
- A Kali Linux (or any Linux distro with security tools) VM or a dedicated machine.
- Network connectivity to the target web app (public URL or internal IP).
- Tools: nmap, dirb/gobuster, Nikto, OWASP ZAP, sqlmap, Burp Suite Community.
- A text editor for notes (e.g., VS Code, Vim).
- Permission: written authorization from the application owner.
Step 1: Reconnaissance – Gather the Basics
Before you start poking holes, collect as much open‑source information as possible. Start with a simple WHOIS lookup to confirm ownership and note the registrar, then run a DNS enumeration to discover subdomains.
Commands:
whois example.com host -t any example.com sublist3r -d example.com -o subdomains.txt
Document every subdomain, IP address, and technology fingerprint (e.g., “Powered by WordPress 5.8”). Tools like whatweb or wappalyzer can automate fingerprinting. This stage helps you decide which assets deserve deeper testing and prevents you from missing hidden admin panels.
Step 2: Mapping the Attack Surface – Enumerate Endpoints
Now you need a list of URLs, parameters, and hidden files. Directory brute‑forcing uncovers forgotten admin pages, backup files, or test scripts that are often left exposed.
Example using gobuster with a common wordlist:
gobuster dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt -t 50 -x php,html,txt -o gobuster.txt
Review the output, cherry‑pick interesting endpoints, and add them to a spreadsheet. Don’t forget to test both HTTP and HTTPS, and note any redirects that could reveal load‑balancer or CDN configurations.
Step 3: Vulnerability Scanning – Automated First Pass
Automation speeds up the discovery of known issues. Run a lightweight scanner like Nikto for server‑side problems and OWASP ZAP for client‑side vulnerabilities.
Examples:
nikto -h https://example.com -output nikto.txt zap.sh -daemon -port 8090 -config api.disablekey=true & zap-cli -quickurl https://example.com -quickout zap_report.html
Scrutinize the reports for things like outdated server banners, insecure cookies, or missing security headers. Remember, scanners generate false positives; each finding needs manual verification.
Step 4: Exploitation – Validate Critical Flaws
With a shortlist of high‑risk items, move to manual exploitation. Common web‑app attack vectors include SQL injection, cross‑site scripting (XSS), and insecure deserialization.
SQL injection example using sqlmap:
sqlmap -u "https://example.com/search.php?q=testing" --batch --level=3 --risk=2 --dump
If the target is vulnerable, sqlmap will enumerate databases and optionally dump data. For reflected XSS, use Burp Suite to inject a payload like <script>alert('XSS')</script> into query parameters and observe execution in the browser.
Document every successful exploit, the payload used, and the impact (e.g., “access to user table with usernames and password hashes”).
Step 5: Post‑Exploitation – Assess Impact
Finding a flaw is only half the story; you need to gauge what an attacker could do after initial compromise. If you’ve gained database access, try to extract session tokens or password hashes. If you’ve achieved XSS, attempt a session‑hijack by stealing the Set‑Cookie header.
Sample command to extract cookies from a Burp proxy dump:
grep "Set-Cookie" burp_proxy.log | cut -d" " -f2
Assess whether privilege escalation is possible (e.g., admin panel access) and note any data exfiltration paths. This step helps you prioritize remediation based on real business impact.
Step 6: Reporting – Turn Findings into Actionable Advice
A well‑structured report turns technical data into a roadmap for developers. Use the following template:
- Executive Summary – high‑level risk rating (Critical/High/Medium/Low).
- Scope – URLs, IPs, and tools used.
- Methodology – brief description of each step.
- Findings – for each issue include: Description, Evidence (screenshots or logs), Risk Rating, Reproduction Steps, Recommended Fix.
- Conclusion – overall security posture and next steps.
Export screenshots as PNG, attach log excerpts, and keep the language non‑technical for executives while providing deep technical appendices for developers.
Common Mistakes to Avoid
1. Skipping Authorization. Never test a live production site without written permission; you risk legal action and service disruption.
2. Relying Solely on Scanners. Automated tools miss logic flaws and business‑logic vulnerabilities. Manual verification is essential.
3. Overlooking Rate Limits. Aggressive brute‑forcing can lock out legitimate users or trigger WAF blocks, skewing results.
4. Failing to Reset Test Data. If you create test accounts or modify data, clean up after yourself to avoid polluting the environment.
5. Ignoring HTTPS Certificate Errors. Accepting self‑signed certificates without noting them can hide man‑in‑the‑middle risks.
Tips and Tricks
• Use tmux or screen to keep long scans running even if your SSH session drops.
• Combine dirb wordlists with custom entries (e.g., admin, backup, .git) for better coverage.
• Leverage browser extensions like Wappalyzer for quick tech stack identification.
• When using sqlmap, add --tamper=space2comment to bypass simple input filters.
• Keep a “cheat sheet” of common payloads (XSS, SSRF, LFI) handy for rapid copy‑paste.
Frequently Asked Questions
Do I need a paid tool for a thorough test?
No. The open‑source stack (Kali, OWASP ZAP, Burp Community) covers the majority of common vulnerabilities. Paid tools can speed up reporting or provide advanced scanning modules, but they’re not required for a solid basic test.
How long should a basic pen test take?
For a typical small web app, 4–6 hours of hands‑on testing is realistic. Larger applications with many subdomains may extend to a full day. Always allocate extra time for reporting.
Can I run these tests against a live production site?
Only if you have explicit, written consent and the owner is aware of potential performance impact. Prefer testing in a staging environment whenever possible.
Conclusion
Conducting a basic penetration test is a blend of automated discovery and thoughtful manual probing. By following the six steps outlined—recon, surface mapping, scanning, exploitation, post‑exploitation, and reporting—you’ll uncover the most common weaknesses that attackers exploit. Remember to stay within scope, document everything, and translate technical findings into clear remediation guidance. With practice, this workflow becomes second nature, empowering you to harden web applications before a real threat ever appears.
