--- name: infrastructure-pivot description: > Starting from one malicious IP or domain, pivot outward through shared infrastructure (WHOIS, passive DNS, ASN, certificates) to surface related indicators and map a campaign's footprint. Use this skill whenever a user asks to "pivot on this IP/domain", "find related infrastructure", "what else is connected to this", "map this campaign", or wants to expand a single IOC into a broader set of related indicators. Do not use this for a simple single-entity reputation check with no pivoting intent — that's general triage. This skill is specifically for outward expansion from a seed indicator. --- # Infrastructure Pivot Skill Starts from one seed indicator and walks outward through shared infrastructure signals to build a related-infrastructure map — the step that turns "one bad IP" into "here's the campaign." --- ## Workflow Overview ``` 1. Establish the seed → 2. Pivot via WHOIS/registration → 3. Pivot via passive DNS/resolution → 4. Pivot via hosting/ASN → 5. Score relatedness → 6. Render infrastructure map ``` --- ## Step 1 — Establish the Seed Confirm the seed indicator's own verdict first (run a quick reputation check if not already established this session) via `abuseipdb`, `greynoise`, `alienvault_otx`, or `apivoid_3_1_3_node_18_5ed4fc6eac_1765902753366` as appropriate to entity type. Pivoting from an indicator that turns out to be benign wastes calls and produces noise. --- ## Step 2 — Pivot via WHOIS / Registration | Source | ID | Pivot value | |---|---|---| | DomainTools IRIS | `domaintools_iris_3_1_9_node_18_ba17ff4ea1_1697658218` | Registrant email/org, co-registered domains, registration date clustering | | ARIN | `arin_3_2_3_node_18_e319bde8f6_1697656952` | IP block ownership, ASN registration | Look specifically for: same registrant email across multiple domains, domains registered within minutes/hours of each other, and shared registrar/nameserver patterns. --- ## Step 3 — Pivot via Passive DNS / Resolution | Source | ID | Pivot value | |---|---|---| | AlienVault OTX - PassiveDNS | `alienvaultotx_passivedns_3_0_0_node_18_1701382855` | Other domains that have resolved to this IP, and IPs this domain has resolved to over time | | DNS Query | `dns_query_3_0_4_node_18_1734435881` | Current resolution state | | Censys | `censys_3_2_4_node_18_694bba2bea_1697656754` | Certificate and service-banner overlap across IPs | --- ## Step 4 — Pivot via Hosting / ASN | Source | ID | Pivot value | |---|---|---| | ipinfo | `ipinfo` | ASN and hosting provider for the seed and any newly discovered IPs | | Cloudflare Domain Intel | `cloudflare_domain_intel_3_0_0_node_18_468f31c94f_1762439591184` | Domain category/risk clustering | | Majestic Million | `majestic_million_3_1_5_node_18_65f1713366_1723152807` | Rule out established, high-rank domains that surfaced as noise, not campaign infrastructure | For every newly surfaced indicator, run the same base reputation check as Step 1 before including it in the map — a pivot hit isn't automatically malicious (e.g., shared hosting provider with thousands of unrelated tenants is a weak signal on its own). --- ## Step 5 — Score Relatedness Not every pivot hit belongs in the final map. Rate each candidate: | Signal | Relatedness | |---|---| | Same registrant email/org | Strong | | Registered within a tight time window of the seed | Strong | | Shared certificate or unique service banner | Strong | | Resolved to the seed IP historically | Moderate | | Same hosting provider/ASN only, no other overlap | Weak — exclude unless corroborated elsewhere | | Same registrar only (common bulk registrar) | Weak — exclude | Only carry Strong and corroborated Moderate signals into the final report; note Weak candidates were considered and excluded, rather than silently dropping them. --- ## Step 6 — Render Infrastructure Map Render via `visualize:show_widget`. Since this is inherently relational, prefer a node-link style SVG/HTML diagram (seed indicator at center, related infrastructure as connected nodes labeled with the pivot signal that connected them) alongside a supporting table. 1. **Header** — seed indicator, count of related indicators found, confidence 2. **Infrastructure diagram** — seed + related nodes, edges labeled with pivot type (WHOIS/pDNS/cert/ASN) 3. **Related indicators table** — indicator | pivot signal | relatedness | own reputation verdict 4. **Excluded candidates** — brief note on what was considered and ruled out, and why 5. **Suggested next steps** — submit the confirmed set via the IOC bulk submission skill if the user wants to disseminate; check for confirmed hits in internal logs for the new indicators 6. **Footer** — sources queried, pivot depth (how many hops from the seed) ### Visual Design Rules (all reports) Follow the claude.ai design system exactly: - **No hardcoded hex colors.** Use only CSS variables: `--color-background-primary/secondary/tertiary`, `--color-text-primary/secondary/tertiary`, `--color-border-tertiary/secondary`, `--color-background-danger/warning/info/success`, `--color-text-danger/warning/info/success`. - **Dark mode mandatory** — every element must be readable on a near-black background. - Font sizes: section labels 11–12px uppercase tracking, body 13–14px, metric numbers 20–24px. Font weights: 400 body, 500 headings/labels only. Never 600 or 700. - Cards: `background: var(--color-background-primary); border: 0.5px solid var(--color-border-tertiary); border-radius: 12px; padding: 1rem 1.25rem`. - Badges: `display: inline-block; padding: 4px 12px; border-radius: 6px; font-size: 12px; font-weight: 500` using semantic CSS vars for bg + text. - Section separators: `border-top: 0.5px solid var(--color-border-tertiary)`. - Tabler outline icons only (`