A honeypot is a decoy server designed to attract and observe malicious activity. No real services run behind it — every connection is from an uninvited visitor, giving researchers a safe way to study attacker behavior without risk to real systems.

Yes. Every session, command, and credential shown on honeypot.observer was captured from real attackers connecting to our sensors. We do not fabricate or simulate data. Our methodology page documents how we assess confidence and scope our claims.

How many sensors does honeypot.observer operate?

We operate four sensors across three continents: Newark NJ (US-East), Seattle WA (US-West), Frankfurt Germany (Europe), and Tokyo Japan (Asia-Pacific). This provides geographic diversity but does not constitute global visibility.

Do you report malicious IPs?

Yes. Malicious IPs are automatically reported to AbuseIPDB with session evidence. We contribute back to the community that helps protect the rest of the internet.

Methodology

Every blog post and report on this site links back here. This page defines how we assess confidence, scope our claims, and what biases we acknowledge — so readers can calibrate our findings and hold us accountable. For technical details, see About.

// Sensor Coverage

Key LimitationAll observations come from four sensors across three continents — Newark, NJ (US-East), Seattle, WA (US-West), Tokyo, Japan (Asia-Pacific), and Frankfurt, Germany (Europe). We do not claim global visibility. Changes in our data may reflect scanner targeting lists, IP reputation shifts, or sensor configuration — not necessarily real-world trends.

When we say “attacks increased,” we mean attacks at our sensors increased. Always. Four locations improve coverage but do not constitute global visibility.

// Confidence Framework

Every claim is labeled with one of three tiers. No exceptions.

Observed

Direct session evidence. We captured it. No inference required.“Session X executed curl to download a cryptominer binary.”

Assessed

Reasonable inference from multiple data points. Reasoning chain stated explicitly.“These 14 sessions likely originate from the same campaign based on identical behavior and overlapping infrastructure.”

Speculative

Hypothesis only. Presented as a question, not a conclusion.“This traffic spike coincides with [external event] — could there be a connection?”

// What We Will and Won't Claim

Even with multiple sensors, some claims are off-limits. Four locations do not constitute global visibility.

We will say

“We observed X” / “Across our sensors, Y happened”
“N sessions exhibited this behavior” (explicit count and scope)
“This may indicate X, though Y and Z are also possible”

We will not say

“Attacks are increasing” (increasing where? globally? we don't know)
“Threat actors are targeting X” (implies intent we can't verify)
“This attack originated from [country]” (source IP ≠ origin)

// Known Biases & Limitations

If you spot a bias we haven't listed, we want to hear about it.

Geographic biasFour sensors (US-East, US-West, Asia-Pacific, Europe). Traffic volume from a given country reflects who scans our sensor IPs, not who is “most active” globally. Frankfurt and Tokyo improve European and Asia-Pacific visibility, but significant geographic blind spots remain.

Protocol coverageSSH, HTTP, and limited TCP only. DNS, SMTP, SIP, and others are not captured. Our data skews toward SSH-heavy attack patterns.

Scanner list effectsA sudden traffic spike might just mean a mass scanner found us — not that attacks are increasing.

Session boundariesSession grouping is approximate. Multiple attackers behind the same exit node may merge; a single attacker reconnecting quickly may appear continuous. Published session counts reflect this.

Field coverage gapsSSH visibility is significantly deeper than HTTP. Some HTTP request details may not be captured. We're transparent about what our pipeline can and can't see.

Classification confidenceATT&CK mapping and intent classification use automated analysis. Edge cases exist. When confidence is low, we say so.

Survivorship biasSophisticated actors who fingerprint honeypots or avoid scanning entirely are invisible to us. Our dataset is inherently biased toward opportunistic, automated attacks — which is what we focus on.

Enrichment lagThreat intel lookups reflect database state at query time. An IP clean today may have been heavily reported yesterday. Enrichment data is a snapshot, not a verdict.

// Publication Safety

Every piece of content goes through these checks before publishing:

IP defangingPublished IPs use bracket notation (192[.]168[.]1[.]1) to prevent accidental interaction

Credential aggregationAggregate statistics only — top families, frequency distributions. Never individual pairs.

No working exploit codeSession transcripts are annotated, never step-by-step reproduction instructions

No third-party identificationCompromised third-party infrastructure revealed in attacker commands is redacted

No actor attributionWe default to behavioral descriptions. Named attribution requires overwhelming, independently corroborated evidence.

// Quality Standard

Every claim is tested against one question: would this survive the most skeptical reader in the room? If not, we fix it or don't publish it.