Nothing New at All — Day 14, the Same File from Nine Places

Every morning there are flyers scattered in front of the ground-floor entrance of the apartment building.

For the first few days after moving in, you pick them up one by one. Who put all of these here, and how did they get in at this hour? Then about a week in, you just step over them. After two weeks you stop registering that the flyers are there at all.

Let me flag one thing here. Flyers arriving every day does not mean our home has been marked. It means the people who work this neighborhood have always worked it every day. So it is nothing to be startled by. But “nothing to be startled by” and “safe” are also not the same sentence.

The record left in our honeypot on the single day of August 29, 2026 is exactly that story. On this day there was not one new thing. So instead of what was new, this day we write down what did not change at all across 14 days.

First, let me unpack one unfamiliar term. A honeypot is a decoy server, deliberately made flimsy and put out on the internet. It does no real work. It is a machine left open so we can record, in full, who comes in and what they do. Every number below is what got stamped there.

The topic we picked for this day is “nothing changed”

FACT Every day we search that day’s raw data for something that was not there through the day before. On August 29 we did not find it. We compared against all 14 days of raw data from August 16 to August 29, and there was no item from this day that had not appeared in the previous 13.

FACT Concretely: the fingerprint of the public key file saved on this day, a8460f44…, appears on all 14 days. The addresses the file was fetched from, hxxp://5[.]182[.]210[.]174 and hxxp://185[.]93[.]89[.]72, likewise repeat across 13–14 days each. The connecting-program fingerprint 16443846… (SSH-2.0-Go) is a value already seen from 30 sources cumulatively. And the 40,525 VNC contacts on the second server standing beside it fall inside the range of the previous three days (29,111–45,113).

FACT The completeness score of the session that did the most on this day was 41. The recent high is 44. It did not even break the record.

INFERRED So it was a day with nothing to write in “today’s news” form. Instead we made that state itself the topic. The same file coming in repeatedly for two solid weeks, each time from a different origin, means this is not a one-off incident but a permanently laid-down background. Incidents end; backgrounds do not. As a sentence for a management report, this one is the more uncomfortable of the two.

The day in chronological order

Laid out in time order, it looks like this. There are a lot of lines, but look at just the fourth, fifth, and sixth from the bottom, side by side. The times are far apart — early morning, midday, evening — yet the numbers attached to them are the same in all three.

1. 2026-08-29T03:51:16Z
   FACT ATK-477862(154.217.x.x, Telnet) login success. 17 commands over 72 seconds. 5 intent types — reconnaissance (system), file download, execute after download, grant execute permission, persistence (planting an SSH key). TTY recording present. Files saved: 0
2. 2026-08-29T03:52:28Z
   FACT ATK-477862 session ends. The only case this day where all four stages of intent — recon → download → execute permission → persistence — were stamped in a single session
3. 2026-08-29T06:31:35Z
   FACT ATK-10149C(45.198.x.x, SSH, client SSH-2.0-Go, fingerprint 16443846184eafde36765c9bab2f4397) login success. 13 seconds, 3 commands, 10 files brought in. Completeness 41, the day's highest
4. 2026-08-29T06:31:48Z
   FACT ATK-10149C session ends. What was brought in: 2 shell scripts fetched from hxxp://5[.]182[.]210[.]174 and 4 ELF executables for ARM, MIPS, Renesas SH, and ARM EABI4 — the throw-everything approach of someone who does not know the architecture
5. 2026-08-29T06:55:56Z
   FACT ATK-2CB5A2(Telnet) login success. 20 commands, 11 files, 18 seconds, completeness 40
6. 2026-08-29T11:06:42Z
   FACT ATK-48CBAA(Telnet) login success. 20 commands, 11 files, 19 seconds, completeness 40 — same shape as the session 4 hours 10 minutes earlier
7. 2026-08-29T14:52:48Z
   FACT ATK-5392AA(Telnet) login success. 20 commands, 11 files, 18 seconds, completeness 40 — the same shape for the third time in one day. All three aliases saved the same 1-byte file (01ba4719…), and that file was saved 33 times over today
8. 2026-08-29 (daily aggregate)
   FACT Honeypot 01: 634 sessions, 183 unique origins, 251 login attempts, 766 commands, 152 TTY recordings. The top command intent is 'grant execute permission' at 161 times
9. 2026-08-29 (daily aggregate)
   FACT Honeypot 02: 41,968 sessions, 247 unique origins. 40,525 VNC contacts came from only 36 origins
10. 2026-08-16 ~ 2026-08-29 (14-day comparison)
    FACT Public key sample a8460f44… appears on all 14 days. The count of 'plant SSH key' intent ranged between 7 and 69, and today's 10 is on the low side (the maximum is 69 on 08-25)

FACT Two things in the table catch the eye. One is the 13 seconds at 06:31. From login to fetching all 10 files and leaving took 13 seconds. That works out to one file every 1.3 seconds. The other is the three lines below. 06:55, 11:06, 14:52 — nearly four hours apart from each other, yet 20 commands, 11 files, 18–19 seconds, completeness 40 are identical in all three.

INFERRED It is hard to read this as a person sitting down three times. We read it as the same template running three times in one day. But that is as far as it goes. Our data has no command text, so we cannot say it was the same person or the same organization.

That one sheet that comes every day was not an advertisement

FACT What the nine places left behind on this day is not nine different things. It is one identical file. A 389-byte OpenSSH RSA public key, whose fingerprint (sha256) is a8460f44….

Let me unpack the word fingerprint here. It is a 64-character value computed over the whole file. Change a single character inside the file and the value changes entirely. So we use this value to decide whether two files are the same or different.

FACT 389 bytes is about the size of two or three lines of a text message. And this value has been identical for 14 consecutive days, from August 16 to August 29.

Let me unpack what a public key is right here too. On a Linux server there is a file called authorized_keys (the list of permitted keys). Write one line of public key into it, and whoever holds its counterpart comes straight in without being asked for a password at all. And here is the crux: even if you change every password, this list stays exactly as it is. A password is checked at the door; this list is stored inside the server. They are different objects.

FACT The commands classified this day as ‘persistence — planting an SSH key’ number 10. Across the 14 days this value ranged between 7 and 69, with the maximum being 69 on August 25. This day sits at about one-seventh of the maximum, on the low side.

INFERRED But that is the point of this day. Fewer came, and they still came. Twenty flyers yesterday and three today does not mean the person delivering flyers has vanished. The volume dropping and the volume stopping are different things. And with this particular sheet of paper, one is enough. If on any one of those 14 days this line got saved on a single real server, that server still opens with the same key today. It makes no difference how many times the password was changed in the meantime.

Two files fetched from the same address had different fingerprints

FACT Opening up the 10 files that ATK-10149C took in over 13 seconds at 06:31 gives this. Two 1,608-byte Bash scripts fetched from hxxp://5[.]182[.]210[.]174/ok, and four ELF executables fetched from the same address.

ELF is the file format for programs that run directly on Linux. And the four are for ARM, MIPS, Renesas SH, and ARM EABI4 respectively. These are CPU types. The same program will not run if the CPU differs, so a separate build is needed per type.

INFERRED Throwing all four types into one session means they arrived not knowing what this machine is. It is like bringing the whole keyring and trying them one at a time. Only one has to fit. Server, home router, NAS — it does not matter.

FACT The four together come to 291,267 bytes. 52,496 + 68,632 + 46,288 + 123,851. And of those, only the last one (ARM EABI4, 123,851 bytes) still has its debug information attached and is not stripped. The other three are stripped. Stripping is the work of removing the human-readable name tags from a program. Removing them makes the file smaller and analysis harder. Only one of the four had not had that done, so it came in as the largest and the most readable.

FACT On the Bash script side there is something stranger. The address is the same and the size is exactly the same at 1,608 bytes, yet two files with different fingerprints (801cba39…, 0c058175…) turned up.

INFERRED It means they were fetched from the same spot but what was inside differed. What differed we cannot say, because we do not put file contents in the brief. But for anyone running a blocklist, this is a practical problem. Write down one fingerprint and the other one passes right through.

A 1-byte empty file was saved 33 times

FACT The most-saved file on this day is neither the public key nor an executable. It is a 1-byte empty file (01ba4719…), and it was saved 33 times. One byte is the size of a single character. There is not even a marker indicating the file type, so it is classified as “no magic.”

FACT The places that delivered it are three aliases — ATK-2CB5A2 at 06:55, ATK-48CBAA at 11:06, and ATK-5392AA at 14:52. Those are the same three cases from the timeline above with the identical 20 commands, 11 files, and 18–19 seconds.

INFERRED Three sessions at 11 each, and the three add up to 33. Since the numbers line up, it is possible that the three sessions each saved the same empty file 11 times. But the brief does not write down that connection directly. And what this file is and why it repeats, we do not know. We will come back to this at the end.

The doorknob was turned once every six minutes

FACT Login attempts on this day number 251. Spread evenly across the full day, that is someone trying an ID and password about once every six minutes. Distinct origins number 183.

FACT Below are the 11 kinds pared down to only combinations observed from 3 or more distinct IPs. A combination that appeared from only one place could be a real account leaked from somewhere, so we do not publish the values.

FACT Besides these 11 kinds, there are 142 more kinds that appeared from a single source only. We write only the count and not the values.

INFERRED Reading the table top to bottom, its character shows. Thirteen different places typed admin/admin identically. That means 7% of the 183 places entered the same value as if by agreement. The second row, 345gs5662d34, is a string that looks entirely meaningless, yet the ID and password are the same and 9 places typed it identically. We read that as meaning they are not values a person thought up one by one, but a list circulating somewhere being read off verbatim. It is not a list made to target us. It is the same as a flyer put into any house at all.

The files they left behind

These are values to write down. Press a value to copy it — these are not here to be read, they are here to be put into a blocklist. The addresses are deliberately broken (hxxp://, [.]). Copying and pasting them as-is will not connect.

INFERRED Reading this list top to bottom shows that the period over which each value stays useful differs. The public key fingerprint at the top is unchanged on day 14, so writing it down once buys you two weeks. Conversely, the file at 5[.]182[.]210[.]174/ok had two fingerprints from the same spot on the same day. Writing down a fingerprint and writing down an address go into the same list but have different lifespans.

Mapped onto the international classification table

The techniques attackers use carry numbers that the whole world uses in common. It is a list called MITRE ATT&CK. Below, pressing an ID takes you to the original description — we attach them so you can check for yourself rather than take our word for it.

• T1110.001Brute Force: Password Guessing — 251 login attempts / 183 unique originsINFERRED
• T1078.001Valid Accounts: Default Accounts — admin/admin (13 IPs), root/root, support/supportINFERRED
• T1082System Information Discovery — 'reconnaissance — system' 75 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 27 times, 10 sample types savedINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'grant execute permission' 161 timesINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — 766 commands, 3 shell script sample typesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — planting an SSH key' 10 times, public key file saved from 9 aliasesINFERRED
• T1070Indicator Removal — 'removing traces' 10 timesINFERRED
• T1046Network Service Discovery — 'nmap' string twice in RDP cookies on honeypot 02, low-frequency LDAP·MSSQL·SMB contactsINFERRED

FACT The largest number among the nine lines is the fifth, grant execute permission, 161 times. That is 21% of this day’s 766 commands. It is the work of attaching a “this may be executed” marker to a fetched file. That this is one-fifth of the day’s commands reads as meaning the purpose of the side coming in was execution, not sightseeing.

INFERRED And all nine lines carry the ‘INFERRED’ badge. What we saw is the intent classification and counts of commands, not a purpose the attacker stated themselves.

All of yesterday

FACT Based on Sensor 01 (the high-interaction honeypot).

FACT The port and protocol numbers overlap exactly at 332 and 302. So we wrote them matched up as Telnet on 2223, SSH on 2222. But this is a match made by looking at the numbers; the port is not recorded on each individual session.

Telnet is a very old remote access method. It is a channel left open so that from across the internet you can type directly into that machine’s command window, and the password flows through unencrypted, as-is. On this day that channel accounted for a little over half.

FACT We also carry over the numbers from the second server standing beside it (Sensor 02). This one is low-interaction, so login successes, shell commands, and credentials do not exist there in the first place. What is counted is only ‘how many times did something knock’ and ‘what did the protocol propose’. These are all records of knocking on the door, not of coming in.

FACT Overall it is 41,968 sessions and 247 unique origins. Divided across the day, something knocked on this server about once every 2 seconds.

INFERRED Same server, and the picture in front of the two doors is the exact opposite. On the VNC side 36 places were attached at 1,126 times each; on the RDP side 132 places passed by once each. The former is a few sources repeating in bulk, the latter is many sources skimming shallowly.

FACT The protocols told us some things too. Of the 40,525 VNC contacts, 40,488 proposed version 003.003. That is 99.9%. The newer 003.008 is only 31 cases. On the SMB side, decades-old dialects were mixed in, such as ‘PC NETWORK PROGRAM 1.0’ (19 times), ‘LANMAN1.0’ (36 times), and ‘Windows for Workgroups 3.1’ (18 times). In RDP connection cookies, <ip> was stamped 494 times, hello 449 times, and then nmap twice, naap twice, eltons twice, and empty values twice.

INFERRED That 99.9% proposed the same old version we read as the trace of the same script knocking repeatedly, not a human hand. Leading with old dialects is likewise characteristic of a broad scan trying to catch even outdated systems.

FACT The top 6 origins (ATK-43D1F7·ATK-943F0E·ATK-554563·ATK-992AD3·ATK-B24952·ATK-D9A63B) each produced nearly identical volumes at 5,051–5,276, and the next 3 (ATK-28B422·ATK-B954FC·ATK-AE6CC0) are clustered too at 3,146–3,171.

INFERRED It looks like a distributed scanner splitting the same workload. But this is a pattern of scale, not a basis for affiliation.

FACT Compared with yesterday (8/28), it is down overall. VNC 45,113 → 40,525, RDP 2,114 → 1,064, ADB 87 → 37. It falls inside the range of the previous three days (29,111–45,113), so it was not a particularly concentrated day.

FACT The sizes of the 4 ADB samples are 46,525 · 153,208 · 239,388 · 334,816 bytes. Three are from the single alias ATK-1D7F04, and one is shared between ATK-1D7F04 and ATK-CBA37D. These files have no record of where they were fetched from. That means no address was left to put on a blocklist.

The tools were unchanged

FACT Connections coming in over SSH use slightly different greetings depending on the program. The value summarizing that greeting is called the client fingerprint. It is a value indicating which program was used to connect.

FACT There were 45 fingerprint clusters on this day. Among them, f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6) is a value observed from 9 places this day and 289 places cumulatively. The 16443846… (SSH-2.0-Go) used by the day’s highest-completeness session is also a value already seen from 30 places cumulatively.

INFERRED It means the origin IPs change every day while the tools stay the same. We covered this passage separately in a short video posted the same day.

FACT But two lines have to be drawn. First, this is a fingerprint of a build, not a fingerprint of a person. Completely unrelated people using the default libssh that ships in the same distribution have the same value. You must not read 45 clusters as 45 actors. Second, this fingerprint does not exist for Telnet at all. More than half of this day’s sessions were Telnet, so this method cannot group that half in any way.

So what should you do

INFERRED Of the six ‘if this control had not been in place’ items the brief compiled, we put them in the order this day’s data supports most strongly.

1. Open authorized_keys once and look — this is the center of this day. After a successful login, the behavior of planting the attacker’s public key occurred 10 times, and 9 origins left that file behind. If you run a server, open the ~/.ssh/authorized_keys file. If there is a line you do not remember putting in, that is someone else’s key. Changing the password does not erase it. If in incident response you only reset passwords and never look at this file, the door is still open after you have stamped it “remediation complete.”

2. Get rid of default accounts and common passwords — the 11 kinds in the table above are combinations that 3 or more distinct IPs actually knocked with. If even one of them is alive, the time it takes is measured in seconds, not minutes. All five sessions observed on this day succeeded at login, and the fastest case took 13 seconds from login to bringing in 10 files.

3. Do not leave management ports open to the internet as-is — you become a target even without a vulnerability. This is an address never advertised anywhere, yet 183 places attached to it in a day, and 247 places attached to the server beside it. For the single reason that it is open.

4. Block the same place when it keeps knocking — 40,525 VNC contacts came from 36 places. Blocking just those 36 places makes most of that day’s contacts disappear. It also means there are fewer things to block than you would think. Without blocking, this noise hits authentication processing and log storage directly, and the one genuinely successful case gets buried in the noise.

5. Restrict outbound connections from the server — 27 file downloads and 27 execute-after-download attempts get cut off here. And there is one thing to add. FACT Among this day’s samples there were 12 in which the address inside is visible only after decompression, and that address was of the hxxp://31[.]77[.]227[.]121/bins/ family. INFERRED It means files with no URL visible on the surface were carrying a distribution site inside. An inspection that only skims the surface of a file will not catch it.

6. Keep logs separately, off the server — intent to erase traces was observed 10 times. That is 10 out of 766 commands for the day, so the proportion is low. But the reason we can write the timeline above, and the reason we can cross-check against 152 TTY recordings, is that the logs remain outside the server. If the logs live only inside that machine, then after they are erased, not even the fact that they were erased remains.

FACT And one caveat attaches to number 5. Planting an SSH key, which was this day’s main persistence path, requires no outbound connection. Block all outbound and this one is still not blocked.

Things that have happened before

INFERRED The Mirai botnet (2016, derivatives continuing since the source was published). It logs in using a list of Telnet default credentials, then throws ELF binaries built separately per CPU type in sequence and executes whichever one fits. It is structurally the same as the form in which ATK-10149C brought in four types — ARM, MIPS, Renesas SH, ARM EABI4 — in a single session this day. But we do not conclude that it is the same family — there are simply too many derivatives since the source was published. (Basis: the published source code, US-CERT/CISA alert TA16-288A, US federal court indictment and judgment records)

INFERRED The TeamTNT Linux/cloud intrusion campaigns (2020–). These are cases of entering a Linux host via weak authentication and then adding their own public key to authorized_keys, maintaining access whether or not the password gets changed. The 10 key plantings observed this day, and the pattern of the same public key file being saved from 9 places, are the same as this technique. Our data has no command text, so we have no basis to say it is the same tool or the same actor. (Basis: threat intelligence reports from multiple security vendors)

What We Don’t Know

This is the most important part of this post. There is more that we could not write than what is written above.

• We do not know the order. We cannot confirm from the data whether the five intents stamped on ATK-477862 at 03:51 occurred in the order ‘recon → download → execute permission → persistence’. Only that those stages were observed is fact.
• That same session was stamped with ‘file download’ and ‘execute after download’ intents, yet 0 files were saved. We cannot distinguish whether the download failed, whether it succeeded but was not saved, or whether it was only classified with no actual transfer occurring.
• The connection port per session is not in the data. Because the port counts (2223=332 / 2222=302) and the protocol counts (Telnet 332 / SSH 302) match exactly, Telnet=2223 and SSH=2222 is an inference matched up from that.
• The three sessions that executed the most commands this day (ATK-2CB5A2·ATK-48CBAA·ATK-5392AA) each executed 20 commands and saved 11 files, yet their intent classification is entirely empty. It appears the classifier failed to catch them, and what these three sessions did cannot be known from this brief. The fact that the day’s highest-command sessions fall into a classification gap needs separate follow-up.
• A 1-byte empty file was saved 33 times and three aliases delivered it in common. We do not know what the contents are or why it repeats. The ‘three sessions at 11 each’ in the body is a matter of the numbers lining up; the data does not write down that connection.
• From the same address hxxp://5[.]182[.]210[.]174/ok, two files with identically 1,608 bytes but different hashes turned up. What differed cannot be confirmed, because we do not include file contents.
• The fingerprint of the public key file is the same, but we do not know whose key it is, or whether it is controlled by a single private key. Hashes matching means ‘the same file’, not ‘the same operator’.
• The client fingerprint is a fingerprint of a build, not a fingerprint of a person. Unrelated users on the same distribution’s default OpenSSH/libssh have the same value. You must not read 45 clusters as 45 actors.
• On Sensor 02, we cannot compute whether one origin swept multiple services together. The sum of per-service unique IPs (232) is smaller than the total unique IPs (247), so the overlap cannot be back-calculated, and there is no per-origin service list. Writing 0 would be false, so we left it as no value.
• We do not know the intersection of unique IPs between Sensor 01 and 02. The 430 unique origins from combining the two sensors is an upper bound, and the real value may be smaller. That is why we did not sum the two sensors in the tables above.
• The 4 downloads on Sensor 02 appear to have come from the ADB channel, but the data does not state the channel.
• The background statistics we hold — 6,580 CVEs, 388 KEV entries, 98 confirmed ransomware cases, and values like CVE-2018-13379 and CVE-2021-44228 — are background context based on KISA security notices. There is no basis connecting them to this day’s honeypot observations, so we did not use them as facts in the body.
• For the C-TAS report, only success at the transport layer is confirmed. Whether it was actually ingested on the KISA side needs separate verification.
• This comparison was done only against the 14 days of raw data from 8/16 to 8/29. We were not able to check for overlap with already-published posts.

And below are the things there is no means to confirm in the first place. We do not infer them.

• ASN·ISP — we have no such database. We cannot say which provider the distribution sites 5[.]182[.]210[.]174 · 185[.]93[.]89[.]72 sit at, nor whether the top six origins on Sensor 02 are on the same network as each other.
• Geolocation — likewise absent. And IP geolocation is not a basis for attribution in the first place. We do not name any country, company, or individual as this day’s attacker.
• VPN·Tor·cloud status — we have no means of determining it. Among the 183 places and 247 places, we cannot distinguish which are waypoints and which are origins.
• VirusTotal — not integrated. We cannot attach external multi-engine verdicts to this day’s 10 sample types. Sample classification uses MalwareBazaar tags.
• User-Agent — neither observation surface is HTTP. 01 is SSH·Telnet, 02 is SMB·RDP·VNC·MSSQL·LDAP·ADB.
• CVE linkage — SSH·Telnet attacks mostly do not reference a specific vulnerability, and Sensor 02 is at the protocol negotiation stage, so the same applies.

INFERRED To sum up, this day went like this. 634 sessions, 251 login attempts, 766 commands. There was not one thing we had never seen before. The same file on day 14, the same two addresses in week 2, the same tool fingerprint at 289 cumulative places.

On a day like this, the report usually says “nothing unusual.” That is not wrong. But the flyers in front of the entrance have nothing unusual every day either. The problem is not the flyers — it is that while everyone steps over the flyers, nobody checks whether the door is locked.

Stepping over them and checking the door are two different jobs. If you have even one server today, you only need to open the authorized_keys file once. It takes a few seconds.

The observation day is the single day of August 29, 2026 (UTC). Origin IPs are carried over exactly in the brief’s masked form (154.217.x.x) and were not restored. Distribution addresses are written in altered form so they will not connect (hxxp://, [.]). For credentials, only the 11 combinations observed from 3 or more distinct IPs are quoted; for the 142 combinations that appeared from a single source only, we state the count and do not publish the values. ASN, nationality, and actor attribution have no means of confirmation, so we do not infer them.