Hunanghunang (is.) — honey
■ Live honeypot telemetrySSH + Telnet sensorHelsinki, Finland

Put a machine online.
Count what happens.

This site is wired to a honeypot — a decoy server that accepts the internet's unsolicited login attempts and writes them down. Nobody was told it exists. The first attack arrived after it went live, and it has not been quiet since. None of this is targeted. All of it is automated. That is the point.

01

The numbers

lifetime · since
Login attempts captured
0
lifetime · since the sensor went live
Last 24 hours
0
≈ one every
Distinct sources
0
lifetime · pseudonymized at ingest
First attack after going live
nobody was told this machine exists

updated 2026-08-06 13:40 UTC · refreshes automatically

Honest framing — read this before the charts

Everything on this page is automated background noise. No human chose this machine; botnets scan the entire internet and try default passwords on whatever answers. This machine just wrote it down. If you put a server online with password authentication and a guessable credential, this traffic finds it — typically within the hour.

So: this is not evidence of sophisticated attackers, and the numbers below are not a threat-intelligence feed. They are a measurement of how hostile the baseline is — and of how little it takes to be compromised by accident.

02

Around the clock

login attempts over time
last 48 hours · peak 1 / hour · UTC
last 30 days · peak 1 / day · UTC

There is no quiet hour. Scanning botnets are distributed across time zones and run continuously; the dips and spikes are campaign churn, not working hours.

03

Where it comes from

aggregate counts only
fewermore none recorded
#Source countryAttemptsShare

Country and network tell you where infected machines and cheap VPSes are, not where an “attacker” sits. A large share of this traffic is compromised devices whose owners have no idea.

04

What they try

most-attempted credentials
#Username / passwordTries

Top usernames

Top passwords

This is the whole trick. Not zero-days — dictionaries. The bots try root/123456 because it still works often enough, somewhere, to keep botnets growing.

05

Mapped to MITRE ATT&CK

observed behavior → technique

Each captured behavior is classified against MITRE ATT&CK, the shared vocabulary defenders use to talk about attacker techniques. The mapping is deliberately conservative — a technique is only counted when the event is direct evidence of it (the classifier and its tests are open source).

TechniqueTacticObserved

Counts are events, not incidents: one bot session typically produces a connection, a burst of password guesses, and — if it gets a shell — a short scripted sequence of discovery, payload download, and persistence attempts. The shell it gets here is fake.

06

What would have stopped this

per attack class, the boring control that works
Password guessing · observed 0×

Credential spraying

Endless dictionaries of common passwords against root and admin. Volume does the work.

Stopped by: disabling password authentication entirely (PasswordAuthentication no) — SSH keys only. Fail2ban and rate limiting cut the noise; key-only auth ends the game.

Default accounts · observed 0×

Factory credentials

pi/raspberry, ubnt/ubnt: devices shipped with documented logins and never changed.

Stopped by: changing or disabling default accounts before the machine ever faces the network. Treat first boot as part of deployment, not a TODO.

Tool transfer · observed 0×

Malware staging

After a “successful” login: wget a payload to /tmp, chmod 777, run it. Usually a Mirai variant or a cryptominer.

Stopped by: egress filtering (servers rarely need arbitrary outbound HTTP), noexec on world-writable mounts, and alerting on new executables.

Persistence · observed 0×

Keys and cron jobs

Appending an attacker key to authorized_keys or installing a cron entry, so the bot can come back even after a password change.

Stopped by: file-integrity monitoring on ~/.ssh and cron directories (auditd, Wazuh), and alerting on authorized_keys changes you didn't make.

Discovery · observed 0×

Scripted recon

uname -a, cat /proc/cpuinfo, cat /etc/passwd — sizing up the machine for mining profitability or botnet duty.

Stopped by: honestly — by everything above. Once recon runs, you're already compromised. Prevention lives at authentication and exposure, not here. Detection (this row) is your tripwire.

Exposure · the root cause

The open port itself

All of this traffic exists because port 22 answered. Most machines don't need SSH reachable from the entire internet.

Stopped by: not exposing SSH publicly — WireGuard/VPN, an IP allowlist, or an SSH bastion. Moving to a nonstandard port reduces noise, not risk; scanners check those too.

07

Method & data handling

how this works, and what it stores

How it works

The sensor is Cowrie, an established honeypot that emulates an SSH/Telnet server and a fake shell — attackers interact with a recording, not a real system. It runs on an isolated, disposable host with outbound traffic firewalled to a single telemetry channel, and holds no credentials for anything real.

Events flow one way: sensor → authenticated ingest API → database → pre-aggregated rollups → this page. The site you are reading never connects to the honeypot and renders only aggregate data. Full architecture, threat model, and runbook are on GitHub.

Data handling

Source IP addresses are personal data under GDPR and are treated accordingly: at ingest they are replaced with a keyed pseudonym (HMAC) and a truncated network prefix (/24 or /48). Raw IPs are never stored or displayed. Raw event records are deleted after 30 days; the numbers on this page are anonymous lifetime aggregates, folded once from each event and kept with no per-source data behind them.

Captured usernames, passwords, and commands shown here were typed by automated tooling at a decoy machine. This site sets no cookies and runs no analytics. Geolocation is resolved from database files held on the server, so an observed address is never sent to a third party; the pseudonymized event store is hosted in the EU by Vercel and Neon. Questions: andri.is.