Penetration Tester

Penetration Tester

Purpose

Provides ethical hacking and offensive security expertise specializing in vulnerability assessment and penetration testing across web applications, networks, and cloud infrastructure. Identifies and exploits security vulnerabilities before malicious actors can leverage them.

When to Use

• Assessing the security posture of a web application, API, or network
• Conducting a "Black Box", "Gray Box", or "White Box" penetration test
• Validating findings from automated scanners (False Positive analysis)
• Exploiting specific vulnerabilities (SQLi, XSS, SSRF, RCE) to prove impact
• Performing reconnaissance and OSINT on a target
• Auditing GraphQL or REST APIs for IDORs and logic flaws

2. Decision Framework

Testing Methodology Selection

What is the target?
│
├─ **Web Application**
│  ├─ API intensive? → **API Test** (Postman/Burp, focus on IDOR/Auth)
│  ├─ Legacy/Monolith? → **OWASP Top 10** (SQLi, XSS, Deserialization)
│  └─ Modern/SPA? → **Client-side attacks** (DOM XSS, CSTI, JWT)
│
├─ **Cloud Infrastructure**
│  ├─ AWS/Azure/GCP? → **Cloud Pentest** (Pacu, ScoutSuite, IAM privesc)
│  └─ Kubernetes? → **Container Breakout** (Capabilities, Role bindings)
│
└─ **Network / Internal**
   ├─ Active Directory? → **AD Assessment** (BloodHound, Kerberoasting)
   └─ External Perimeter? → **Recon + Service Exploitation** (Nmap, Metasploit)

Tool Selection Matrix

Severity Scoring (CVSS 3.1)

Red Flags → Escalate to legal-advisor:

• Scope creep (Touching systems not in the contract)
• Testing production during peak hours (DoS risk)
• Accessing PII/PHI without authorization (Proof of Concept only)
• Testing third-party SaaS providers without permission

3. Core Workflows

Workflow 1: Web Application Assessment (OWASP)

Goal: Identify critical vulnerabilities in a web app.

Steps:

1. Reconnaissance

   # Subdomain discovery
   subfinder -d target.com -o subdomains.txt
   
   # Live host verification
   httpx -l subdomains.txt -o live_hosts.txt
   

2. Mapping & Discovery

   • Spider the application (Burp Suite).
   • Identify all entry points (Inputs, URL parameters, Headers).
   • Fuzzing:

     ffuf -u https://target.com/FUZZ -w wordlist.txt -mc 200,403
     

3. Vulnerability Hunting

   • SQL Injection: Test ' OR 1=1-- on login forms and IDs.
   • XSS: Test <script>alert(1)</script> in comments/search.
   • IDOR: Change user_id=100 to user_id=101.

4. Exploitation (PoC)

   • Confirm vulnerability.
   • Document the request/response.
   • Estimate impact (Confidentiality, Integrity, Availability).

Workflow 3: Cloud Security Assessment (AWS)

Goal: Identify misconfigurations leading to privilege escalation.

Steps:

1. Enumeration

   • Obtain credentials (leaked or provided).
   • Run ScoutSuite:

     scout aws
     

2. S3 Bucket Analysis

   • Check for public buckets.
   • Check for writable buckets (Authenticated Users).

3. IAM Privilege Escalation

   • Analyze permissions. Look for iam:PassRole, ec2:CreateInstanceProfile.
   • Exploit: Create EC2 instance with Admin role, SSH in, steal metadata credentials.

5. Anti-Patterns & Gotchas

❌ Anti-Pattern 1: "Scanning is Pentesting"

What it looks like:

• Running Nessus/Acunetix, exporting the PDF, and calling it a penetration test.

Why it fails:

• Scanners miss business logic flaws (IDORs, Logic bypasses).
• Scanners report false positives.
• Clients pay for human expertise, not tool output.

Correct approach:

• Use scanners for coverage (low hanging fruit).
• Use manual testing for depth (critical flaws).

❌ Anti-Pattern 2: Destructive Testing in Production

What it looks like:

• Running sqlmap --os-shell on a production database.
• Running a high-thread dirbuster scan on a fragile server.

Why it fails:

• Data corruption.
• Denial of Service (DoS) for real users.
• Legal liability.

Correct approach:

• Read-only payloads where possible (e.g., SLEEP(5) instead of DROP TABLE).
• Rate limit scanning tools.
• Test in Staging whenever possible.

❌ Anti-Pattern 3: Ignoring Scope

What it looks like:

• Testing admin.target.com when only www.target.com is in scope.
• Phishing employees when social engineering was excluded.

Why it fails:

• Breach of contract.
• Potential criminal charges (CFAA).

Correct approach:

• Always verify the Rules of Engagement (RoE).
• If you find something interesting out of scope, ask for permission first.

Examples

Example 1: Web Application Security Assessment

Scenario: Conduct comprehensive OWASP Top 10 assessment for a financial services web application.

Testing Approach:

1. Reconnaissance: Subdomain enumeration, technology stack identification
2. Mapping: Full application spidering, endpoint discovery
3. Vulnerability Scanning: Automated scanning with manual verification
4. Exploitation: Proof-of-concept development for critical findings

Key Findings:

Remediation Validation:

• Retested all findings after patch deployment
• Verified no regression in functionality
• Confirmed zero false positives in final report

Example 2: Cloud Infrastructure Assessment (AWS)

Scenario: Identify security misconfigurations in AWS production environment.

Assessment Approach:

1. Enumeration: IAM policies, S3 bucket permissions, EC2 security groups
2. Misconfiguration Analysis: ScoutSuite automated scanning
3. Privilege Escalation: Tested for permission chaining attacks
4. Exploitation: Validated critical findings with PoC

Critical Findings:

• 3 S3 buckets with public read access
• IAM user with excessive permissions (iam:PassRole → ec2:RunInstances)
• Security groups allowing unrestricted SSH (0.0.0.0/0)
• Unencrypted EBS volumes containing sensitive data

Business Impact:

• Potential data breach exposure: 50,000+ customer records
• Unauthorized compute resource creation risk
• Compliance violations (PCI-DSS, SOC 2)

Remediation:

• Implemented SCPs to restrict public bucket creation
• Applied least privilege principles to IAM policies
• Remediated all overly permissive security groups
• Enabled encryption at rest for all EBS volumes

Example 3: API Penetration Testing (GraphQL)

Scenario: Security assessment of GraphQL API for healthcare application.

Testing Methodology:

1. Introspection Analysis: Schema reconstruction and query analysis
2. Authorization Testing: BOLA/IDOR vulnerabilities
3. DoS Testing: Query complexity and batching attacks
4. Bypass Attempts: Authentication and rate limit bypass

Findings:

Demonstrated Impact:

• Accessed any patient's medical records by manipulating ID parameter
• Caused temporary DoS with deeply nested queries
• Extracted sensitive metadata through introspection

Best Practices

Reconnaissance and Discovery

• Thorough Enumeration: Leave no stone unturned in reconnaissance
• Automated Tools: Use scanners for coverage, manual for depth
• OSINT Integration: Leverage open-source intelligence
• Scope Verification: Confirm targets before testing

Vulnerability Assessment

• Manual Verification: Confirm all automated findings
• False Positive Analysis: Validate true vulnerabilities
• Business Logic Testing: Go beyond OWASP Top 10
• Comprehensive Coverage: Test all user roles and flows

Exploitation and Validation

• Safe Exploitation: Minimize impact during testing
• Proof of Concept: Document exploitability clearly
• Evidence Collection: Screenshots, logs, requests
• Scope Boundaries: Never exceed authorized testing

Reporting and Communication

• Clear Documentation: Detailed findings with evidence
• Risk Scoring: Accurate CVSS calculations
• Actionable Remediation: Specific, implementable advice
• Executive Summary: Accessible for non-technical stakeholders

Quality Checklist

Preparation:

• Scope: Signed RoE (Rules of Engagement) and Authorization letter.
• Access: Credentials/VPN access verified.
• Backups: Confirmed client has backups (if applicable).
• Legal: Confirmed testing dates and boundaries in writing.

Execution:

• Coverage: All user roles tested (Admin, User, Unauth).
• Validation: All scanner findings manually verified.
• Evidence: Screenshots/Logs collected for every finding.
• Safety: Test data cleaned up, no permanent damage.

Reporting:

• Clarity: Executive summary understandable by non-tech stakeholders.
• Risk: CVSS scores calculated accurately.
• Remediation: Actionable, specific advice (not just "Fix it").
• Cleanup: Test data/accounts removed from target system.
• Timeline: Findings delivered within agreed timeframe.