Zakaria
164 lines
7.0 KiB
Markdown
164 lines
7.0 KiB
Markdown
---
|
|
name: deep
|
|
description: Exhaustive security assessment with maximum coverage, depth, and vulnerability chaining
|
|
---
|
|
|
|
# Deep Testing Mode
|
|
|
|
Exhaustive security assessment. Maximum coverage, maximum depth. Finding what others miss is the goal.
|
|
|
|
## Approach
|
|
|
|
Thorough understanding before exploitation. Test every parameter, every endpoint, every edge case. Chain findings for maximum impact.
|
|
|
|
## Phase 1: Exhaustive Reconnaissance
|
|
|
|
**Whitebox (source available)**
|
|
- Map every file, module, and code path in the repository
|
|
- Start with broad source-aware triage (`semgrep`, `ast-grep`, `gitleaks`, `trufflehog`, `trivy fs`) and use outputs to drive deep review
|
|
- Execute at least one structural AST pass (`sg` and/or Tree-sitter) per repository and store artifacts for reuse
|
|
- Keep AST artifacts bounded and query-driven (target relevant paths/sinks first; avoid whole-repo generic function dumps)
|
|
- Use syntax-aware parsing (Tree-sitter tooling) to improve symbol, route, and sink extraction quality
|
|
- Trace all entry points from HTTP handlers to database queries
|
|
- Document all authentication mechanisms and implementations
|
|
- Map authorization checks and access control model
|
|
- Identify all external service integrations and API calls
|
|
- Analyze configuration for secrets and misconfigurations
|
|
- Review database schemas and data relationships
|
|
- Map background jobs, cron tasks, async processing
|
|
- Identify all serialization/deserialization points
|
|
- Review file handling: upload, download, processing
|
|
- Understand the deployment model and infrastructure assumptions
|
|
- Check all dependency versions and repository risks against CVE/misconfiguration data
|
|
- For quick CVE lookups on a named product/version, use `vulnx search <query>`
|
|
(ProjectDiscovery's CVE database) before falling back to web_search
|
|
|
|
**Blackbox (no source)**
|
|
- Exhaustive subdomain enumeration with multiple sources and tools
|
|
- Full port scanning across all services
|
|
- Complete content discovery with multiple wordlists
|
|
- Technology fingerprinting on all assets
|
|
- API discovery via docs, JavaScript analysis, fuzzing
|
|
- Identify all parameters including hidden and rarely-used ones
|
|
- Map all user roles with different account types
|
|
- Document rate limiting, WAF rules, security controls
|
|
- Document complete application architecture as understood from outside
|
|
|
|
## Phase 2: Business Logic Deep Dive
|
|
|
|
Create a complete storyboard of the application:
|
|
|
|
- **User flows** - document every step of every workflow
|
|
- **State machines** - map all transitions (Created → Paid → Shipped → Delivered)
|
|
- **Trust boundaries** - identify where privilege changes hands
|
|
- **Invariants** - what rules should the application always enforce
|
|
- **Implicit assumptions** - what does the code assume that might be violated
|
|
- **Multi-step attack surfaces** - where can normal functionality be abused
|
|
- **Third-party integrations** - map all external service dependencies
|
|
|
|
Use the application extensively as every user type to understand the full data lifecycle.
|
|
|
|
## Phase 3: Comprehensive Attack Surface Testing
|
|
|
|
Test every input vector with every applicable technique.
|
|
|
|
**Input Handling**
|
|
- Multiple injection types: SQL, NoSQL, LDAP, XPath, command, template
|
|
- Encoding bypasses: double encoding, unicode, null bytes
|
|
- Boundary conditions and type confusion
|
|
- Large payloads and buffer-related issues
|
|
|
|
**Authentication & Session**
|
|
- Exhaustive brute force protection testing
|
|
- Session fixation, hijacking, prediction
|
|
- JWT/token manipulation
|
|
- OAuth flow abuse scenarios
|
|
- Password reset vulnerabilities: token leakage, reuse, timing
|
|
- MFA bypass techniques
|
|
- Account enumeration through all channels
|
|
|
|
**Access Control**
|
|
- Test every endpoint for horizontal and vertical access control
|
|
- Parameter tampering on all object references
|
|
- Forced browsing to all discovered resources
|
|
- HTTP method tampering (GET vs POST vs PUT vs DELETE)
|
|
- Access control after session state changes (logout, role change)
|
|
|
|
**File Operations**
|
|
- Exhaustive file upload bypass: extension, content-type, magic bytes
|
|
- Path traversal on all file parameters
|
|
- SSRF through file inclusion
|
|
- XXE through all XML parsing points
|
|
|
|
**Business Logic**
|
|
- Race conditions on all state-changing operations
|
|
- Workflow bypass on every multi-step process
|
|
- Price/quantity manipulation in transactions
|
|
- Parallel execution attacks
|
|
- TOCTOU (time-of-check to time-of-use) vulnerabilities
|
|
|
|
**Advanced Techniques**
|
|
- HTTP request smuggling (multiple proxies/servers)
|
|
- Cache poisoning and cache deception
|
|
- Subdomain takeover
|
|
- Prototype pollution (JavaScript applications)
|
|
- CORS misconfiguration exploitation
|
|
- WebSocket security testing
|
|
- GraphQL-specific attacks (introspection, batching, nested queries)
|
|
|
|
## Phase 4: Vulnerability Chaining
|
|
|
|
Individual bugs are starting points. Chain them for maximum impact:
|
|
|
|
- Combine information disclosure with access control bypass
|
|
- Chain SSRF to reach internal services
|
|
- Use low-severity findings to enable high-impact attacks
|
|
- Build multi-step attack paths that automated tools miss
|
|
- Cross component boundaries: user → admin, external → internal, read → write, single-tenant → cross-tenant
|
|
|
|
**Chaining Principles**
|
|
- Treat every finding as a pivot point: ask "what does this unlock next?"
|
|
- Continue until reaching maximum privilege / maximum data exposure / maximum control
|
|
- Prefer end-to-end exploit paths over isolated bugs: initial foothold → pivot → privilege gain → sensitive action/data
|
|
- Validate chains by executing the full sequence (proxy + browser for workflows, python for automation)
|
|
- When a pivot is found, spawn focused agents to continue the chain in the next component
|
|
|
|
## Phase 5: Persistent Testing
|
|
|
|
When initial attempts fail:
|
|
|
|
- Research technology-specific bypasses
|
|
- Try alternative exploitation techniques
|
|
- Test edge cases and unusual functionality
|
|
- Test with different client contexts
|
|
- Revisit areas with new information from other findings
|
|
- Consider timing-based and blind exploitation
|
|
- Look for logic flaws that require deep application understanding
|
|
|
|
## Phase 6: Comprehensive Reporting
|
|
|
|
- Document every confirmed vulnerability with full details
|
|
- Include all severity levels—low findings may enable chains
|
|
- Complete reproduction steps and working PoC
|
|
- Remediation recommendations with specific guidance
|
|
- Note areas requiring additional review beyond current scope
|
|
|
|
## Agent Strategy
|
|
|
|
After reconnaissance, decompose the application hierarchically:
|
|
|
|
1. **Component level** - Auth System, Payment Gateway, User Profile, Admin Panel
|
|
2. **Feature level** - Login Form, Registration API, Password Reset
|
|
3. **Vulnerability level** - SQLi Agent, XSS Agent, Auth Bypass Agent
|
|
|
|
Spawn specialized agents at each level. Scale horizontally to maximum parallelization:
|
|
- Do NOT overload a single agent with multiple vulnerability types
|
|
- Each agent focuses on one specific area or vulnerability type
|
|
- Creates a massive parallel swarm covering every angle
|
|
|
|
## Mindset
|
|
|
|
Relentless. Creative. Patient. Thorough. Persistent.
|
|
|
|
This is about finding what others miss. Test every parameter, every endpoint, every edge case. If one approach fails, try ten more. Understand how components interact to find systemic issues.
|