0x4D31/honeypot-data publishes JA3/JA4 fingerprints, HTTP captures, and pseudonymized source-IP telemetry from Internet-facing honeypots for defensive research and threat-intelligence work.
| Tool | 0x4D31/honeypot-data — public honeypot datasets and observation reports with JA3/JA4 and HTTP fingerprint data |
| Category | Threat-intelligence dataset repository |
| Primary Use | Studying real-world scanning and exploitation behavior via JA3/JA4 TLS fingerprints and HTTP request captures in defensive research |
| Safe Use | Purely passive, defensive resource: datasets for authorized threat-intelligence analysis, detection engineering, and lab-based research; contains no tooling that acts on third-party systems |
| Telemetry Note | This is telemetry itself — it documents what honeypots observed; the Finch dataset pseudonymizes source IPs, while the PHP2Shell evidence reports deliberately retain source IPs as published indicators for defenders |
Most repositories covered here are instruments — tools you run. 0x4D31/honeypot-data is the opposite: it is the raw output of instruments someone else ran, packaged so that defensive professionals can study what the Internet actually does to exposed services. The repository publishes datasets and observation reports collected from Internet-facing honeypots, and its organizing theme is fingerprinting — capturing the JA3 and JA4 TLS fingerprints and HTTP behavior of unsolicited traffic so that defenders can recognize the same patterns on their own networks. With CC-BY-4.0 licensing and a small but focused set of topics (dataset, fingerprint, honeypot, http, ja3, ja4, tls), it positions itself as a citable public resource rather than a piece of software.
Structurally, the repository splits into two arms: bulk datasets and targeted observation reports. The flagship dataset covers a three-month window from 2025-07-31 to 2025-11-01 and originates from what the README calls a Finch Reverse Proxy honeypot. The details live in a dedicated DATASET_CARD.md — a dataset-card convention borrowed from the ML world, which signals the author cares about documented provenance and responsible handling. Critically, the Finch dataset pseudonymizes source IPs, meaning the thousands of scanners that touched the honeypot cannot be trivially re-identified or weaponized from the release alone. That choice makes the dataset safe to redistribute and analyze without turning it into an attack list.
The second arm is where the repository gets sharper. A 2026-10-24 evidence collection titled PHP2Shell documents confirmed remote-code-execution attempts against the honeypot, organized into 35 case folders. Each folder pairs HTTP packet captures with selected Apache, PHP, Tetragon, and signal records — a layered view that spans the web server, the runtime, and kernel-level eBPF security telemetry from Tetragon. The evidence README explicitly documents limited substitutions applied to the data, which is good forensic hygiene: analysts know exactly what has been altered before they draw conclusions from it.
A notable and deliberate asymmetry runs through the releases. The Finch dataset strips source IPs; the PHP2Shell evidence reports retain them, unredacted, as indicators. The README is explicit that this is intentional — those IPs are treated as published IOCs for defenders, not as privacy failures. For a threat-intelligence team, that distinction matters operationally: bulk scanning traffic is noise best studied in aggregate with pseudonymization, while confirmed-exploitation sources are signal worth blocklisting, enriching, and pivoting on. The repository enforces that philosophy release by release rather than applying a single blanket policy, and each README tells you which regime you are in.
The observation reports themselves cover a narrow window — 2026-10-22 to 2026-10-24 — and split the PHP2Shell activity into two documents: initial exploitation attempts and confirmed RCE. That two-stage framing is analytically useful because it mirrors how real campaigns progress: broad probing first, successful weaponization later. Analysts reading the reports can trace the delta between the two phases, which is exactly the kind of longitudinal context that isolated log samples never provide.
For fingerprint-focused work, the JA3/JA4 angle is the durable value. TLS fingerprinting has become a cornerstone of passive traffic classification: defenders hash the ClientHello to profile what library or tool generated a connection, and honeypot-derived fingerprints of malicious tooling are the ground truth that powers those detections. A dataset that correlates JA4 fingerprints with the HTTP requests and exploitation outcomes that followed the handshake lets detection engineers build rules that fire on the network layer before a payload ever reaches a parser. This correlation — handshake fingerprint plus request body plus outcome — is rarer in public data than raw logs alone.
Where does this fit in an authorized workflow? The primary consumers are SOC analysts and threat researchers tuning detections, students of Internet background radiation studying scanner ecosystems, and purple-team members who need realistic adversary traffic for lab exercises. Because the material is entirely observational — captures of attacks against a honeypot the operator controls — there is no operational risk in studying it, and no attack tooling to misuse. It is documentation of hostile behavior, not a means of reproducing it.
A few caveats worth flagging to fellow professionals. First, honeypot traffic is biased toward what exposes itself: low-and-slow or targeted actors may never appear, so treat the data as a floor, not a census. Second, source IPs in the evidence reports are point-in-time indicators; compromised hosts get remediated, and blocking lists built from them decay quickly. Third, the dataset windows are short and the sample sizes modest — 33 stars on the repo suggest a niche audience — so statistical claims about scanner populations should be made carefully. The DATASET_CARD.md is the right place to check stated limitations before citing numbers.
From a defender's telemetry perspective, this repository is itself a model of good practice worth emulating: pseudonymize by default, document substitutions, retain IOCs only when they carry confirmed-exploitation value, and package releases with dataset cards. Teams running their own honeypots could adopt the same conventions — the Finch/PHP2Shell split of bulk-pseudonymized versus indicator-retaining evidence is a clean pattern for any organization that publishes what its sensors observe.
In sum, 0x4D31/honeypot-data is a compact but well-curated window into what Internet-facing services endure daily, expressed through JA3/JA4 fingerprints, HTTP captures, and layered host telemetry including Tetragon eBPF events. It is educational and documentary by nature, most valuable to defenders building detections and researchers studying exploitation campaigns, and its transparent handling of source-IP data shows more editorial care than most public threat feeds. Watch the repository's release cadence — if the observation-report format continues, it could grow into a useful longitudinal record of in-the-wild exploitation tooling and behavior.
0x4D31/honeypot-data.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.