Standard pentest methodology

Standard Pentest Methodology

penkit51 AI — professional penetration testing skill pack. Authorized testing only.

Deep Exploitation Guide

Standard Testing Mode

Balanced security assessment with structured methodology. Thorough coverage without exhaustive depth.

Approach

Systematic testing across the full attack surface. Understand the application before exploiting it.

Phase 1: Reconnaissance

Whitebox (source available)

• Map codebase structure: modules, entry points, routing
• Run semgrep first-pass triage to prioritize risky flows before deep manual review
• Run at least one AST-structural mapping pass (sg and/or Tree-sitter), then use outputs for route, sink, and trust-boundary mapping
• Keep AST output bounded to relevant paths and hypotheses; avoid whole-repo generic function dumps
• Identify architecture pattern (MVC, microservices, monolith)
• Trace input vectors: forms, APIs, file uploads, headers, cookies
• Review authentication and authorization flows
• Analyze database interactions and ORM usage
• Check dependencies and repo risks with trivy fs, gitleaks, and trufflehog
• Understand the data model and sensitive data locations

Blackbox (no source)

• Crawl application thoroughly, interact with every feature
• Enumerate endpoints, parameters, and functionality
• Fingerprint technology stack
• Map user roles and access levels
• Capture traffic with proxy to understand request/response patterns

Phase 2: Business Logic Analysis

Before testing for vulnerabilities, understand the application:

• Critical flows - payments, registration, data access, admin functions
• Role boundaries - what actions are restricted to which users
• Data access rules - what data should be isolated between users
• State transitions - order lifecycle, account status changes
• Trust boundaries - where does privilege or sensitive data flow

Phase 3: Systematic Testing

Test each attack surface methodically. Spawn focused subagents for different areas.

Input Validation

• Injection testing on all input fields (SQL, XSS, command, template)
• File upload bypass attempts
• Search and filter parameter manipulation
• Redirect and URL parameter handling

Authentication & Session

• Brute force protection
• Session token entropy and handling
• Password reset flow analysis
• Logout session invalidation
• Authentication bypass techniques

Access Control

• Horizontal: user A accessing user B's resources
• Vertical: unprivileged user accessing admin functions
• API endpoints vs UI access control consistency
• Direct object reference manipulation

Business Logic

• Multi-step process bypass (skip steps, reorder)
• Race conditions on state-changing operations
• Boundary conditions: negative values, zero, extremes
• Transaction replay and manipulation

Phase 4: Exploitation

• Every finding requires a working proof-of-concept
• Demonstrate actual impact, not theoretical risk
• Chain vulnerabilities to show maximum severity
• Document full attack path from entry to impact
• Use Python scripts through exec_command for complex exploit development

Phase 5: Reporting

• Document all confirmed vulnerabilities with reproduction steps
• Severity based on exploitability and business impact
• Remediation recommendations
• Note areas requiring further investigation

Chaining

Always ask: "If I can do X, what does that enable next?" Keep pivoting until reaching maximum privilege or data exposure.

Prefer complete end-to-end paths (entry point → pivot → privileged action/data) over isolated findings. Use the application as a real user would—exploit must survive actual workflow and state transitions.

When you discover a useful pivot (info leak, weak boundary, partial access), immediately pursue the next step rather than stopping at the first win.

Mindset

Methodical and systematic. Document as you go. Validate everything—no assumptions about exploitability. Think about business impact, not just technical severity.

Platform Methodology

Standard Pentest Methodology

penkit51 AI — professional penetration testing skill pack. Authorized testing only.

Deep Exploitation Guide

Standard Testing Mode

Balanced security assessment with structured methodology. Thorough coverage without exhaustive depth.

Approach

Systematic testing across the full attack surface. Understand the application before exploiting it.

Phase 1: Reconnaissance

Whitebox (source available)

• Map codebase structure: modules, entry points, routing
• Run semgrep first-pass triage to prioritize risky flows before deep manual review
• Run at least one AST-structural mapping pass (sg and/or Tree-sitter), then use outputs for route, sink, and trust-boundary mapping
• Keep AST output bounded to relevant paths and hypotheses; avoid whole-repo generic function dumps
• Identify architecture pattern (MVC, microservices, monolith)
• Trace input vectors: forms, APIs, file uploads, headers, cookies
• Review authentication and authorization flows
• Analyze database interactions and ORM usage
• Check dependencies and repo risks with trivy fs, gitleaks, and trufflehog
• Understand the data model and sensitive data locations

Blackbox (no source)

• Crawl application thoroughly, interact with every feature
• Enumerate endpoints, parameters, and functionality
• Fingerprint technology stack
• Map user roles and access levels
• Capture traffic with proxy to understand request/response patterns

Phase 2: Business Logic Analysis

Before testing for vulnerabilities, understand the application:

• Critical flows - payments, registration, data access, admin functions
• Role boundaries - what actions are restricted to which users
• Data access rules - what data should be isolated between users
• State transitions - order lifecycle, account status changes
• Trust boundaries - where does privilege or sensitive data flow

Phase 3: Systematic Testing

Test each attack surface methodically. Spawn focused subagents for different areas.

Input Validation

• Injection testing on all input fields (SQL, XSS, command, template)
• File upload bypass attempts
• Search and filter parameter manipulation
• Redirect and URL parameter handling

Authentication & Session

• Brute force protection
• Session token entropy and handling
• Password reset flow analysis
• Logout session invalidation
• Authentication bypass techniques

Access Control

• Horizontal: user A accessing user B's resources
• Vertical: unprivileged user accessing admin functions
• API endpoints vs UI access control consistency
• Direct object reference manipulation

Business Logic

• Multi-step process bypass (skip steps, reorder)
• Race conditions on state-changing operations
• Boundary conditions: negative values, zero, extremes
• Transaction replay and manipulation

Phase 4: Exploitation

• Every finding requires a working proof-of-concept
• Demonstrate actual impact, not theoretical risk
• Chain vulnerabilities to show maximum severity
• Document full attack path from entry to impact
• Use Python scripts through exec_command for complex exploit development

Phase 5: Reporting

• Document all confirmed vulnerabilities with reproduction steps
• Severity based on exploitability and business impact
• Remediation recommendations
• Note areas requiring further investigation

Chaining

Always ask: "If I can do X, what does that enable next?" Keep pivoting until reaching maximum privilege or data exposure.

Prefer complete end-to-end paths (entry point → pivot → privileged action/data) over isolated findings. Use the application as a real user would—exploit must survive actual workflow and state transitions.

When you discover a useful pivot (info leak, weak boundary, partial access), immediately pursue the next step rather than stopping at the first win.

Mindset

Methodical and systematic. Document as you go. Validate everything—no assumptions about exploitability. Think about business impact, not just technical severity.

Validation & Reporting

• Confirm every finding with reproducible PoC before reporting
• Document: severity (CVSS), affected asset, steps, evidence, remediation
• Use record_vulnerability when running inside the penkit51 platform
• Chain low-severity findings into higher-impact attack paths
• Never report without evidence — distinguish hypothesis from confirmed vuln

Validation & Reporting

• Confirm every finding with reproducible PoC before reporting
• Document: severity (CVSS), affected asset, steps, evidence, remediation
• Use record_vulnerability when running inside the penkit51 platform
• Chain low-severity findings into higher-impact attack paths
• Never report without evidence — distinguish hypothesis from confirmed vuln