Somebody Read the Site, Then Came Back Every Week: A Month of Targeted Credential Attacks Against This Server's Own Usernames

Two usernames appear in this honeypot's logs that exist nowhere in any credential wordlist: syscfg, the handle of this site, and feed, the subdomain serving its honeypot API. Across 1,251,496 events from thousands of addresses, exactly five source addresses ever tried them.

Those five did not arrive together. Each one fired a single burst on a single day, 40 to 88 minutes long, and then never appeared again. The first was 13 August. The last was 10 September. Somebody read this site, worked out which machine was behind it, derived two account names from what they read, and has been coming back roughly every week since from a fresh address.

This is the one finding in the corpus that only exists here. It is also, as it turns out, considerably less sophisticated than that opening paragraph suggests, and the gap between the two is the interesting part.

//The Five Bursts

Every one of these addresses ran the same job against the same three usernames, and each appeared on exactly one day:

213.209.159.142 - 13 Aug 09:18 UTC - 424 attempts over 65 min - DE, Augsburg
213.177.179.80 - 14 Aug 10:55 UTC - 182 attempts over 40 min - NL, Amsterdam
213.177.179.62 - 20 Aug 20:45 UTC - 466 attempts over 70 min - not geolocated
172.94.9.55 - 04 Sep 05:31 UTC - 466 attempts over 65 min - not geolocated
213.177.179.91 - 10 Sep 02:40 UTC - 438 attempts over 88 min - NL, Eygelshoven

1,976 login attempts in total. The username split is near-identical across runs: 157 syscfg, 157 feed, and 112 to 152 root. The 14 August run is the odd one, stopping early at 45 of each.

The pacing is deliberate

Every burst runs between 0.08 and 0.12 attempts per second. That is roughly one login attempt every nine seconds, sustained for an hour or more.

This is not a tool running flat out. A credential sprayer that wanted throughput would finish 466 attempts in under a minute. Pacing at one attempt every nine seconds is slow enough to stay under most rate-limiting and fail2ban thresholds, and slow enough that in a real log it reads as background noise rather than an attack. Compare the mdrfckr botnet sessions in the same corpus, which reach key implantation a median 2.13 seconds after TCP connect and clearly do not care who notices.

The cadence

The gaps between burst starts are 1.1 days, 6.4 days, 14.4 days and 5.9 days.

Three of those four cluster near six days, and the 14.4-day gap is almost exactly double, which is what a weekly job with one missed run would look like. That is a reading, not a finding: four intervals cannot establish a schedule. What the data does support is that this is recurring rather than a one-off, and that it has continued for at least a month.

The start times are scattered across the clock - 09:18, 10:55, 20:45, 05:31, 02:40 UTC - so if there is a scheduler behind it, it is not a naive fixed-hour cron.

//One Provider Behind Them

Three of the five addresses geolocate, and all three come back to the same ISP: Feo Prest SRL. They sit in two different countries and two different /24 networks, so the netblock is not the common thread. The provider is.

The obvious objection is that this might just be a large hosting provider that shows up everywhere. It is not, at least not here. Of 2,397 distinct addresses this honeypot has enriched, five are Feo Prest, which is 0.21% and ranks 67th by volume. For scale, the top of that list is Google LLC at 117 addresses, DigitalOcean at 59, Hurricane Electric at 47. Feo Prest is not background traffic in this dataset.

And those five Feo Prest addresses are precisely the three reconnaissance addresses plus two others, which is where it gets more interesting.

A sixth address, same provider, different wordlist

213.209.159.230 - Feo Prest, Augsburg - behaves nothing like the five. It made 32 attempts spread thinly across 27 to 31 August, and its usernames were admin (15), test123, portal, root, dashboard, console.

That is a web-admin flavoured list, not the generic Linux one. It never tried syscfg or feed. A seventh Feo Prest address, 213.209.159.108, made a single root attempt on 16 August and nothing else.

Two readings fit. Either the same operator is running several different jobs from the same provider, or the provider simply hosts more than one person doing this sort of thing. The data cannot separate those, and a shared hosting provider is weak evidence for a shared operator. It is worth recording because it is checkable, not because it is conclusive.

Every session used a Go SSH client

All seven addresses announced SSH-2.0-Go, on every single session, with no variation. That is the Go standard library's x/crypto/ssh package, which means purpose-built tooling rather than a shell script wrapping the ssh binary. It is a weak indicator on its own, since plenty of legitimate scanners are written in Go, but combined with the username list it narrows things.

//What Was Targeted, and What Was Not

The reconnaissance was targeted. syscfg and feedare not in any standard username list, they correspond to this site's handle and its API subdomain, and in 1.25 million events nobody else tried them. Deriving those two names required reading the site and connecting it to this machine.

The credential attack was not targeted at all. Each username was tried against the same 147-password set, and it is an off-the-shelf top-list: 000000, 123456, qwerty, letmein, football, starwars, trustno1, qwertyuiop. Exactly six entries derive from the username - syscfg, syscfg!, syscfg123, syscfg123!, syscfg@, syscfg@123, and the matching six for feed - and appending the username to the password list is a default rule in Hydra and Medusa, not a sign of hand-crafted effort.

So the effort went into working out who to attack and stopped there. Somebody spent time on reconnaissance, then pointed commodity tooling at the result and paced it to stay quiet. That is a lower bar than the targeting implies, and it is also the combination most likely to actually work against a real host, because the slow pacing defeats the alerting that would catch a loud attack.

//The Part That Generalises

Running a public security research site is itself a targeting signal. The site went up, the honeypot went live, and within weeks something had read it, identified the host, and started a recurring campaign against account names that only make sense if you have seen the site. Separately, CERT-Bund had already auto-reported the same machine to Hetzner for an open Telnet port before it had been running a month.

The defensive lesson is not about these seven addresses, which will be replaced. It is that the pacing works. One attempt every nine seconds for an hour, from a fresh address each time, would clear most threshold-based alerting. If this had been aimed at a host with password authentication enabled and a weak root password, nothing would have fired. It failed here for one boring reason: the real SSH service on this machine requires key authentication, and the honeypot the attempts actually landed on accepts everything by design.

//Update, 18 September: It Stopped

This article originally described the cadence as clustering near six days and explicitly declined to call it weekly, on the grounds that four intervals cannot establish a schedule. Seven more days of logs are now in, covering 11 to 17 September, and they settle it.

Zero attempts against syscfg or feed in that week. If the campaign were running on a six-to-seven day cycle, a sixth burst was due around 16 or 17 September. Nothing came.

One of the five addresses did reappear, and it is worth recording exactly what it did. 213.209.159.142 - the address behind the very first burst on 13 August - opened a single connection on 15 September at 14:43:53 UTC, negotiated a key exchange, and closed 42 seconds later. It made no login attempt at all. One connection, no credentials, then gone.

That is consistent with a check that the host is still alive, and it is also consistent with a stray scan that happens to originate from an address seen before. A single connection cannot distinguish those, and I am not going to pretend otherwise.

What the seven-day gap does establish is that the weekly reading was wrong, or the campaign has ended, or it has moved to an interval longer than a week. The honest summary is that five bursts over 29 days were followed by seven days of silence. Anyone who had written "weekly campaign, expect the next run on the 16th" would now be explaining themselves.

//Method, and What This Does Not Show

One Cowrie sensor, one address, port 22 exposed directly, 12 August to 10 September 2026, parsed from the raw cowrie.json daily files rather than the aggregated API. Attempt counts are cowrie.login.* events; each corresponds to one session.

Every login in this dataset is recorded as a success. Cowrie accepts any credential by design, so nothing here says whether these passwords would have worked against a real service. The attacker was talking to an emulator the whole time.

The geolocation is third-party and unverified.Country, city and ISP come from ip-api.com's free tier through this site's enrichment cache. ISP attribution from that source can be stale or wrong, and city-level data especially so. The Feo Prest observation is worth following up, not treating as established. Two of the five addresses are absent from the cache entirely, so their provider is unknown.

This is not attribution. Seven addresses at one hosting provider running similar tooling is consistent with one operator and equally consistent with several customers of a provider that tolerates this. Nothing here identifies a person, a group or a motive.

The cadence rests on four intervals. Describing it as weekly is an interpretation of 1.1, 6.4, 14.4 and 5.9 days. If the campaign continues, the next few bursts will confirm or kill that reading, and that is the cheapest possible follow-up: the same query against another month of logs.