---

name: osint-methodology description: "Comprehensive OSINT methodology for external red-team operations and authorized attack-surface assessments. Covers the 6-stage recon pipeline (seed → asset expansion → enrichment → exposure analysis → convergence → operator-armed active validation) with connector-resilience and stage-vs-gating discipline, asset-graph discipline, severity rubric, confidence upgrade workflows, time budgeting, identity-fabric mapping, breach×identity correlation with per-person identity dossiers, 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." version: 2.3 sources: community, public_research 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
• 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
• OSINT methodology
• open source intelligence
• target profiling
• OSINT workflow
• recon methodology
• threat actor investigation
• attribution

---

OSINT Methodology — External Red-Team Edition

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 acme.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 > 0 | | Email | Name-pattern inferred OR snippet-only | Listed in Hunter/IntelX/breach, OR SMTP 250 (abort at DATA) | | Bucket | Permutation candidate + HEAD returns 200/301/403 (exists) | GET listing = CONFIRMED | | Credential / secret | Regex match in captured text | Read-only validator returns success (scope + account-ID documented) | | Person | Name from single source | Confirmed by second independent source | | SSO tenant | OIDC discovery endpoint returns metadata | Tenant GUID extracted AND domain ties back via MX/autodiscover/SP record |

Default reporting posture: never claim CONFIRMED without explicit corroboration. When in doubt, downgrade.

---

3. Output Format

Each finding uses this schema (drops cleanly into asset-management tools):

Finding:
  id:          <stable hash or UUID>
  module:      <technique that discovered it>
  asset_key:   <typed key, e.g. sub:api.example.com>
  category:    <e.g. SECRET_LEAK, OPEN_GRAPHQL_API, SSO_EXPOSURE>
  severity:    <info|low|medium|high|critical>
  confidence:  <tentative|firm|confirmed>
  title:       <one-line summary>
  description: <2-5 sentences>
  evidence:
    url:       <where found>
    timestamp: <UTC ISO8601>
    sha256:    <hash of any downloaded artifact>
    raw:       <truncated to 2 KiB>
  references:  [<CVE-ID, advisory URL, vendor doc>]
  remediation: <action the asset owner can take>

Always use UTC timestamps.

---

4. Source Hygiene & Citations

For every artifact: URL + UTC timestamp + SHA-256 + tool version + run_id.

• Hash all downloads with SHA-256. Screenshot in PNG.
• Raw HTTP captures capped at 2 KiB body. JSONL logs, one line per event.
• Separate evidence read-only from working copies; never edit captured artifacts.
• Prefer durable references (CVE, ATT&CK technique ID, RFC). If ephemeral, archive first (archive.today, Wayback SavePageNow).

---

5. Do NOT

• Do NOT paste creds, session tokens, real PII, or unique pivots into cloud LLMs. Use local models for sensitive analysis.
• Do NOT assume vendor labels are ground truth (TRM, Chainalysis, Arkham can disagree).
• Do NOT assert ownership from a single signal (favicon hash, shared NS, shared CT issuer — each is a hypothesis).
• Do NOT run fuzzing, SYN scans, masscan, or nuclei fuzzing/* outside explicit --aggressive mode.
• Do NOT use a credential validator for anything except read-only verification.
• Do NOT mirror-image the threat actor. Separate capability from intent and sponsorship.
• Do NOT escalate when you hit active defenses — back off and document (§6.4).

---

6. OpSec

6.1 Sock Puppets

Build posting history, age the account, use a separate browser profile. Persona generation: Fake Name Generator, This Person Does Not Exist. Browser isolation: Firefox Multi-Account Containers. Disposable numbers for SMS verification. Audit every extension before install. Maintain chain-of-custody: timestamp every action, hash every artifact.

6.2 Detectability Tagging

Tag every operation so you can reason about the trail you leave.

| Tag | Examples | |---|---| | Low | Passive Shodan InternetDB; crt.sh; Wayback CDX; SecurityTrails PDNS; Hunter.io; HTTP HEAD on public buckets; getuserrealm.srf; OIDC metadata fetch. | | Medium | GetCredentialType user-enum; Okta /api/v1/authn user-enum; credential validation; AWS sts:GetCallerIdentity; Swagger/GraphQL probes; targeted favicon-hash + JARM fingerprinting. | | High | Active port scans (naabu/masscan/nmap); Nuclei full runs against production; subdomain brute-force at scale; SMTP RCPT TO enum; web fuzzing. |

Defaults: passive by default. Active probes only when (a) explicitly authorized, (b) within agreed windows, (c) operator aware of log volume.

6.3 Validator Discipline

When you find a credential in the wild, confirm liveness with read-only validators only (/me, auth.test, sts:GetCallerIdentity). Never create, modify, delete, or send. Record checked_at UTC + truncated response + scope/account-ID. Concrete validator endpoints for 9 providers live in offensive-osint §23.

6.4 Detection-Aware Probing

Signs you've been detected (escalating severity): 429 / Retry-After; captcha interstitials; WAF block page; status-code drift (200→403 from your IP only); banner change; NXDOMAIN rollback; honeypot bait (credentials that don't validate); direct contact.

Back-off ladder:

1. Halve concurrency; add 2–10s jitter.
2. Stop hitting the triggering path; pivot to a different module.
3. New User-Agent / TLS fingerprint.
4. Rotate egress IP (residential proxy, different cloud region).
5. Pause 1–24 hours.
6. If WAF block / status drift / direct contact: stop and consult the engagement lead.

---

7. External Red-Team Recon Pipeline

Six sequential operational stages, then reporting as a post-stage; modules within a stage can run concurrently.

| Stage | What you do | |---|---| | 1 — Seed Discovery | WHOIS, ASN enum (HE BGP Toolkit, RIPEstat), DNS records (A/AAAA/MX/TXT/NS/SOA/CAA), CT history (crt.sh, Censys). | | 2 — Asset Expansion | Subdomain enum (passive first → permutations → brute); cloud bucket permutation; typosquat generation; Wayback CDX; mobile app discovery; DNS walking; LinkedIn employee enum; org/subsidiary footprint (reverse-WHOIS, corporate registries). | | 3 — Enrichment | First active web traffic + identity signal: port/service (Shodan InternetDB → naabu); TLS handshakes (cert chain, JARM, favicon mmh3); WAF/CDN inference; origin discovery; security headers; email harvest; email security audit; GitHub dorking; JS deep analysis; SSO/IdP fingerprinting (passive tier); API discovery (passive classifier); secrets sweep (Postman, Stack Exchange); vendor product fingerprinting; container/CI-CD/cloud-native exposure; job posting harvest. | | 4 — Exposure Analysis | Bulk active probing: Nuclei always-on checks; TLS deep audit; breach × identity correlation → SSO_EXPOSURE findings; targeted misconfig probes (.git/config, .env, /actuator/env, /_cat/indices, /console); vulnerability prioritization (CVE × EPSS × KEV × POC). | | 5 — Convergence | One bounded recursion round over hostnames/assets surfaced by Stages 2–4 (re-mutate, re-probe — not an open-ended crawl); cloud-footprint follow-up (e.g. account-ID extraction from a leaked cloud access key); supply-chain claimability check (internal/scoped package names confirmed unclaimed on the public registry). | | 6 — Active Validation | Hard-gated, operator-armed, engagement-authorized proof tier — default OFF. Live credential submission (default-cred + breach-credential replay) against owned panels; active cloud/container/API/SSO confirmation; host-header injection / blind-SSRF; HTTP request-smuggling differential; injection-payload confirmation (e.g. XSS); JWT-forge auth-bypass differential. Every module here needs explicit arming plus a per-target scope-confirmation step on top of engagement authorization (§1). | | Reporting (post-stage) | Risk scoring per finding; asset graph export; client-facing report (exec summary + technical detail + remediation); reproduction package; bug bounty submission if applicable. |

7.1 Pipeline Priority Order (highest signal density first)

1. Breaches — HudsonRock Cavalier + HIBP + DeHashed. Highest ROI; often yields plaintext corp SSO creds.
2. GitHub recon — code-search dorks. Fastest path to AWS keys, Slack tokens, JWT secrets.
3. Nuclei misconfig sweep — exposed admin panels, CVEs with public POCs.
4. **C