Infrastructure Security – Threat Intelligence – Dubai
SSH Dictionary Attack: Why Botnets Keep Trying root, ubuntu, admin and minecraft
TL;DR
Automated botnets spray common Linux usernames at every reachable SSH server. This is opportunistic, not targeted. In a September 2026 honeypot dataset published by MSI’s State of Security, root received 45,302 login attempts from 350 distinct IP sources, with admin at 3,254 and ubuntu at 1,142.
Disabling SSH password authentication in favour of public keys is the single most effective control against an SSH dictionary attack. Compromise leads to cryptomining, DDoS recruitment, and lateral movement — documented by AhnLab ASEC on 8 October 2026. Game-server botnets like xlabs_v1 are a separate threat path, recruiting via exposed ADB, not SSH guessing.
If you have reviewed your server’s authentication logs and seen a flood of failed logins for root, ubuntu, admin, or postgres, you are likely dealing with an SSH dictionary attack. This is not a targeted attack against your organisation. It is the background noise of the internet: automated botnets running large-scale credential stuffing against every reachable IP address, looking for a single weak entry point.
This advisory breaks down exactly what these usernames mean, which accounts are being targeted, what happens after a successful login, and the hardening steps that stop the overwhelming majority of these attempts. The core recommendation is simple: disable SSH password authentication in favour of public-key authentication, and disable direct root login.
What an SSH Dictionary Attack Actually Is
An SSH dictionary attack is an automated attempt to authenticate to a service by trying a precompiled list of likely usernames paired with common, default, or previously leaked passwords. Against SSH, it is the lowest-cost way to find an internet-facing server with weak credentials. The attempts are not personal. A botnet does not know or care who owns the server. It knows only that a TCP port is open, and that somewhere in a list of thousands of IP addresses, at least one host will accept root with a password from the top of the list.
SSH brute force vs. SSH dictionary attack — what’s the difference?
An SSH brute force attack systematically tries every possible combination of characters until it finds the right one. An SSH dictionary attack uses a curated list of likely passwords (drawn from previous data breaches, common defaults, and predictable patterns). In practice, modern botnets almost exclusively use dictionary attacks, and the terms are often used interchangeably in log analysis and threat intelligence.
Why it still works: old, leaked, and default passwords remain useful to attackers. Rapid7’s 2022 honeypot research found that only 14 of 512,002 unique attempted passwords were absent from the rockyou2021.txt wordlist — meaning the effective dictionary is still overwhelmingly built from known leaked credentials.
What an SSH Dictionary Attack Reveals About Usernames
root — the highest-volume target
In many SSH honeypot datasets, root is among the most frequently attempted usernames — reflecting its status as the universal Linux superuser rather than any specific interest in the host. MSI’s State of Security honeypot (published 24 September 2026) recorded 45,302 root login attempts from 350 distinct IP sources — more than four times the volume of the next most targeted account. A successful root login means full control of the host.
Scope Note
These figures describe one honeypot deployment over a defined collection window. They should not be read as a census of global attack volume.
Cloud and infrastructure defaults — ubuntu, admin, deploy
Cloud images ship with predictable account names, and attackers build their dictionaries around those defaults. The exact default depends on the image, distribution, and provider:
| Provider / Image | Typical default account |
|---|---|
| Amazon Linux (AWS) | ec2-user |
| Ubuntu cloud images | ubuntu |
| Debian cloud images | admin — found in some Debian-derived images and provider-built appliances, not a universal Debian default |
| Generic VPS / appliance images | root, admin, user |
In the same September 2026 dataset, admin received 3,254 attempts from 256 distinct source IPs, and ubuntu received 1,142 attempts from 125 source IPs.
Database service identities — postgres, mysql, oracle
Usernames such as postgres, mysql, and oracle appear in SSH credential logs because attackers reuse lists across services. Be precise about what this means:
- An SSH attempt using the username
postgrestargets an operating-system account. It is not evidence that a PostgreSQL service is exposed. - Database authentication is handled by the database service itself, on its own port (commonly 5432 for PostgreSQL, 3306 for MySQL), using its own credential store.
Practical control: ensure database service identities cannot obtain an interactive shell (for example, by setting the account’s shell to /usr/sbin/nologin), and never expose database ports to untrusted networks.
Web server accounts — nginx, apache
Compromising a web server user gives an attacker a foothold for malware injection, defacement, or use as a pivot. Web-facing accounts should run with least privilege, and web applications should never execute with the ability to escalate to administrative rights without an explicit, audited path.
minecraft — a signal of botnet economics
The presence of minecraft in credential logs reflects the economics of DDoS-for-hire: a meaningful share of infected hosts are game servers or IoT devices, and the operators of those botnets are also looking for more game servers to recruit.
However, this should be presented accurately. The best-documented recent campaign in this space — xlabs_v1, a Mirai-derived botnet analysed by Hunt.io — recruits hosts primarily by exploiting exposed Android Debug Bridge (ADB) services on TCP port 5555, and distributes its payload via a server on TCP port 25565 (the default Minecraft port). It supports 21 DDoS attack variants, including a RakNet flood aimed at Minecraft-related traffic. What the evidence supports: a botnet capable of attacking game servers. What the evidence does not establish: that this botnet recruits those servers by guessing a minecraft SSH account. Treat game-server botnets as a related but distinct threat path from the SSH dictionary attack pattern.
What Happens After a Successful SSH Dictionary Attack
A compromised host is a resource, not a destination. AhnLab ASEC’s 8 October 2026 analysis of Q3 attack activity documents Linux SSH attack chains that proceed to deploy ShellBot (a Perl-based DDoS bot), XMRig cryptominers, rootkits, and backdoor tooling.
Persistence Mechanisms
Attackers may add unauthorized keys, create accounts, or install scheduled tasks and services. In one documented APNIC honeynet observation, 2,621 source IPs executed the same command to remove the existing ~/.ssh directory, write a single attacker-controlled key into authorized_keys, and then lock down permissions. The key’s comment ends in mdrfckr, and APNIC publishes its fingerprint as SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw; any server carrying this key in authorized_keys should be treated as compromised. This is a documented campaign-specific behaviour, not a universal sequence. A password reset alone does not remove a file-based key grant — the key persists until someone removes it.
- Resource theft: cryptomining that consumes CPU and increases cloud spend.
- DDoS recruitment: enrolling the host in a botnet swarm.
- Lateral movement: credential harvesting and tooling to move deeper into the network.
Indicators of an SSH Dictionary Attack
Certain recurring credential strings appear in automated SSH attempts. For example, the string 345gs5662d34 has been observed across multiple honeypot datasets. SANS ISC’s DShield sensor aggregation reports tens of thousands of password attempts using this exact string.
Correct interpretation: this demonstrates that the string is used in automated credential attempts. It does not establish that every attempt containing it originates from Mirai or any specific botnet. Treat such strings as useful indicators of scanning activity, not as definitive attribution. Correlate them with source behaviour, timestamps, network indicators, and host telemetry before attributing activity to a particular malware family.
How to Harden Against an SSH Dictionary Attack
Disable SSH password authentication where feasible
Use public-key authentication, or another appropriately configured stronger method. Test a second connection before closing your current administrative session — a configuration error can lock you out.
Precision note: this blocks password guessing over SSH. It does not eliminate credential attacks against other services, stolen-key abuse, exploitation of software vulnerabilities, or weaknesses in other enabled authentication methods.
Disable direct root login
Set PermitRootLogin no and operate through a named administrative account with controlled sudo access and audit logging.
Restrict network access
Use a firewall, VPN, or IP allowlist where practical, and rate-limit repeated authentication attempts. A non-standard SSH port is optional noise reduction — not a security boundary, and not a substitute for access controls.
Monitor for successful logins and persistence
Alert on unexpected successful authentication, new entries in authorized_keys, unusual processes, privilege escalation, unexpected outbound traffic, and changes to critical system files.
Patch and isolate services
Keep the operating system and exposed services updated. Restrict database ports to trusted networks. Run web applications, databases, and game servers under dedicated, least-privilege accounts — and never as root.
Layer supplementary controls
Tools like fail2ban and connection rate limiting are useful additions, but they sit alongside key authentication, patching, monitoring, and firewall rules. Ensure you also stay on top of critical infrastructure vulnerabilities like the recent cPanel CVE.
How to Verify Your SSH Configuration Safely
Before reloading SSH, validate the configuration and test a second connection from another terminal. Do not close your existing session until you have confirmed access.
| Check | Command | Clean Result |
|---|---|---|
| Password authentication disabled | sshd -T | grep passwordauthentication | passwordauthentication no |
| Root login disabled | sshd -T | grep permitrootlogin | permitrootlogin no |
| Public key authentication enabled | sshd -T | grep pubkeyauthentication | pubkeyauthentication yes |
| No unexpected key grants | cat ~/.ssh/authorized_keys | Only keys you recognise |
| No unexpected sudoers files | ls -la /etc/sudoers.d/ | No unfamiliar files |
| Fail2ban active | systemctl status fail2ban | active (running) |
The Bottom Line
Stop Guessing. Start Hardening.
An SSH dictionary attack does not care about your business. It cares about finding a server with a weak password on a common account. The root attempts, the ubuntu probes, and the minecraft scans are all part of the same automated economic engine: find the cheapest entry point, install the payload, and monetize the resource.
Your defense is not complex, but it requires action. Disable password-based SSH. Rename default accounts. Monitor your logs. And do not assume that your server is too small to be noticed — bots scan everything, and they exploit whatever they find.
Sources and Methodology
This advisory is based on published, attributable research rather than proprietary telemetry. Honeypot figures describe specific deployments and collection windows and are not global measurements.
- MSI, State of Security — The Same Ten Passwords, Twenty Years Later (24 Sep 2026)
- AhnLab ASEC — Statistical Report on Malware Targeting Linux SSH Servers in Q3 2026 (8 Oct 2026)
- btw.media, reporting APNIC honeynet data — APNIC’s Honeynet Saw 2,621 IPs Leave an SSH Key Behind (27 Oct 2026)
- SANS ISC / DShield — aggregated SSH honeypot data (Live dataset)
- The Hacker News, citing Hunt.io — Mirai-Based xlabs_v1 Botnet Exploits ADB… (7 May 2026)
- Rapid7 — We’re Still Terrible at Passwords (20 Oct 2022)
Frequently Asked Questions: SSH Dictionary Attack
Is my server being specifically targeted?
Almost certainly not. High-volume root and admin attempts are the baseline noise of the internet. Targeted attacks look different: they involve reconnaissance, service-specific exploitation, and credentials or usernames tied to your organisation.
Why do attackers still try root if most servers disable it?
Because enough servers do not. The cost of including root in the list is effectively zero, and the payoff of a single success is total control of a host.
Does changing the SSH port stop these attacks?
It reduces background scanning noise substantially in many environments, but it is not a security control. Determined scanners and targeted actors will find the service. Rely on authentication hardening and access restrictions instead.
Does disabling SSH password authentication eliminate the whole attack surface?
No. It closes password guessing over SSH. It does not address vulnerability exploitation, stolen or mismanaged keys, other exposed services, or misconfigured applications.
Are exposed databases related to these SSH attempts?
They are a separate exposure surface. SSH username logs do not indicate database exposure. Assess database reachability directly with a dated scan of your own infrastructure and restrict those ports to trusted networks.
Should I rename default cloud accounts?
Generally, no — disable password access for them, restrict their SSH reachability, and preserve provider-required accounts unless you fully understand the operational impact of changing them.
Running internet-facing infrastructure in the UAE?
The Orange Club builds and manages cloud infrastructure, VPS environments, and production systems for businesses in Dubai and the UAE. If you need help auditing your SSH posture, reviewing exposed services, or hardening your CI/CD and server estate, we can help.
Leave a Reply