/osint-methodology

name: osint-methodology
description: "Comprehensive OSINT methodology for external red-team operations and authorized attack-surface assessments. Covers the staged recon pipeline, asset-graph discipline, severity rubric, confidence upgrade workflows, time budgeting, identity-fabric mapping, breach×identity correlation, detectability tagging, detection-aware probing, WAF/CDN bypass, vulnerability prioritization, phishing infrastructure planning, bug bounty submission, and client deliverable templates. Use when planning or executing reconnaissance against authorized targets, mapping an organization's external attack surface, investigating a person/entity, or producing client deliverables."
when_to_use: "Use when planning or executing reconnaissance against authorized targets, mapping an org's external attack surface (perimeter recon, footprinting, asset triage), investigating a person/entity or threat actor (attribution, target profiling), correlating breach×identity data, doing detection-aware probing or WAF/CDN/origin-discovery bypass, prioritizing vulnerabilities (EPSS, CISA KEV), planning phishing infrastructure, or producing bug-bounty submissions and client deliverables."

OSINT Methodology — External Red-Team Edition

BEHAVIORAL CONTRACT

**When triggered:** Planning/executing authorized external recon, mapping an org's attack surface, investigating a person/entity, producing engagement deliverables, or methodology/framework questions about OSINT tradecraft.

**Execute:**

1. If authorization is not established, run the soft scope check (§1) exactly once. 2. Identify which pipeline stage (§7) the user/engagement is in or needs to start. 3. Propose the next concrete action from the priority order (§7.1), citing the relevant sub-skill to co-load. 4. Tag every assertion with a confidence level (§2). Default to TENTATIVE; never claim CONFIRMED without documented corroboration. 5. For every finding, emit the output schema (§3) with severity from the rubric (§9). 6. Apply detectability tagging (§6.2) to every proposed probe. 7. If detection signs appear, execute the back-off ladder (§6.4). 8. Chain autonomously through pipeline stages — do not wait for prompting between stages.

**Output:** Structured findings per §3 schema. Deliverables per §14 templates.

**Severity rules:** §9 anchors + escalation rules. HSTS missing on auth path = HIGH. Wildcard CORS + credentials = HIGH. Endpoint score >= 70 = at least HIGH. Domain breach >= 10 employees = CRITICAL. KEV CVE match = CRITICAL.

**Gating rules:** Never skip authorization check on first mention of new target. Never claim CONFIRMED on single-source evidence. No destructive probes unless explicit --aggressive mode.

**Chain to:** Always co-load `offensive-osint` (router). Load specific sub-skills per §11 pointers as engagement progresses. Chain autonomously through priority order (§7.1).

---

0. When to Use / When NOT

**Use this skill when:** planning or executing authorized external recon (red team, bug bounty, ASM); mapping an org's attack surface; investigating a person/entity/threat-actor; producing client deliverables.

**Do NOT use this skill when:** the user needs active exploitation, post-exploitation, or malware dev; blue-team/detection content; or the target's authorization is unclear — surface the scope question first.

---

1. Authorization & Legal Posture

Intended for assets the operator owns or has **written authorization** to assess.

**Soft scope check** — when authorization isn't established, ask once:

> _"Quick scope check: is this a target you own or have written authorization to assess? I want to make sure we stay on the right side of the engagement boundary."_

Once asserted, don't re-ask. If the engagement type is stated ("pentest of example.com under contract"), proceed.

**Always-on guardrails:**

• Never weaken auth, rate limits, or safety controls on the target side.
• No destructive probes (SYN scans at line-rate, masscan, fuzzing) outside explicit `--aggressive` mode.
• Never paste real PII, credentials, session tokens, or API keys into cloud-hosted LLMs.
• Never act against assets outside documented scope, even "obviously related" ones.

---

2. Confidence Levels

Every assertion carries a confidence level.

| Level | Meaning | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **TENTATIVE** | Plausible from indirect evidence; unverified. Snippet-only dork match, email pattern inferred from name, single passive-source subdomain. | | **FIRM** | Directly observed, uncorroborated. Subdomain resolves; Shodan banner returned; CT-log entry. | | **CONFIRMED** | Multiple independent corroborations OR directly verified. Live-validated token; bucket listable; three-source subdomain convergence. |

**Rule of three for attribution:** 3 independent weak signals, OR 1 strong + 1 weak. Never single-source attribute.

2.1 Confidence Upgrade Workflows

| Asset type | TENTATIVE → FIRM | FIRM → CONFIRMED | | ------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------ | | Subdomain | ≥2 passive sources OR DNS resolves | Serves on a standard port AND banner/cert returned | | IP | ≥2 sources (passive DNS, ASN, Shodan) | TCP SYN-ACK or ICMP reply | | WebApp | URL extracted but not yet hit | HTTP returns 2xx/3xx/4xx AND content-length