> ## Documentation Index
> Fetch the complete documentation index at: https://roadtocybersec.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Penetration Testing

> Learn ethical hacking methodology, OSINT, scanning, exploitation, post-exploitation, cloud and supply chain testing, reporting, and legal boundaries.

# Penetration Testing

Penetration testing is an **authorized security assessment** that simulates attacker behavior to find and help fix weaknesses before real attackers exploit them. It is legal only when scoped, approved, and documented.

Modern pentesting goes beyond scanning servers. Realistic assessments may include web apps, APIs, cloud accounts, SaaS integrations, developer workflows, CI/CD pipelines, identity systems, and supply chain exposure.

## Types of Penetration Tests

| Type                     | Scope                                                 | What it simulates                            |
| ------------------------ | ----------------------------------------------------- | -------------------------------------------- |
| **Black box**            | Tester has little or no internal knowledge            | External attacker                            |
| **White box**            | Tester has source code, architecture, and credentials | Deep review with maximum context             |
| **Gray box**             | Tester has partial knowledge or user credentials      | Realistic attacker with some foothold        |
| **External**             | Internet-facing systems                               | Remote attacks                               |
| **Internal**             | Inside network access                                 | Compromised employee or device               |
| **Web/API**              | Web apps and APIs                                     | Application abuse and data access flaws      |
| **Cloud**                | Cloud accounts and workloads                          | IAM abuse, exposed storage, misconfiguration |
| **Supply chain / CI/CD** | Repositories, pipelines, packages, build systems      | Developer and release path compromise        |
| **Red team**             | Multi-stage adversary simulation                      | Full security program effectiveness          |

## Scoping and Rules of Engagement

Before testing begins, define:

* In-scope systems, domains, APIs, cloud accounts, and repositories
* Out-of-scope systems and prohibited actions
* Testing window
* Allowed methods, including whether social engineering is permitted
* Rate limits and denial-of-service boundaries
* Data handling rules
* Emergency contacts
* Reporting expectations
* Written authorization

<Warning>
  Testing without explicit written permission is illegal in most jurisdictions. "I was only testing" is not a defense.
</Warning>

## The Pentesting Methodology

<Steps>
  <Step title="1. Planning">
    Confirm authorization, scope, objectives, contacts, and constraints.
  </Step>

  <Step title="2. Reconnaissance">
    Collect public and provided information about the target.
  </Step>

  <Step title="3. Scanning and Enumeration">
    Identify services, technologies, exposed endpoints, permissions, and attack paths.
  </Step>

  <Step title="4. Vulnerability Analysis">
    Map findings to weaknesses, CVEs, misconfigurations, and abuse cases.
  </Step>

  <Step title="5. Exploitation">
    Safely prove impact within scope.
  </Step>

  <Step title="6. Post-Exploitation">
    Determine blast radius without causing unnecessary harm.
  </Step>

  <Step title="7. Reporting">
    Communicate risk, evidence, impact, and remediation clearly.
  </Step>
</Steps>

## Reconnaissance

**OSINT** is intelligence gathered from public sources. It often reveals exposed services, old documents, leaked credentials, staff names, technologies, and vendor relationships.

### Passive Reconnaissance

| Source                   | What you learn                                     |
| ------------------------ | -------------------------------------------------- |
| DNS records              | Subdomains, mail servers, IP ranges                |
| WHOIS and registrar data | Ownership and registration details                 |
| Certificate Transparency | Subdomains and certificate history                 |
| Search engines           | Exposed documents, login pages, cached content     |
| LinkedIn and job posts   | People, roles, technologies, vendors               |
| GitHub and GitLab        | Source code, secrets, package names, internal docs |
| Shodan and Censys        | Exposed services and banners                       |
| Wayback Machine          | Historical pages and removed endpoints             |

### Active Reconnaissance

Active recon interacts with the target and may be detected. Examples include port scanning, directory enumeration, API probing, and authenticated role exploration.

## Scanning and Enumeration

### Network Scanning with Nmap

```bash theme={null}
# Basic TCP scan
nmap -sT target.com

# Full port scan with service detection
nmap -p- -sV -sC target.com

# UDP scan of common ports
nmap -sU --top-ports 100 target.com
```

### Web and API Tools

| Tool                   | Purpose                                             |
| ---------------------- | --------------------------------------------------- |
| **Burp Suite**         | Intercept, inspect, and modify HTTP traffic         |
| **OWASP ZAP**          | Open-source web scanning and proxying               |
| **ffuf / Gobuster**    | Discover hidden paths and files                     |
| **Nikto**              | Find web server misconfigurations                   |
| **SQLMap**             | Detect and exploit SQL injection in authorized labs |
| **Postman / Insomnia** | Explore APIs and authorization behavior             |

## Web and API Testing Focus

Prioritize vulnerabilities with real impact:

* Broken access control and IDOR
* Authentication bypass
* OAuth misconfiguration
* SQL injection and other injection types
* XSS
* SSRF
* File upload abuse
* Insecure deserialization
* Missing rate limits
* Sensitive data exposure
* Business logic flaws

For APIs, test both route-level authorization and object-level authorization. A token that can call an endpoint should not automatically access every object behind it.

## Cloud and SaaS Testing

Cloud and SaaS assessments require careful scoping because mistakes can affect production services.

### Common Findings

* Public storage buckets
* Over-permissive IAM roles
* Long-lived access keys
* Unused admin accounts
* Missing MFA for privileged users
* Publicly exposed databases
* Weak logging and retention
* Unrestricted data export features
* Risky OAuth applications

### SaaS Questions

* Who has admin access?
* Which third-party apps have OAuth grants?
* Can users bulk export data?
* Are audit logs available and retained?
* Are API keys scoped and rotated?
* What alerts exist for unusual login and export behavior?

## Supply Chain and CI/CD Testing

Recent attacks against developer tools and package ecosystems make supply chain testing increasingly important.

### Areas to Review

* Repository permissions and branch protection
* Personal access token scope and lifetime
* Secrets in source code and commit history
* CI/CD workflow permissions
* Self-hosted runner isolation
* Package publishing permissions
* Dependency confusion exposure
* Unsigned releases
* Build scripts that download and execute remote code
* Extension and plugin allowlists

### Safe Test Ideas

* Create a harmless test secret and verify secret scanning catches it.
* Attempt to push to protected branches with low-privilege accounts.
* Review whether untrusted pull requests can access secrets.
* Check whether package names can be confused with public registry packages.
* Verify release artifacts are signed or traceable to a workflow.

## Exploitation

Exploitation proves that a weakness has real impact. It must stay within scope and avoid unnecessary damage.

Good exploitation:

* Demonstrates access with minimal data exposure.
* Uses test accounts or synthetic records when possible.
* Captures evidence without disrupting users.
* Stops before destructive actions.

Bad exploitation:

* Exfiltrates more data than needed.
* Causes downtime without approval.
* Creates persistence without explicit authorization.
* Tests out-of-scope systems.

## Post-Exploitation

Post-exploitation answers: what could an attacker do after the first foothold?

Activities may include:

* Privilege escalation checks
* Credential and token exposure review
* Lateral movement path analysis
* Data access validation
* Cloud role assumption review
* CI/CD abuse path analysis
* Package publishing impact assessment

<Warning>
  Persistence, data exfiltration, and lateral movement are high-risk activities. They must be explicitly authorized and carefully controlled.
</Warning>

## Reporting

The report is the most important deliverable. A finding that is poorly explained may not get fixed.

### Finding Structure

1. **Title**: Clear and specific.
2. **Severity**: Critical, High, Medium, Low, or Informational.
3. **Summary**: One plain-language paragraph.
4. **Affected assets**: Systems, endpoints, accounts, or workflows.
5. **Evidence**: Screenshots, requests, logs, or command output.
6. **Impact**: What an attacker could realistically do.
7. **Root cause**: Why the issue exists.
8. **Remediation**: Specific fix guidance.
9. **Retest steps**: How to verify the fix.

### Business Impact Examples

* Account takeover
* Data exposure
* Cross-tenant data access
* Repository cloning
* Package publishing compromise
* Cloud resource takeover
* Service disruption
* Regulatory or contractual exposure

## Bug Bounty Programs

Bug bounty programs allow researchers to report vulnerabilities for rewards. They are not permission to test anything you want.

Getting started:

1. Read the policy and scope carefully.
2. Practice on legal labs such as PortSwigger Web Security Academy, OWASP WebGoat, Hack The Box, and TryHackMe.
3. Start with common bugs such as IDOR, XSS, access control, and information disclosure.
4. Write concise reports with clear reproduction steps.
5. Do not access, modify, or download unnecessary data.

## Legal and Ethical Framework

* Always get written authorization.
* Stay within scope.
* Minimize impact.
* Protect sensitive data.
* Report promptly.
* Do not disclose publicly without permission.
* Keep evidence secure.

| Jurisdiction | Example law or concern                           |
| ------------ | ------------------------------------------------ |
| Brazil       | Lei 12.737/2012, unauthorized access             |
| US           | Computer Fraud and Abuse Act                     |
| EU           | Directive on attacks against information systems |
| UK           | Computer Misuse Act                              |

## Practical Lab Ideas

1. Perform OSINT on a fictional company domain.
2. Scan a local lab network and write a short asset inventory.
3. Find and fix IDOR in a vulnerable web app.
4. Review a CI workflow for secret exposure risk.
5. Test a cloud IAM policy in a sandbox.
6. Write a professional report for one finding.

## Key Takeaways

1. **Authorization is mandatory**.
2. **Scoping protects both tester and client**.
3. **Modern pentests include cloud, SaaS, identity, and CI/CD**.
4. **Supply chain paths are valid attack paths when in scope**.
5. **Proof of impact should be controlled and minimal**.
6. **The report is the product**.