--- name: asset-host-investigation description: > Build a host-centric investigation timeline for a specific IP address or hostname, pulling together EDR detections, logs, vulnerability exposure, and network context into one view. Use this skill whenever a user gives a specific IP/hostname and asks "what's going on with this host", "investigate this machine", "pull everything on this IP", "what happened on this endpoint", or pastes an EDR alert tied to a device and wants full context. Also trigger when a user wants to know what else is affected by/connected to a given asset. Do not use for IOC reputation checks with no internal-asset angle — that's general triage, not host investigation; use this one specifically when the internal machine/host itself is the subject. --- # Asset / Host Investigation Skill Builds a single-host investigation view: what the host is, what's running on it, what's been detected on it, what it's talked to, and whether it's vulnerable — in one pass instead of six separate console logins. --- ## Workflow Overview ``` 1. Identify the asset → 2. Pull identity & inventory context → 3. Pull detection history → 4. Pull network activity → 5. Pull vulnerability exposure → 6. Render host timeline ``` --- ## Step 1 — Identify the Asset Extract the IP or hostname with `polarity:parse_entities`. If both are known, use whichever the user provided and cross-resolve the other via DNS/EDR lookups in Step 2. --- ## Step 2 — Identity & Inventory Context | Source | ID | What it adds | |---|---|---| | Axonius | `axonius_3_5_2_node_18_38fbb69596_1761866620482` | Asset owner, criticality, OS, install base | | IP2User (DHCP) | `polarity_chameleon_3_0_0_node_18_1727117038` | Who was using this IP at a given time | | IP2User (Splunk) | `splunk_3_6_4_node_18_27043de191_1727064799` | Cross-check of the above | | DNS Query | `dns_query_3_0_4_node_18_1734435881` | Forward/reverse resolution | | AWS EC2 | `aws_ec2_3_1_2_node_18_3d1e4059fd_1712774347` | Instance metadata if this is cloud infrastructure | | Google Compute Engine | (check `list_available_integrations` if GCP is in scope) | Same, for GCE | --- ## Step 3 — Detection History | Source | ID | What it adds | |---|---|---| | CrowdStrike EDR | `crowdstrike` / `crowdstrike_3_7_4_node_18_33726b1dc9_1751971059359` | Detections, process tree, behavioral indicators | | Cortex XDR | `cortex_xdr_3_0_1_node_18_af9d0966a1_1727982953` | Incidents and XQL query results | | Microsoft Sentinel | `microsoft_sentinel` | Incidents, threat intel matches for this host | | LOLBAS | `lolbas_3_0_0_node_18_fa7e4c5610_1718042471` | Flag any living-off-the-land binaries seen in the process history | --- ## Step 4 — Network Activity | Source | ID | What it adds | |---|---|---| | Elasticsearch (main) | `elasticsearch_3_6_5_node_18_f9729f7de9_1752502730003` | General log hits for this host/IP | | Elasticsearch - Netflow | `elasticsearch_3_6_3_node_18_1fed945c7a_1724331736` | Connections to/from this IP | | Elasticsearch - Proxy | `elasticsearch_3_6_1_node_18_0a609e64b7_1697764894` | Outbound web activity from this host | | Arkime | `arkime_3_1_0_node_18_bf9e578955_1746711919` | Full packet-level search if deeper detail is needed | | Forward Networks | `forward_networks_3_0_0_node_18_bfb05884c2_1723059061` | Network path/reachability to and from this host | For any external IP this host talked to, run standard reputation checks (`abuseipdb`, `greynoise`, `ipinfo`, `alienvault_otx`) to see if the host is beaconing to known-bad infrastructure. --- ## Step 5 — Vulnerability Exposure | Source | ID | What it adds | |---|---|---| | CrowdStrike Exposure Management | `crowdstrike_exposure_3_0_3_node_18_f89390a1d9_1782921542885` | CVEs this specific host is exposed to | | Elasticsearch - Vuln | `elasticsearch_3_6_3_node_18_1fed945c7a_1724331215` | Scan-based CVE hits for this host | | ORCA Security | `orca` | If cloud workload | --- ## Step 6 — Render Host Timeline Render via `visualize:show_widget`: 1. **Header** — hostname/IP, owner (from Axonius), criticality tag, overall risk read 2. **Identity strip** — OS, owner, last-seen user, cloud/on-prem tag 3. **Timeline** — chronological feed merging detections, notable network connections, and any vulnerability scan events, each tagged by source 4. **External connections table** — remote IP | reputation verdict | first/last seen | volume 5. **Open vulnerabilities** — CVE | CVSS | exploited in the wild? (cross-reference CISA KEV if time allows) 6. **Recommended actions** — isolate host, force credential reset for last user, patch priority — time-horizon badged. Note explicitly that Claude does not execute isolation/containment itself. 7. **Footer** — sources queried, time window covered ### 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 (`