Commands Up 18.5× — Only One in 33 Had a Meaning Attached

When you open an apartment mailbox after a few days, a thick stack of paper spills out.

Most of it is flyers. Fried chicken places, moving companies, gyms. Sometimes the same sheet is doubled or tripled up. And mixed in among them are a few things you actually have to open. Maintenance fee statements, registered mail notices, that sort of thing.

So here’s a question. If the paper in your mailbox increased eighteenfold, is that a big deal?

The answer depends on what increased eighteenfold. If it’s only flyers that went up eighteen times, your wrist just gets a little sore. But if somebody slipped a spare key to your home into that stack, the story is completely different.

On September 1, 2026, our server’s mailbox was in exactly that state.

First, let me unpack one unfamiliar term. A honeypot is a bait server deliberately built to look flimsy and put out on the internet. It does no real work. It is a machine left open for the sole purpose of recording, in full, who comes in and what they do. Every number below was recorded there.

What Went Up 18.5× in a Single Day

FACT First, let me put yesterday and the day before side by side. August 31 on the left, September 1 on the right.

FACT Scan the table up and down and the multiples are all over the place. Commands went up 18.53×, but the number of places that came calling went up 1.28×. SSH-side connections are 1.15×, essentially flat, and the entire increase is piled up on Telnet.

Let me unpack two more terms here. SSH and Telnet are both ways of connecting to a distant computer and issuing commands to it. Telnet is the far older method, and the password travels across unencrypted, exactly as typed.

FACT On this day, 81.9% of sessions were Telnet. Both the figure of 2,945 and the 81.9% share are the highest of both across the August 16 – September 1 window we can check. The previous high was not 2,945 on August 26 but 2,639, and the share that day was 48.1%. August 23 was 18.2%, August 30 was 14.6%, and August 31 was 28.6%.

INFERRED Convert it to sessions per source and you get this. 3,595 ÷ 414 = 8.68. Yesterday it was 779 ÷ 324 = 2.40. The number of places that came didn’t increase much; each place came many more times.

FACT And here is what this post has to state before anything else. We cannot explain from the data why Telnet went up 13.2× in a single day. If a large new group had poured in, the source count should have jumped along with it, but it stopped at 1.28×. It’s possible a small number of sources sharply increased their repetition volume, but the raw data has no per-source session counts, so we have no means of checking.

But Only 3% of That 18.5× Had a Meaning Attached

FACT 14,085 commands were executed. Divided across the day, that’s about one every 6 seconds.

FACT What was done after a successful login is counted by classifying the ‘intent’ of the commands. Here is what was classified on this day.

FACT The total of 422 is 3.0% of the 14,085 commands. Only about one command in 33 had a meaning attached. The remaining 13,663 were not classified under any intent.

FACT And even within those 422 there is a skew. The top two items, ‘granting execute permission’ and ‘reconnaissance’, account for 351 — 83.2%.

Two more terms to unpack. ‘Granting execute permission’ is the act of attaching a marker to a downloaded file that says “this is a program that may be run.” On Linux, merely downloading a file doesn’t make it run. The marker has to be attached separately. ‘Reconnaissance’ is the step before that: looking around to see “what kind of machine is this.”

INFERRED So, back to the mailbox. The paper that spilled out went up eighteenfold, but only one sheet in thirty-three was worth opening. And most of even those single sheets were preparatory motions like “had a look around” or “got ready to execute.”

FACT Acts that actually leave something behind are far fewer. Leaving someone else’s key behind happened 13 times, and attempting to erase the record of a visit happened 10 times. Against the full command count, that is 0.09% and 0.07% respectively.

INFERRED So this is how to read this day’s numbers. Transcribing “commands went up 18×” into “attack activity went up 18×” is wrong. We do not know what most of the increase was. The actual intrusion behavior we could count was 13 times and 10 times.

The Day in Chronological Order

Laid out in time order, it looks like this. There are a lot of lines, and you don’t have to read them all. Just look at the five lines with actual timestamps — how closely elapsed time and command counts resemble each other, and how strikingly short one single line is, are the crux of this day.

1. 2026-09-01 (full day)
   FACT Honeypot 01: 3,595 sessions · 414 unique sources · 3,486 login attempts · 14,085 commands · 2,980 TTY recordings. By port: 2223 (Telnet) 2,945 · 2222 (SSH) 641
2. 2026-09-01 (vs. previous day)
   FACT The 01 tallies in the 8/31 brief were 779 sessions · 324 unique IPs · 440 login attempts · 760 commands · 556 on 2222. Today is 4.62× sessions · 7.92× login attempts · 18.53× commands, yet unique sources are only 1.28× and SSH sessions only 1.15×. The increase is concentrated in Telnet (223→2,945, 13.2×)
3. 2026-09-01T00:28:45Z ~ 00:29:52Z
   FACT ATK-D3BC49 (220.132.x.x, Telnet) login succeeded. Over 67 seconds: 31 commands, 3 intent types (file download · download then execute · granting execute permission), 1 download, TTY recorded. Because it is Telnet, the client program fingerprint is an empty string
4. 2026-09-01T00:35:28Z ~ 00:36:29Z
   FACT ATK-20A6CD (147.139.x.x, Telnet) login succeeded. Over 61 seconds: 17 commands, 5 intent types (reconnaissance — system · file download · download then execute · granting execute permission · persistence — planting an SSH key). All five stages of intent were recorded, yet the download count is 0
5. 2026-09-01T02:41:25Z ~ 02:42:32Z
   FACT ATK-80C958 (125.228.x.x, Telnet) login succeeded. 67 seconds · 31 commands · 3 intent types · 1 download — matching ATK-D3BC49 from two hours earlier in command count, intent combination, and duration (67 seconds) alike
6. 2026-09-01T06:39:24Z ~ 06:39:27Z
   FACT ATK-CA5936 (130.12.x.x, SSH) login succeeded. 3.8 seconds · 1 command, yet 5 intent types · 2 downloads (a 399-byte OpenSSH private key 43728fbf… + a 54-byte ASCII 00b6f15c…), fingerprint 16443846…4397 / SSH-2.0-Go. Completeness 19, today's highest
7. 2026-09-01T09:50:08Z ~ 09:51:10Z
   FACT ATK-8120D7 (34.150.x.x, Telnet) login succeeded. 62 seconds · 17 commands · 5 intent types · 0 downloads — matching ATK-20A6CD from nine hours earlier in command count and intent combination
8. 2026-09-01 (intent tally)
   FACT command_intents total 422 — granting execute permission 207 · reconnaissance (system) 144 · download then execute 24 · file download 24 · persistence (planting an SSH key) 13 · removing traces 10. Of 14,085 commands, 3.0% were classified by intent, and 83.2% (351) of those 422 are the first two items
9. 2026-09-01 (samples)
   FACT The stored samples are 7 kinds totaling 1,175 bytes, and that is all (389+306+9+9+9+399+54). ELF executable binaries: 0. Total delivery count is 28
10. 2026-09-01 (fingerprints)
    FACT 9 SSH client fingerprints were recorded. The top one, acaa53e0a7d7ac7d1255103f37901306 (SSH-2.0-OpenSSH_7.4), is 233 sources today · 758 cumulative, which is 56.3% of today's 414 unique IPs on 01. Archived recorded values were 125 sources on 8/25 · 206 on 8/27 · 113 on 8/31
11. 2026-09-01 (honeypot 02)
    FACT 54,779 contacts · 315 unique sources. VNC 52,441 (95.7%) · RDP 2,030 · SMB 225 · MSSQL 50 · LDAP 11, plus 22 ADB sessions and 0 stored samples
12. 2026-09-01 (honeypot 02 · vs. previous day)
    FACT VNC in the 8/31 brief was 53,310 contacts · 46 unique IPs. Today it is 52,441 · 78, so contact volume fell 1.6% while sources rose 69.6% — per-source dropped from 1,159 to 672
13. 2026-09-01 (honeypot 02 · protocol vocabulary)
    FACT In VNC negotiation, the versions the other side proposed were 003.003 52,078 times · 003.008 240 times (99.54% of recorded values are the lower one). 003.008 was 34 on 8/31, so today is 7.06×. All 334 SMB dialect proposals are SMB1-family and 'SMB 2.???' proposals number 0 — there were 2 each on 8/26 and 8/31. The single 'Samba' dialect string is a value not present in the 16 days of archive
14. 2026-09-01 (honeypot 02 · RDP cookies)
    FACT RDP cookies are hello 1,473 · <ip> 426 · (empty) 3 · Test 2 · Administr 2 · zgrab 1. hello is 2.4× the 604 from 8/26

FACT Look again at the five lines with actual timestamps. The four Telnet entries are 67 seconds · 61 seconds · 67 seconds · 62 seconds. And these four split cleanly into two pairs. Two with 31 commands · 3 intent types · 1 download (00:28, 02:41), and two with 17 commands · 5 intent types · 0 downloads (00:35, 09:50). Within each pair, even the elapsed time is nearly identical.

INFERRED This is not work a person sits down and does. The probability that different sources, hours apart, type the identical number of commands in the identical order is essentially nil. We read this as the same pre-written script being replayed. That said, all four are Telnet, so the client program fingerprint itself does not exist. For this day’s Telnet sessions there is no way to confirm “it was the same tool” by fingerprint.

FACT And there is one strikingly short line. From 06:39:24 to 06:39:27 — 3.8 seconds. Exactly one command. Yet in this single entry, 5 intent types were recorded and 2 files changed hands. It is this day’s top completeness score (19 points).

INFERRED In terms of the flyer stack: the thinnest envelope was the heaviest. The one 3.8-second entry left more behind than the four 62-second ones.

Are You Using This Password?

FACT Login attempts on this day: 3,486. Divided across the full day, someone tried an ID and a password about once every 25 seconds. Yesterday it was once every 3 minutes 16 seconds.

FACT Below are 20 of them, narrowed down to only combinations observed from 3 or more distinct IPs. The count column is filled in only where the brief recorded a count.

FACT The \x00 in the second-to-last row is the notation used to write down an invisible character. It is not a form a person can type by hand.

INFERRED First and second place catch the eye. root/xc3511 218 times, root/vizxv 208 times. Both belong to the family of default passwords shipped from the factory on specific manufacturers’ devices. These are not strings a person thinks up and types. We read them as a program working through a list in order. The top three combinations alone add up to 620 attempts.

FACT And the ID/password combinations observed on this day totaled 337. What appears in the table above is 20. For the remaining 317, we counted them and did not publish the values.

Back to the mailbox. When a letter with someone else’s name on it ends up in our mailbox, we don’t open it. We just count how many there were and hand them to the building office.

INFERRED Those 317 are exactly that. A combination that appeared from only one or two sources may be a real person’s account that actually leaked from somewhere. Transcribing it here would inflict a second harm on that person. So we only count them. For reference, 317 is 2.2× the 142 from August 29.

INFERRED But hidden in here is this day’s strangest ratio. The 20 we published are 5.9% by combination count, yet by attempt count they are 1,916 — 55.0% of all 3,486. Some twenty combinations produce more than half the attempts. It means a dictionary of default values belonging to nobody was half the force knocking on this server.

FACT It’s also worth noting that two different shapes are mixed into the table. root/xc3511 was thrown 218 times by 4 sources. That’s 54.5 per source. Conversely, 345gs5662d34/345gs5662d34 was 9 sources, 9 attempts — exactly once per source. I’ll come back to this difference in ‘So What Should You Do’ below.

What Was Left Behind Is 1,175 Bytes, and That’s All

FACT The files that actually remained on the server this day are 7 kinds, 1,175 bytes total. About the volume of six or seven lines of a short text message. Executable binaries — that is, actual malicious program files that run — number 0.

Here are the values to write down. Click a value and it copies — these exist not to be read but to be put into a blocklist. The addresses have been deliberately broken (hxxp://, [.]). Copying and pasting them as-is will not connect.

FACT Of the eight lines, only one has an address on it. All the rest are ‘source address not recorded’. Which means only one address is left to put on a blocklist.

Two things to unpack here.

The fingerprint (sha256) is a 64-character value computed over the entire file. Change a single character inside the file and the value changes completely. So this value is what determines whether two files are the same or different.

A public key works like this. A Linux server has a file called authorized_keys (the list of permitted keys). Write one public key line into it and whoever holds its counterpart comes straight in without ever being asked for a password. Put simply, it’s slipping a spare key that opens the door without a password into the mailbox. And the important part: changing the password leaves that key exactly where it is.

INFERRED The 389-byte item on the top line is that key. For the defending side it’s a nuisance of an object. There is no source address, so there is no address to block. Even if the server blocks all outbound communication, this isn’t stopped. Because it’s something that happens inside the server, in the moment the door opens, and ends there.

Mapped to the International Classification

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

• T1110.001Brute Force: Password Guessing — 3,486 login attempts · 337 credential combinations (20 published / 317 unpublished)INFERRED
• T1078.001Valid Accounts: Default Accounts — admin/admin 19 IPs · 160 times, root/123456 7 IPs · 117 times, and other factory-default-family entriesINFERRED
• T1082System Information Discovery — command_intents 'reconnaissance — system' 144 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 24 times; a 306-byte shell script delivered from hxxp://185[.]93[.]89[.]72/wget to 7 aliasesINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'granting execute permission' 207 times, today's most frequent intentINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — planting an SSH key' 13 times; a 389-byte public key observed at 10 aliasesINFERRED
• T1070Indicator Removal — 'removing traces' 10 times. That is 0.07% against 14,085 commandsINFERRED
• T1046Network Service Discovery — 54,779 contacts across 5 services (VNC · RDP · SMB · MSSQL · LDAP) on honeypot 02. Only contact and protocol negotiation were observedINFERRED
• T1021.005Remote Services: VNC — 52,441 contacts, but as a low-interaction sensor neither authentication success nor session establishment was observed. Version-negotiation proposal values are all there isINFERRED

FACT The largest number among the nine lines is on the top line, 3,486 login attempts. And the smallest is on the sixth line, 13 key plantings. The gap this post has been talking about from the start shows up here too, unchanged.

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

Yesterday, the Whole Day

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

FACT One value in the table doesn’t line up. The per-port total of 3,586 (2,945 + 641) is 9 less than the 3,595 sessions. It appears to mean there are sessions with no port recorded, but the reason is not in the raw data.

FACT I’ll also carry over the numbers from the second server standing next to it (sensor 02). This one is low-interaction, so login successes, commands, and credentials do not exist in the first place. All it counts is ‘which door was knocked on, how many times.’

FACT Overall that’s 54,779 contacts and 315 unique sources. Divided across the day, something knocked on this server about once every 1.6 seconds. The six rows above sum exactly to the total.

FACT Something changed on the VNC side compared with yesterday. Yesterday, 46 sources produced 53,310 contacts (1,159 per source). This day, 78 sources produced 52,441 (672 per source). The amount of knocking fell 1.6% while the number of places knocking rose 69.6%.

INFERRED It reads as the same volume being split across more places. That said, the raw data doesn’t link sources to services, so we say nothing beyond that.

FACT The protocols also told us something. Protocol vocabulary means the value the connecting side proposes up front, saying “I will speak in this version.”

• In VNC, the versions proposed by the other side were 003.003 52,078 times and 003.008 240 times. 99.54% of recorded values are the lower one. That said, 003.008 went up 7.06× from yesterday’s 34.
• All 334 SMB dialect proposals are SMB1-family, and SMB 2.??? proposals number 0. There were 2 each on August 26 and 31. The single Samba dialect string is a value not present in the 16 days of records.
• RDP connection cookies were hello 1,473 times, <ip> 426 times, empty 3 times, Test 2 times, Administr 2 times, zgrab 1 time. hello went up 2.4× from 604 on August 26.

INFERRED hello and <ip> read as placeholders auto-filled by a tool rather than usernames a person typed. That said, which tool cannot be pinned down from these values.

233 Sources Share a Fingerprint, but They Are Not One Group

FACT Connections arriving over SSH open with a slightly different greeting depending on the program. The value summarizing that greeting is called the client fingerprint. It indicates which program was used to connect.

FACT Nine fingerprints made the list on this day. The top one is acaa53e0a7d7ac7d1255103f37901306 (SSH-2.0-OpenSSH_7.4), at 233 sources this day, 758 cumulative. That is 56.3% of this day’s 414 total sources on 01. The recorded values were 125 sources on August 25, 206 on August 27, and 113 on August 31.

INFERRED Looking at the number alone, you want to write “233 sources are one group.” We don’t write that. This value is the string of the default OpenSSH 7.4 client that simply ships with widely used Linux distributions. It is normal for people with no relation to each other to share the same value.

FACT So what can be said stops at “233 sources use the same tool.” “233 sources are one organization” does not hold up with this data. For reference, this fingerprint carries no ‘left a sample behind’ marker on this day.

So What Should You Do

INFERRED Here are the six ‘had this control been absent’ items the brief laid out, ordered by how strongly this day’s data backs each one.

1. Don’t leave management ports open straight onto the internet — this is number one for the day. In a single day, 414 sources contacted a server that was never advertised anywhere, and on the server next to it, RDP drew 161 sources · VNC 78 · SMB 43 · MSSQL 14 · LDAP 7. Combining the two servers gives at most 729 sources (an upper bound, since overlap is unknown). From the VNC port alone, 52,441 contacts came in — a daily average of 0.6 per second. Move the remote-access entrance behind a VPN or an allowlisted IP and this entire volume of attempts disappears before it ever reaches the authentication stage. Exposure itself determines attempt volume.

2. Eliminate default accounts and common passwords — all 5 completed sessions this day succeeded at login. And the 20 entries in the table above alone account for 1,916 attempts, 55.0% of the total. Every one is either a factory default or a four-digit number. Look at how long things took after success. 17 to 31 commands within 62–67 seconds, and one case in 3.8 seconds. There is no time for a person to notice.

3. Replace password-opened doors with key-opened doors — 81.9% of this day’s sessions were Telnet. Telnet has no key-authentication option at all, and credentials travel unencrypted. So the thing to do on the Telnet side is not ‘let’s use keys’ but ‘let’s turn that service off.’ And there’s a reverse direction too. Once an attacker gets in with a password and plants a public key they own, access is maintained afterward even if you change the password. The number of sources that left that public key on this day is 10.

4. Restrict outbound connections from the server — ‘file download’ 24 times and ‘download then execute’ 24 times are exactly the same number. It means what was downloaded led to the execution stage without exception. Had outbound communication been blocked by default with only necessary destinations allowed, it would have been cut off at the download stage. That said, on this day only the 306-byte loader script was recovered, and not one of the next-stage files that loader calls was captured. We saw stage 1 and did not see stage 2.

5. Don’t rely on ‘lock after N failures’ alone — I mentioned the table above has two different shapes in it. root/xc3511 was 4 sources, 218 attempts, 54.5 per source. This repetition type definitely trips count-based blocking. But 345gs5662d34 was 9 sources at exactly one attempt each, and root/3245gs5662d34 was 5 sources at exactly one each. This distributed type never reaches the count threshold at all. So this item is not ‘throw it away’ but ‘this alone isn’t enough.’ You must not read a growing block log as having become that much safer.

6. Keep logs outside the server as well — intent to erase traces was observed 10 times this day. At 0.07% of all commands it’s a small number, and far below August 25’s 70. Still, it was observed. The reason we can count these 10 is that logs accumulate separately, outside the honeypot. On a production server, logs must be shipped out to another system immediately to see the same thing.

FACT And a caveat on item 4. Planting an SSH key requires no outbound connection. Block all outbound traffic and this still isn’t stopped. If you run a server, open up ~/.ssh/authorized_keys once and take a look. If there’s a line you don’t remember putting there, that’s someone else’s key. Changing your password does not remove it.

It Has Happened Before

INFERRED The Mirai botnet (2016). A case of mass-infecting IoT devices using Telnet and a dictionary of device factory-default accounts. It matches this day’s observations in form along two axes. 81.9% of sessions were Telnet, and the two most-attempted passwords (xc3511 218 times, vizxv 208 times) are of the factory-default family for specific manufacturers’ devices. The behavioral sequence of the completed sessions — reconnaissance → download → granting execute permission → persistence — follows the same mold. That said, we are not attributing this day’s observations to Mirai. It is a comparison noting that the approach is of the same family. We do not cite figures such as infected device counts or damage amounts. (Basis: published source code, US-CERT/CISA alerts in the United States, public incident analysis reports from several vendors)

INFERRED WannaCry (2017). A case that spread using an SMBv1 vulnerability (MS17-010 / CVE-2017-0144). We use it as background context only. The 334 SMB dialect proposals on honeypot 02 this day were all SMB1-family (NT LM 0.12, LANMAN1.0, LM1.2X002, PC NETWORK PROGRAM 1.0, Windows for Workgroups 3.1, and so on) and SMB 2.??? proposals numbered 0. It means the very vocabulary used to speak is pitched at the old generation. The fact that SMBv1 was the stage for a large-scale incident is verifiable from public materials, but this day’s observations go only as far as the dialect negotiation stage, and no exploitation attempt was confirmed. (Basis: Microsoft security bulletin MS17-010, the CVE, public incident analysis reports)

What We Don’t Know

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

• [Core] We cannot explain from the data why Telnet jumped 13.2× in a single day. Unique sources rose only 1.28× (324→414), so it is not explained by ‘a large number of new attackers came in.’ It’s possible a small number of sources sharply increased their repetition volume, but the raw data has no per-source session counts for 01, so we cannot check.
• [Core] Of 14,085 commands, only 422 (3.0%) were classified by intent. Whether the remaining 13,663 failed to match the classification rules, or are intent-free repetition, typos, or prompt noise, the raw data does not say. You must not read ‘commands went up 18×’ as ‘attack activity went up 18×’ — actual persistence attempts were 13, and trace removal 10.
• The TTY recording count is written as two different values, 2,980 and 216. There is no explanation of the relationship between the two (whether it’s created vs. retained, or a different basis).
• The per-port total of 3,586 (2,945 + 641) is 9 less than the 3,595 sessions. It appears to mean there are sessions with no port recorded, but no reason is given.
• The 9-byte sample 4af5a5c9… has a single source, yet the count column reads 7. For other entries the two values match. We cannot determine whether one source left it 7 times or this is a tallying error, so the body text uses only the source count and does not interpret the count.
• ATK-20A6CD and ATK-8120D7 both have ‘file download’ and ‘download then execute’ in their intents, yet the download count is 0. Whether a download was attempted but not stored, or the intent classification and the storage tally use different criteria, is not distinguished.
• We cannot distinguish whether the 399-byte OpenSSH private key (43728fbf…) was planted or was something already on the server that someone tried to take away. It’s on the download list, but the address column is empty. This unresolved item, left by the August 19 brief, remains unchanged on this day, the seventh observation.
• The fact that the 389-byte public key’s hash is the same means ‘the same file,’ not ‘the same operator.’ Whether the 10 aliases that left this file on this day are one entity, or different entities using the same tool, cannot be determined. Nor is it in the data who — or how many people — hold the corresponding private key.
• The 233 sources of the top fingerprint acaa53e0… (SSH-2.0-OpenSSH_7.4) must not be read as a single set. Because it is the default client string of a widely used distribution, it is normal for many unrelated parties to share the same value. Also, the total number of fingerprint clusters is 40 while only 9 appear in the list, so the size of the remaining 31 clusters is unknown.
• On honeypot 02, there are 22 ADB sessions but no associated objects, an empty download list, and 0 samples obtained. What was delivered in those 22 ADB contacts (or whether there was any delivery at all) cannot be determined. We do not write ‘there was no delivery.’
• That VNC negotiation version 003.003 is 99.54% is the distribution of ‘the value the other side proposed.’ This distribution may be determined by what our honeypot presents first, so we do not draw conclusions about the nature of the other side’s tooling from this value. Nor can we distinguish whether 003.008 going from 34 to 240 means the tooling changed or our own responses changed.
• There are two points on honeypot 02 where values don’t line up, and the difference in both is exactly 123 (VNC 52,441 vs. version-proposal total 52,318; RDP 2,030 vs. cookie total 1,907). We do not interpret the fact that it is the same number and record it only as a fact. The reason is not in the raw data.
• 02 was not a collection failure this day. However, we cannot know the intersection of unique IPs across the two sensors, so the combined unique source count can only be stated as an upper bound of 729. The sum of per-service unique IPs (78+161+43+14+7=303) is less than the overall 315, so we also cannot work backwards to tell whether one source swept several services together. This same constraint has held for 7 consecutive days since August 26.
• Separately, we do not know which of this day’s sessions or samples the separately obtained Discord webhook address connects to. It does not appear in the address column of any download on this day, so it appears to be an indicator obtained through a separate route, and we did not narrate it in connection with this day’s events. The webhook token string is itself an abusable value, so it is not transcribed into the body. Several briefs since August 20 have excluded it for the same reason.
• The 12 distribution indicators that only surface when unpacked (the 31[.]77[.]227[.]121/bins/* family) carry no date notation, and downloads from this path on this day number 0. The only download host observed this day is a different one (185[.]93[.]89[.]72). With no means of confirming whether it is the same campaign, we left it as background material only.
• The background statistics we hold — 6,607 CVEs · 390 CISA KEV entries · 98 confirmed ransomware cases — are background context based on KISA security advisories. They are not connected to this day’s honeypot observations, and no CVE reference was observed in this day’s SSH/Telnet attacks.
• C-TAS reporting is confirmed only as far as succeeding at the transport layer. Whether it was actually ingested on KISA’s side requires separate confirmation, and this day’s report count and processing status are not in the data.
• Aliases (ATK-XXXXXX) are merely markers pointing to the same masked source across posts; they are not identities.
• Finally, a honeypot is a server built to open the door for you. A successful login does not mean ‘these credentials also work on a real production server’; it means ‘these credentials are being tried.’

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

• ASN · ISP — we have no such database. We cannot confirm which carrier or which hosting range it was.
• Geolocation — likewise absent. And IP geolocation is not grounds for attribution to begin with. We name no country, company, or individual as this day’s attacker. We infer nothing from what lies behind the masking.
• VPN · Tor · cloud status — we have no means of determining this.
• VirusTotal — not integrated. We cannot attach malware-family names to the 7 samples obtained this day. For sample classification we use MalwareBazaar tags.
• User-Agent — neither observation surface is HTTP. 01 is SSH/Telnet; 02 is SMB/RDP/VNC/MSSQL/LDAP/ADB. The RDP cookies, SMB dialects, and VNC versions cited above are not substitutes for a User-Agent but negotiation vocabulary fixed by the protocol.
• CVE linkage — SSH and Telnet attacks mostly use credentials without referencing any specific vulnerability. The same goes for 02, which is at the protocol negotiation stage.

INFERRED To sum up, this is the day. 3,595 sessions, 3,486 login attempts, 14,085 commands. Against yesterday, commands are 18.53×. Yet within that, the ones with a meaning attached numbered 422 — one in 33. And the acts that actually left something behind were 13 keys and 10 trace-erasures.

Back to the mailbox. On a day when the paper that spilled out went up eighteenfold, what we should do is not weigh the paper. It is to check whether a spare key is tucked inside. On this day it was tucked in thirteen times. That key file has been coming through with the same hash for seventeen days since August 16, and only the sources delivering it change every day.

So what this day’s data points to is not ‘write down the addresses that swarmed in yesterday.’ That list goes stale in a day. If you have even one server, there are just two things to try today. Check whether your remote-access entrance is sitting open straight onto the internet, and open up ~/.ssh/authorized_keys once. The latter takes a few seconds.

The observation period is the single day of September 1, 2026 (UTC). Source IPs are carried over exactly in the brief’s masked form (220.132.x.x, 147.139.x.x, 125.228.x.x, 130.12.x.x, 34.150.x.x) and were not restored. Distribution addresses are written in altered form so they will not connect (hxxp://, [.]). Credentials cited are only the 20 combinations observed from 3 or more distinct IPs; for the 317 combinations that did not meet that bar, only the count is disclosed and the values are not published — because a combination appearing from only one or two sources may be a genuinely leaked account. ASN, nationality, and actor attribution are not inferred, as we have no means of confirming them.