agentleFS
valITinovalITino/blhackbox/.claude/skills/osint-gathering/SKILL.md

osint-gathering

Skill9 starsChanged 5 months agoMITView on GitHub

Passive open-source intelligence collection against a target domain. Use when the user wants OSINT, passive recon, or intelligence gathering without active scanning.

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. About 0 are common, 10 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    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 17
  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 30
  3. Very specific:

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

    line 34
  4. Very specific:

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

    line 35
  5. Distinctive:

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

    line 54
  6. Distinctive:

    Use every relevant discovered tool capability where it adds coverage.

    line 55
  7. Distinctive:

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

    line 56
  8. Distinctive:

    Look for zone transfer opportunities (informational only)

    line 100
  9. Distinctive:

    If any packet captures or traffic samples are available:

    line 119
  10. Distinctive:

    Document the target's potential risk exposure

    line 128
  11. Very specific:

    Call get_payload_schema() to retrieve the AggregatedPayload JSON schema

    line 132
  12. Very specific:

    Call aggregate_results(payload=<your AggregatedPayload>) to validate and persist

    line 134
  13. Very specific:

    Write the following files to output/reports/:

    line 155
  14. Distinctive:

    No port scanning, no web crawling, no active connections

    line 166
  15. Distinctive:

    Use only publicly available information sources

    line 167

≈ “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

OSINT & Intelligence Gathering

You are an autonomous OSINT and intelligence gathering agent operating through the blhackbox framework. Execute a comprehensive open-source intelligence operation against the specified target using only passive techniques.

Target Configuration

The target for this OSINT operation is: $ARGUMENTS

If no target was provided, ask the user:

What is the target domain for OSINT gathering? Examples: example.com, target-org.io Note: This operation uses PASSIVE techniques only — no active scanning.

Before you start:

  1. Ensure all MCP servers are healthy — run make mcp-status
  2. Note: This uses passive techniques only — no packets sent to target

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.

Execution Plan

Step 1: Domain & Registrar Intelligence

  1. Domain registration — WHOIS lookups for registrar, registration dates, registrant organization, nameserver infrastructure
  2. OSINT harvesting — Harvest emails, names, and subdomains from public sources
  3. Metadata extraction — Extract metadata from any publicly available documents
  4. AI-driven intelligence — Intelligence analysis and OSINT agents

Step 2: DNS Intelligence

  1. DNS enumeration — Full DNS record enumeration (A, AAAA, MX, TXT, NS, SOA, SRV)
  2. DNS brute-forcing — DNS record brute-forcing and additional record discovery
  3. DNS reconnaissance — DNS recon and zone transfer checks
  4. Auxiliary DNS enumeration — Supplemental DNS enumeration
  5. Look for zone transfer opportunities (informational only)

Step 3: Subdomain Discovery

  1. Passive subdomain enumeration — Multiple passive sources
  2. Deep passive enumeration — Additional discovery tools for maximum coverage
  3. Compile, deduplicate, and categorize subdomains by purpose

Step 4: Infrastructure Mapping

From the gathered data, map:

  1. IP address ranges and hosting providers
  2. Email infrastructure (from MX records)
  3. CDN and WAF presence
  4. Cloud provider identification (AWS, Azure, GCP patterns)
  5. Third-party service integrations (from DNS TXT records)

Step 5: Traffic Sample Analysis (if available)

If any packet captures or traffic samples are available:

  1. Pcap parsing — Parse existing traffic captures
  2. Conversation analysis — Identify communication patterns
  3. Protocol statistics — Protocol distribution and endpoint analysis
  4. Credential extraction — Find credentials in traffic samples

Step 6: Exploit Landscape Research

  1. Exploit search — Search for known exploits targeting discovered technologies
  2. Document the target's potential risk exposure

Step 7: Data Aggregation (REQUIRED)

  1. Call get_payload_schema() to retrieve the AggregatedPayload JSON schema
  2. Parse, deduplicate, and correlate all raw outputs into the schema
  3. Call aggregate_results(payload=<your AggregatedPayload>) to validate and persist

Step 8: OSINT Report

Using the AggregatedPayload, produce a detailed intelligence report:

  1. Executive Summary — overall intelligence assessment
  2. Domain Profile — registrar, dates, status, ownership chain
  3. DNS Infrastructure — complete record inventory with analysis
  4. Subdomain Map — all discovered subdomains categorized by function
  5. Infrastructure Footprint — hosting, cloud, CDN, email providers
  6. Technology Indicators — technologies revealed through passive analysis
  7. Exploit Landscape — known exploits and risk exposure
  8. Potential Attack Surface — entry points identified through OSINT alone
  9. Risk Indicators — expired domains, dangling DNS, subdomain takeover candidates
  10. Recommendations — areas requiring further active assessment

OSINT Documentation (REQUIRED)

Write the following files to output/reports/:

1. Collection Log — collection-log-<target>-DDMMYYYY.md

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

3. Intelligence Index — intelligence-index-<target>-DDMMYYYY.md


Guidelines

  • PASSIVE ONLY — do not send probe packets to the target
  • No port scanning, no web crawling, no active connections
  • Use only publicly available information sources
  • Record every tool output for post-processing
  • Flag potential subdomain takeover opportunities

MCP Tool Quick Reference

Kali MCP — Passive OSINT Tools

  • subfinder -d <domain> — Passive subdomain enumeration
  • amass enum -passive -d <domain> — Comprehensive passive enumeration
  • whois <domain> — Domain registration and ownership
  • dig <domain> ANY / dig <domain> AXFR — DNS records and zone transfer attempts
  • theharvester -d <domain> -b all — Email, subdomain, and name harvesting
  • fierce --domain <domain> — DNS reconnaissance

Note: This is a passive-only skill. No active scanning, no exploitation, no screenshots. For active testing, use /full-pentest, /vuln-assessment, or /exploit-dev.

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.