What my honeypots reveal about how attackers think

Series: How minds are moved · Social engineering: the attack on one mind at a time · 5 of 6

On 27 August 2026, a single machine connected to my SSH honeypot 17,066 times in under nine hours. It tried 17,069 different username and password pairs, one after another, without a pause and without ever typing a command. It never came back. That one visitor tells you most of what you need to know about how automated attackers think: they don’t think about you at all. They think about volume.

My honeypots are fake servers that pretend to be badly secured, so that I can watch what attackers try. I’ve written before about how the plumbing works and what it taught me. This post is about the attackers’ side: what they guess, when they come, how long they stay, and where mass guessing ends and something more targeted begins. Everything here is aggregate counts. I name no addresses, networks or people.

Contents · 11 sections

TL;DR #

• Since 21 March 2026 my SSH honeypot has logged 752,369 sessions from about 12,000 addresses in 145 countries.
• 91% of sessions last under ten seconds. Fewer than one in ten ever types a command.
• A few persistent machines do much of the work: the 50 busiest addresses account for about a third of all sessions.
• Attackers follow fashion. Usernames for cloud images, crypto validator nodes and Raspberry Pis appear in the lists as those set-ups become popular.
• The same split runs through social engineering: mass “spray and pray” for whoever is careless, and slower, tailored attempts for whoever is worth it.

What a honeypot can and cannot show #

A honeypot sees only what comes to it. It’s one small sensor, not a map of the internet. It also changes the data by design. Mine accepts some common passwords on purpose, so that I can see what happens after a login. About 18% of sessions “succeed”, and that number reflects my settings, not the attackers’ skill.

What it does show well is behaviour: which guesses are made, in what order, how fast, by how many machines, and how that changes over time. That’s the part worth sharing.

Speed: most visitors don’t stay #

Of the 752,369 sessions, 684,803 were over in under ten seconds. The average session lasted about six seconds. Only 216 lasted more than five minutes.

Most visitors connect, try a short list of guesses, and leave. Only 69,411 sessions, about 9%, typed any command at all, and 7,609, about 1%, tried to download a file.

This is the economics of mass attack. A script that spends six seconds per server can visit hundreds of thousands of servers a day. It doesn’t need to be clever. It only needs a tiny fraction of those servers to have kept a default password.

Persistence: a few machines do most of the work #

The traffic isn’t evenly spread. The 50 busiest addresses together opened 242,145 sessions, about 32% of everything the honeypot has seen. A single address in the top group worked through more than 17,000 different password pairs in a single day.

Geography shows the same split, with one caution: a country here means where a server is hosted, not who controls it. Addresses hosted in the Netherlands opened 380,720 sessions from only 712 addresses, more than 500 each on average. Addresses in the United States opened 24,565 sessions from 3,079 addresses, about eight each. The first pattern is a handful of rented servers hammering away. The second is a wide spread of machines, many of them probably hijacked devices, each knocking a few times.

Both are automated. One works through brute repetition, the other through sheer numbers.

Timing: machines don’t sleep #

A human attacker would have to sleep. Scripts don’t. Spread across the hours of the day in UTC, login attempts never fall below 27,293 in the quietest hour or rise above 41,475 in the busiest. There is no night.

What the data does show is bursts. My timeline analysis has flagged 141 waves, short periods when activity jumped to several times its normal level and then dropped back. A wave usually means a new list or a new campaign being run against large address ranges, mine among them. The waves come and go. The background never stops.

The guesses: defaults, lists and fashion #

Of the 831,443 login attempts, the username root alone appeared 290,952 times. Next came admin, ubuntu, user, test, deploy, postgres and debian. These are default accounts on routers, cloud images, databases and Linux systems. The attacker isn’t guessing your password. They are betting that you never changed the vendor’s.

Three patterns stand out.

Spraying. One weak password is tried across many usernames. The password 123456 alone was paired with 2,223 different usernames by more than 3,000 addresses.

Shared lists. 30,647 username and password pairs were tried by more than one address. One pair made of a meaningless string, 345gs5662d34, has been tried by 1,393 different addresses since 31 March and was still arriving on 13 November. A string like that only makes sense as the fingerprint of a single tool family, copied onto many machines.

Fashion. The lists follow what people are setting up. The username ubuntu, the default account on many cloud server images, was tried 26,902 times by 3,117 addresses. Usernames such as sol, solana and solv, used on crypto validator nodes, appear from May onwards. The old Raspberry Pi default, pi with raspberry, was still tried 834 times.

That last group is where spray and pray starts to look a little targeted. It’s still automated, but someone is reading the news, watching what people install and updating the lists. When a new tool becomes popular, its obvious usernames show up in the lists.

My web sensors show the same instinct. Of nearly 30,000 outside addresses my classifier has sorted by intent, 4,492 were looking for leaked secrets, such as forgotten configuration files that hold passwords or keys, and 741 were probing login pages.

What this has to do with social engineering #

At first sight a password script and a con artist have little in common. Look at the strategy, though, and they are the same two businesses.

Spray and pray is the mass phishing email. Send the same message to a million inboxes, spend nothing per target, and live off the few who click. Its levers are default habits, the password nobody changed, the link nobody checked.

Targeted attacks are spear phishing and pretexting. They cost more per target: research, a believable role, a reason to trust. They are worth it only for someone with access or money. My honeypot sees the cheap end of this, with lists tuned to fashion. The expensive end, the phone call to a help desk or the cloned voice of a boss, happens to people, not servers.

The lesson from my logs carries straight over to people. Mass attackers don’t need you to be stupid. They need you to be default.

What it feels like from the inside #

If you run a small server, the first week of watching your logs feels like being under siege. Thousands of strangers try to log in, around the clock. It feels personal. It isn’t. The script that knocked on your door also knocked on a hundred thousand others in the same hour, and it will forget you as soon as it moves on.

That’s a useful feeling to understand, because scam calls and phishing emails are built to create the opposite impression: that this message is about you, now, urgently. Most of the time you are just one row on a list.

How to notice it #

For anyone running a server, a router or a home lab:

• Default usernames with password login enabled: root, admin, ubuntu, pi, and new ones such as tool names.
• A password that appears on any common list, even with a capital letter and ! added.
• Secrets in files that are reachable from the web, such as configuration files or a site’s version-control folder.
• No limit on failed logins, and no alert when one address tries thousands of times.

What to do:

1. Turn off password logins for SSH and use keys.
2. Don’t create accounts named after the tool you just installed.
3. Rate-limit and ban repeat offenders. Shared blocklists help, because the same addresses hit everyone.
4. Keep secrets out of the web root and out of public repositories.
5. Read your own logs once in a while. You’ll see the lists change before the headlines do.

Frequently asked questions #

Are these attacks aimed at me? #

Almost never. The same lists and the same odd strings arrive from hundreds of different machines at once. A small server is attacked because it exists, not because of who owns it.

Why do attackers still try 123456 in 2026? #

Because it still works somewhere. A guess costs a fraction of a second, and a single success on a forgotten device pays for millions of failures.

What is the difference between spraying, brute force and credential stuffing? #

They are three different things. Spraying tries one common password against many usernames, hoping one account is weak. Brute force makes many guesses against a single account. Credential stuffing replays real username and password pairs leaked from one site against accounts on other sites, betting that people reuse passwords. What my honeypot mostly sees is default and dictionary guessing: common usernames paired with common passwords, tried across many servers. A honeypot has no real users, so it can’t tell me much about stuffing with leaked pairs.

Should I run a honeypot myself? #

Only if you can isolate it properly and want to study the data. For most people, removing default accounts and using keys does far more good than watching attackers.

The lesson #

My honeypots show attackers who don’t hate anyone and don’t know anyone. They try what is most likely to have been left unchanged, as fast as possible, everywhere at once, and they update their lists to match whatever people are installing this month. The human version of the same strategy is the mass phishing email and the scam call that pretends to be personal. The defence is the same in both worlds: don’t be the default. Change what came out of the box, and check what claims to be urgent.