$npx -y skills add meltedinhex/analyst-ai-pack --skill enriching-iocs-with-threat-intel-sourcesEnriches indicators with context from threat-intel sources: planning lookups against
| 1 | # Enriching IOCs with Threat Intel Sources |
| 2 | |
| 3 | ## When to Use |
| 4 | |
| 5 | - You have atomic indicators and need context: reputation, related infrastructure, first/last |
| 6 | seen, and known associations. |
| 7 | - You are scoring indicator confidence before acting or reporting. |
| 8 | - You must plan lookups without leaking your investigation to the adversary. |
| 9 | |
| 10 | **Do not use** active interaction (visiting a C2 URL, resolving a live domain from your own |
| 11 | network) for enrichment — use passive sources to avoid tipping off the adversary. |
| 12 | |
| 13 | ## Prerequisites |
| 14 | |
| 15 | - Defanged indicators (from the defanging skill) and access to enrichment sources/APIs. |
| 16 | - Awareness of each source's operational-security implications. |
| 17 | |
| 18 | ## Safety & Handling |
| 19 | |
| 20 | - Prefer passive sources (passive DNS, sample DBs, reputation feeds) over active probing. |
| 21 | - Never submit a customer/internal sample to a public sandbox without authorization — it becomes |
| 22 | publicly retrievable and can expose sensitive data. |
| 23 | |
| 24 | ## Workflow |
| 25 | |
| 26 | ### Step 1: Group indicators by type |
| 27 | |
| 28 | Separate hashes, domains, IPs, and URLs; each maps to different enrichment sources. |
| 29 | |
| 30 | ### Step 2: Plan the right lookups |
| 31 | |
| 32 | Map each type to passive sources: hashes → sample/AV databases; domains → passive DNS, WHOIS, |
| 33 | reputation; IPs → ASN/geo, passive DNS, reputation; URLs → URL reputation/sandbox history. |
| 34 | |
| 35 | ```bash |
| 36 | python scripts/analyst.py plan iocs.json |
| 37 | ``` |
| 38 | |
| 39 | ### Step 3: Score confidence |
| 40 | |
| 41 | Combine source agreement, age, and prevalence into a confidence score; a single hit on one feed |
| 42 | is weaker than corroboration across independent sources. |
| 43 | |
| 44 | ### Step 4: Annotate and pivot |
| 45 | |
| 46 | Attach context (first seen, related infrastructure, family) and pivot on strong links (shared |
| 47 | registrant, hosting, certificate) to expand the picture. |
| 48 | |
| 49 | ### Step 5: Record provenance |
| 50 | |
| 51 | Note which source provided each piece of context and when, so the enrichment is auditable and |
| 52 | re-checkable. |
| 53 | |
| 54 | ## Validation |
| 55 | |
| 56 | - Each indicator is routed to type-appropriate, passive sources. |
| 57 | - Confidence reflects corroboration across independent sources, not a single feed. |
| 58 | - Every enrichment carries source and timestamp provenance. |
| 59 | |
| 60 | ## Pitfalls |
| 61 | |
| 62 | - Actively resolving/visiting live infrastructure and alerting the adversary. |
| 63 | - Uploading sensitive samples to public services, leaking data. |
| 64 | - Treating one feed's verdict as ground truth without corroboration. |
| 65 | |
| 66 | ## References |
| 67 | |
| 68 | - See [`references/api-reference.md`](references/api-reference.md) for the lookup planner. |
| 69 | - MITRE ATT&CK and passive-DNS enrichment concepts (linked in frontmatter). |