# Testing Methodologies A testing methodology is the structured process used to run a penetration test. It defines how the tester moves from planning to discovery, validation, exploitation, reporting, and retesting. ([NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final)) A methodology prevents the test from becoming random tool usage. It gives the tester a repeatable path while still leaving room for judgment, investigation, and environment-specific decisions. *** ## Common Testing Flow Most penetration tests follow a similar high-level flow. ([NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final)) ([PTES](https://github.com/penetration-testing-execution-standard/ptes)) 1. **Planning** * Define scope, objectives, testing window, rules, communication, and evidence handling. 2. **Reconnaissance** * Collect information about the target from passive and active sources. 3. **Enumeration** * Interact with known systems, applications, services, and identities to extract useful details. 4. **Vulnerability Discovery** * Identify weaknesses that may be exploitable. 5. **Validation** * Confirm whether the weakness is real. 6. **Exploitation** * Demonstrate impact when it is safe and authorized. 7. **Post-Exploitation** * Understand what access means and what risk it creates. 8. **Reporting** * Document findings, evidence, impact, and remediation. 9. **Retesting** * Confirm whether remediation fixed the issue. This flow changes depending on the engagement type. A web application test, internal network test, API test, AI penetration test, and Active Directory assessment will not follow the exact same path. *** ### Planning Planning defines how the test will be performed before technical work starts. It usually includes scope, objectives, testing windows, allowed techniques, restricted techniques, contacts, emergency process, reporting requirements, data handling rules, and cleanup expectations. Planning protects both the client and the tester. It also prevents technical work from moving faster than authorization, scope, and operational safety. *** ### Reconnaissance Reconnaissance collects information about the target. It may include domains, subdomains, IP ranges, public services, technologies, employees, cloud assets, repositories, exposed files, and third-party relationships. Reconnaissance can be passive or active. Passive reconnaissance avoids direct interaction with target systems. Active reconnaissance interacts with the target and must follow the Rules of Engagement. *** ### Enumeration Enumeration is deeper than reconnaissance. It means interacting with known assets to understand what they expose. Enumeration may include: * Listing open ports. * Identifying service versions. * Reviewing web directories. * Testing authentication behavior. * Querying DNS records. * Listing SMB shares. * Querying LDAP. * Mapping API endpoints. * Identifying users, groups, and roles. Good enumeration usually creates better findings. Poor enumeration usually causes missed attack paths. *** ### Vulnerability Discovery Vulnerability discovery identifies weaknesses that may be exploitable. This may involve manual testing, tool-assisted checks, configuration review, version analysis, authentication testing, authorization testing, input validation testing, service review, or known vulnerability research. At this stage, the tester should treat results as leads. A possible vulnerability is not a confirmed finding until it is validated. *** ### Validation Validation confirms whether the weakness is real. A tester should validate findings carefully and safely. Validation may include: * Repeating the behavior. * Comparing users or roles. * Confirming service behavior. * Checking whether a payload changes the response. * Proving unauthorized access. * Demonstrating controlled impact. * Reviewing logs or output. * Capturing clear evidence. {% hint style="info" %} Scanner output should be treated as a lead until it is manually validated. {% endhint %} A finding should be reported only after the tester can explain what happened, why it happened, and what impact it creates. *** ### Exploitation Exploitation is the controlled use of a vulnerability to demonstrate impact. It should only happen when the action is in scope, allowed by the Rules of Engagement, safe enough for the target environment, needed to prove impact, documented properly, and limited to the minimum required proof. Not every vulnerability needs full exploitation. Sometimes a safer validation method is enough. {% hint style="warning" %} Use the least intrusive method that proves the issue. Do not perform destructive exploitation unless it is explicitly approved. {% endhint %} *** ### Post-Exploitation Post-exploitation explains what gained access means. It may include current user context, privilege level, accessible systems, accessible data, trust relationships, internal reachability, credential exposure, possible attack paths, and business impact. Post-exploitation is not the same as persistence. Persistence should only be tested when it is clearly allowed. *** ### Reporting Reporting converts technical work into usable security value. A good report should include finding title, affected asset, severity, impact, technical details, evidence, reproduction steps, remediation guidance, useful references, and retesting notes. The report should not be a tool output dump. It should explain what happened, why it matters, and how to fix it. ([NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final)) ([PCI Penetration Testing Guidance](https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf)) *** ### Retesting Retesting confirms whether the fix resolved the issue. The tester should repeat the original validation steps, confirm the vulnerable behavior no longer works, check whether the fix introduced a new weakness, and document the result. A finding should only be marked as fixed when the original issue is no longer reproducible. Retesting should not silently become a new full penetration test unless that was agreed. *** ## OWASP Web Security Testing Guide The OWASP Web Security Testing Guide is a methodology and reference for web application and web service security testing. ([OWASP WSTG](https://owasp.org/www-project-web-security-testing-guide/)) It helps structure application-layer testing instead of relying only on scanners or isolated payloads. Useful WSTG areas include: 1. Information gathering. 2. Configuration and deployment management. 3. Identity management. 4. Authentication testing. 5. Session management testing. 6. Authorization testing. 7. Input validation testing. 8. Error handling. 9. Cryptography. 10. Business logic. 11. Client-side testing. OWASP WSTG is most useful when the engagement focuses on web applications or web services. It helps the tester avoid focusing only on injection vulnerabilities while missing authentication, authorization, configuration, and business logic issues. *** ## NIST SP 800-115 NIST SP 800-115 provides guidance for technical information security testing and assessment. ([NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final)) It is useful when the engagement needs structure, repeatability, documentation, and formal assessment discipline. The main phases are: 1. **Planning** * Define scope, rules, objectives, permissions, and assessment approach. 2. **Discovery** * Gather information about the target environment. 3. **Attack** * Validate and exploit weaknesses when authorized. 4. **Reporting** * Document findings, impact, evidence, and remediation. NIST is especially useful in environments where governance, audit, or compliance expectations matter. It is also useful when the tester needs to explain that testing is more than exploitation. *** ## PTES PTES stands for Penetration Testing Execution Standard. ([PTES](https://github.com/penetration-testing-execution-standard/ptes)) It describes a full penetration testing process from preparation to reporting. Common PTES areas include: 1. Pre-engagement interactions. 2. Intelligence gathering. 3. Threat modeling. 4. Vulnerability analysis. 5. Exploitation. 6. Post-exploitation. 7. Reporting. PTES is useful when building a complete penetration testing workflow. It also reinforces that exploitation is only one part of a professional assessment. *** ## Choosing the Right Methodology Use the methodology that matches the engagement. | Engagement Type | Useful Methodology | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Web application test | [OWASP WSTG](https://owasp.org/www-project-web-security-testing-guide/) | | API test | [OWASP WSTG](https://owasp.org/www-project-web-security-testing-guide/) with [OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) | | Internal network test | [PTES](https://github.com/penetration-testing-execution-standard/ptes) or [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final) | | Active Directory assessment | PTES with AD-specific enumeration and attack-path workflow | | Formal security assessment | [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final) | | Full penetration testing program | PTES with NIST-style planning and reporting discipline | The methodology should support the objective. Do not force a methodology if it does not fit the engagement. *** ## Mistakes to Avoid Common methodology mistakes include: * Starting technical testing before scope is clear. * Treating reconnaissance and enumeration as the same thing. * Running tools without a testing plan. * Reporting possible issues without validation. * Exploiting without confirming permission. * Capturing weak evidence. * Skipping failed attempts in the notes. * Ignoring business context. * Writing findings without clear remediation. * Not planning retesting. The methodology should make testing clearer. It should not become a rigid script that prevents the tester from thinking. *** ## References * [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final) * [PCI Security Standards Council: Penetration Testing Guidance](https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf) * [OWASP Web Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) * [OWASP API Security Top 10 2023](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) * [Penetration Testing Execution Standard](https://github.com/penetration-testing-execution-standard/ptes) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://reaper.gitbook.io/my-penetration-test-guide/methodology-and-planning/testing-methodologies.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.