Research Sensor Disclosure

1. What this page is

This page publicly discloses how IntrusionLabs collects the raw data that drives our threat intelligence. It is intended both as transparency to the Internet community and as the operational description that underpins our Terms of Service and Privacy Policy. If you want a one-paragraph summary: we operate honeypots that are designed to receive unauthorized connection attempts; we record what happens during those connections; we publish aggregated, de-identified attribution derived from those recordings; and we do not publish the raw contents of what attackers send us.

2. Who operates these sensors

The sensors are operated by Opaque Research LLC, an Ohio limited liability company, under the trade name IntrusionLabs. All data captured by these sensors is the property of Opaque Research LLC.

3. Where the sensors are

At the time of this writing, our sensors operate in the following locations. We intentionally list approximate cities and countries rather than specific IP addresses so that this disclosure is durable across routine infrastructure changes.

We expect to add additional sensor locations over time. We do not place sensors in jurisdictions subject to comprehensive US sanctions or in jurisdictions where honeypot operation would be unlawful under local law.

4. What the sensors are and how they work

A honeypot is a system intentionally exposed to the public Internet with no legitimate production use. All inbound traffic to a honeypot is, by definition, unsolicited — there is no reason to connect to one unless you are scanning, probing, brute-forcing, or attempting unauthorized access. Our sensors run well-known open-source honeypot software, including cowrie (SSH/Telnet), opencanary (multi-protocol), and an in-house port-scan collector.

Sensors do not provide any legitimate service to any user. They do not host customer data, do not transit customer traffic, and are not connected to any system holding customer information. They exist solely to record unauthorized interaction attempts.

5. Banner and consent

Where the underlying protocol supports it, our sensors display a banner at connection time stating that the system is operated by IntrusionLabs for security research, that activity is recorded, and that continued connection constitutes consent to recording. Protocols that do not support a banner (or where attacker software would not read one) rely on the inherent unauthorized nature of the connection — no reasonable party could connect to these systems believing they were authorized to do so.

6. What we record

For each connection our sensors may record:

• Source IP address, source port, destination port, transport protocol, and timestamp;
• Protocol-level negotiation metadata (e.g., SSH client version string, TLS JA4 fingerprint, HASSH fingerprint);
• Credentials attempted (usernames, passwords, keys);
• Commands issued and the output we returned;
• Files uploaded or downloaded during the session;
• Derived metadata from the above (session shape, behavioral pattern, fingerprint clusters, campaign membership).

7. What we publish

From the recorded data above we derive aggregated attribution and publish it through our Service. Published data includes:

• IP reputation records with confidence scores and evidence counts;
• ASN-level summaries and subnet behavior;
• Behavioral pattern classifications (e.g., scanner, credential_harvester, opportunistic_bruter, proxy_abuser);
• Campaign assessments that link IPs sharing a common fingerprint or coordinated behavior;
• Evidence provenance (which sensor saw what, when, and how it contributed to each label).

8. What we do not publish

We deliberately exclude the following from any public or customer-facing output:

• Credentials. We do not publish attacker-supplied usernames, passwords, keys, or tokens, even though these are typically stolen or reused from elsewhere.
• Raw session transcripts. We do not publish command-by-command recordings of attacker sessions.
• Uploaded payloads. We do not publish malware binaries, scripts, or other files attackers pushed to our sensors.
• Personal identifiers of natural persons. We publish network-level attribution (IP, ASN, subnet, PTR hostname when available). We do not attempt to identify, name, photograph, or profile the human operator behind any IP.
• Anything that could itself cause further harm if republished.

9. Retention

Raw sensor data is retained for analytical replay purposes for 12 to 18 months and then purged. Aggregated attribution derived from that data is retained indefinitely, subject to the correction and erasure processes in our Takedown & Subject-Access Policy.

10. Benign scanners, researchers, and responsible actors

A portion of traffic to our sensors comes from legitimate parties: academic researchers (e.g., university scanning projects), commercial reconnaissance services (Shodan, Censys), non-profit scanners (Shadowserver), and other recognized benign actors. We maintain an allowlist of known benign scanners and label them as such in our data, with capped confidence scores and exclusion from campaign aggregation.

If you operate a scanner or research project and believe your traffic is being misclassified, email takedown@intrusionlabs.com with documentation (source IPs or netblocks, purpose, scan schedule, contact) and we will work with you to classify your traffic appropriately.

11. Law enforcement and legal process

If you are a law enforcement officer seeking sensor data pursuant to a valid legal process (subpoena, court order, search warrant, mutual legal assistance treaty request, or equivalent in the relevant jurisdiction), please direct the request to legal@intrusionlabs.com. We will review each request with counsel and respond consistent with applicable law and our obligations to any affected parties.

12. Questions or complaints

If you have a question or complaint about our sensor operation, email legal@intrusionlabs.com. For data-correction or data-removal requests see our Takedown & Subject-Access Policy.