All posts
The same '559 commands' intrusion that has been repeating since October 13 from shifting origins came back on the night of October 18. Within 1 hour and 8 minutes, four places pulled down the same two files. The install script came from an address we had never seen. The device executable was the same size as last time, but its hash was a value we had never seen.
An address that had only sent down a tiny installer script on October 8 sent down three kinds of executables 44 times on October 15. All three appear to be built for the chips in small devices like routers, not the computers we use. The same day, screen-sharing (VNC) contacts hit 84,222 — once again breaking the record set two days earlier.
On October 13, three sources came in over Telnet and ran through the same 559 commands five times. Each run pulled down 22 files and left within a minute and a half, and at 4:50 PM two of them arrived 0.9 seconds apart and did the same work side by side. The address that served the install script is the fourth one to show up from the same address range.
On October 11, 255 sources touched the remote desktop door (3389) — the most in a single day since we began keeping records. Yet contacts per source were just 4.15, the fewest ever. The same day, on our other server, a session came back using the same tool we saw 46 days ago and attempted key planting, a scheduled job, and trace removal all within one minute.
On the evening of October 8, the same source logged into our server over Telnet four times. All four times it finished 9 commands in 9.5–9.7 seconds, and each time it pulled down a 1,670-byte installer script. This file was downloaded 15 times that day, and all 15 times the one doing the downloading was this single source.
On the morning of October 6, a single source logged into our SSH server five times over 8 minutes and 37 seconds. Each time it ran exactly two commands, and across all visits it pulled down 24 files. Those executables were built for ARM 32-bit devices, not servers — and the client fingerprint, the distribution hosts, and the hashes were all values we had never seen before.
All nine file types left on our two honeypots on October 4 were hashes we had seen before. One session even came back matching a visit from 42 days earlier down to 32 seconds, 48 commands, and 12 files. Only one number set a record. Password combinations whose values we withheld — because they could be someone's real account — numbered 3,026 types, the most we have ever recorded.
On October 1 there were 43,402 screen-sharing (VNC) connection attempts — within the normal range. But the version string offered on connect was a new one that had never once held a majority across 21 days, and it accounted for 63.2%. The same day, on our other server, a file named — literally — 'backdoor.sh' came down from an address we had never seen.
On September 27, a malware distribution address we had noted five days earlier served files again. The lead installer script has not changed a single bit in 37 days since August 21. All nine executables that followed were files we had never seen before, and three of them matched their earlier sizes down to the byte while differing in content.
On September 22, files came down again from a malware distribution address we first wrote down on August 21. The installer script at the front was not a single character different from a month ago, but all six executables — one per CPU type — were files we had never seen before. Five of those six carried exactly the names we had once learned only by unpacking a compressed sample.
On September 20, a single 389-byte public key that had appeared daily since August 16 was registered on our server from 41 different sources. That is 2.4 times the previous high of 17 among the days we compared — and there is no record that ties it in one line to the three other numbers that jumped alongside it the same day. Next to it, the executable we wrote 'was not rebuilt' three days ago came back to the same address, 1,696 bytes larger.
On September 17, a third address appeared sharing its first three octets with the address that handed out files twice in August. All seven files that came from it are absent from 27 days of records, and five of them carry name tags resembling programs Linux runs on its own. Yet the intrusion that brought these seven files appears in none of the five sessions recorded that day.
At 12:07 PM on September 15, a Telnet intrusion ran 7 commands in 7 seconds and pulled down 2 files. The address the files came from and the address the intruder came from shared their first two octets — a shape we also saw on September 7 and 8, making this the third time in nine days. And 6 hours 59 minutes later, the same thing happened once more from the same place.
On September 13, contacts hitting the remote desktop port reached 42,578 in a single day, surpassing the previous high of 34,811 set three days earlier. The top sender was the same alias as before, and the name tag 'hello', which had dropped to 16 three days ago, came back at 7,039. All four file types received by the neighboring server were hashes we had seen before.
On September 10, knocks on the remote desktop port came to 34,811 in a single day. That is 1.62× the 21,483 from all 14 days between August 26 and September 8 combined — yet the number of places knocking was 109, inside the usual range. This is not a record of more visitors arriving; it is a record of one place pressing the button 319 times.
On September 8, an address absent from 23 days of records dropped nine executables at once, differing only in CPU type. The intrusion that collected them typed exactly three commands and was over in 33.25 seconds. Then, 1 minute 12 seconds later, a 33.26-second run came through again.
On September 7, an address that had never appeared in 22 days of records showed up for the first time. The two executables downloaded from it are nearly identical in size and do the same thing — two builds differing only in the order they read numbers. Whoever made them sent them out without stripping the labels inside the files.
On September 6, the number of places knocking on the screen-sharing door went from 100 to 264 in a single day. But the number of knocks only rose 1.4x, which means the knocks per source were cut in half. This is the record of a day when a thin, wide-spread crowd was layered on top of the few who hit hard.
On September 5, five of the six files that landed on our server were names already written down for 20 days running. But while cross-checking the records, we found the error was on our side. A field we'd logged as 'so far, 50 sources' had read 35 the day before — and that wasn't because the attacks had let up.
On September 4, 233 of the 419 sources that visited our server arrived carrying the same client-program marking. But those 233 didn't drop a single file, and the only marking that actually delivered a sample that day came from just 2 IPs. This is the record of a day when the most-stamped footprint and the footprint that left something behind were not the same.
On September 3, four files we had written down on a blocklist five days earlier came back in. But when we fingerprinted them, three were new files that had never appeared once in 18 days of archives, and exactly one was the same file, unchanged down to the bit, for the sixth day running. What doesn't change even when the clothes do — that day's data showed it in four lines.
On September 2, the doorknobs on our server turned 44,140 times in a single day. But only one 'thing we'd never seen before' actually made it inside, and it came through a passage that opens just 23 times a day. Everything else was the same rerun, on day 17 and day 18.
On September 1, the commands entered into our server went from 760 to 14,085 in a single day. But only 422 of them (3.0%) had a classified intent, and the act of actually leaving someone else's key behind happened 13 times. A bigger number and a more dangerous number are not the same thing, so on this day we broke down what the bigger number actually was.
On August 31, four numbers that yesterday read 107, 107, 106, and 116 all dropped to 8 in unison. That they rose together and fell together points strongly toward their having been one cluster, but the data has still never tied the four together. Instead, 324 distinct sources knocked on the door — the fourth highest of the sixteen days — while sessions per source hit a low of 2.40.
On August 30, 107 different sources arrived carrying the same username and the same single password. Yet the average number of knocks per source was 1.05. Nine sources yesterday became 107 in a single day, and the same 389-byte key file came from the same 107 sources.
On August 29 there was not a single thing our honeypot had never seen before. The same 389-byte file showed up for the 14th day running, this time from nine different places, and the two distribution sites were unchanged too. 'Nothing happened' and 'the same thing happened again today' are not the same sentence, so on this day we wrote down the fact that nothing changed.
On August 28, a server that had caught nothing for two days produced four files all at once. 773,937 bytes in total, all from the same single source. But these files have no field at all for recording 'where it came from,' so we're left with no address to add to a blocklist and no distribution site to report.
On August 27, the commands run on our server numbered 2,313 — one-sixth of the previous day's total. Yet the number of distinct source locations hit 442, setting a new high for the third day running, and exactly one behavior set a high alongside it: planting someone else's public key. The same 389-byte file appeared for the 12th consecutive day, this time from 26 different sources.
On August 26, our two servers received 42,000 and 5,000 contacts. The noisiest one didn't leave behind a single file, and one session that lasted 12.5 seconds left ten. That day's data showed us twice over that measuring risk by volume of noise flips the order.
The number of times someone knocked on our server's door yesterday was perfectly ordinary. But three behaviors that happen *after* the door opens all hit ten-day highs on the same day. Adding someone else's name to the standing-access list: 69 times. Erasing the record of having been there: 70 times — a difference of exactly one.
Yesterday our honeypot received files with the same names from the same address as the day before. But all three executables had entirely different contents, and only the loader script at the front was identical for a second day. Yesterday's data measured, directly, that every value you write into a blocklist has a different shelf life.
An executable came back to our honeypot yesterday, two days after the last one. It came from a neighboring address sharing the same leading digits as the distribution host from two days earlier, with the entire file-naming convention swapped out. Not one of the twelve malicious file names we had written down in advance matched. What we got instead was a five-second routine repeated three times in one day.
Yesterday our honeypot was the busiest it has been since we started recording. 3,553 sessions, 7,574 commands. And yet not a single malicious executable came down to the server, and one session matched a record from four days earlier on seven separate values. The only difference was how long it took.
Yesterday a new address showed up on our honeypot — one that had not appeared once in five days of records. But the folder name and the file-naming scheme were identical to an older address. Here is why we recognized a first-time address on day one, and what that does and does not let us say.
Four completed telnet sessions from yesterday's honeypot matched right down to the numbers: 31 commands, 1 download, dwell time in the 68-second range. Telnet has no client fingerprint, so the grouping method we normally rely on didn't apply. Here's what we grouped them by instead, and exactly how far that grouping goes.
A single 63-second session left behind zero samples and planted nothing but an SSH public key. The same key hash showed up three days running — 8/16, 8/17, 8/18 — and the number of sources planting it grew from 10 to 12 to 16. Here's how to notice a compromise when there's no file for antivirus to catch.
Three days straight the completed sessions were Telnet; on the fourth day it switched to SSH. The intruder stayed 3.6 seconds, and ran exactly one command.
