1.1 Penetration Testing vs. Vulnerability Scanning vs. Red Teaming#

To understand where penetration testing sits within enterprise risk management, we must distinguish between three distinct security assessment disciplines:

2.1 The Penetration Testing Execution Standard (PTES)#

The Penetration Testing Execution Standard (PTES) defines seven rigorous phases of an assessment lifecycle:

1. Pre-Engagement Interactions: Defining legal boundaries, Rules of Engagement (RoE), emergency contacts, escalation paths, and operational windows.
2. Intelligence Gathering (Reconnaissance): Harvesting open-source intelligence (OSINT), analyzing DNS records, identifying infrastructure footprints, and discovering employee identities.
3. Threat Modeling: Identifying business assets, modeling attacker capabilities, and constructing prioritized attack trees.
4. Vulnerability Analysis: Discovering flaws through automated tooling and manual inspection of protocol implementations and application logic.
5. Exploitation: Executing precise, controlled actions to prove the viability of identified vulnerabilities without causing unintended system outages or data corruption.
6. Post-Exploitation: Determining the business value of compromised assets, identifying sensitive data paths, escalating privileges, and demonstrating lateral movement capabilities.
7. Reporting: Translating technical findings into actionable business risk analyses, executive summaries, and technical remediation roadmaps.

2.2 Complementary Standards: NIST SP 800-115, OWASP WSTG, & OSSTMM#

• NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment): Provides federal and enterprise guidance on target identification, vulnerability analysis, and penetration testing techniques.
• OWASP Web Security Testing Guide (WSTG v4.2): The industry benchmark for web application testing, defining over 90 discrete test cases across 12 categories (Identity Management, Authentication, Authorization, Session Management, Input Validation, Cryptography, Business Logic, and Client-Side Testing).
• OWASP ASVS (Application Security Verification Standard): Defines granular technical security requirements for designing, developing, and testing secure web applications across three verification levels (L1: Opportunistic, L2: Standard Enterprise, L3: Critical Infrastructure).
• OSSTMM (Open Source Security Testing Methodology Manual): A scientific, peer-reviewed methodology focusing on operational security metrics, calculating the Risk Assessment Value (RAV) across physical, human, wireless, telecommunications, and data networks.

3.1 Defining the Scope and Testing Models#

Assessments are categorized based on the amount of preliminary information provided to the testing team:

graph LR
    subgraph BlackBox [Black Box: Zero Knowledge]
        B1["Target IP/Domain List Only"] --> B2["Simulates External Unauthenticated Adversary"]
    end
    subgraph GrayBox [Gray Box: Partial Knowledge]
        G1["Standard User Account & API Specs"] --> G2["Simulates Malicious Insider / Compromised Tenant"]
    end
    subgraph WhiteBox [White Box: Full Knowledge]
        W1["Full Source Code, IAM & Architecture"] --> W2["Comprehensive Code Audit & White-Hat Review"]
    end

Rules of Engagement (RoE) Requirements

A comprehensive Rules of Engagement document must explicitly define:

• Explicit In-Scope Targets: Exact FQDNs, CIDR blocks, API endpoints, and physical locations.
• Explicit Out-of-Scope Targets: Third-party cloud infrastructure (e.g., non-dedicated SaaS), shared hosting tenants, critical production databases, and physical branch offices.
• Prohibited Techniques: Explicit restrictions regarding Distributed Denial of Service (DDoS), destructive malware, physical entry, or social engineering targeting non-consenting personnel.
• Deconfliction Procedures: A shared secure communication channel (e.g., Signal or dedicated PGP-encrypted mail) to immediately verify whether observed alerts in the Security Operations Center (SOC) are simulated pentest traffic or a legitimate cyberattack.
• Emergency Stop Protocols: Immediate halt procedures if testing impacts system availability, disrupts business operations, or uncovers an active, third-party intrusion.

4.1 Passive Reconnaissance Techniques#

1. Certificate Transparency (CT) Log Analysis: Modern SSL/TLS certificates issued by public Certificate Authorities must be logged in public, append-only CT logs. Querying these logs reveals subdomains, internal hostnames, and newly deployed staging environments:

   1
   # Query crt.sh API for subdomains
   2
   curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u
   

2. ASN and IP Space Discovery: Identifying an organization’s Autonomous System Number (ASN) allows mapping of all announced IP prefixes owned by the company:

   1
   # Query BGP routing tables for an organization's ASN
   2
   whois -h whois.radb.net -- '-i origin AS13335' | grep -Eo "([0-9.]+){4}/[0-9]+"
   

3. Public Code Repository & Secret Scraping: Developers frequently commit configuration files containing hardcoded database credentials, private API keys, and staging endpoints to public repositories:

   • Git commit histories (git log -p)
   • Environment files (.env, docker-compose.yml, kubeconfig)
   • Hardcoded AWS access keys (AKIA...)

4.2 Active Reconnaissance & Network Discovery#

Active reconnaissance interacts directly with network services to identify open ports, service versions, and protocol configurations.

sequenceDiagram
    autonumber
    participant Tester as Scanner (Tester)
    participant OpenTarget as Target: Port 443 (Open)
    participant ClosedTarget as Target: Port 2222 (Closed)
    participant FilteredTarget as Target: Port 3389 (Filtered)

    Note over Tester,OpenTarget: 1. TCP SYN Half-Open Scan
    Tester->>OpenTarget: TCP SYN (Seq=x)
    OpenTarget-->>Tester: TCP SYN-ACK (Seq=y, Ack=x+1)
    Tester->>OpenTarget: TCP RST (Seq=x+1) [Teardown Handshake]

    Note over Tester,ClosedTarget: 2. Closed Port Handling
    Tester->>ClosedTarget: TCP SYN (Seq=x)
    ClosedTarget-->>Tester: TCP RST-ACK

    Note over Tester,FilteredTarget: 3. Filtered State (Firewall Drop)
    Tester->>FilteredTarget: TCP SYN (Seq=x)
    FilteredTarget--xTester: Packet Dropped / No Response

5.1 Automated Vulnerability Scanning vs. Manual Verification#

Automated scanners (such as Nessus, OpenVAS, or Burp Suite Scanner) rely on signature databases and heuristic probes. However, automated tools exhibit inherent limitations:

• High False-Positive Rates: Scanners often rely solely on banner strings without verifying whether vendor backports have patched the underlying issue.
• Blindness to Business Logic: An automated scanner cannot deduce that user $A$ modifying /api/order/529 to /api/order/528 allows unauthorized viewing of a competitor’s invoice.
• Lack of Attack Chaining: Scanners evaluate findings in isolation and cannot recognize that an unauthenticated DNS zone transfer combined with an exposed internal Redis cache permits full domain compromise.

Methodological Principle

A professional penetration test uses automated scanning solely for baseline discovery. Every finding must be manually validated, assessed for exploitability within the specific environment, and correlated against other architectural components.

6.1 Active Directory Attack Mechanics#

1
# Example Impacket command for AS-REP Roasting
2
GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -outputfile asreproast.hashes

6.2 Network Pivoting and Lateral Movement#

When testing isolated internal networks, testers establish secure tunnels through dual-homed compromised hosts to reach deeper network enclaves:

graph LR
    Tester["External Tester<br/>198.51.100.5"] -->|"SOCKS5 SSH Tunnel / Chisel"| DMZ["Compromised DMZ Host<br/>Eth0: 198.51.100.20<br/>Eth1: 10.0.1.5"]
    DMZ -->|"Pivoted Encrypted Traffic"| InternalNet["Internal Subnet (10.0.0.0/8)<br/>Domain Controllers, DBs, File Shares"]

• SOCKS5 Dynamic Port Forwarding (SSH): Establishes an encrypted proxy tunnel routing arbitrary TCP traffic into the internal subnet:

  1
  ssh -D 1080 -q -C -N user@dmz-host.example.com
  

• Reverse TCP Tunneling (Chisel / WireGuard): Used when outbound firewalls block incoming connections but permit outbound HTTP/HTTPS/WebSocket traffic.

7.1 Broken Object-Level Authorization (BOLA / IDOR)#

Insecure Direct Object References (IDOR) occur when an application accepts user-supplied input to retrieve database records or execute actions without validating that the authenticated user possesses authorization for that specific object.

1
GET /api/v2/invoices/948102 HTTP/1.1
2
Host: api.company.com
3
Authorization: Bearer <User_A_Token>

If User A can simply increment the numeric identifier to /api/v2/invoices/948101 and retrieve User B’s proprietary financial invoice, the application suffers from BOLA (the #1 vulnerability on the OWASP API Security Top 10).

Remediation: Enforce centralized, attribute-based access control (ABAC) or policy enforcement points (e.g., Open Policy Agent) directly at the data layer:

1
// Secure Authorization Check
2
async function getInvoice(userId: string, invoiceId: string) {
3
  const invoice = await db.invoices.findUnique({ where: { id: invoiceId } });
4
  if (!invoice || invoice.tenantId !== userId) {
5
    throw new ForbiddenError("Access Denied: Unauthorized Object Reference");
6
  }
7
  return invoice;
8
}

7.2 Server-Side Request Forgery (SSRF)#

Server-Side Request Forgery occurs when a web application fetches a remote resource based on a user-supplied URL without properly validating the destination address.

graph LR
    Attacker["Attacker"] -->|"POST /export?url=http://169.254.169.254/latest/meta-data/"| WebApp["Vulnerable Web Server"]
    WebApp -->|"Internal HTTP Request"| IMDS["AWS Instance Metadata Service (169.254.169.254)"]
    IMDS -->|"Returns IAM Security Credentials / STS Tokens"| WebApp
    WebApp -->|"Returns Response"| Attacker

In cloud environments (AWS, GCP, Azure), attackers leverage SSRF to query internal Cloud Instance Metadata Services (IMDS) at the non-routable link-local address 169.254.169.254, extracting temporary IAM credentials, service account tokens, and environment secrets.

Remediation:

1. Enforce AWS IMDSv2, which requires session-oriented token handshakes via HTTP PUT headers that SSRF payloads cannot easily forge:

   1
   # IMDSv2 requires token generation
   2
   TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
   3
   curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
   

2. Implement strict URL destination whitelists at the application layer, resolving DNS records and blocking loopback (127.0.0.0/8), link-local (169.254.0.0/16), and private RFC 1918 addresses before dispatching HTTP requests.

7.3 JSON Web Token (JWT) Implementation Vulnerabilities#

JWTs are ubiquitously used for stateless authentication. Penetration testing evaluates standard implementation flaws:

1. The none Algorithm Attack: Modifying the header {"alg": "none", "typ": "JWT"} and stripping the signature bytes. If the backend fails to enforce a cryptographic algorithm whitelist, it accepts unsigned arbitrary claims.

2. Algorithm Key Confusion (RS256 to HS256): When a server expects an asymmetric RSA signature (RS256 using a private key to sign and a public key to verify), an attacker converts the header to HS256 (HMAC with SHA-256) and signs the token using the server’s publicly accessible RSA public key as the HMAC shared secret.

3. Weak HMAC Secrets: Symmetric HMAC keys with low entropy can be cracked offline at billions of guesses per second using Hashcat:

   1
   hashcat -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt
   

8.1 AWS IAM Privilege Escalation Chains#

Unlike on-premises networks where privilege escalation relies on operating system vulnerabilities or memory manipulation, cloud privilege escalation is almost exclusively driven by over-permissive IAM permissions.

Common IAM privilege escalation vectors include:

8.2 Container Escapes & Kubernetes RBAC Auditing#

In containerized environments (Docker, containerd, Kubernetes), testers evaluate whether a compromised application container can break out to the underlying host node:

graph TD
    Pod["Compromised Pod Container"] -->|"1. Detect Privileged Flag or CAP_SYS_ADMIN"| HostKernel["Linux Kernel (Shared with Host)"]
    Pod -->|"2. Mount Host Root (/dev/sda1 -> /mnt/host)"| HostDisk["Underlying Node Filesystem"]
    HostDisk -->|"3. Write to /mnt/host/etc/crontab or inject SSH key"| HostExecution["Host Root Code Execution"]

1. Privileged Containers (--privileged): A container run with full host capabilities can directly mount the host node’s root filesystem (mount /dev/sda1 /mnt/host) and achieve host root execution.

2. Dangerous Linux Capabilities: Capabilities such as CAP_SYS_ADMIN, CAP_SYS_PTRACE, or CAP_NET_ADMIN enable kernel module loading, memory tracing, or traffic manipulation across the host namespace.

3. Mounted Docker Sockets (/var/run/docker.sock): If the host Docker daemon socket is mounted into a container, the container can instruct the daemon to launch a sibling container with full host root filesystem access.

4. Kubernetes Service Account Tokens: Pods automatically mount a service account token at /var/run/secrets/kubernetes.io/serviceaccount/token. Testers query the Kubernetes API server to audit Role-Based Access Control (RBAC) permissions:

   1
   # Check Kubernetes API permissions
   2
   kubectl auth can-i --list --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
   

9.1 Linux Privilege Escalation Vectors#

1. SUID Binaries with GTFOBins Functions: Executables with the SUID bit set (chmod u+s) execute with the permissions of the file owner (typically root). If standard system utilities (such as find, vim, or nmap) carry SUID bits, they can be abused to spawn a root shell:

   1
   # Find SUID binaries on the filesystem
   2
   find / -perm -u=s -type f 2>/dev/null
   

2. Sudoers Misconfigurations: Over-permissive /etc/sudoers entries granting passwordless execution (NOPASSWD:) of interpreters or scripts that allow arbitrary sub-process spawning.

3. Systemd Service / Cron Hijacking: Writable systemd unit files or cron scripts that execute periodically as root.

9.2 Windows Privilege Escalation Vectors#

1. Token Impersonation Privileges (SeImpersonatePrivilege / SeAssignPrimaryTokenPrivilege): Accounts running web services or database engines (e.g., NT AUTHORITY\NETWORK SERVICE or LOCAL SERVICE) frequently possess SeImpersonatePrivilege. Attackers induce a local system service running as SYSTEM to authenticate against a local named pipe or COM server controlled by the attacker, capturing the SYSTEM token and duplicating it to spawn an administrative shell (the foundation of the Potato exploit family).

2. Unquoted Service Paths: If a Windows service executable path contains spaces and is not enclosed in quotation marks (e.g., C:\Program Files\Vendor App\service.exe), Windows attempts to execute binaries along each path segment in order:

   • C:\Program.exe
   • C:\Program Files\Vendor.exe
   • C:\Program Files\Vendor App\service.exe

   If an unprivileged user has write permissions to C:\, placing an executable named Program.exe results in arbitrary code execution as SYSTEM upon service reboot.

10.1 Calculating Risk: CVSS v3.1/v4.0 vs. OWASP Risk Rating#

Penetration testing findings are scored using standard risk calculators:

$\text{Risk} = \text{Likelihood} \times \text{Impact}$

1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H  -->  Base Score: 9.8 (CRITICAL)
2
(Network accessible, Low complexity, No privileges, No user interaction, High C/I/A impact)

10.2 The Remediation Lifecycle#

Remediation must be structured into two distinct tracks:

1. Short-Term Tactical Fixes: Immediate operational measures to eliminate active exploitation paths (e.g., rotating compromised credentials, deploying a Web Application Firewall (WAF) rule, restricting an over-permissive security group).
2. Long-Term Architectural Remediations: Structural improvements that eradicate entire vulnerability classes (e.g., migrating from string-concatenated SQL queries to an ORM with parameterized queries, implementing central OAuth/OIDC authorization gateways, deploying automated cloud posture management (CSPM)).

Retesting and Attestation

A penetration test is not concluded until the client implements remediations and the testing team executes a formal Retest. Retesting verifies that patches successfully resolve the vulnerability without introducing regressions, culminating in a formal Letter of Attestation for regulatory auditors and stakeholders.

11.1 The MITRE ATT&CK Telemetry and Defense Matrix#

By mapping offensive actions to the MITRE ATT&CK matrix, organizations establish measurable detection coverage:

Core Principles for Technical Practitioners#

1. Never Rely on Assumptions: A firewall rule, an IAM boundary, or an authentication check must be experimentally validated under adversarial conditions.
2. Think in Graphs, Not Lists: Attackers do not target vulnerabilities in isolation; they traverse interconnected trust graphs across networks, identities, and applications.
3. Bridge Offense and Defense: The ultimate metric of a successful penetration test is not the number of shells popped, but the long-term resilience and detection capability instilled within the defensive team.

Selected References & Technical Documentation#

• PTES Team. (2014). The Penetration Testing Execution Standard. http://www.pentest-standard.org/
• National Institute of Standards and Technology (NIST). (2008). Technical Guide to Information Security Testing and Assessment. NIST Special Publication 800-115.
• OWASP Foundation. (2021). OWASP Web Security Testing Guide (WSTG v4.2).
• OWASP Foundation. (2023). OWASP API Security Top 10 2023.
• MITRE Corporation. (2024). MITRE ATT&CK Matrix for Enterprise. https://attack.mitre.org/
• Rietdijk, C. W., & Putnam, H. Adversarial Engineering and Enterprise Threat Modeling Standards.
• Kim, G., Behr, K., & Spafford, G. The Practice of Network Security Monitoring: Understanding Incident Detection and Response.