New Clothes Every Time, But the Same Walk for Six Days Running

Someone is walking toward you from a distance. You can’t see their face yet. They’re wearing clothes you’ve never seen before.

And yet you already know. Ah, it’s them.

You didn’t know from the clothes. The way they walk, the angle they carry a bag at, the habitual wave of the hand. Even with the face out of view, those arrive first. Because clothes can be changed, but a walk usually can’t.

In security, writing down “this file is dangerous” is exactly this problem. We have to choose what to note in our notebook. Write down the color of the clothes and you’ll miss tomorrow. Write down the walk and it carries a little further.

On September 3, 2026, four files came into our server. The same four we had already written down five days earlier. But when we fingerprinted them, three were files we’d never seen, and only one was unchanged.

First, let me unpack one unfamiliar term. A honeypot is a decoy server made deliberately flimsy and put out on the internet. It does no real work. It’s a machine left open so that whatever anyone comes in and does gets recorded in full. Every number below was captured there.

There Are Two Servers, and Their Characters Are Opposites

FACT Sensor 01 is a server where a person can actually come in and type commands. It has two doors. One is SSH, the other is Telnet. Both are ways of connecting to a distant computer and issuing commands. Telnet is the far older method, and passwords flow through it unencrypted, exactly as typed.

FACT Sensor 02 is a server with nothing but doorknobs attached. If someone knocks, it just answers “there’s a door here.” It doesn’t let anyone inside. So on this side, successful logins, commands, and password records do not exist in the first place. Here the word “contact” means the number of times the door was knocked on, not the number of times it opened.

FACT But there is exactly one exception on 02 as well. It’s ADB. ADB is short for “Android Debug Bridge,” a developer channel for connecting an Android device to a computer to push and pull apps. On 02, this is the only channel through which files can actually be carried in.

The four files in this post are all a story about 02.

That Day in Chronological Order

Laid out in time order, it looks like this. First, notice that the top four lines have no time. The 02 records have no clock attached to them at all. From below that, everything is preserved down to the second.

1. 2026-09-03 (time unknown)
   FACT Sensor 02 obtained 4 samples across 32 ADB sessions. All 4 came from a single source, ATK-5A7674, and each was observed 3 times. No item in 02 carries a timestamp, so we cannot say when during the day this happened
2. 2026-09-03 (time unknown)
   FACT Of those 4, d7188b8c… (153,208 bytes) is exactly the same hash recorded in the 8/28 and 8/30 briefs. The hashes of the other 3 (7a48c93c… 46,582B · 608ee011… 235,292B · d4e8c642… 334,752B) appear nowhere in 18 days of archives
3. 2026-09-03 (time unknown)
   FACT Compared against the sizes in the 8/28 and 8/30 records: 46,525→46,582 (+57) · 239,388→235,292 (−4,096) · 334,816→334,752 (−64) · 153,208→153,208 (0). The 4,096 difference in the second is exactly 4KB. What that figure means has no basis in the source data
4. 2026-09-03 (time unknown)
   FACT 02's per-service contacts of 42,714 + 32 ADB sessions = 42,746, which matches the total. ADB is 0.07% of the whole. On 02, ADB was again the only channel that day where the content of what was pushed in remained
5. 2026-09-03T02:05:53Z ~ 02:05:57Z
   FACT Sensor 01: ATK-CA5936 (130.12.x.x, SSH) logged in successfully. 3.844 seconds, 1 command but 5 intent types, 2 downloads (399-byte OpenSSH private key 43728fbf… · 54-byte ASCII 00b6f15c…). Fingerprint 16443846…4397 / SSH-2.0-Go. Alias, fingerprint, and figures match the 8/19, 8/24, 8/25, 8/28, and 8/30 briefs
6. 2026-09-03T02:43:17Z ~ 02:44:18Z
   FACT Sensor 01: ATK-86979F (212.132.x.x, Telnet) logged in successfully. 60.4 seconds, 22 commands, 11 downloads — all 11 are 1-byte empty files (01ba4719…). This session's only intent is 'impair defenses,' and the day's total for 'impair defenses' is also 1
7. 2026-09-03T02:52:54Z / 10:00:38Z / 12:51:00Z
   FACT Sensor 01: three Telnet sessions, ATK-9CF939 · ATK-93FAFF · ATK-D0D176, came in separately over 10 hours, and all three are completely identical — login success, 17 commands, 0 downloads, 5 intent types, completeness 17. Durations are 61.1s · 61.9s · 70.9s. Being Telnet, not a single line of client fingerprint remains
8. 2026-09-03 (daily aggregate)
   FACT Sensor 01 unique sources: 457 — surpassing the 442 of 8/27, the previous high across 18 days of archives, making it the most in 19 days. Sessions numbered 2,378, or 5.20 per source. By port: 2223 (Telnet) 1,381 · 2222 (SSH) 997, so Telnet is 58.1%
9. 2026-09-03 (daily aggregate)
   FACT Intent funnel: recon—system 488 → grant execute permission 164 → file download 37 / execute after download 37 → persistence—SSH key planting 10 → trace deletion 7 → impair defenses 1. It narrows by 3–4x at each stage. The 745 classified as intents are 12.4% of the day's 6,001 commands

FACT Look again at the middle three lines. 61.1 seconds · 61.9 seconds · 70.9 seconds. All three had 17 commands, all three had 0 downloads. But the times they came in — 02:52 · 10:00 · 12:51 — are scattered across 10 hours.

INFERRED The arrival times weren’t coordinated, but what they did matches. This isn’t the shape of work a person does sitting down. We read it as the same pre-written sequence played back three times.

Four Files — Three New Outfits, One Unchanged

FACT The files 02 obtained that day number 4. There were 4 on August 28 as well, and August 30 had the same 4-item composition.

Let me unpack the word hash here. A hash (sha256) is a 64-character value computed from the entire file. Change a single character inside the file and the value changes completely. So we use this value to decide “are this file and that file the same thing.” Think of it as something like a human fingerprint.

FACT We matched that day’s four fingerprints against the 8/28 and 8/30 records. Here’s the result.

FACT Three of the four lines have fingerprints we’ve never seen. They appear nowhere in the 18 days of records we hold, from August 16 to September 2.

FACT And only the bottom line is unchanged down to the bit. From August 28 to September 3, it’s the same file for the sixth day running.

INFERRED Let me attach something to compare the difference figures to. +57 bytes is about the volume of nineteen Korean characters. −64 bytes is the length of one line of the sha256 hash value just mentioned (64 characters). In clothing terms, it’s about the level of one button being changed.

FACT The 4,096 bytes in the middle line is exactly 4KB. It catches the eye because it’s such a round number.

FACT So we stop here. We don’t know why this number is exactly 4,096. The source data gives no basis for it. We simply note the fact that it’s a round number.

FACT One more thing to make clear. The source data never told us that the upper and lower rows of the table above are “new versions of the same slot.” We know exactly two things. That the arrangement of the four sizes is similar, and that one of them matches down to the fingerprint.

INFERRED But for the defending side, this becomes a problem all the same. If you took down the four fingerprints on August 28, on September 3 that list misses on three quarters of them. Only one of the four lines still hits.

INFERRED Back to the story about the walk. It amounts to having written down the color of the clothes. Three outfits came in newly bought, and only one was unchanged.

The Name Tags Were Different Every Time Too

FACT The aliases of the sources that dropped these files also differ every time.

FACT And here we draw a line. An alias (ATK-XXXXXX) is a marker attached so that the same masked source can be pointed to across posts. It is not an identity. A different alias means the masked source is different, and it says nothing beyond that.

INFERRED So in this post we do not use the phrase “the same person.” Walking alike doesn’t make someone the same person. They could be people who learned the same thing at the same academy. When mutually unrelated people each run the same widely distributed tool, the same shape comes out.

The Door Those Files Came Through Was 0.07% of the Whole

FACT Contacts received by server 02 that day: 42,746.

INFERRED Spread evenly across the full day, that’s about once every 2 seconds. And this is a machine we never advertised at all.

FACT Of those, ADB sessions numbered 32. That’s 0.07% of the whole. On the same day, a single VNC (screen sharing) port was knocked on 41,705 times.

INFERRED Compared side by side, that’s 1,303 times more. And the side where files remained was the door with 32.

FACT Let’s compare sizes too. The total of the 4 items 02 received that day is 769,834 bytes. Adding up all 6 sample types that came out of 01 the same day gives 1,158 bytes.

INFERRED That’s a 665x difference. The server where people actually came in and even typed commands is far lighter. The same asymmetry was there on August 28 and 30.

INFERRED And d7188b8c…, the one among that day’s 4 that has gone unchanged the longest, is 153,208 bytes. That’s about the size of 500 copies of the 306-byte shell script that came down on 01 that same day, strung together.

FACT That said, this post does not say what these files are. The 02 records have no field at all for recording file type or classification. What we have is only sizes and fingerprints.

Values Worth Writing Down

FACT Below are the files observed that day. Press a value to copy it — these aren’t here to be read, they’re here to go into your blocklist. Addresses were deliberately broken when written (hxxp://, [.]). Copy and paste them as-is and they won’t connect. The top four lines are 02, the ones below are 01. And count how many lines say ‘address not recorded.’

FACT Only one line out of eleven has an address written on it. All the rest say ‘address not recorded.’

INFERRED For the defending side, this is a nuisance. If there’s no address to block, there’s nothing to put on the blocklist. No distribution site remains to report either. What’s left is only the fingerprint — and as we just saw, three quarters of that fingerprint was changed out of within six days.

FACT And among the 6 sample types on 01 that day, there is not a single executable binary. Only an empty file, a shell script, two kinds of ASCII text, a public key, and a private key.

Are You Using This Password

FACT Login attempts that day: 2,047.

INFERRED Spread evenly across the full day, that’s about once every 42 seconds. Meaning that during the 30 minutes it takes to eat a meal, the doorknob turned more than forty times.

FACT Below are the 20 combinations filtered to only those observed from 3 or more distinct IPs.

FACT For a few of them the counts remain as well. admin/admin was tried 96 times from 22 distinct sources, root/admin 77 times from 6, root/vizxv 73 times from 5, and enable\x00/linuxshell\x00 69 times from 4. Attempts leaving the password entirely blank also occurred 30 times from 4 sources.

FACT These 20 are not all the combinations observed that day. There are 594 more that did not meet the threshold. Those 594 we only counted; we did not publish their values.

INFERRED The reason is this. A combination that appeared from only one or two sources could be a real person’s account that was actually leaked somewhere. Transcribing it here would inflict a second harm on that person. So we only count. The 20 listed above are all factory-default lineage repeated from 4 or more sources — belonging to no one.

FACT The 594 is the sixth largest value among the 18 days we hold. Ahead of it are 8/18 (1,388) · 8/25 (1,017) · 8/23 (1,007) · 8/16 (934) · 8/30 (897).

INFERRED What’s worth noting in the table are values like root/vizxv, root/7ujMko0admin, and root/default. These are not passwords made by a person. They’re values the company that built the device put in at the factory. Which is why the sense that “it’s not a password I set, so it’s safe” works exactly in reverse. The device an administrator has never once logged into is the most dangerous.

Mapped to the International Classification

The techniques attackers used carry numbers the whole world shares. It’s a list called MITRE ATT&CK. Below, press an ID to go to the original description — it’s attached so you can check for yourself rather than take our word for it.

• T1110.001Brute Force: Password Guessing — 2,047 login attempts, 20 combinations quotable from the sourceINFERRED
• T1078.001Valid Accounts: Default Accounts — admin/admin (22 sources), root/vizxv (5 sources), and other device factory-default lineageINFERRED
• T1082System Information Discovery — 'recon — system' 488 timesINFERRED
• T1046Network Service Discovery — 'recon — network' 1 timeINFERRED
• T1105Ingress Tool Transfer — 'file download' 37 times, 4 ADB samples on 02INFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'grant execute permission' 164 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — SSH key planting' 10 times, 389-byte public key from 5 sourcesINFERRED
• T1070Indicator Removal — 'trace deletion' 7 timesINFERRED
• T1562Impair Defenses — 'impair defenses' 1 time (ATK-86979F session)INFERRED
• T1021.005Remote Services: VNC — 41,705 contacts on 02 / 135 sourcesINFERRED
• T1021.001Remote Services: Remote Desktop Protocol — 568 contacts on 02 / 102 sourcesINFERRED
• T1021.002Remote Services: SMB/Windows Admin Shares — 388 contacts on 02 / 48 sourcesINFERRED

FACT All twelve lines carry the ‘INFERRED’ badge. Because what we saw was the intent classification and counts of commands, not a purpose the attacker stated themselves.

FACT And the bottom three lines carry one more caveat. 02 is a server with nothing but doorknobs, so the event of a successful login does not exist at all. Those 40,000-odd are ‘knocked,’ not ‘came in.’

The Whole of Yesterday

FACT Based on sensor 01 (the side people can actually come into).

INFERRED The bottom line is the quietest number in this table. Seven out of every eight commands have no meaning attached to them. What we could classify as “this is a command that was trying to do X” was only 12.4%.

FACT The breakdown of those 745 is as follows. ‘Intent’ is the value classifying what a typed command was trying to do.

INFERRED Look at the shape descending from top to bottom. 488 → 164 → 37 → 10 → 7 → 1. It narrows by 3–4x at each stage. They all go as far as looking around, but very few make it to actually leaving something behind.

FACT ‘Grant execute permission’ is the work of attaching a mark to a downloaded file saying “this is a program that may be run.” On Linux, a file won’t run just because you’ve received it. You have to attach the mark separately.

FACT And ‘file download’ at 37 and ‘execute after download’ at 37 are exactly the same number. Meaning what was downloaded led to the execution stage without exception.

FACT Let me also transcribe the numbers from server 02 standing beside it. Again, ‘contact’ here means the number of knocks.

FACT The six lines sum to 42,746, matching the total exactly. Look at the top and the bottom side by side. Files that came out of 41,705 contacts: 0. Files that came out of 32: 4.

FACT There are two ‘not recorded’ entries on the ADB line. That day’s per-service breakdown table had no ADB entry at all, so we cannot know the port number or the unique source count. The August 27 and 30 records had them. Here, 0 means ‘not written down,’ not ‘none.’

FACT There’s one more shape on the VNC side. That day, the counts for the top 7 sources by event volume on 02 were 7,183 / 7,131 / 6,323 / 5,094 / 5,035 / 5,007 / 5,000. But 8th place is 182.

INFERRED Between 7th and 8th there’s a 27.5x cliff. The 40,773 from the top 7 combined is 95.4% of all contacts on 02 and 97.8% of VNC contacts. These seven appear to be the substance of the VNC flood.

FACT That said, we stop here. We cannot know whether these seven are related to each other. Similar numbers alone don’t let us write that they’re the same actor, and we have no means to confirm it. And ATK-5A7674, which left the 4 files that day, is not on this top list.

FACT Let me also transcribe what specification the knockers spoke in. Protocol vocabulary is the value the connecting side proposes first, saying “I’ll speak in this version.”

• The versions proposed on VNC were 003.003 in 40,826 cases and 003.008 in 645. Of the 41,471 with a version recorded, 98.4% were the old version. 234 have no version recorded.
• For SMB dialects, of the 327 recorded, SMB 2.??? appears exactly once, and the remaining 326 (99.7%) are pre-SMB1 vocabulary like NT LM 0.12 · LANMAN1.0 · LM1.2X002 · PC NETWORK PROGRAM 1.0. Of the 388, 61 have no record.
• For RDP connection cookies, 433 of the 440 recorded (98.4%) came out as <ip> after sanitization. Meaning an IP-shaped string was sitting in the cookie slot. The rest are 3 instances of hello and 4 values that appear to be nine-character random strings. Of the 568, 128 have no cookie recorded.

INFERRED On a server with SMB1 turned off, those 326 simply end at the negotiation stage. And putting the target IP itself in the cookie slot instead of a username reads as the trace of an automated tool working through a list, not a person. That said, the IP string inside the cookie is subject to masking, so we do not publish the original, and we make no judgment about what that value points to either.

The Tools Stay the Same, but the IPs Change Daily

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

FACT That day, fingerprint clusters were counted at 39, of which 12 types made it into the record. Adding up that day’s sources for the 12 gives 288, which is 63% of 01’s 457 unique sources.

FACT Number one is acaa53e0… (SSH-2.0-OpenSSH_7.4) with 255 sources that day and 1,005 cumulative.

INFERRED Looking at the number alone makes you want to write “255 sources are one group.” We won’t. This value is the string of the default client that simply ships with widely used Linux distributions. It’s normal for mutually unrelated people to have the same value. What can be said goes as far as “255 sources use the same tool,” and “255 sources are one organization” does not hold up with this data.

FACT But among the 12 types, only one cluster actually left samples. It’s 16443846…4397 (SSH-2.0-Go), with 4 sources that day and 19 cumulative. And this is the fingerprint of the ATK-CA5936 session in the timeline above.

INFERRED Here we return to the start of this post. The tool stays the same, but the source holding that tool changes daily. The four files on 02 that day had the same shape. The name tags differed every time — ATK-F4738A → ATK-E23F05 · ATK-1D7F04 → ATK-5A7674 — but the fact that they come carrying four as one set, and the fingerprint of one of them, stayed the same for six days.

INFERRED If the face changes every time, a notebook that writes down faces is useless.

FACT And that day carries one more limit. Telnet, which was 58.1% of sessions, has no such thing as a fingerprint at all. SSH exchanges greetings on connection, but Telnet has no such procedure. That’s why the fingerprint field is empty for the four Telnet sessions in the timeline above.

So What Should Be Done

INFERRED Here are seven “if this control hadn’t been there” items, ordered by how strongly that day’s data backs them.

1. Eliminate factory-shipped accounts and common passwords — the day’s top five sessions by completeness all begin after a successful login, without exception. And all 20 types in the table above are either defaults or strings of digits. This is the spot that falls first to the cheapest automation.

2. Let people in with keys instead of passwords — all 2,047 attempts that day were on the password path. And ‘SSH key planting’ was observed 10 times. Linux servers have a file called authorized_keys (the list of permitted keys). If one line of public key gets in there, whoever holds its pair comes in without being asked for a password at all. Put plainly, it’s a spare key that opens without a password hung by the front door. And changing the password leaves that key in place. That day, even sessions that failed to leave a single sample reached the key-planting stage.

3. Don’t leave management ports wide open to the internet — two machines we never advertised at all received contacts in the 45-thousand range in a single day. That day’s 457 unique sources on 01 is the most in 19 days. Even with zero vulnerabilities, this much pressure is applied constantly. Move them behind a VPN or a jump host and most of this pressure never arrives in the first place.

4. Turn off the Android debug channel (ADB) — this is the point of the day. In contacts it’s 32 out of 42,746, 0.07%. And yet all four samples obtained that day came from here. If you set defensive priorities by knock count, you look at this door precisely last. The typical case is having turned it on briefly during development and never turning it off.

5. Restrict outbound connections from the server — intrusion and weapons import are separate. That day’s 37 ‘file downloads’ and 37 ‘execute after download’ are that spot. 7 different sources pulled the same 306-byte script from the same external address (hxxp://185[.]93[.]89[.]72/wget). Block outbound traffic by default and the next stage is cut off even if a login is breached. That day’s 01 sample total is only 1,158 bytes, but as long as the distribution site is alive, the size can grow at any time — in fact, 02 received 769,834 bytes on the same day.

6. Keep logs off the server as well — intent to erase traces was observed 7 times that day, and intent to impair defenses once. The counts are small. Even so, whoever comes in after the erasure cannot even know what was erased. If you don’t ship logs off the server immediately, the only thing recoverable after an incident is the fact that ‘we don’t know when we were breached.’

7. Don’t rely on ‘lock out after N failures’ alone — this item cuts both ways that day. On 01, sessions per source were 5.20. Since each source knocks about five times and leaves, a threshold like ‘block after 5 failures’ would almost never have fired. Conversely, VNC on 02 was 309 per source, and the top 7 were 5,000 apiece. Had there been rate limiting here, most of it would have been cut. The same measure is nearly useless at one door and decisive at another. Design a defense on per-IP thresholds alone and it won’t catch the broad, shallow attempts like those on 01.

FACT A caveat on #2. SSH key planting requires no outbound connection. No matter how tightly you clamp #5, this isn’t blocked by it. If you run a server, open the ~/.ssh/authorized_keys file once. If there’s a line you don’t remember putting in, that’s someone else’s key. Changing your password won’t erase it.

It Has Happened Before

INFERRED ADB.Miner (2018). A worm that scanned for devices with Android Debug Bridge (5555/tcp) open and spread mining code. The structure in which an ADB channel left open without authentication becomes a file-injection path is the same as 02 that day. That said, we are not saying it’s the same family. We don’t have the type or classification of that day’s samples, so what can be said goes only as far as the shape of the path being the same. (Basis: security vendor threat intelligence public report — 360 Netlab)

INFERRED Mirai botnet (2016). A case of mass-infecting IoT devices via Telnet and a dictionary of device factory-default accounts, after which the source code was published and derivative families spread. The top combinations quoted that day (root/vizxv, root/7ujMko0admin, admin/admin, root/default) are of a lineage overlapping that published default-account dictionary. And 58.1% of that day’s sessions were Telnet. That said, an overlapping dictionary only suggests the lineage of a tool; it does not identify who is operating it. (Basis: US CISA (then US-CERT) alert TA16-288A · published source code)

INFERRED RealVNC authentication-type negotiation bypass vulnerability CVE-2006-2369 (2006). Of the 41,471 screen-sharing versions proposed on 02 that day, 40,826 (98.4%) were 003.003. RFB 3.3 is an old version in which the authority to choose the authentication method sits on the server side, so it’s a value a scanner targeting this class of flaw, or unauthenticated screen-sharing servers, would favor. That said, this is background explanation based on the protocol definition and a published CVE, and we have no basis for saying the contacts observed that day attacked this vulnerability. (Basis: CVE registered with MITRE/NVD)

We Don’t Stop at Observation

FACT The distribution address obtained that day, hxxp://185[.]93[.]89[.]72/wget, and the three new hashes from 02 are subject to reporting to C-TAS (the Korea Internet & Security Agency’s Cyber Threat Analysis and Sharing system).

FACT With a caveat, though. What we can confirm goes only as far as the transmission having succeeded. Whether it was actually ingested on the receiving side cannot be stated from these records.

What We Don’t Know

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

• [Core] The 02 records have no clock at all. We cannot say when during the day, or at what intervals, the 4 samples came in. That’s why every 02 line in the timeline is left as ‘time unknown.’
• [Core] Attributing the four to the ADB path is an inference we stitched together. It comes from the structure that ‘the only channel on 02 through which files can be carried in is ADB, and the rest are low-interaction and don’t receive files.’ The source data did not explicitly link these downloads to a specific service.
• [Core] We don’t know what these four are. The 02 records have no field at all for recording file type or classification. With no basis for judging whether they’re executables, libraries, or just data, we described them by size and fingerprint alone.
• We cannot know whether the three are “new versions of the same slot” as the three from 8/28 and 8/30, or entirely different files. The source data doesn’t connect the two. All we know is that the arrangement of the four sizes is similar and that one of them matches down to the fingerprint. What the size differences (+57 / −4,096 / −64) mean also has no basis.
• The fact that the aliases differ on 8/28, 8/30, and 9/03 means the masked sources differ, and says nothing beyond that. An alias is a marker for cross-referencing between posts, not an identity.
• That day’s per-service breakdown table has no ADB entry, so we cannot know the port number or the unique source count. It isn’t stated as a collection failure, but compared with 8/27 and 8/30, we note the fact that the information volume for this channel decreased.
• The TTY recording figure remains in two forms, 1,597 and 249. The definitions of the two values aren’t explained, so we can’t distinguish what was recorded from what was retained.
• ‘SSH key planting’ is 10 times, but the 389-byte public key is 5 sources and 5 times. The source data doesn’t explain why the two figures don’t match. It appears there were cases where an attempt to plant a key didn’t lead to a file being saved, but there’s no basis for that.
• Fingerprint clusters number 39, but only 12 types made it into the record. The list’s source sum of 288 is 63% of 01’s unique sources, and we don’t know how the remaining 169 are distributed. And Telnet, which was 58.1% of that day’s sessions, has no fingerprint at all.
• We cannot distinguish whether the 399-byte private key (43728fbf…) was planted by the attacker or was something on the server that they tried to take. It’s in the download list, but the address field is empty. It has been in the same state since August 19, for the sixteenth day.
• Indicators obtained through separate paths were not linked to that day’s events. Those are the 12 distribution addresses that only surface once decompressed, and 1 Discord webhook address. Neither is connected to any of that day’s downloads. The webhook token string is itself an abusable value, so we do not transcribe it in the body.
• The 6,607 CVEs · 390 CISA KEV entries · 98 confirmed ransomware linkages we hold as background statistics are background context pulled from KISA security advisories. They don’t connect directly to that day’s SSH, Telnet, and protocol negotiation observations, so we did not put them into the factual record.
• We cannot know the intersection of unique sources between the two servers, so we can only speak of the combined unique sources as an upper bound of at most 777. Even within 02, the 320 unique sources and the per-service sum of 302 differ — one source can span multiple services, so they can’t simply be added.
• The C-TAS report is only confirmed as far as having succeeded at the transport layer.
• Finally, a honeypot is a server built to open its doors. A successful login doesn’t mean ‘this password also works on a real production server’; it means ‘this password is being tried.’

And below are things we have no means of confirming in the first place. We do not infer.

• ASN · ISP — we have no relevant database. We cannot confirm which carrier or which hosting range it is.
• Geolocation — likewise absent. And IP geolocation is not by itself a basis for attribution. We do not name any country, company, or individual as that day’s attacker.
• VPN · Tor · cloud status — we have no means of determining it. This is also why we did not interpret the fact that the top 7 sources on 02 are similar in scale.
• VirusTotal — not integrated. Sample classification uses MalwareBazaar tags, and the four items on 02 that day don’t even have those tags. Whether the four are malicious, and their classification, cannot be stated in this post.
• User-Agent — neither observation surface is HTTP. 01 is SSH and Telnet; 02 is SMB, RDP, VNC, MSSQL, LDAP, and ADB. The RDP cookies, SMB dialects, and VNC versions quoted above are not substitutes for a User-Agent but negotiation vocabulary defined by the protocols.
• CVE linkage — SSH and Telnet attacks generally use credentials without referencing a specific vulnerability. 02 is the same, being at the protocol negotiation stage. We cannot link a specific vulnerability to anything observed that day.

INFERRED To sum up, that day went like this. Doorknobs turned more than 45 thousand times across two servers. The door where something was actually left behind was the one that opened 32 times, and of the four things that came out of it, three were files we’d never seen and one was unchanged for the sixth day.

INFERRED Let me return to the story about the walk from the beginning. On August 28 we wrote four fingerprints in our notebook. Five days later, that notebook was right on only one of four lines. Because clothes can be changed.

INFERRED That’s not to say we shouldn’t write down fingerprints. Write them down, but don’t hang your defense on that one thing. That four come as a set, that one of them doesn’t change, and that it came in through a door that opens thirty-two times a day — shapes like these last longer than clothes.

If you have even one machine attached to the internet, there are just two things to try today. Checking whether an admin or developer channel you don’t even remember turning on is open, and opening ~/.ssh/authorized_keys once. The latter takes a few seconds.

The observation day is a single day, September 3, 2026 (UTC). Source IPs were transcribed exactly in the brief’s masked form (130.12.x.x) and not restored. Distribution addresses were written in altered form so they won’t connect (hxxp://, [.]). Credentials were quoted for only the 20 combinations observed from 3 or more distinct IPs, and for the 594 combinations that did not meet that threshold we disclosed only the count and did not publish the values — because a combination appearing from only one or two sources could be a genuinely leaked account. ASN, nationality, and actor attribution are not inferred, as we have no means of confirming them.