--- name: osint-methodology description: Comprehensive OSINT methodology for external red-team operations and authorized attack-surface assessments. category: security risk: offensive source: https://github.com/elementalsouls/Claude-BugHunter source_repo: elementalsouls/Claude-BugHunter source_type: community date_added: '2026-09-20' license: MIT license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE compatibility: Requires explicit written authorization for a target scope plus the relevant testing tools for this technique. Docs-only; helper scripts and commands not bundled. sources: community, public_research version: 2.3 triggers: - external recon - external red team - red team external - attack surface management - attack surface mapping - ASM - perimeter recon - target reconnaissance - bug bounty recon - asset discovery - footprint - attack path - identity fabric - SSO discovery - IdP fingerprinting - tenant fingerprinting - M365 enumeration - Microsoft 365 recon - API discovery - GraphQL introspection - mobile recon - APK analysis - cloud bucket enumeration - bucket enum - breach correlation - secret leak hunt - origin discovery - CDN bypass - WAF bypass - vulnerability prioritization - CVE prioritization - EPSS - CISA KEV - phishing infrastructure - pretext development - bug bounty submission - responsible disclosure - client report - exec summary - risk translation - confidence upgrade - time budget - engagement profile - asset triage - detection-aware probing - back-off strategy - persona rotation - OSINT methodology - open source intelligence - target profiling - data correlation - OSINT workflow - intelligence collection - OSINT campaign - recon methodology - threat actor investigation - attribution --- > **⚠️ AUTHORIZED USE ONLY** > This skill is for educational purposes or authorized security assessments only. > You must have explicit, written permission from the system owner before using this tool. > Misuse of this tool is illegal and strictly prohibited. > **Mandatory confirmation gate** > Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target: > 1. Ask the user to state the exact target URL, IP, account, or resource. > 2. Ask the user to confirm written authorization and the permitted scope. > 3. Show the exact command(s) and explain their expected effect. > 4. Wait for explicit confirmation in the current conversation. > > Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab. # OSINT methodology for authorized surface review ## When to Use Use for scoped organizational attack-surface research, evidence correlation and assessment reports. Defensive inventory and source analysis are valid uses. Personal investigations need a legitimate, clearly scoped purpose and privacy limits; do not collect private identifiers, credentials or location histories as an automatic extension of an infrastructure engagement. Exploitation, phishing execution, persistence and account intrusion are outside this methodology. ## Authorization and collection plan Record exact assets, approved sources/queries, allowed active techniques, window, rate limits, data minimization, retention and stop conditions. The root mandatory per-command confirmation gate remains binding; an asserted engagement or a `--deep` flag does not waive it. Ownership evidence is distinct from permission. Discovery of a subsidiary, vendor, employee profile or historical origin does not expand scope. Use approved engagement accounts and egress; do not rotate personas, TLS fingerprints or proxies to evade blocks or platform controls. Start with approved local inventories and public documentation. Separate passive third-party queries from requests to the target: HTTP HEAD, DNS resolution, TLS handshakes, screenshots and API calls can all generate traffic/logs and may send sensitive query information to the provider. Check cost, terms and authorization. Stop at rate limits, WAF challenges, explicit denial or owner contact; document and consult the lead before resuming, without switching identity to bypass them. ## Workflow 1. Define the research question and known seed identities with sources/dates. 2. Collect only relevant authorized evidence and record acquisition method. 3. Represent assets and relationships as typed, timestamped observations. 4. Corroborate each specific claim using independent sources and alternatives. 5. Prioritize by verified exposure, business context and uncertainty, not hostname keywords, email role or a fixed numeric “interest score”. 6. Draft findings and recommended next steps; submit/contact/publish only when specifically authorized. Preserve unresolved leads as hypotheses. ## Evidence record example ```json { "asset_key": "domain:example.org", "claim": "appears in a certificate SAN", "source": "approved CT record reference", "observed_at": "2026-10-23T10:00:00Z", "confidence": "directly observed record; present ownership unverified", "scope_status": "candidate, active testing not approved", "alternatives": ["historic deployment", "shared hosting"], "limitations": ["not evidence of a live service or vulnerability"] } ``` Confidence attaches to the precise claim. A resolved domain, an HTTP response, a matched photo or three copied search results does not confirm ownership, attribution, exploitation or a person's identity. Counts of signals are not a universal proof rule. Distinguish source independence, direct observation and inference; record counterevidence and possible stale/spoofed data. ## Data handling Store restricted evidence and redacted working copies separately. Record source, UTC time, tool version, full content hash and any truncation or normalization. Hashes bind bytes, not truth, legal admissibility or replayability. Do not submit private URLs, artifacts, PII or secrets to public archives, sandboxes or external models without explicit data-sharing approval. A local model is not automatically private: check logging, telemetry, access and storage. Do not acquire stolen dumps or validate found credentials merely to increase confidence; stop and notify via the approved owner channel, with redaction. Read [technical interpretation guidance](references/details.md) before classifying identity, cloud, media, blockchain or vulnerability data. ## Limitations and provenance Docs-only adaptation of [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter), with upstream MIT attribution retained. No scanner engine, corpus, CLI `--deep` mode, test evidence or third-party credentials are bundled. Referenced external services may require permission, payment, accounts and version-specific APIs. Do not install from moving snippets or assume a companion skill is present. No enumeration completeness, current compromise, court-grade evidence, attribution certainty or guaranteed bounty follows from this workflow.