IntrusionLabs IntrusionLabs
Features / Provenance
// Deep dive — for CTI practitioners

Evidence, all the way down

Every verdict on our platform drills to the raw cowrie or opencanary event it came from. Campaign, actor, session, event — four layers, each one click from the next. You see what we saw, in the order we saw it.

TL;DR

Other reputation services give you a label. We give you the label, the actor behind it, the sessions the actor ran, the credentials they tried, the commands they typed, and the files they tried to drop — all linked, all public, all drillable from one URL to the next. If you don't trust our call, click through and decide for yourself. That posture is the whole thing.

// The chain, by the numbers

Active campaigns
3,122
auto-detected
Actors
14,615
tracked
Sessions
682,865
captured
Sessions w/ creds
249,108
usernames + passwords captured

Every layer flows into the next. A campaign is a set of actors. An actor is a set of sessions. A session is a set of events. The chain is navigable from any end — click a campaign to see its members, click an actor to see their sessions, click a session to see the raw JSON event stream.

// Walking one actor through the chain

Pulled live from the current highest-volume suspicious actor on our platform. Every link in this block resolves to the actual page — no simulation, no curated example. If the numbers look different by the time you read this, that's because the aggregation cycle has run again.

Layer 1 — Actor
85.11.167.2 suspicious mysql_bruter
BG · ColocaTel Inc. · confidence 0.34
208,067 events observed, 208,067 sessions, member of 459 active campaigns.
The actor page carries the labels, the confidence, the campaign memberships, the corroboration sources, and a link to every session — that's layer 1 to 2.
Layer 2 — Sessions

Each session is one inbound connection. The session profile carries the behavioral pattern (scanner, credential_harvester, malware_dropper, &c), the depth score, and the raw event stream the session was built from.

Sample session with captured credentials
session fd00dfb77b02fe77
pattern: mysql_probe · last seen 2026-04-15 19:35
This session alone captured 1 credential attempts.
Layer 3 — Captured credentials & commands

Per session: every username + password the attacker tried, every command they typed after auth, every file they attempted to download. Stored as JSON, rendered in the session detail partial.

The captured credentials payload is where cross-actor clustering starts to pay off: actors running the same password list can be pivoted by credential fingerprint, even when their IPs, HASSH, and ASNs all differ.

Layer 4 — Raw honeypot event

Each session is built from individual HoneypotEvent records — the raw JSON pushed in by a cowrie or opencanary sensor at the edge, with a dedup key, a timestamp, the originating agent ID, and the full event payload. Nothing is aggregated away.

This is as close to the sensor as it gets. If an event ID says something happened, you can trace the path through our ingest endpoint, through the session classifier, into the actor aggregate, and out to the campaign it fed into.

// Why drillability matters

Most reputation services publish a verdict and stop. You either trust the number or you don't — and if you don't, there's nowhere to look. That's a service that wants to be a black box.

A CTI analyst responding to an incident doesn't need our verdict. They need our evidence. Which sensor? Which session? What did the actor type? Did they get in? Did they drop anything? Did the session ID in our export match the session ID in their SIEM? All four of those questions resolve to a specific URL on this platform. No talking to sales, no evidence request, no export pipeline.

We'd rather be drillable and small than opaque and big. A verdict someone can audit is a verdict someone can defend in their own incident report — and that's the shape of trust we want our data to carry.

// What we don't publish

Honest about the edges:

  • Raw PCAPs. Cowrie and opencanary emit structured JSON; we don't retain the raw packet capture behind each session. Full-packet replay is a fundamentally different product and isn't what we offer.
  • Sensor-to-IP mapping at event time. Each event carries an agent ID (w4m_seattle_01, w4m_singapore_01). We don't publish which of our sensors is at which IP, so attackers can't selectively evade us. Agent IDs tell you which of ours saw it, not where it lives.
  • Cross-customer data. We're first-party, not a community platform. Every session in our database came off our own sensors. There's no "other customer saw this IP" inference — every datum is ours to stand behind.

// How to use it

Drill a campaign
/threats/campaign/<uuid>/

Every campaign detail page links to its member actors, the detection rationale prose, and the aggregate top-N stats.

Drill an actor
/threats/actor/<ip>/

Or via API: GET /api/v1/actor/<ip>. Both surface the intent reason, confidence, corroborations, and session list.

Export for incident response

Bulk IOCs via /feeds/v1/ips.txt. Per-IP verdicts + reasons via POST /api/v1/threats/bulk with a list of IPs.

Audit without signup

Everything above is public. No API key, no login. 60 requests/hour per source IP on read endpoints. If you need higher, email.

// See also