80 IPs, 22 countries, one password: anatomy of an SSH mining campaign
In 16 hours, 80 addresses on five continents tried the same unusual password on our SSH honeypot. Every attempt failed. Two of them came back with a common weak password, got in, and installed a miner. What that tells defenders, and the indicators to block.
Correction, November 7: the first version of this post said the honeypot accepted 82 logins with the shared password and that 78 of those logins ran nothing. That was wrong. Every attempt with the shared password was rejected; the two machines that got in used a different, common password. The sections below are rewritten from the database.
Everything below comes from one blackpot.io sensor on the open internet between November 5 and 6, 2026. Attacker addresses are left out of this post; the ones we reported are in our free threat feed.
The pattern
Between 11:41 UTC on November 5 and 04:13 UTC on November 6, 80 different IP addresses in 22 countries (South Korea, the US, Germany, France, India, Mexico, Chile, Kenya, Senegal and more) tried to log in to our SSH honeypot as ubuntu with the same password: a 15-character string with upper and lower case, digits and symbols. 81 attempts in all, almost exactly one per address. Not a dictionary word, not a default, and not something two unrelated bots would ever both guess.
Our login gate rejected all 81. That does not make them noise. A rare password sent once from each of 80 addresses is a credential being checked across a fleet: someone has (or believes they have) a working ubuntu password for a set of hosts, and is distributing the checks so that no single address looks like brute force. One attempt per IP stays under most fail2ban thresholds.
Two came back
Two of the 80, one on a US cable ISP and one on a Korean telecom network, did not stop at the rejection. Each returned as ubuntu with a common six-character password, which the honeypot accepted: the US machine 71 seconds after its failed attempt, the Korean one about 16 hours later. Same username, same SSH client (SSH-2.0-Go), same script afterwards. That is the useful lesson: the operator holds a list of fallback passwords, and blocking the one rare credential does nothing if the host also accepts a weak one.
What they did
Both followed the same script within a few seconds of logging in:
- Fingerprint the host:
uname -a, CPU count from/proc/cpuinfo,sudo -l(US) and a check for RHEL-family distributions. - Find a writable directory, trying
/dev/shm,/tmp,/var/run,/mnt,/rootand/in that order. - Write a small
w.shwatchdog and add it to the user's crontab, with the process names it should keep alive (astats,netai,kstats), so the miner restarts if it is killed or the machine reboots. - Stream a binary over the SSH session's stdin (
cat > netai), mark it executable and start it in the background. No download URL is involved, so URL blocklists never see it. Our sensor captured the file from both machines: an XMRig cryptominer, SHA-2566e11016d0f4e3e0b4481f9cb2ec2a451c74c1c5ab6cceb3bbe7b025b2b7dd264, now on MalwareBazaar.
Static analysis of the binary found the public pool pool.supportxmr.com on ports 80 and 8080, with pool.hashvault.pro:443 and proxy endpoints on 80, 443 and 8080 as fallbacks. Using web ports gets it through egress filters that only allow web traffic.
What to do about it
- Turn off SSH password login on anything internet-facing. The rare password failed here; the common one worked. Keys only, and no weak password ever sits behind them.
- Alert on low-and-slow credential checks: the same username failing from many addresses, one attempt each. Per-IP thresholds miss this; per-username counts across all sources catch it.
- Mount
/dev/shmand/tmpwithnoexec. It breaks the first thing the script tries. - Alert on crontab changes by interactive SSH users, and on new executables written by an SSH session’s shell.
- Watch egress to mining pools, especially on ports 80, 443 and 8080. A server calling
supportxmr.comis almost never legitimate. - Block the indicators. The sample hash and the addresses we reported are in the threat feed, free and refreshed every few minutes.
Sharing it
We uploaded this sample and four others nobody had reported yet to abuse.ch MalwareBazaar, with what our static triage found mapped to MITRE ATT&CK. Attacking addresses go to AbuseIPDB as they happen. A honeypot that only protects its owner wastes most of what it sees.