Tutorial — Triage a SIEM IP in 60 seconds

A SIEM rule fires. The alert names an external IP. You have ninety seconds before the next alert claims your attention. This is the SOC-triage pattern that the toolkit is built around.

What you need

• The toolkit installed.
• An IP from your alert queue.
• 60 seconds.

You do not need a profile for this — triage is per-incident. If the IP turns out to be worth deep investigation, then you open a profile.

Step 1 — Geolocation + classification (15 seconds)

Ctrl+K, type geo, pick IP Geolocation. Paste the IP. Run.

Scan for:

• Hosting flag.
  • "Datacenter" → automated traffic, not a real user. Continue investigating.
  • "Residential" → a real user behind a consumer ISP. Different forensic implications.
  • "Mobile" → real user on a phone.
  • "Anonymous proxy / VPN" → curated VPN exit. Anonymising user.
• Country. Match against your expected user base.
• rDNS pattern. AWS, Azure, GCP, DigitalOcean, etc. — confirms the cloud provider when ASN is generic.

If the IP is a clear datacenter IP from an unexpected country, you already have most of the answer. Move to step 2 for the threat-feed check.

Step 2 — Reputation cross-feed check (15 seconds)

Pivot to IP Reputation. The check runs ThreatFox, URLhaus, Spamhaus DROP, Tor exit list, and GreyNoise Community in parallel.

Outcomes:

• Listed in ThreatFox / URLhaus / Spamhaus → confirmed bad. Block. Move on.
• GreyNoise classified malicious → confirmed scanning. Block.
• GreyNoise classified benign (research scanner / search engine / known-good crawler) → almost certainly safe. Dismiss the alert.
• Tor exit → forensic context, not a verdict. Investigate further.
• Clean across all feeds → unknown IP. Continue to step 3.

Step 3 — Exposed services context (15 seconds)

Pivot to Exposed Services. Surfaces what the public scan databases have observed about the IP — open ports, software versions, CVEs.

Look for:

• Many open ports / many CVEs → unmaintained system, often used as a stepping stone. Block.
• Specific service ports matching your alert (e.g., the alert says it hit your SSH; the IP exposes SSH brute-force scanning) → confirmed bad pattern. Block.
• No exposed services → quiet IP. Less likely to be active scanner; consider monitor.

Step 4 — ASN context if needed (15 seconds)

If you're still uncertain, pivot to ASN Lookup. The organisation name often disambiguates:

• Major cloud (AWS, GCP, Azure) → automated traffic norm.
• Small "Discount Cheap Hosting" → bulletproof / abuse-friendly hosting often used for malicious infrastructure.
• Major ISP → residential or business broadband.
• Educational / research network → legitimate scanning research.

Decision

By now (60 seconds in) you have:

• Hosting / residential / VPN / Tor classification.
• Threat-feed verdict from five feeds.
• Exposed-services context.
• ASN organisational context.

Decide:

When to escalate to a full profile

Open an investigation profile when:

• You see the same IP in multiple alerts over multiple days.
• The IP is part of a campaign (the IPs in your queue cluster on the same ASN, the same favicon, the same registrant).
• The verdict is "inconclusive" and the alert is high-value.

In any of those cases, the investigate suspicious domain tutorial is the next pattern — usually you can find the related domain via reverse-DNS pivot and trace the campaign from there.

Bulk triage

For a queue of dozens of IPs at once, bulk paste mode in IP Geolocation, IP Reputation, and Exposed Services lets you paste the whole list and review the aggregate table. The aggregate view sorts by reputation verdict, surface the bad ones first.

What you learned

The triage pattern is four pivots, one minute, one decision. The toolkit's cross-feed reputation in particular is what makes "decide in seconds" possible — without the unified result, you would be opening five separate browser tabs per alert.