The Loud One Left Empty-Handed; the One That Stayed 12 Seconds Left Ten Things Behind

You’ve probably had a car alarm go off all night in an apartment parking lot. The wailing goes on through the small hours and wakes you up a few times, and in the morning you go out and the car is perfectly fine. The wind shook it, or a cat climbed on it — either way, nothing happened.

But that same night, in the next building over, no sound went off at all. And one car parked there is empty inside, without so much as a broken window.

All night, the side we paid attention to was the side making noise. The side where something actually happened was silent.

On August 26, 2026, the records left on our honeypot looked exactly like that. The side that produced the biggest number that day left nothing behind, and one 12.5-second session left ten files.

Let me unpack one unfamiliar term first. A honeypot is a bait server deliberately built to look weak and put out on the internet. It does no real work. It is a machine left open so that whatever anyone comes in and does gets recorded in full. Every number below was captured there.

From This Day On, There Are Two Servers

FACT Every number in this log so far has come from a single server. That holds for all ten days from August 16 through 25. On this day, a second server appeared in the same brief for the first time.

FACT The two are completely different in character. The first (Sensor 01) is a high-interaction server. Logins actually succeed, whoever comes in can type commands, and every one of those commands is recorded. The second (Sensor 02) is a low-interaction server. It takes greetings at the door and never opens it.

That difference is the backbone of today’s post. The noise was on the second one; the work happened on the first.

The Noisy Side — 42,000 Times

FACT The second server received 42,493 contacts that day. Spread evenly across a full day, that’s about once every 2 seconds. Every time you blinked, somewhere out there something spoke to this machine.

FACT Of those, 40,791 — 96.0% of the total — piled onto a single port. Port 5900, screen sharing (VNC). This is the feature that pulls another computer’s screen over as-is and lets you operate it with your own mouse.

FACT And yet those 40,791 contacts came from exactly 40 places. That’s an average of about 1,020 times per place. It amounts to one place speaking to the same door once every minute and a half, all day long.

FACT The port right next door was the exact opposite. Port 3389, remote desktop (RDP), got 1,221 contacts split across 139 places. About 8.8 times per place. On the same server, the density per place differed by roughly 116x.

INFERRED We read these as two activities of different character. The former is dogged repetition by a handful of tools that stay attached all day; the latter is closer to a broad sweep, many places passing through and checking once.

But Nothing Can Happen Behind That Door

FACT There’s something that must be pointed out here. The second server is low-interaction, so successful logins, shell commands, and credentials do not exist there in the first place. Samples secured: also 0.

FACT What gets recorded as a “command” on this server is not a command a person typed but a protocol frame. Put simply, it is the fixed greeting two machines exchange when they start a conversation. Only that opening line — “which version of the spec do you use?” — gets recorded.

FACT So we cannot write that “the attacker broke in and did such-and-such” about these 42,493 contacts. What we can write is only scale and pattern, and the vocabulary the protocol dictates.

That is the alarm that wailed all night. The sound went off 42,000 times, but the door making that sound was a door behind which nothing could happen.

What the Greeting Alone Reveals

FACT Even so, there is something readable in the greeting. Among the 40,769 screen-sharing contacts where a version was recorded, 40,752 (99.96%) proposed 003.003. The remaining 17 proposed 003.008.

FACT The international document that defines this spec (RFC 6143) defines three versions: 3.3, 3.7, and 3.8. Almost all of them opened with the lowest of the three.

INFERRED There is one reason to open with a low version. That’s the only way every old server can understand you. We read this as being closer to a general-purpose tool trying to sweep everything including legacy systems in one pass, rather than something aimed at a specific target.

FACT The file-sharing (SMB) side points the same way. Across 240 negotiations, the dialects proposed were NT LM 0.12 55 · LANMAN1.0 45 · LM1.2X002 45 · PC NETWORK PROGRAM 1.0 25 · Windows for Workgroups 3.1 25 · LANMAN2.1 25 · LANMAN 20. All of them are SMB1-family, and SMB 2.??? appeared in just 2 cases.

FACT On the remote desktop side, the name tags (cookies) attached at connection time remained. hello 604 · <ip> 449 · Administr 2 · (empty) 1 · aZRyuAPjX 1 · tWpPMjUMh 1.

INFERRED That the top two are hello and <ip> makes them hard to read as usernames a person typed. We read them as placeholders a tool simply dropped into a blank field. <ip> is the form where those literal characters remain in the slot where an IP address was supposed to go.

The Quiet Side — Ten in 12.5 Seconds

FACT On the same day, 14,344 commands were executed on the first server. Divided across the day, that’s someone typing something inside our machine about once every 6 seconds. It is the highest day in the ten days of records we hold (previous high 7,574, +89%).

FACT Among them, one of the sessions that went deepest that day began at 11:29:30 and ended at :42. That’s 12.5 seconds. In those 12.5 seconds it typed 3 commands and took down 10 files. That’s one every 1.25 seconds.

FACT What that session did came in three stages. Download files → grant execute permission → download-then-execute. Let me unpack granting execute permission here. On Linux, a file doesn’t run just because you’ve downloaded it. You have to attach a separate mark saying “this file is allowed to run.” The act of attaching that mark happened 182 times across the whole server that day.

INFERRED 12.5 seconds is not the speed of a person looking at a screen and making judgments. We read it as the time a pre-written sequence took to run through.

The Day in Chronological Order

Laid out in time order, it looks like this. The table is long. Compare the numbers in the second and third rows side by side. They are 47 minutes apart from different origins, and not one value differs.

1. 2026-08-26T04:04:28Z ~ 04:05:14Z (46.2s)
   FACT ATK-E17FA9(185.153.x.x, SSH) login succeeded. 18 commands, 2 downloads. The only session that day where intents ran through four stages — reconnaissance (system) → persistence (planting an SSH key) → persistence (cron) → indicator removal. Across the whole day 'persistence — cron' appears once, and this session is that one. hassh fingerprint f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6)
2. 2026-08-26T04:44:36Z ~ 04:45:56Z (80.0s)
   FACT ATK-CC4D29(217.60.x.x, Telnet) login succeeded. 17 commands, 5 intent types — download-then-execute, granting execute permission, reconnaissance (system), persistence (planting an SSH key), file download. download_count is 0
3. 2026-08-26T05:31:33Z ~ 05:32:39Z (66.9s)
   FACT ATK-081597(138.2.x.x, Telnet) login succeeded. 17 commands, and 5 intent types completely identical to ATK-CC4D29 above, with completeness also the same at 17. 47 minutes apart, different origins
4. 2026-08-26T05:32Z (comparison of the two above)
   INFERRED Two Telnet sessions matching in command count, intent combination, and completeness read as the product of the same automation tool. Telnet has no SSH handshake, so no hassh fingerprint remains (both sessions have empty strings for fingerprint and client), meaning there is no way to confirm this by fingerprint
5. 2026-08-26T07:26:42Z ~ 07:26:55Z (12.6s)
   FACT ATK-F5F4F4(61.46.x.x, Telnet) login succeeded. 22 commands, 11 downloads, completeness 42 — first place for the day. intents is a single item, 'impair defenses', and the day's one and only 'impair defenses' is this session. The file this alias took down is sha256 01ba4719…546b — size 1 byte, file_kind 'very short file (no magic)'
6. 2026-08-26T11:29:30Z ~ 11:29:42Z (12.5s)
   FACT ATK-10149C(45.198.x.x, SSH) login succeeded. 3 commands, 10 downloads, completeness 41. intents in 3 stages — file download, granting execute permission, download-then-execute. hassh fingerprint 16443846184eafde36765c9bab2f4397 (SSH-2.0-Go)
7. 2026-08-26T11:29Z (payload comparison for the session above)
   FACT The samples tied to this alias all came from one place, hxxp://5[.]182[.]210[.]174. Among them, a 1,608-byte Bourne-Again shell script named /ok differs across three hashes — sha256 94d15544…5440 · f98ba385…7d73 · 2b40a245…5eeb. The remaining four are ELF 32-bit executables for different CPU families — PowerPC MSB 50,092 bytes / Intel 80386 LSB 45,860 / MIPS-I 68,632 / ARM EABI4 62,600, all statically linked stripped
8. 2026-08-26T11:29Z (interpretation)
   INFERRED Three files at the same address with the same size but different hashes read as meaning the distribution point is varying the contents slightly on each request. If so, hash-based blocking has never once been effective against this file. However, the JSON contains no file contents, so what differed cannot be confirmed
9. 2026-08-26 daily aggregate (Sensor 01)
   FACT Command intent classification — reconnaissance (system) 2,391 / granting execute permission 182 / download-then-execute 46 / file download 46 / indicator removal 18 / persistence (planting an SSH key) 17 / reconnaissance (network) 1 / persistence (cron) 1 / impair defenses 1
10. 2026-08-26 daily aggregate (Sensor 01)
    FACT sha256 a8460f44…f8f2 — a 389-byte OpenSSH RSA public key file was observed 14 times in total across 12 different aliases (ATK-2C9913·09A5AE·EA9CD5·AEFFBD·E856A7·0870EF·831C59·E17FA9·4795D8·82E025 and others). Multiple origins are planting the same single key file
11. 2026-08-26 daily aggregate (Sensor 02)
    FACT 42,493 contacts / 253 unique origins. By service, VNC 40,791 (40 unique) · RDP 1,221 (139 unique) · SMB 240 (43 unique) · LDAP 94 (13 unique) · MSSQL 61 (7 unique), plus 86 ADB sessions. The five services sum to 42,407 + ADB 86 = 42,493, so the total checks out
12. 2026-08-26 (Sensor 02, protocol vocabulary)
    FACT Among the 40,769 VNC contacts where a version was recorded, 003.003 accounts for 40,752 (99.96%) and 003.008 for 17. The dialects proposed in SMB negotiations were NT LM 0.12 55 · LANMAN1.0 45 · LM1.2X002 45 · PC NETWORK PROGRAM 1.0 25 · Windows for Workgroups 3.1 25 · LANMAN2.1 25 · LANMAN 20 — all SMB1-family, with just 2 cases of 'SMB 2.???'. RDP cookies were hello 604 · <ip> 449 · Administr 2 · (empty) 1 · aZRyuAPjX 1 · tWpPMjUMh 1
13. 2026-08-26 (Sensor 02, interpretation)
    INFERRED 003.003 is the lowest of the three versions defined by RFC 6143 (3.3 / 3.7 / 3.8). That nearly all of them proposed the lowest version reads as meaning the other side is closer to a general-purpose scanner trying to sweep even legacy servers in one pass. The SMB side points the same way — if only 2 of 240 negotiations proposed SMB2, the very vocabulary being used to open the conversation is pitched at legacy systems

FACT Two spots in the table catch the eye. One is 04:44 and 05:31. Different origins, yet the command count, intent combination, and completeness score do not differ by even one value. The other is 07:26. It’s the day’s top completeness session, but the file it took down was a 1-byte empty file. The size of a single character.

INFERRED We read the 04:44 and 05:31 pair as the same automation tool having run twice. That is everything we can say. Telnet leaves no client-program fingerprint at all, so even the claim that the tool is the same cannot be confirmed by fingerprint.

Same Address, Same Size, Three Different Hashes

FACT The files the 12.5-second session took down are interesting. They all came from one place, hxxp://5[.]182[.]210[.]174. Among them, one file named /ok splits into three fingerprints.

Let me unpack fingerprint (sha256) here. It’s a 64-character value computed from the entire file. Change even one 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 The three files have the same address, exactly the same size at 1,608 bytes, and the same file type. A shell script about half a sheet of A4 in length. And yet the fingerprints split into three: 94d15544… · f98ba385… · 2b40a245….

INFERRED We read this as meaning the distributing side is varying the contents slightly with every request that comes in. If so, the approach of writing down a fingerprint and putting it on a blocklist has never once been effective against this file. It’s not that the value you wrote yesterday doesn’t match today — the moment you write it down, the next one already has a different value.

FACT That said, our data does not contain the file contents. What differed cannot be confirmed.

It Doesn’t Discriminate by CPU

FACT The other four that came down from the same address are different in character. All of them are ELF 32-bit executables. ELF is the program file format that runs directly on Linux.

FACT The four are for four different CPU families. PowerPC 50,092 bytes · Intel 80386 45,860 · MIPS-I 68,632 · ARM EABI4 62,600. All statically linked stripped. Put simply, that means they were built to run on their own without borrowing parts from outside, with every human-readable name tag erased.

FACT All four together come to about 222KB. Smaller than one photo from a smartphone.

INFERRED Having builds prepared in advance for each CPU type means an intent not to discriminate about the target. Server, home router, network camera, set-top box — once the login is cracked, you just pick the one that fits that machine and drop it in.

Values to Write Down

Click a value to copy it — these are here not to be read but to be put on a blocklist. The addresses have been deliberately mangled (hxxp://, [.]). Copying and pasting them as-is will not connect.

INFERRED Even within the same table, values have different lifespans. The file at 185[.]93[.]89[.]72 catches 8 places with one fingerprint. Write it down and you catch multiple origins at once. Conversely, 5[.]182[.]210[.]174/ok split into three fingerprints at one spot. They sit side by side in the same list, but one is a net and the other is a net that has already been torn.

This Is Where the Day Flipped

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

FACT The cumulative set of fingerprints we hold is 45. 33 on 8/17 → 36 on 8/18 → 37 on 8/19 and 8/20 → 42 on 8/25 → 45 on this day, up by 3 in a single day.

FACT The largest group that day is acaa53e0a7d7ac7d1255103f37901306 (SSH-2.0-OpenSSH_7.4). It grouped 169 IPs in one day alone. Since 373 origins came to the first server that day, close to half of them used the same program. Cumulatively it’s 356, up from 125 on 8/25.

FACT And here is today’s core point. Every one of the 12 fingerprint types caught that day left behind not a single file, without exception. The tool that groups the most IPs under one value produced 0 samples.

FACT Conversely, the fingerprint of the 12.5-second session that actually dropped 10 samples, 16443846…4397 (SSH-2.0-Go), is not among the day’s top 12 fingerprints.

INFERRED The noisiest tool and the tool that actually leaves something behind are different. Measure risk by the volume of the noise and the ordering flips entirely. The alarm that wailed all night was empty-handed, and ten came out of the side that made no sound.

FACT · WARNING That said, one line must be drawn. hassh is a fingerprint of a build, not of a person. People with no connection to each other who use the default OpenSSH shipped in the same distribution will have the same value. In fact, the fingerprint of that day’s 12.5-second session is identical to the value the August 19 brief recorded as the fingerprint of a different alias (ATK-CA5936). Even so, we cannot say it’s the same person. It only means a tool that uses the same library.

There Are Addresses Visible Only After Unpacking

FACT Some of the samples are packed with UPX. UPX is a tool that shrinks executables, and in the packed state no addresses turn up at all, no matter how hard you dig through the file’s surface.

FACT We obtained 12 indicators only by unpacking. All of them are per-CPU-type filenames under 31[.]77[.]227[.]121/bins/ — parm·parm5·parm6·parm64·parm7·pm68k·pmips·pmpsl·pppc·psh4·pspc·x86_64.

FACT And yet the distribution points recorded in the actual download logs that day are 5[.]182[.]210[.]174 and 185[.]93[.]89[.]72. Different from the host that came out of the unpacking.

INFERRED With collection that only looks at the surface, there was no way to obtain those 12 from that day’s traffic. It means there is one more distribution point beyond the visible ones.

Which Passwords Were Tried

FACT There were 5,273 login attempts that day. Spread evenly across a full day, that’s someone entering an ID and password about once every 16 seconds. Divided by 373 origins, it’s an average of 14 attempts per place.

FACT Below are 20 combinations, filtered down to only those observed from 3 or more different IPs. Combinations seen from only one place could be genuine leaked accounts, so we do not publish their values.

FACT Beyond these 20, there are 204 more combinations we are not publishing. Ten times as many as what we published. We give only the count, not the values.

INFERRED One entry in the table catches the eye. 345gs5662d34 is not a dictionary word. The ID and password are identical. And it turned up exactly 10 times from 10 different IPs. Precisely once per place. We read that not as the shape of something hammering to break in, but as the shape of a single poke to see whether this string works, then moving on.

FACT And P@ssw0rd · Passw0rd · p@ssw0rd · passw0rd sit side by side in the table. Combinations that mix uppercase and special characters — and they are already on the list.

Mapped to the International Classification

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

• T1110.001Brute Force: Password Guessing — login_attempts 5,273 / 373 unique IPsINFERRED
• T1078.001Valid Accounts: Default Accounts — admin/admin (23 IPs), root/root (10 IPs), and 20 quotable combinations in totalINFERRED
• T1082System Information Discovery — 2,391 counts of 'reconnaissance — system'INFERRED
• T1105Ingress Tool Transfer — 46 counts of 'file download', 11 types in the downloads arrayINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 182 counts of 'granting execute permission'INFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 17 counts of 'persistence — planting an SSH key'INFERRED
• T1053.003Scheduled Task/Job: Cron — 1 count of 'persistence — cron'INFERRED
• T1070Indicator Removal — 18 counts of 'indicator removal'INFERRED
• T1562Impair Defenses — 1 count of 'impair defenses'INFERRED
• T1046Network Service Discovery — on Sensor 02, 253 places contacted 5 service ports. This is mapped from the fact of service contact alone and does not identify a scanning toolINFERRED
• T1021.005 / T1021.001Remote Services: VNC / RDP — mapped by service type only. Being a low-interaction sensor, no fact of remote services actually being used was observedINFERRED

FACT Look at the two rows with the smallest numbers. 1 cron, 1 impair defenses. On a day with 5,488 sessions, exactly once each. And we know which session each of those single occurrences came from — cron was the 04:04 session, impair defenses was the 07:26 session.

INFERRED All eleven rows carry the ‘INFERRED’ badge. What we saw is the intent classification and count of commands, not a purpose the attacker stated. The bottom two rows in particular are attached on the fact of contact alone, so they should be read with extra care.

Yesterday in Full

FACT This is on the basis of Sensor 01 (high-interaction). Sensor 02’s figures use a different session unit, so they have not been added in.

FACT “Highest” means the highest within the ten-day range of 8/16–8/25. We did not compare against records before that.

FACT The second server (Sensor 02) looks like this. Again: this side is low-interaction, so successful logins, commands, and credentials do not exist there in the first place.

FACT The unique origins across both sensors come to at most 626. Since we can’t know how many places touched both servers, this is an upper bound assuming no overlap at all.

FACT There is one cell in the table that doesn’t add up. The sum of the top 8 VNC contact sources (7,623 / 7,599 / 5,181 / 5,178 / 5,118 / 3,354 / 3,353 / 3,334 = 40,740) sits within 51 of the VNC total of 40,791. However, this top list carries no service breakdown, so we cannot assert that these 8 are those 40.

FACT And the masked 159.203.x.x appears under two different aliases (ATK-B954FC 5,178 contacts, ATK-D9A63B 3,334 contacts). They merely share the first two octets and are different origins, and an alias is not an identity either. They must not be read as the same organization.

So What Should You Do

INFERRED Here are the six “if this control had been absent” items the brief laid out, ordered by how strongly this day’s data supports each.

1. Start by eliminating default accounts and weak passwords (likelihood: high) — admin/admin was tried 178 times from 23 places, root/root 76 times from 10 places, root/admin 149 times from 9 places. The day’s top 5 completeness sessions all succeeded at login, without exception. If even one survives, it opens within that same day. What follows a break-in is exactly what was observed this day — reconnaissance (2,391) → download (46) → execute permission (182) → execution (46). At the short end, it got this far in 12.5 seconds.

2. Turn off password login and leave only key-based login (likelihood: high) — after successful logins, 17 counts of planting someone else’s public key were observed. Let me unpack SSH key planting here. A Linux server has a file called authorized_keys (the list of permitted keys). If a public key is written as a line there, the person holding its counterpart gets in without being asked for a password. So even if you change the password later, that line stays alive. “Password change complete” is not grounds for closing an incident.

3. Don’t leave management ports open to the internet as-is (likelihood: high) — in this one day 373 places knocked on two ports, and on the server next door 253 places attached to five services. They don’t come because you’re a target; they come because you’re open. You enter the standing candidate pool without notice.

4. Automatically block a place that keeps knocking (likelihood: high) — 40,791 screen-sharing contacts came from 40 places. Flipped around, that’s also good news. Blocking just 40 places makes 96% of that day’s contacts disappear. There are fewer things to block than you’d think.

5. Restrict outbound connections from the server (likelihood: high) — 46 file downloads and 46 download-then-executes get cut off right here. Having builds ready for each CPU type means the target isn’t being discriminated. This is the last gate remaining after a login has been cracked.

6. Keep logs somewhere outside the server (likelihood: medium) — 18 counts of intent to erase traces and 1 count of intent to impair defenses were observed. The 04:04 session went all the way through reconnaissance → key planting → cron → indicator removal in 46 seconds. If the logs had only been on the server, some of those would have succeeded. 18 is a small number against 5,488 sessions, so we placed this at ‘medium’.

It Has Happened Before

INFERRED Mirai botnet (2016). The top quotable credentials that day were defaults like admin/admin · root/root · support/support · user/user · guest/guest · pi/pi (each from 5 or more places), and on the same day ELF binaries for PowerPC, MIPS, ARM, and i386 came down together from one distribution point. The structure of getting in with default accounts and dropping in the executable matching the device’s CPU is the same. This is not an assertion that this day’s observations belong to a specific malware family; it means the pattern resembles a publicly documented precedent. (Basis: US-CERT advisory TA16-288A, plus the publicly released source code and numerous vendor analysis reports)

INFERRED WannaCry (2017). Across the 240 file-sharing negotiations on the second server that day, the dialects proposed — NT LM 0.12 · LANMAN1.0 · PC NETWORK PROGRAM 1.0 and so on — were all SMB1-family, with only 2 cases of SMB 2.???. This points only to the fact that nine years on, the vocabulary used to open conversations on the internet is still pitched at SMB1. It is not the case that MS17-010 exploitation was confirmed in this day’s observations — only the negotiation stage was observed. (Basis: vendor security bulletin MS17-010, CVE-2017-0144, CISA KEV listing)

INFERRED RealVNC authentication bypass (2006). 99.96% of that day’s screen-sharing contacts proposed the lowest version in RFC 6143. We use this only as background context that that very stage of negotiating version and authentication method was the setting for a past public vulnerability. This day’s observations extend only to contact and version proposal; no authentication bypass attempt was confirmed. (Basis: CVE-2006-2369 and vendor advisories)

What We Don’t Know

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

• The second server’s ADB details are missing entirely. That there were 86 sessions is confirmed only by arithmetic on the total (five services summing to 42,407 + 86 = 42,493). Neither the unique IP count nor what was dropped is in the data. This must not be read as “there were no ADB attacks that day.” Of all things, ADB is the one channel on the second server where the content of a drop could have been recorded, so this gap needs confirmation in the next collection.
• The second server’s sample list is an empty array and secured samples are 0. Whether no file was actually dropped, or the collector failed to catch it, cannot be distinguished.
• Whether a single origin swept multiple services cannot be computed. The top-origin list has no service breakdown, and there is no per-service IP list. From the inequality that the sum of per-service unique IPs (40+139+43+13+7=242) is less than the overall 253, all that follows is “at least 11 places were outside those five services.” So we left this value as “no value” rather than 0.
• The top 8’s sum of 40,740 is close to the VNC total of 40,791, but since it is not a service-broken-down figure, we cannot assert they are the same.
• The VNC version-proposal total of 40,769 and the VNC session count of 40,791 differ by 22. This appears to mean some contacts had no version recorded, but the reason is not in the data.
• The RDP cookie Administr is a string cut off at 9 characters. What the original value was, and why it was cut off, cannot be confirmed.
• On the first server, the command intent values sum to 2,703 while the overall command count is 14,344. We cannot know whether the two figures use the same unit, so we did no ratio calculations like “X% of commands were reconnaissance.”
• The 12.5-second session’s download count is 10 in the session record, but the sum of the entries tied to this alias in the sample list is 12 (7 hashes). It’s possible that session-level and day-level aggregates are mixed together.
• That session’s fingerprint is not among the day’s 12 fingerprint types. It’s likely the number of IPs grouped under this fingerprint was below the list’s floor (2 places), but whether that list carries only the top few is not stated in the data.
• We cannot confirm why the three /ok files are all 1,608 bytes yet have different hashes. The file contents are not in the brief. Whether it is per-request alteration at the distribution point or some other cause is unconfirmed.
• There is one Discord webhook address among the reference indicators, but the data does not connect it to any sample or session. There is no basis for saying it is the communication channel of any specific session observed that day.
• The distribution points observed that day are being reported to C-TAS. However, what was confirmed extends only to transport-layer success; whether KISA ingested it is unconfirmed at this point.
• The vulnerability statistics we hold as background (6,579 CVEs tracked, 387 CISA KEV listings, 98 linked to ransomware) have no connection to this day’s observations on the two servers. Nowhere on this day was an attack referencing a specific vulnerability confirmed.
• The comparison basis is only the ten days of 8/16–8/25. We did not compare against anything before that, so “highest” is valid only within this range. And those ten days were all the first server alone, so the second server has no past values to compare against at all — there is no baseline for judging whether 42,493 contacts is more or less than usual.
• ATK-XXXXXX is an identifier for pointing at the same origin across briefs. It is not an identity, and it cannot be used to restore a masked IP either.

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

• ASN · ISP — we have no relevant database. We cannot say which provider the distribution points 5[.]182[.]210[.]174 · 185[.]93[.]89[.]72 · 31[.]77[.]227[.]121 sit with. This post mentions no telecom carrier and no hosting provider for any origin.
• 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.
• VPN · Tor · cloud status — we have no means of determining this. Among the 626 places, we cannot distinguish which are waypoints and which are points of origin.
• VirusTotal — not integrated. Multi-engine verdicts on this day’s 11 hash types are not in this post. Sample classification uses MalwareBazaar tags.
• User-Agent — neither observation surface is HTTP. The first is SSH and Telnet; the second is SMB, RDP, VNC, MSSQL, LDAP, and ADB.
• CVE linkage — SSH and Telnet attacks mostly do not reference vulnerabilities. The second server is the same, being at the negotiation stage. There is not a single statement in this post linking this day’s observations to a specific CVE.

INFERRED To sum up, the day went like this. The door that produced the biggest number was a door behind which nothing could happen. The tool that grouped the most IPs under one value left behind not a single file. The side that actually left ten came and went quietly over 12.5 seconds, and that tool’s fingerprint didn’t even make it onto the day’s top list.

It’s a relief when the car is fine after a night of loud alarms. The problem is that nobody looked at the side that made no sound. There is no guarantee that the biggest bar on the dashboard is the most urgent matter. This day’s data was the opposite.

The observation period is the single day of August 26, 2026 (UTC). Origin IPs are carried over in the brief’s masked form (45.198.x.x) and were not restored. Distribution addresses are written in altered form so they will not connect (hxxp://, [.]). Credentials are quoted for only the 20 combinations observed from 3 or more different IPs, and for the 204 unpublished combinations we give only the count, not the values. ASN, nationality, and actor attribution have no means of confirmation, so we do not speculate.