security-assessment

Required Tools

This is an orchestrator skill that delegates to sub-skills. Tool requirements depend on which sub-skills are invoked during the assessment.

| Sub-Skill | Tools Required | Reference | |-----------|---------------|-----------| | recon-and-enumeration | rustscan, nmap, ffuf, nuclei, httpx, dig | See recon skill | | webapp-pentesting | rustscan, nmap, ffuf, nuclei, nikto, sqlmap, curl | See webapp skill | | api-pentesting | curl, ffuf, httpx, nuclei, sqlmap | See api skill | | infra-pentesting | rustscan, nmap, Metasploit, john, hashcat | See infra skill | | android-pentesting | adb, jadx, apktool, Frida, mitmproxy | See android skill | | secure-code-review | ripgrep, find, ast-grep | See code-review skill |

Tool Execution Protocol

Before starting any assessment, verify tool availability and establish fallback chains:

1. Pre-Assessment Tool Check

CRITICAL: If SUPERHACKERS_ROOT is not set, auto-detect it first

# Auto-detect SUPERHACKERS_ROOT if not set
if [ -z "${SUPERHACKERS_ROOT:-}" ]; then
  # Try common plugin cache paths
  for path in \
    "$HOME/.claude/plugins/cache/superhackers/superhackers/1.2.* \
    "$HOME/.claude/plugins/cache/superhackers/superhackers/"* \
    "$HOME/superhackers" \
    "$(pwd)/superhackers" \
    "$(dirname "$(dirname "${BASH_SOURCE[0]:-$0}")")"; do
    if [ -d "$path" ] && [ -f "$path/scripts/detect-tools.sh" ]; then
      export SUPERHACKERS_ROOT="$path"
      echo "Auto-detected SUPERHACKERS_ROOT=$SUPERHACKERS_ROOT"
      break
    fi
  done
fi

# Verify detection worked
if [ -z "${SUPERHACKERS_ROOT:-}" ] || [ ! -f "$SUPERHACKERS_ROOT/scripts/detect-tools.sh" ]; then
  echo "ERROR: SUPERHACKERS_ROOT not set and auto-detection failed"
  echo "Please set: export SUPERHACKERS_ROOT=/path/to/superhackers"
  return 1
fi

# Run automated tool detection
bash $SUPERHACKERS_ROOT/scripts/detect-tools.sh > tool_check.log 2>&1

# Analyze results
if rg -q "TOOLS_BROKEN" tool_check.log; then
  echo "WARNING: Some tools are broken and need reinstallation"
  rg "TOOLS_BROKEN" tool_check.log
fi

if rg -q "REQUIRED_MISSING" tool_check.log; then
  echo "CRITICAL: Required tools are missing"
  rg "REQUIRED_MISSING" tool_check.log
  echo ""
  echo "Options:"
  echo "1. Install missing tools (see SETUP.md)"
  echo "2. Proceed with available tools (reduced coverage)"
  echo "3. Cancel assessment"
fi

# Cache tool availability for sub-skills
export TOOL_AVAILABILITY=$(cat tool_check.log)

2. Sub-Skill Tool Validation

Before delegating to any sub-skill, verify its required tools are available:

# Check if recon tools are available before loading recon skill
RECON_TOOLS="rustscan nmap ffuf nuclei httpx dig"
MISSING_TOOLS=()

for tool in $RECON_TOOLS; do
  if ! command -v $tool >/dev/null 2>&1; then
    MISSING_TOOLS+=($tool)
  fi
done

if [ ${#MISSING_TOOLS[@]} -gt 0 ]; then
  echo "WARNING: Recon phase missing tools: ${MISSING_TOOLS[*]}"
  echo "Fallback tools will be used by recon skill"
  echo "See TOOLCHAIN.md for fallback chains"
fi

3. Tool Failure During Assessment

If a tool fails during assessment execution:

1. Don't skip the phase - Use fallback tools
2. Document the failure - Note which tools failed and what was used instead
3. Don't downgrade severity - Finding severity based on what was tested, not what failed

# Example: Port scanning phase
echo "=== Phase 2: Port Scanning ==="

if command -v rustscan >/dev/null 2>&1; then
  echo "Using rustscan for port discovery..."
  bash $SUPERHACKERS_ROOT/scripts/run-tool.sh rustscan 60 scan_results.txt -- rustscan -a $TARGET --ulimit 5000
else
  echo "PRIMARY_TOOL_FAILURE: rustscan not available"
  echo "FALLBACK: Using nmap for port scanning"
  bash $SUPERHACKERS_ROOT/scripts/run-tool.sh nmap 300 scan_results.txt -- nmap -sS -T4 $TARGET
fi

# Validate output before proceeding
bash $SUPERHACKERS_ROOT/scripts/validate-output.sh rustscan scan_results.txt $?

4. Assessment-Level Decision Tree

When multiple tools fail, decide whether to:

• Continue with reduced coverage - Document limitations, test what you can
• Re-plan the assessment - Adjust methodology to available tools
• Report to stakeholder - If critical tools are missing

# Decision framework
PRIMARY_TOOLS_AVAILABLE=$(rg -c "local" tool_check.log)
TOTAL_REQUIRED_TOOLS=$(rg -c "Yes" TOOLCHAIN.md | head -1)

AVAILABILITY_RATIO=$((PRIMARY_TOOLS_AVAILABLE * 100 / TOTAL_REQUIRED_TOOLS))

if [ $AVAILABILITY_RATIO -lt 50 ]; then
  echo "WARNING: Less than 50% of required tools available"
  echo "Recommendation: Re-plan assessment or install tools"
  echo "Current tool availability: $PRIMARY_TOOLS_AVAILABLE/$TOTAL_REQUIRED_TOOLS"
fi

Run bash $SUPERHACKERS_ROOT/scripts/detect-tools.sh for tool availability, or read $SUPERHACKERS_ROOT/TOOLCHAIN.md for the full resolution protocol before starting any assessment to identify available tools and plan accordingly.

Overview

Role: Engagement Planner — Your job is to define scope, select methodology, and sequence the engagement phases. Stay in your lane: you plan and coordinate, you do NOT perform testing, verification, or reporting.

Master orchestrator skill for comprehensive security assessments. This skill coordinates the full assessment lifecycle — from scoping and planning through testing, analysis, and reporting. It ties together all specialized security skills (recon, pentesting, code review, exploit development, reporting) into a cohesive engagement.

Pipeline Position

Position: Phase 1 (Planning) — the FIRST skill loaded in a full engagement Expected Input: User's scope definition, target URLs/IPs, rules of engagement, engagement depth preference Your Output: Engagement plan — scope boundaries, skill sequence, depth selection, rules of engagement Consumed By: All subsequent skills (defines their operating boundaries and sequence) Critical: Your plan determines which skills are loaded, in what order, and at what depth. An incomplete plan = an incomplete engagement.

This is NOT a replacement for specialized skills. It is the conductor that determines WHICH skills to invoke, in WHAT order, and HOW to synthesize their outputs into actionable security intelligence.

Sub-Skill Registry

| Skill | Purpose | When to Invoke | |-------|---------|----------------| | superhackers:recon-and-enumeration | Attack surface discovery | Always first in external assessments | | superhackers:webapp-pentesting | Web application testing | Web apps in scope | | superhackers:api-pentesting | API security testing | REST/GraphQL/gRPC APIs in scope | | superhackers:secure-code-review | Source code analysis | Source code access granted | | superhackers:vulnerability-verification | Confirm exploitability | Before reporting any finding | | superhackers:exploit-development | PoC/exploit creation | When verification requires custom exploit | | superhackers:infra-pentesting | Infrastructure testing | Network/server infra in scope | | superhackers:android-pentesting | Mobile app testing | Android apps in scope | | superhackers:writing-security-reports | Deliverable creation | Always at end of engagement |

When to Use

• Starting a new security assessment, pentest, or red team engagement
• Defining scope, rules of engagement, or methodology for a security project
• Coordinating multiple testing activities across different attack surfaces
• Performing threat modeling (STRIDE, attack trees, DFDs)
• Rating vulnerabilities with CVSS and mapping to compliance frameworks
• Managing assessment timeline, milestones, and deliverables
• Communicating findings to stakeholders (emergency, interim, final)
• Deciding which specialized skill to invoke for a given task
• Synthesizing findings from multiple testing phases into a unified report

Core Pattern

PLAN  → Define scope, methodology, threat model, timeline
  ↓
RECON → Discover and enumerate the attack surface
  ↓
TEST  → Execute testing activities using specialized skills
  ↓
ANALYZE → Rate findings, assess risk, map to frameworks
  ↓
REPORT → Compile deliverables, present to stakeholders

Execution Discipline

• Persist: Continue working through ALL steps of the Core Pattern until completion criteria are met. Do NOT stop after a single tool run or partial result.
• Scope: Work ONLY within this skill's methodology. Do NOT jump to another phase (e.g., don't start writing the report while still testing).
• Negative Results: If thorough testing reveals no vulnerabilities, that IS a valid result. Document what was tested and report "no findings" — do NOT invent issues.
• Retry Limit: Max 3 attempts per test. If blocked, classify the failure and proceed.

Quick Reference

Assessment Type Decision Matrix

| Assessment Type | Scope | Depth | Stealth | Duration | Deliverable | |----------------|-------|-------|---------|----------|-------------| | Vulnerability Assessment | Broad | Shallow | No | 1-3 days | Vuln list + risk ratings | | Penetration Test | Defined | Deep | Optional | 1-3 weeks | Full report + PoCs | | Red Team Engagement | Goal-based | Varies | Yes | 2-8 weeks | Narrative + TTPs | | Security Audit | Comprehensive | Review-level | No | 1-4 weeks | Compliance report | | Code Review | Source code | Deep | N/A | 3-10 days | Code findings report | | Bug Bounty Triage | Single target | Deep | No | Ongoing | Per-finding reports |

Skill Orchestration Flowchart

External Assessment (no source):
  recon-and-enumeration → webapp-pentesting / api-pentesting / infra-pentesting
    → vulnerability-verification → exploit-development (if needed)
    → writing-security-reports

Internal Assessment (with source):
  secure-code-review → vulnerability-verification
    → webapp-pentesting / api-pentesting (validate in running app)
    → writing-security-reports

Full Engagement:
  recon-and-enumeration → secure-code-review (if source available)
    → webapp-pentesting + api-pentesting + infra-pentesting + android-pentesting
    → vulnerability-verification → exploit-development
    → writing-security-reports

CVSS v4.0 Quick Scoring

CVSS 4.0 uses a lookup-based algorithm rather than a simple formula with individual metric weights. Use the FIRST calculator or Python cvss library for accurate scores.

Note: Use Python cvss library (pip install cvss) for accurate score calculation: from cvss import CVSS4

| Metric | Values | Description | |--------|--------|-------------| | AV | N, A, L, P | Attack Vector | | AC | L, H | Attack Complexity | | AT | N, P | Attack Requirements (NEW) | | PR | N, L, H | Privileges Required | | UI | N, P, A | User Interaction (changed: P=passive, A=active) | | VC | H, L, N | Confidentiality impact on vulnerable system | | VI | H, L, N | Integrity impact on vulnerable system | | VA | H, L, N | Availability impact on vulnerable system | | SC | H, L, N | Confidentiality impact on subsequent systems | | SI | H, L, N | Integrity impact on subsequent systems | | SA | H, L, N | Availability impact on subsequent systems |

| Score Range | Rating | |------------|--------| | 0.0 | None | | 0.1 – 3.9 | Low | | 4.0 – 6.9 | Medium | | 7.0 – 8.9 | High | | 9.0 – 10.0 | Critical |

Implementation

Phase 1: Assessment Planning

1.1 Scope Definition

Establish clear boundaries before any testing begins.

## Assessment Scope Document

### In-Scope Assets
- [ ] Web applications (list URLs/domains)
- [ ] APIs (list endpoints, documentation links)
- [ ] Infrastructure (list IP ranges, cloud accounts)
- [ ] Mobile applications (list app IDs, platforms)
- [ ] Source code repositories (list repos, branches)
- [ ] Internal networks (list VLANs, subnets)

### Out-of-Scope
- [ ] Third-party services not owned by client
- [ ] Production databases (unless explicitly authorized)
- [ ] Denial-of-service testing (unless explicitly authorized)
- [ ] Social engineering (unless explicitly authorized)
- [ ] Physical security testing (unless explicitly authorized)

### Rules of Engagement
- Testing window: [dates and times]
- Emergency contact: [name, phone, email]
- Escalation procedure: [steps for critical findings]
- Data handling: [classification, storage, destruction]
- Credential usage: [provided creds, credential stuffing policy]
- Automated scanning limits: [rate limiting, excluded scanners]

1.2 Engagement Depth Selection

Before selecting methodology, determine the engagement depth. This setting propagates to ALL downstream skills and controls how much time and effort is invested in each phase.

| Depth | Duration | Focus | Skip | Mindset | |-------|----------|-------|------|---------| | Quick | 1-2 hours | Auth bypass, BOLA/IDOR, RCE, SQLi, SSRF, exposed secrets | Exhaustive enum, deep fuzzing, info disclosure, theoretical issues | Time-boxed bug bounty hunter | | Standard | Half-day to full day | OWASP Top 10 + business logic for critical flows | Persistent retesting, edge cases, deep chaining | Methodical, systematic | | Deep | Multi-day | Full attack surface including edge cases, chaining, persistence | Nothing — exhaustive coverage | Relentless, creative, patient |

Quick Depth:

• Recon: Map auth + critical flows only, identify high-value endpoints, skip deep discovery
• Testing: Focus on critical/high-impact vulns only (auth bypass, RCE, SQLi, SSRF, exposed secrets)
• Subagents: Only for parallel high-priority targets
• Validation: Minimal PoC, demonstrate real impact
• Chaining: When a strong primitive is found, attempt ONE high-impact pivot immediately
• Scanner config: nuclei -severity critical,high only

Standard Depth:

• Recon: Full crawl, endpoint enumeration, role mapping, tech fingerprinting
• Testing: Systematic by category with focused subagents (input validation, auth, access control, business logic)
• Subagents: One per testing category, run in parallel
• Validation: Working PoC with impact demonstration, try one chain per finding
• Chaining: Always ask "what does this finding enable next?" — prefer complete end-to-end paths
• Scanner config: nuclei -severity critical,high,medium

Deep Depth:

• Recon: Whitebox analysis — every code path, data model, integration point. If source available, map every file/module
• Business Logic: Map every user flow, state machine, trust boundary, invariant. Identify implicit assumptions
• Testing: Hierarchical decomposition — component → feature → vulnerability level. Each area gets dedicated analysis
• Subagents: Spawn specialized agents per component, scale horizontally
• Chaining: Every finding is a pivot point — continue to maximum privilege. Validate full sequence
• Persistence: Research tech-specific bypasses, alternative techniques, edge cases. Revisit with new info from other findings
• Scanner config: nuclei with all templates, custom templates if needed

How to determine depth:

• User says "quick check", "sanity test", "before deployment" → Quick
• User says "pentest", "security assessment", "vulnerability assessment" → Standard
• User says "comprehensive", "thorough", "annual assessment", "red team" → Deep
• If unclear → Ask: "Should I do a quick high-impact check, a standard systematic assessment, or a deep comprehensive review?"

Propagating depth to downstream skills: When invoking sub-skills, pass the depth context:

Engagement depth: [Quick|Standard|Deep]
→ recon-and-enumeration: adjust scope per depth level above
→ webapp/api/infra-pentesting: adjust testing breadth and tool configuration
→ vulnerability-verification: adjust PoC depth (minimal for Quick, full for Deep)
→ exploit-development: skip for Quick, selective for Standard, comprehensive for Deep

Time Distribution Within Each Phase

Regardless of engagement depth, distribute effort within each phase as:

| Allocation | Activity | Example | |---|---|---| | ~10% | Setup and orientation | Review scope, configure tools, create working dirs | | ~30% | Broad exploration | Run multiple scan types, enumerate widely, try diverse payloads | | ~30% | Evaluation and triage | Analyze results, prioritize findings, eliminate false positives | | ~30% | Focused exploitation | Deep-dive on highest-priority findings, build exploit chains, gather evidence |

Anti-patterns:

• Spending 80% on automated scanning — miss manual-only findings
• Spending 80% on one attack vector — miss breadth
• Skipping evaluation — report unverified findings

Plan Adaptation: When findings change priorities, adjust the remaining plan using minimal modifications — don't restart from scratch. Add new targets, remove dead ends, reorder by updated priority.

1.3 Methodology Selection

Choose methodology based on assessment type and client requirements:

| Framework | Best For | Key Focus | |-----------|----------|-----------| | OWASP Testing Guide (OTG) | Web app pentests | Structured web testing categories | | OWASP ASVS | Security audits, code review | Verification levels (L1/L2/L3) | | PTES | Full pentests | End-to-end pentest lifecycle | | OSSTMM | Comprehensive assessments | Operational security metrics | | NIST SP 800-115 | Government/compliance | Technical security testing | | MITRE ATT&CK | Red team engagements | Adversary TTPs mapping |

1.3 Threat Modeling

Perform threat modeling BEFORE testing to focus effort on highest-risk areas.

STRIDE Model — Apply to each component in the data flow:

| Threat | Question | Example | |--------|----------|---------| | Spoofing | Can an attacker impersonate a user or system? | Stolen JWT, forged SAML assertion | | Tampering | Can data be modified in transit or at rest? | MITM on API calls, database manipulation | | Repudiation | Can actions be performed without audit trail? | Missing logging on admin actions | | Information Disclosure | Can sensitive data leak? | Error messages with stack traces, exposed API keys | | Denial of Service | Can availability be impacted? | ReDoS, resource exhaustion, algorithmic complexity | | Elevation of Privilege | Can a user gain unauthorized access? | IDOR, privilege escalation, broken RBAC |

Building an Attack Tree:

Goal: Access admin panel without authorization
├── Bypass authentication
│   ├── Brute-force credentials
│   ├── Exploit password reset flow
│   ├── Steal session token (XSS, session fixation)
│   └── Exploit SSO/OAuth misconfiguration
├── Bypass authorization
│   ├── IDOR on admin API endpoints
│   ├── Modify role claim in JWT
│   ├── Exploit mass assignment to set admin flag
│   └── Access admin routes without auth middleware
└── Exploit infrastructure
    ├── Access admin interface on internal port
    ├── Exploit SSRF to reach admin panel
    └── Pivot from compromised internal host

Data Flow Diagram Approach:

1. Identify all data entry points (user inputs, API calls, file uploads, third-party webhooks)
2. Map data flows between components (frontend → API → database → cache)
3. Mark trust boundaries (internet → DMZ → internal network → database tier)
4. Identify where data crosses trust boundaries — these are your priority testing points
5. Document data sensitivity levels at each point

Phase 2: Reconnaissance

REQUIRED SUB-SKILL: Use superhackers:recon-and-enumeration for detailed reconnaissance methodology.

Orchestration approach for recon:

# 1. Passive reconnaissance first — no direct target interaction
# Domain enumeration, OSINT, technology fingerprinting
# → Output: list of subdomains, IPs, technologies, exposed services

# 2. Active reconnaissance — direct target interaction
# Port scanning, service enumeration, directory discovery
# → Output: detailed service map, application inventory

# 3. Synthesis — combine passive and active findings
# Build target inventory with:
#   - Each application/service identified
#   - Technology stack per target
#   - Authentication mechanisms observed
#   - Potential attack vectors per target

Phase 3: Testing Execution

3.1 Testing Orchestration

Execute testing in priority order based on threat model:

Priority 1: Authentication & Authorization
  REQUIRED SUB-SKILL: Use superhackers:webapp-pentesting for web auth testing
  REQUIRED SUB-SKILL: Use superhackers:api-pentesting for API auth testing
  Focus: Login bypass, privilege escalation, session management, OAuth/OIDC flows

Priority 2: Injection & Input Handling
  REQUIRED SUB-SKILL: Use superhackers:webapp-pentesting for web injection testing
  REQUIRED SUB-SKILL: Use superhackers:api-pentesting for API injection testing
  REQUIRED SUB-SKILL: Use superhackers:secure-code-review for source-level analysis
  Focus: SQLi, XSS, SSTI, command injection, deserialization

Priority 3: Business Logic
  No specific sub-skill — requires manual analysis based on application context
  Focus: Payment manipulation, workflow bypass, race conditions, IDOR

Priority 4: Infrastructure
  REQUIRED SUB-SKILL: Use superhackers:infra-pentesting for infrastructure testing
  Focus: Service misconfigurations, default credentials, network segmentation

Priority 5: Client-Side & Mobile
  REQUIRED SUB-SKILL: Use superhackers:android-pentesting for Android testing
  Focus: Local storage, certificate pinning, reverse engineering, IPC

Priority 6: Configuration & Hardening
  REQUIRED SUB-SKILL: Use superhackers:secure-code-review for configuration review
  Focus: Headers, TLS, CORS, cookie flags, error handling

3.2 Testing Tracker

Maintain a testing checklist during execution:

## Testing Progress

### Authentication (P1)
- [ ] Registration flow — input validation, email verification
- [ ] Login — brute force protection, credential stuffing, timing attacks
- [ ] Password reset — token entropy, expiration, reuse
- [ ] Session management — token generation, expiration, invalidation
- [ ] Multi-factor auth — bypass techniques, fallback mechanisms
- [ ] OAuth/OIDC — redirect_uri validation, state parameter, token leakage

### Authorization (P1)
- [ ] Horizontal access control — IDOR on all resource endpoints
- [ ] Vertical access control — privilege escalation paths
- [ ] Function-level access — admin functionality accessible to users
- [ ] API authorization — missing auth on endpoints

### Injection (P2)
- [ ] SQL injection — all input points, blind, time-based
- [ ] Cross-site scripting — reflected, stored, DOM-based
- [ ] Command injection — OS command contexts
- [ ] Template injection — server-side template engines
- [ ] LDAP/XPath injection — directory service queries
- [ ] Header injection — HTTP response splitting, host header

### Data Exposure (P2)
- [ ] Sensitive data in responses — PII, credentials, tokens
- [ ] Error handling — stack traces, debug info, verbose errors
- [ ] API response filtering — excessive data exposure
- [ ] Caching — sensitive data in cache headers

### Business Logic (P3)
- [ ] Payment/transaction manipulation
- [ ] Workflow bypass — skipping required steps
- [ ] Race conditions — TOCTOU, parallel request abuse
- [ ] Rate 

<!-- Content truncated for initial SEO render. Open the source file tab for the full file. -->