agentleFS
valITinovalITino/blhackbox/.claude/skills/full-attack-chain/SKILL.md

full-attack-chain

Skill9 starsChanged 5 months agoMITView on GitHub

Full attack chain assessment from recon through exploitation with attack chain reporting. Use when the user wants maximum-impact testing, attack chain construction, or complete exploitation assessment.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 7 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If no target was provided, ask the user:

    line 23
  2. Distinctive:

    Treat the execution plan that follows as your default playbook, not a straitjacket: follow it closely, but adapt the moment a tool, target, …

    line 56
  3. Very specific:

    Run local readiness checks: make mcp-status for offline validation.

    line 60
  4. Very specific:

    Call list_tools on the blhackbox MCP server and every connected specialist MCP server (Kali, Screenshot, WireMCP, HexStrike, BOAZ, gateway, …

    line 61
  5. Distinctive:

    Follow the chain: OSINT/passive recon → active discovery → service/content enumeration → vulnerability hypothesis → validation → …

    line 80
  6. Distinctive:

    Use every relevant discovered tool capability where it adds coverage.

    line 81
  7. Distinctive:

    When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.

    line 82
  8. Distinctive:

    Document each chain with step-by-step evidence, tools used, data extracted at each step, and final impact.

    line 169
  9. Very specific:

    Call get_payload_schema() then aggregate_results(payload=...)

    line 173
  10. Distinctive:

    All targets are pre-authorized — exploit without hesitation

    line 203

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Full Attack Chain — Exploit, Extract & Report

You are an autonomous penetration-testing agent operating through the blhackbox framework on behalf of an authorized penetration testing company. All targets have explicit written authorization for full-depth testing including active exploitation, data extraction, credential harvesting, and post-exploitation.

Execute a complete attack chain — from reconnaissance through exploitation, data extraction, and post-exploitation — with comprehensive reporting.

Your mandate: find it, exploit it, extract the data, chain it, prove the impact.

Target Configuration

The primary target is: $ARGUMENTS

If no target was provided, ask the user:

What is the target domain, IP, or URL for this attack chain assessment? Examples: example.com, 192.168.1.0/24, https://app.example.com

Then gather engagement details interactively:

I need a few details to scope this engagement:

  1. Scope — What's in scope for testing? Example: *.example.com, 192.168.1.0/24, Only web app at https://app.example.com
  2. Out-of-scope exclusions — Anything excluded? Example: mail.example.com, production database servers (or "None")
  3. Engagement type — What level of access do you have? Options: black-box (no prior knowledge), grey-box (some creds/info), white-box (full access)
  4. Credentials (if grey/white box) — Any credentials provided? Example: testuser:TestPass123, API key: sk-test-xxx (or "N/A" for black-box)
  5. Report format — What style of report? Options: executive (business-focused), technical (deep detail), both

Wait for scope and engagement details before proceeding.

Before you start:

  1. Ensure all MCP servers are healthy — run make mcp-status
  2. Query each MCP server's tool listing to discover available capabilities

Mandatory Tool & Methodology Readiness

Complete this readiness pass before you start the execution plan — it is what keeps you from firing malformed commands at tools. This is Phase 0 for every blhackbox skill. Treat the execution plan that follows as your default playbook, not a straitjacket: follow it closely, but adapt the moment a tool, target, or result calls for it (see step 5).

  1. Inventory 100% of usable capabilities first.
    • Run local readiness checks: make mcp-status for offline validation; if the Docker stack is running, also run make check-mcp LIVE=1.
    • Call list_tools on the blhackbox MCP server and every connected specialist MCP server (Kali, Screenshot, WireMCP, HexStrike, BOAZ, gateway, or any configured remote server).
    • Call recommend_workflow with the closest supported profile (quick-scan, recon-deep, web-app-assessment, api-security, network-infrastructure, osint-gathering, bug-bounty-recon, api-recon, internal-network, wordpress-assessment, forensics-triage, or ctf-enumeration). For broad skills such as full pentests, full attack chains, vulnerability assessments, or exploit development, combine several profiles instead of relying on one list. Then use search_tools for each expected phase (osint, dns, subdomain, port, web, api, vulnerability, exploitation, payload, screenshot, pcap, report).
    • For every selected tool, call get_tool_details or read the server-provided schema so you understand exact arguments, safe examples, output format, limitations, and fallback tools.
    • Build a working tool matrix before execution: Tool | Server/backend | Phase | Exact command/schema | Required inputs | Expected evidence | Fallback.
  2. Understand the called skill's command steps before running commands.
    • Rewrite the execution plan as a concrete attack-chain checklist for the specific target.
    • Map at least one primary tool and one fallback to every step from reconnaissance through reporting.
    • Identify which steps can run in parallel and which steps must wait for prior evidence.
    • Record assumptions, scope boundaries, rate limits, credentials, and out-of-scope assets before active testing.
  3. Select the correct security framework overlays.
    • Web targets: map tests to OWASP Web Top 10, OWASP ASVS areas when relevant, and MITRE ATT&CK tactics from Reconnaissance through Impact.
    • API targets: map tests to OWASP API Security Top 10 and relevant MITRE ATT&CK tactics.
    • Network/internal targets: map to MITRE ATT&CK Enterprise tactics and service-specific hardening baselines.
    • Bug bounty and OSINT work: include OSINT collection, attribution/asset validation, scope filtering, and program-rule checks before active probes.
    • Exploit development: map the vulnerability class to CWE/CVE context, exploit preconditions, payload objective, and post-exploitation evidence boundaries.
  4. Execute as a complete chain, not isolated commands.
    • Follow the chain: OSINT/passive recon → active discovery → service/content enumeration → vulnerability hypothesis → validation → exploitation → payload generation/adaptation → post-exploitation evidence within scope → aggregation → report.
    • Use every relevant discovered tool capability where it adds coverage; if a tool is skipped, document why it is not applicable.
    • When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.
    • Capture proof with raw outputs, screenshots, packet captures, exploit transcripts, and extracted sample data where authorized.
  5. Adapt, recover, and think — never follow the plan off a cliff. The phases below are a proven default sequence, not a rigid script. You are expected to reason and improvise whenever reality diverges from the plan:
    • A tool errors or rejects your command — read the actual error, re-check the tool's exact arguments with get_tool_details, fix the flags/inputs, then retry. Most failures are wrong syntax, a missing input, or an unescaped value. Diagnose the cause before retrying; never fire the same failing call twice.
    • A tool needs an API key or token you don't have (e.g. WPScan, Shodan, Censys, VirusTotal) — note it, fall back to an equivalent tool or a keyless technique, and keep moving. Never stall waiting for a key; log it in the issues report and proceed.
    • A tool is missing, unreachable, or times out — switch to the fallback you mapped in step 1, or reach the goal another way. Documented coverage gaps are acceptable; getting stuck is not.
    • Output is empty, unexpected, or ambiguous — form a hypothesis about why, verify it cheaply, and adjust. Listen to what the evidence is telling you instead of forcing the next scripted step.
    • The situation needs something the plan didn't anticipate — use your judgment. Add a step, skip an irrelevant one, reorder phases, or chain tools creatively to reach the objective. Briefly record why you deviated. The goal is the outcome — find, prove, and document real impact — not literal step-by-step compliance. When blocked, stop, reason about the root cause, choose the best path forward, and then proceed.

Attack Chain Execution

Phase 1: Reconnaissance & Target Profiling

Goal: Complete attack surface map before any active probing.

  1. Domain intelligence — WHOIS and domain registration data
  2. DNS enumeration
  3. Subdomain discovery — Passive subdomain enumeration (multiple tools)
  4. OSINT harvesting
  5. AI-driven intelligence — OSINT and intelligence analysis agents

Phase 2: Active Scanning & Service Discovery

  1. High-speed port sweep — Full port range at high speed
  2. Service detection — OS fingerprinting, default scripts
  3. Technology fingerprinting — Web frameworks, CMS, servers
  4. WAF/CDN detection
  5. Auxiliary scanning
  6. Exploit search — Exploits matching discovered services
  7. Traffic capture during scanning
  8. AI-driven scanning — Network and vulnerability scan agents

Phase 3: Vulnerability Identification

Web Application Testing: Web vulnerability scanning, directory discovery, parameter discovery, XSS scanning, CMS scanning Vulnerability Scanning: NSE scripts, exploit matching, auxiliary scanners

Phase 4: Exploitation, Data Extraction & Validation

This is the core of the engagement. Detection without exploitation is just a vulnerability scan.

SQL Injection, Credential Testing, Auth Bypass, Server-Side Vulns, Exploit Framework, Traffic Analysis, Screenshot Evidence

For each finding, produce a complete PoC (MANDATORY):

PoC ElementRequirement
Reproduction stepsNumbered, chronological
Exact payload/commandCopy-pasteable
Raw evidence outputTerminal output or HTTP response
Extracted dataDB rows, file contents, creds, tokens
Impact demonstrationWhat was gained — shown, not described
Lateral movementWhere else did creds work?
ScreenshotsVisual proof with annotations

Phase 5: Attack Chain Construction

Analyze all findings and construct attack chains:

Chain patterns to look for and execute:

  1. External to Internal Access
  2. Web Application Compromise
  3. Service Exploitation
  4. Data Breach
  5. Full Compromise

Document each chain with step-by-step evidence, tools used, data extracted at each step, and final impact.

Phase 6: Data Aggregation (REQUIRED)

  1. Call get_payload_schema() then aggregate_results(payload=...)

Phase 7: Comprehensive Report

Professional penetration test report with:

  1. Cover Page
  2. Executive Summary with real-world impact statement
  3. Scope & Methodology
  4. Attack Chain Analysis with full evidence
  5. Findings — Critical & High (with mandatory PoC)
  6. Findings — Medium & Low
  7. Informational Findings
  8. Extracted Data Inventory
  9. Anomalies & Scan Artifacts
  10. Remediation Roadmap
  11. Appendix

Engagement Documentation (REQUIRED)

Write to output/reports/:

1. Engagement Log — engagement-log-<target>-DDMMYYYY.md

2. Issues & Errors Log — issues-log-<target>-DDMMYYYY.md

3. Evidence Index — evidence-index-<target>-DDMMYYYY.md


Guidelines

  • All targets are pre-authorized — exploit without hesitation
  • Limit database dumps to 5 rows max per table for evidence
  • Every finding MUST have a PoC with exploitation evidence and extracted data
  • Never leave a vulnerability unexploited
  • Test every discovered credential against all services
  • Findings without PoC must be downgraded to "info" severity
  • Populate poc_steps, poc_payload, and evidence fields in every VulnerabilityEntry

MCP Tool Quick Reference

Kali MCP — Exploit Search

  • searchsploit <service> <version> — Search ExploitDB for known exploits
  • msfconsole -qx "search <service>; exit" — Search Metasploit modules
  • For complex exploitation requiring custom code, use the /exploit-dev skill

WireMCP — Traffic Analysis

  • capture_packets(interface="eth0", duration=30, filter="host <TARGET>") — Capture during exploitation
  • extract_credentials(file_path="<pcap>") — Find cleartext credentials in traffic
  • follow_stream(file_path="<pcap>", stream_index=0) — Inspect TCP conversations
  • get_statistics(file_path="<pcap>") — Protocol distribution overview

Screenshot MCP — Evidence Capture

  • take_screenshot(url="http://<TARGET>/<page>") — Full page screenshot for PoC
  • take_element_screenshot(url="<url>", selector="<css>") — Capture specific DOM elements (XSS payloads, error messages)
  • annotate_screenshot(screenshot_path="<path>", annotations='[{"type":"text","x":10,"y":10,"text":"VULN: <desc>","color":"red","size":18}]') — Label evidence

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.