Most Sources Ever, One-Sixth the Activity — Exactly One Thing Went Up

The door locks on homes these days have more than one way to open. A PIN works, tapping a card works, and a fingerprint works too.

There’s one thing people tend to miss here. You can register multiple cards, and changing the PIN does not stop a registered card from opening the door. The PIN is what you punch in at the door; the card list is what’s stored inside the lock. They’re separate things.

So when you move into a new place, there are actually two things to do: change the PIN, and clear the list of registered cards. Most people only do the first. The second is buried a few menus deep, and nothing bad happens right away if you skip it.

The records left in our honeypot on August 27, 2026 are exactly that second story.

First, let me unpack one unfamiliar term. A honeypot is a bait server, deliberately made flimsy and put out on the internet. It does no real work. It’s a machine left open purely to record, in full, who comes in and what they do. Every number below was recorded there.

Three Numbers Moved in Opposite Directions

FACT Let’s start with what dropped. On August 26, 14,344 commands were executed on this server. On August 27, it was 2,313 — about one-sixth in a single day (-83.9%). Sessions also fell by more than half, from 5,488 to 2,605 (-52.5%).

FACT But the number of source locations went the other way. Distinct sources came to 442. That’s 361 on 8/25 → 373 on 8/26 → 442 on 8/27, a new high for the third consecutive day. Across the 12 days we hold in the archive, the lowest was 131 on 8/16. This is 3.4 times that.

FACT Divide the two numbers and you get this. Commands per session were 2.61 on 8/26; on 8/27 they were 0.89. In effect, they opened the door, came in, and left without saying an average of one word.

INFERRED It was a day of broad sweeping without going deep. More sources reached the door than on any of the 12 days, yet the traces of anything done inside were among the fewest.

FACT In the middle of all this, exactly one behavior set a high. “Persistence — planting an SSH key,” 36 times, from 26 different sources that left a key behind. The 12-day trend for this value: 10 sources on 8/16 → 16 on 8/18 → 6 on 8/23 → 19 on 8/24 → 21 on 8/25 → 12 on 8/26 → 26 on 8/27. It’s the largest value in the observed window.

Let me unpack planting an SSH key right here. Linux servers have a file called authorized_keys (the list of permitted keys). Write one public key line into it, and whoever holds the matching key simply walks in without being asked for a password. It’s the same as registering one card with a door lock. And just like a door lock, changing every password still leaves the registered card working.

The Day in Chronological Order

Laid out in order, it goes like this. The table is long, but pay attention to the timestamps on the third and fourth rows. They overlap by seconds, not minutes.

1. 2026-08-27T00:57:17Z ~ 00:58:25Z (67.3s)
   FACT ATK-2A42D2(125.229.x.x), successful telnet login. 31 commands, 1 download. 3 intent types — file download, granting execute permission, execute after download. completeness 16. TTY recorded (contents not included). Because it's telnet, fingerprint and client are empty strings. This alias appears in the delivered_by list for a 306-byte POSIX shell script (a6296a79…, hxxp://185[.]93[.]89[.]72/wget)
2. 2026-08-27T07:29:41Z ~ 07:29:42Z (1.3s)
   FACT ATK-10149C(45.198.x.x), successful telnet login. 3 commands and 1 download in 1.35 seconds. 3 intent types, completeness 14 — the shortest and lowest of the day's top 5. This alias is the sole source that fetched the 1,608-byte bash script (99308ec8…) from hxxp://5[.]182[.]210[.]174/ok
3. 2026-08-27T08:37:07Z ~ 08:38:07Z (60.8s)
   FACT ATK-6817F1(103.78.x.x), successful telnet login. 17 commands, 0 downloads. 5 intent types — reconnaissance → file download → execute after download → granting execute permission → persistence (planting an SSH key). completeness 17, the day's highest value
4. 2026-08-27T08:37:59Z ~ 08:39:02Z (63.1s)
   FACT ATK-EE174F(13.143.x.x), successful telnet login. Started 52 seconds after the session above while it was still in progress, overlapping it for about 8.3 seconds. Command count 17, 5 intent types, and completeness 17 are all identical to the preceding session. Different source, same progression. Both sessions had 0 downloads
5. 2026-08-27T09:58:13Z ~ 09:59:21Z (67.4s)
   FACT ATK-DD3BCB(114.35.x.x), successful telnet login. With 31 commands, 1 download, 3 intent types, and completeness 16, it is effectively identical to ATK-2A42D2 at 00:57 right down to the elapsed time (67.4s vs 67.3s), and both appear in the delivered_by list for the same 306-byte script (a6296a79…)
6. 2026-08-27 daily totals
   FACT A 389-byte OpenSSH RSA public key (a8460f44…) was observed 34 times from 26 different sources. No URL was recorded. The same day, "persistence — planting an SSH key" in command_intents was 36, a difference of 2 from the 34 sample events — unlike 8/25 (69 intents vs 21 events, a gap of more than 3x), it nearly matches
7. 2026-08-27 daily totals
   FACT The 306-byte POSIX shell script at hxxp://185[.]93[.]89[.]72/wget came through with the same hash (a6296a79…) for the 11th consecutive day since 8/17. Sources were 2, with 2 occurrences — the lowest in the observed window, matching 8/25 (8/22's 15 sources is the maximum). By contrast, hxxp://5[.]182[.]210[.]174/ok again matched at exactly 1,608 bytes in size while the hash was new again
8. 2026-08-27 daily totals
   FACT The day's 4 downloads were 1 SSH public key, 1 POSIX shell script, 1 bash script, and 1 nine-byte ASCII text file (4af5a5c9…, ATK-BECAD3, a single source, 2 occurrences). ELF executable binaries: 0
9. 2026-08-27 daily totals (sensor 02)
   FACT Honeypot 02 contacts 30,804 / unique sources 266. VNC 29,111 (38 unique) · RDP 1,425 (116 unique) · SMB 162 (46 unique) · LDAP 58 (38 unique) · MSSQL 22 (19 unique), ADB sessions 26. The 5 services sum to 30,778 + ADB 26 = 30,804, so the total checks out. Down 27.5% from yesterday's 42,493

FACT What the table shows is two pairs. The two 08:37 entries are from different sources, yet their command count, intent types, and completeness score do not differ by a hair. The 00:57 and 09:58 entries likewise both have 31 commands and 1 download, with elapsed times of 67.3 and 67.4 seconds — effectively the same.

INFERRED We read this as the same tool having run twice. That is the full extent of what can be said. Our data holds no raw command text, so we cannot say it was the same person or the same organization.

The Card That Got Planted Was a Single 389-Byte File

FACT What the 26 sources left behind was not 26 different cards. It was one and the same file. A 389-byte OpenSSH RSA public key, fingerprint (sha256) a8460f44….

Let me unpack fingerprint here too. It’s a 64-character value computed over the entire file. Change a single character inside the file and the value changes completely. That’s why this value is used to judge whether two files are the same or different.

FACT 389 bytes is about the size of a two-line text message. And this fingerprint has been identical for 12 consecutive days, from 8/16 through 8/27.

INFERRED That means the same card has been getting registered for 12 days straight. If on any one of those days this card actually made it onto a real server, that server still opens with the same card today. It doesn’t matter how many times the password has been changed in the meantime.

FACT Two numbers nearly line up. The “key planting” intent read out of the commands was 36; the events where that file was actually stored numbered 34. A difference of 2. On 8/25, those two values were 69 and 21 — a gap of more than three times. On this day they nearly met.

INFERRED That said, we cannot claim all 36 instances planted this file. The data does not connect the two numbers. We’ll return to this in “What We Don’t Know” at the end.

FACT Also, of the day’s 4 downloads, executable binaries (ELF) numbered 0. ELF is the program file format that runs directly on Linux. On 8/26, four variants came down, one per CPU type; on this day, not one.

INFERRED It was a day when nothing that antivirus would flag came down at all. Yet the behavior of building a way back in was the highest of the 12 days. “No malicious files were caught” and “nothing happened” are not the same statement.

The Largest Group of Visitors Left Nothing Behind

FACT SSH connections use slightly different greetings depending on the program. The value summarizing that greeting is called the client fingerprint. It indicates which program was used to connect.

FACT On this day, the top 16 fingerprints among the 442 sources cover 267 of them (60.4%). One of them alone (acaa53e0…, SSH-2.0-OpenSSH_7.4) accounts for 206 sources, 46.6% of all sources. Nearly half were using the same program.

FACT Yet this largest group left no files at all. Only two fingerprints left samples (both SSH-2.0-Go), 2 sources each, 4 sources combined. That’s 0.9% of the day’s sources.

INFERRED The day’s inversion — “most sources ever, activity collapsed” — shows up intact at the fingerprint level. But a line has to be drawn here. This is a fingerprint of a build, not of a person. People with no connection to each other, running the default OpenSSH shipped in the same distribution, will have the same value. We can only say it’s the same tool; we cannot say it’s the same organization.

Which Passwords Were Tried

FACT There were 2,298 login attempts on this day. Spread evenly across the full day, that’s someone trying the door handle about once every 38 seconds.

FACT Below are 20 combinations, filtered to only those observed from 3 or more distinct IPs. Combinations seen from a single source could be genuine leaked credentials, so we do not publish their values.

FACT Beyond these 20, there are 757 more combinations seen from a single source only. We record only the count, not the values.

INFERRED The top row of the table sums up the day’s picture. 345gs5662d34 is a string that looks entirely meaningless. The username and password are identical. And 26 different sources typed it exactly the same way, as if by prior arrangement. We read that as meaning it isn’t a value people thought up one at a time, but a list circulating somewhere being read off verbatim.

The Four Files Left Behind

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

INFERRED Here the two addresses part ways in character. The file at 185[.]93[.]89[.]72 has had the same fingerprint for 11 days straight. Write down one fingerprint and it stays useful for over ten days. Conversely, the file at 5[.]182[.]210[.]174 is exactly 1,608 bytes every time while the fingerprint is always new. For that one, writing down the fingerprint means missing it the next day. They go into the same list, but the length of time they stay useful differs.

Mapped to the International Classification

The techniques attackers use carry numbers that the whole world shares. The list is called MITRE ATT&CK. Below, click an ID to go to the original description — it’s there so you can check for yourself rather than take our word for it.

• T1110Brute Force — 2,298 login_attempts, 20 quotable combinations + 757 single-source combinationsINFERRED
• T1078.001Valid Accounts: Default Accounts — admin/admin (14 sources), root/root (7 sources), user/user (4 sources) and others observed, and the top 5 sessions all have login_success=trueINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — "persistence — planting an SSH key" 36 times, a 389-byte RSA public key from 26 sources, 34 occurrences. This is the central evidence of the day's briefINFERRED
• T1105Ingress Tool Transfer — "file download" 10 times, "execute after download" 10 times, 2 distribution points with external URLs recordedINFERRED
• T1222.002Linux File and Directory Permissions Modification — "granting execute permission" 67 timesINFERRED
• T1070Indicator Removal — "trace deletion" 36 times (about half of 8/25's 70)INFERRED
• T1082System Information Discovery — "reconnaissance — system" 1,811 times, 78.3% of the day's commandsINFERRED
• T1595Active Scanning — sensor 02's 30,804 contacts span 5 services, and no shell or successful login exists. This is a pre-compromise stage mappingINFERRED

FACT The largest number among the eight rows is the second from the bottom: reconnaissance, 1,811 times. That’s 78.3% of the day’s total commands. Spread across the day, a command asking “what kind of machine is this?” came in about once every 48 seconds.

INFERRED Read the whole table by its badges and all eight rows are “INFERRED.” What we saw is the intent classification and counts of the commands, not a purpose the attackers stated themselves.

The Full Day

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

FACT There’s one more inversion in the access channels. By session count, SSH dominates with 2,419. Yet the top 5 sessions that carried on to actual activity after a successful login were, without exception, telnet. Telnet is a very old remote access method. It’s a channel left open so someone across the internet can type directly into that machine’s command prompt, and the password travels unencrypted, in the clear.

FACT Here are the numbers from the other server standing beside it (sensor 02). This one is low-interaction, so successful logins, commands, and credentials do not exist in the first place. All it counts is “how many times did someone knock” and “what did the protocol propose.”

INFERRED Same server, and the picture at the two doors is the exact opposite. On the VNC side, a few sources stayed attached all day; on the RDP side, many sources passed through once each. That said, what was observed here goes only as far as the protocol negotiation stage. No authentication bypass or vulnerability exploitation was confirmed.

So What Should You Do

INFERRED Of the six “if this control had been absent” items the brief lays out, here they are in the order this day’s data supports most strongly.

1. Look at the list of registered cards — this is the day’s centerpiece. Planting an attacker’s public key after a successful login occurred 36 times, from 26 sources. If you run a server, open ~/.ssh/authorized_keys once and look. If there’s a line you don’t remember putting there, that’s someone else’s card. Changing the password does not erase it.

2. Turn off password login and leave only key login — the 20 combinations in the table above are ones that 3 or more distinct IPs actually tried. If even one of them is live, it gets opened that same day.

3. Don’t leave management ports open straight to the internet — you become a scan target even without a vulnerability. 442 sources attached themselves for the sole reason that it was open.

4. Block a source that keeps knocking — on sensor 02, 29,111 VNC contacts came from 38 sources. Blocking just those 38 removes 94.5% of the day’s contacts. It also means there are fewer things to block than you’d think.

5. Restrict outbound connections from the server — 10 file downloads and 10 execute-after-download instances get cut off here. That said, the download volume itself was small on this day. FACT And the day’s main persistence path, SSH key planting, requires no outbound connection. It is not stopped by outbound blocking.

6. Keep logs off the server as well — intent to erase traces was observed 36 times. Had the logs lived only on the server, some of those would have succeeded. The reason we can write the timeline above is that the logs remain outside the server.

It’s Happened Before

INFERRED The Mirai family (derivatives have persisted ever since the source was published in 2016). The fact that the top 5 sessions by completeness were all telnet and all logged in successfully, and that the quotable credentials center on defaults like admin/admin, root/root, and user/user, touches on the published telnet default-credential dictionary spread pattern. That said, there was no per-CPU-type ELF distribution on this day (0 ELF among 4 downloads). We cite this as technique context only, not as family attribution. (Basis: US CISA alert TA16-288A, plus the published source code and numerous vendor analysis reports)

INFERRED TeamTNT Linux/cloud campaigns (2020–, tracked continuously by numerous vendors). The combination is: immediately after a successful login, plant the attacker’s public key in authorized_keys to secure a re-entry path that survives credential changes. This day’s 36 key-planting instances and the 26 sources of an identical-hash public key are that shape. The 8/25 post cited the same case, but there the basis was “simultaneous peaks of 69 intents and 70 trace deletions.” Here the basis runs the opposite direction: on a day when overall activity collapsed, only the key-planting source count peaked. Our data holds no raw command text, so there is no basis to say it was the same tool or the same actor. (Basis: public reports from multiple security firms and the MITRE ATT&CK T1098.004 documentation)

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.

• The “persistence — planting an SSH key” intent was 36; download events for the 389-byte public key were 34. A difference of 2 is far closer than 8/25 (69 vs 21), but the data does not connect the intent count to the sample count. We cannot confirm whether all 36 instances planted this key. The title of this post hangs on this number.
• Only 10 of the 26 delivery sources for the public key a8460f44… are listed. The 08:37 twin sessions (ATK-6817F1 and ATK-EE174F) have “key planting” among their intents but are not among the 10 listed, so we cannot confirm from the data whether those two sessions planted that key.
• Those two twin sessions have “file download” and “execute after download” among their intents, yet the download count is 0. We cannot distinguish whether the download failed or succeeded but wasn’t stored.
• Two session pairs emerged with completely identical command counts, elapsed times, intents, and completeness (the 31-command/~67-second pair and the 17-command/~61–63-second pair). It looks like the result of the same tool running, but there is no raw command text to confirm it, and there is even less basis to say it was the same person or the same organization.
• The TTY recording count is 1,910, but only 188 were actually retained. We don’t know whether the 10x difference is due to retention policy or a difference in counting basis.
• Among the reference indicators, one Discord webhook address is listed in defanged form, but there is no date saying whether this value was observed on this day or is cumulative. It is not connected to any of the day’s 4 downloads, and there is no related indicator in the 8/16–8/26 records either. It may be new, but we could not conclude “it was observed on this day,” so we did not use it as a fact in the body.
• For the same reason, the 12 instances of 31[.]77[.]227[.]121/bins/* carry no date marking. The same path on the same host already appears in the 8/16 records, making it hard to treat as new, and since ELF count was 0 on this day, we did not connect these 12 to this day’s observations.
• The cumulative number of distinct hashes for hxxp://5[.]182[.]210[.]174/ok is a sum across our archive, so deduplication is not guaranteed. We do not use it as an exact total. All that is certain is that since 8/17 the size has been exactly 1,608 bytes every time while the hash keeps changing, and since we do not include file contents, we cannot say what changed.
• The premise that the alias ATK-10149C points to the same source as in the 8/22–8/24 records follows from our aliasing rules. It means only the same source, not the same person or organization.
• Sensor 02 shows 26 ADB sessions, but the ADB detail present on 8/26 is absent from this day’s data. It is not explicitly marked as a collection failure either, so we cannot write “there were no ADB attacks that day”; we record only the fact that this channel carried less information than yesterday.
• For sensor 02, we cannot determine “whether a single source swept multiple services.” There is no per-source service list, and the sum of unique IPs per service (38+116+46+38+19=257) is smaller than the 266 total unique IPs, so the numbers hold even with no overlap at all.
• Of sensor 01’s 442 sources, the top 16 client fingerprints cover 267. The distribution of the remaining 175 is unknown, and telnet sessions have no fingerprint at all. The total cluster count is 45, but only 16 are carried in the data.
• The 708 unique sources across both sensors combined is an upper bound that arises because the intersection is unknown. How many sources actually touched both sensors is unknown.

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

• ASN/ISP — we have no such database. We cannot say which provider the distribution points 185[.]93[.]89[.]72 and 5[.]182[.]210[.]174 sit with, or whether sensor 02’s top sources are on the same network as each other.
• Geolocation — likewise absent. And IP geolocation is not a basis for attribution to begin with. We name no country, company, or individual as this day’s attacker.
• VPN/Tor/cloud status — we have no means of determining it. Among the 442 and the 266 sources, we cannot tell which are waypoints and which are origins.
• VirusTotal — not integrated. We cannot attach external multi-engine verdicts to this day’s 4 samples.
• User-Agent — neither observation surface is HTTP. 01 is SSH and telnet; 02 is SMB, RDP, VNC, MSSQL, LDAP, and ADB.
• CVE linkage — neither sensor shows any trace referencing a specific vulnerability on this day. The CVE figures we hold as background statistics are not connected to any session or sample observed on this day.

INFERRED To sum up, the day went like this. More sources reached the door than on any of the 12 days, and what was done inside dropped to one-sixth. Yet the number of sources that registered one card and left was 26 — the highest. That card has been the same single card for 12 days.

Changing a password is changing the door lock’s PIN. No matter how diligently you do that, if you never once open the list of registered cards, the door keeps opening.

The observation day is a single day, August 27, 2026 (UTC). Source IPs are carried over in the brief’s masked form (103.78.x.x) and were not restored. Distribution addresses are written in altered form so they will not connect (hxxp://, [.]). Credentials are cited for only the 20 combinations observed from 3 or more distinct IPs; for the 757 combinations seen from a single source only, we state the count and do not publish the values. ASN, nationality, and actor attribution are not speculated on, as we have no means of confirming them.