first commit
This commit is contained in:
@@ -0,0 +1,163 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
name: quick
|
||||
description: Time-boxed rapid assessment targeting high-impact vulnerabilities
|
||||
---
|
||||
|
||||
# Quick Testing Mode
|
||||
|
||||
Time-boxed assessment focused on high-impact vulnerabilities. Prioritize breadth over depth.
|
||||
|
||||
## Approach
|
||||
|
||||
Optimize for fast feedback on critical security issues. Skip exhaustive enumeration in favor of targeted testing on high-value attack surfaces.
|
||||
|
||||
## Phase 1: Rapid Orientation
|
||||
|
||||
**Whitebox (source available)**
|
||||
- Focus on recent changes: git diffs, new commits, modified files—these are most likely to contain fresh bugs
|
||||
- Run a fast static triage on changed files first (`semgrep`, then targeted `sg` queries)
|
||||
- Run at least one lightweight AST pass (`sg` or Tree-sitter) so structural mapping is not skipped
|
||||
- Keep AST commands tightly scoped to changed or high-risk paths; avoid broad repository-wide pattern dumps
|
||||
- Run quick secret and dependency checks (`gitleaks`, `trufflehog`, `trivy fs`) scoped to changed areas when possible
|
||||
- Identify security-sensitive patterns in changed code: auth checks, input handling, database queries, file operations
|
||||
- Trace user input through modified code paths
|
||||
- Check if security controls were modified or bypassed
|
||||
|
||||
**Blackbox (no source)**
|
||||
- Map authentication and critical user flows
|
||||
- Identify exposed endpoints and entry points
|
||||
- Skip deep content discovery—test what's immediately accessible
|
||||
|
||||
## Phase 2: High-Impact Targets
|
||||
|
||||
Test in priority order:
|
||||
|
||||
1. **Authentication bypass** - login flaws, session issues, token weaknesses
|
||||
2. **Broken access control** - IDOR, privilege escalation, missing authorization
|
||||
3. **Remote code execution** - command injection, deserialization, SSTI
|
||||
4. **SQL injection** - authentication endpoints, search, filters
|
||||
5. **SSRF** - URL parameters, webhooks, integrations
|
||||
6. **Exposed secrets** - hardcoded credentials, API keys, config files
|
||||
|
||||
Skip for quick scans:
|
||||
- Exhaustive subdomain enumeration
|
||||
- Full directory bruteforcing
|
||||
- Low-severity information disclosure
|
||||
- Theoretical issues without working PoC
|
||||
|
||||
## Phase 3: Validation
|
||||
|
||||
- Confirm exploitability with minimal proof-of-concept
|
||||
- Demonstrate real impact, not theoretical risk
|
||||
- Report findings immediately as discovered
|
||||
|
||||
## Chaining
|
||||
|
||||
When a strong primitive is found (auth weakness, injection point, internal access), immediately attempt one high-impact pivot to demonstrate maximum severity. Don't stop at a low-context "maybe"—turn it into a concrete exploit sequence that reaches privileged action or sensitive data.
|
||||
|
||||
## Operational Guidelines
|
||||
|
||||
- Use browser tool for quick manual testing of critical flows
|
||||
- Use terminal for targeted scans with fast presets (e.g., nuclei with critical/high templates only)
|
||||
- Use proxy to inspect traffic on key endpoints
|
||||
- Skip extensive fuzzing—use targeted payloads only
|
||||
- Create subagents only for parallel high-priority tasks
|
||||
|
||||
## Mindset
|
||||
|
||||
Think like a time-boxed bug bounty hunter going for quick wins. Prioritize breadth over depth on critical areas. If something looks exploitable, validate quickly and move on. Don't get stuck—if an attack vector isn't yielding results quickly, pivot.
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: standard
|
||||
description: Balanced security assessment with systematic methodology and full attack surface coverage
|
||||
---
|
||||
|
||||
# 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.
|
||||
Reference in New Issue
Block a user