---
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 (`<i class="ti ti-NAME" aria-hidden="true">`). Never filled variants.
- Sentence case everywhere. No ALL CAPS section titles.
- No gradients, drop shadows, blur, or glow effects.
- Score/meter bars: plain `<div>` with width `${value}%`, no canvas or chart libraries.
- Always render via `visualize:show_widget` (HTML mode). Call `visualize:read_me` with
  `modules: ["mockup"]` first if not already done this session. One line of prose before the
  widget call, nothing after except an offer to drill into any section.

---

## Handling Edge Cases

**Host not found in inventory (Axonius)**: Note it may be unmanaged/shadow IT or off Axonius's
scope — this itself is worth flagging as a finding, not just a gap.

**Cloud-ephemeral IP (autoscaling, short-lived instance)**: Narrow every lookup to the specific
time window the user cares about; a long-lived-reputation view of a recycled IP is misleading.

**No EDR coverage on this host**: Say so plainly — network and log data alone gives a partial
picture, and any verdict should be qualified as lower-confidence.

**Very high network-activity volume**: Summarize top talkers and anomalies rather than listing
every connection; offer to drill into a specific remote IP or time window on request.
