Penetration Testing Fundamentals
Penetration testing is an authorized security assessment that imitates selected attacker actions against defined systems. It tests whether weaknesses can be combined into meaningful access or impact, then records evidence that helps owners reduce that risk.
itOffensive security and application security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Penetration Testing Fundamentals
Penetration testing is an authorized attempt to bypass security controls inside a defined environment. It is not a contest to see how many tools can be installed before lunch. The useful result is a defensible answer to a security question: can this approved starting position reach this approved impact, and what control lets it happen? The authorization is not paperwork orbiting the technical work. It is one of the controls that makes the work safe enough to trust.
The five useful nouns are objective, scope, test position, evidence chain, and remediation loop. The objective says what needs answering. Scope names the targets, identities, techniques, timing, data rules, and exclusions. Test position says where the tester begins and what knowledge or credentials are supplied. New visibility can send the tester back to discovery, which is rather like finding another corridor in a museum. It does not turn the museum into yours.
The practical mental model is an evidence ladder. An observation says a behavior exists. A hypothesis says what that behavior might permit. Controlled validation checks the condition. Minimum proof shows only the approved impact needed to answer the objective. Then root cause, remediation, and retest turn the demonstration into something a team can actually close. A scanner alert starts that process; it does not finish it wearing a tiny certificate of achievement.
An attack path matters because risk is often a combination rather than a single dramatic flaw. A reachable service, a usable weakness, an identity, and a trust boundary can join up into an outcome. Breaking one link may close the route. Retesting must also check whether an adjacent route still reaches the same outcome, otherwise the lock has changed while the door remains pleasantly available.
A clean result means no finding was established under the stated scope, position, time, and techniques. It does not prove the absence of vulnerabilities. Use the slides when you need the engagement flow at a glance, the cheatsheet when you need the decisions and limits close at hand, and the practice reference when you want to keep a small local lab inside a real boundary. Field Notes covers the operational judgment that keeps a technically correct test from becoming an unhelpful one. The Reference tab is the route onward when the fundamentals have done their job and stopped pretending to be the whole map.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://csrc.nist.gov/pubs/sp/800/115/final
Supports
- Penetration testing within technical security assessment
- Publication in September 2008
- Planning, discovery, attack, and reporting model
- Limits and operational risks of time-bounded testing
- https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=152164
Supports
- Penetration testing as real-world attack simulation and vulnerability validation
- Rules-of-engagement scope, constraints, contacts, safeguards, data handling, and cleanup
- External, internal, overt, covert, and supplied-knowledge viewpoints
- Iteration from attack to additional discovery
- Distinction between vulnerability scanning hypotheses and controlled validation
- Claims and quiz answers about authorization, safety, minimum proof, findings, and limits
- https://www.pentest-standard.org/index.php/Main_Page
Supports
- Seven PTES sections from pre-engagement interactions through reporting
- Reference-path rationale for a detailed engagement structure
- https://www.pentest-standard.org/index.php/Pre-engagement
Supports
- Importance of scope and pre-engagement questions
- Quiz answer about handling an excluded target
- https://owasp.org/www-project-web-security-testing-guide/
Supports
- Target-specific web application and web service testing framework
- Versioned test scenarios and releases in 2004, 2014, and 2020
- Timeline descriptions of evolving web testing guidance
- https://devguide.owasp.org/en/06-verification/01-guides/01-wstg/
Supports
- WSTG domains for configuration, identity, authentication, authorization, sessions, input, logic, client behavior, and APIs
- Tailoring test selection to the application and organizational requirements
- Reference-path rationale
- https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf
Supports
- Penetration-test components, scope, methodology, reporting, and remediation validation
- Difference between vulnerability assessment and penetration testing
- Quiz answers about validation and partial closure
- https://attack.mitre.org/resources/adversary-emulation-plans/
Supports
- Adversary emulation as threat-informed behavior sequences for testing defenses
- Distinction between penetration testing and detection-focused emulation
- https://www.kali.org/docs/introduction/should-i-use-kali-linux/
Supports
- Intended audience and operational assumptions for a dedicated testing distribution
- Reference-path rationale
- https://github.com/enaqx/awesome-pentest
Supports
- Discovery of Dradis, Faraday, SecLists, GTFOBins, LOLBAS, and Public Penetration Testing Reports
- Ecosystem placement of collaboration, reporting, test-input, and post-exploitation resources
- https://www.dradis.org/ce/
Supports
- Self-hosted collaboration, finding imports, evidence organization, and report generation
- Dradis Awesome Links rationale
- https://docs.faradaysec.com/Getting-started/
Supports
- Workspaces that centralize manual and integrated security findings
- Faraday Awesome Links rationale
- https://github.com/danielmiessler/SecLists
Supports
- Curated test-input lists for discovery, usernames, passwords, URLs, patterns, fuzzing, and web shells
- SecLists Awesome Links rationale
- https://gtfobins.org/
Supports
- Unix-like executable functions that can bypass local restrictions in misconfigured systems
- Distinction between legitimate executable functions and software vulnerabilities
- GTFOBins Awesome Links rationale
- https://lolbas-project.github.io/
Supports
- Windows binaries, scripts, libraries, functions, and ATT&CK mappings
- LOLBAS Awesome Links rationale
- https://github.com/juliocesarfort/public-pentesting-reports
Supports
- Collection of public reports from consulting firms and academic security groups
- Public Penetration Testing Reports rationale
- https://nmap.org/book/history-future.html
Supports
- Nmap first release on 1997-09-01
- Consolidation of reusable port-scanning techniques
- https://www.tenable.com/press-releases/tenable-celebrates-nessus-15th-birthday-and-network-security-leadership
Supports
- Nessus launch on 1998-04-04 with an initial set of vulnerability checks
- Timeline placement of automated vulnerability hypotheses
- https://www.rapid7.com/blog/post/2012/12/07/metasploit-hits-1000-exploits/
Supports
- Metasploit 1.0 release on 2003-10-06
- Timeline placement of reusable exploit modules
- https://www.kali.org/blog/10-years/
Supports
- BackTrack creation from WHAX and Auditor in May 2006
- Kali Linux 1.0 release on 2013-03-13 and Debian packaging model
- https://nmap.org/
Supports
- Nmap Landscape placement in discovery and enumeration
- https://www.tenable.com/products/nessus
Supports
- Nessus checks for flaws, missing patches, and misconfigurations
- Nessus Landscape placement as vulnerability-assessment input
- https://portswigger.net/burp
Supports
- Burp Suite manual web testing, proxy, scanning, and community and professional editions
- Burp Suite Landscape placement
- https://www.zaproxy.org/getting-started/
Supports
- ZAP as a free open-source web penetration-testing proxy with passive and active testing
- ZAP Landscape placement and authorization distinction
- https://www.rapid7.com/products/metasploit/
Supports
- Metasploit vulnerability validation, exploit modules, sessions, and product editions
- Metasploit Landscape placement
- https://www.coresecurity.com/products/core-impact
Supports
- Guided automated validation, maintained exploits, attack maps, cleanup, and reporting
- Core Impact Landscape placement
- https://www.cobaltstrike.com/
Supports
- Cobalt Strike post-exploitation, command and control, adversary simulation, and red-team focus
- Cobalt Strike Landscape placement
- https://www.kali.org/
Supports
- Kali Linux Landscape placement as a maintained tester platform
- https://pentera.io/pentera-platform/
Supports
- Automated validation, attack paths, remediation workflows, and retesting
- Pentera Landscape placement
- https://horizon3.ai/nodezero/
Supports
- Autonomous penetration testing, weakness chaining, attack paths, and fix verification
- NodeZero Landscape placement
- https://plextrac.com/
Supports
- Engagement planning, evidence capture, reporting, remediation tracking, and validation
- PlexTrac Landscape placement
- https://devguide.owasp.org/en/07-training-education/01-vulnerable-apps/01-juice-shop/
Supports
- OWASP Juice Shop as an intentionally insecure web application for security training
- Official Docker-based local installation guidance for the training application
- Use of the application as a controlled target for testing tools and methods
- https://pwning.owasp-juice.shop/companion-guide/latest/part2/score-board.html
Supports
- The official Juice Shop Score Board discovery challenge
- The Score Board as a controlled first observation exercise in the local training application
- https://owasp.org/APTS/standard/appendix/Rules_of_Engagement_Template.html
Supports
- Versioned, auditable rules of engagement that separate authorization, scope, and safety controls
- Explicit authorization, target, temporal, action, and escalation fields for testing boundaries
- Field Notes guidance on treating unrecorded scope clarification as a stop signal
- https://owasp.org/www-project-web-security-testing-guide/v42/5-Reporting/README
Supports
- Reporting of version control, agreed scope, limitations, and engagement timeline
- Field Notes guidance on preserving a result so another practitioner can assess its limits
