What happened exactly?

At 16:48Z, 56 distinct addresses arrive inside one minute. By 17:01Z the rate peaks at 211 attempts a minute. Note the shape of it: through the whole opening phase the count of attempts and the count of distinct source addresses are nearly identical, one attempt per host per minute. This is clearly a botnet deliberately spreading its guesses thin so that no single address trips a per source counter quickly.

It goes on for thirteen minutes. Then arithmetic catches up: the adaptive strike window at that point in time is narrower than 20 minutes, so around 17:02Z hosts begin crossing five accumulated failures and the bans start. The ban rate peaks at 61 in the minute of 17:09Z. From there the two curves cross. Traffic stops reaching the authenticator and starts bouncing off the accept gate instead.

The crossover at 17:13Z is the shield taking hold. Everything to the right of it is the attack still arriving and being dropped at TCP accept, before a key-exchange event even has the chance to occur.

What were they shopping for?

268 distinct usernames were tried. The head of the distribution is the expected system account sweep, and your guess about root and admin was right: together they represent roughly 32% of all attempts.

The interesting part is the second cluster. wallet, crypto, solana, blockchain, exchange, metaverse, plus xmr, monero, eth and binance further down. That is 951 attempts, or about 19% of the total, hunting for crypto custody hosts rather than generic shells.

A third cluster names hosting control panels: whmc, ubersmith, cerberus, panel. And the long tail is a first name dictionary, five attempts each, which is what the single most persistent host in the log was patiently grinding through.

SFTP.cloud’s automatic shield held end-to-end

Nothing authenticated. Across 4,925 attempts from 937 addresses there is not a single successful attacker login on any protocol. The only successful sessions in the entire window are seven WebClient logins by a legitimate user account from a single address.

The cost model held. The accept gate refuses a banned source before the SSH key exchange, so 6,321 of the connections in our logs cost essentially nothing. That’s why the protocol-head process never moved above 0.1% CPU usage while 200 hosts a minute hammered it.

Persistence held. Bans survived in the database and the RAM index rebuilt cleanly. 120 bans expired and were lifted on schedule during the window, with no drift.

A good day’s work

Throughout the entire attack, our SOC staff sat there, watching it all unfold, keeping an eye on resource usage, making sure legitimate users were still signing-in without hiccups.

All they had to do was watch. SFTP.cloud protected itself, silently and efficiently, exactly as it was designed to do.