Methodology
Where the numbers come from, how a raw connection becomes a report, and what we hold back. If a verdict looks wrong, the evidence that produced it is on every report, and you can email info@honeylabs.net.
What the data is
HoneyLabs runs a fleet of open-source honeypot sensors on the public internet. They hold no real services, so every connection that reaches them is unsolicited: a scan, a probe, a brute-force attempt, or an exploit. We index that traffic. Nothing here is sampled from a third-party feed; it is what our own sensors saw.
For each connection we keep the source IP, the destination port, the raw probe payload, protocol fingerprints (JA4, JA3, JA4H, HASSH), the user-agent when present, and a timestamp. All timestamps are UTC.
How an observation becomes a report
An enrichment pipeline annotates each source IP: GeoIP and ASN from MaxMind GeoLite2, reverse DNS, and a scanner classification that matches the rDNS and network operator against known research, commercial, hosting, and VPN scanners. Probe payloads are matched against a library of CVE detection patterns (Nuclei templates), refreshed daily and cross-referenced against the CISA Known Exploited Vulnerabilities catalog.
Results land in ClickHouse and are aggregated per IP, port, ASN, fingerprint, and CVE. Those aggregates are what you query at /lookup, over MCP, and over the HTTP API.
How the verdict is derived
The verdict on a report is a heuristic over the evidence, not a machine-learning score. It reads, in order:
- Known-scanner tags. If the IP belongs to a recognized research or commercial scanner (matched by rDNS and operator), it is labelled as such rather than as a threat.
- Activity shape. Volume, port spread, and how long the IP has been active. A broad flat sweep across many unrelated ports reads as scanning; a narrow, sustained hit reads differently.
- Exploit signatures. Probe payloads that match a CVE pattern lift the verdict to serious or critical, with the matched CVE named on the report.
Confidence reflects how much corroborating evidence there is: a single stray packet is low, a stable fingerprint across thousands of events is high. Every input above is shown on the report, so you can check the verdict against the raw evidence rather than trust it.
What we redact
The public dataset is scrubbed at the database layer so it is safe to share:
- Sensor IPs and sensor identities are removed, in every encoding, including inside payloads.
- Credentials and full payload bytes are stripped from the public view; what remains is the pivotable shape of the probe.
- Indicators in shared text are rendered defanged so a report cannot be a live link to attacker infrastructure.
Coverage and limits
Sensors are not everywhere, so this is a sample of internet scanning, not a census. Not observed is not the same as clean. If an IP has not hit our sensors, the report says so plainly rather than implying the IP is safe. An IP that starts probing shows up within minutes.
Scanner attribution depends on operators keeping honest rDNS and registration data. Some commercial scanners rotate through networks that also host abuse, so a tag describes where an IP lives, not a guarantee of intent. When the two disagree, the events are the source of truth.
Freshness and retention
The public window is the last 90 days, refreshed continuously. Leaderboards and the CVE table run on a rolling recent window (24 hours to 7 days, labelled on each surface). Per-IP, per-port, and per-ASN reports cache briefly, so live figures can lag a running total by a few minutes.