We Thought It Was a Notebook — It Was a Whiteboard. The Day 50 Became 35

Picture a whiteboard hanging in a school hallway. On it are the names of people who haven’t returned their books yet.

Last week you counted 50 names. This week you count 35.

Did they return the books?

Maybe. But there’s another answer. A whiteboard has a fixed number of slots. To write a new name, you have to erase the one at the top. In a notebook the names would keep piling up, but a whiteboard pushes the old names off. Then the number drops not because there are fewer people, but because the board scrolled.

That is exactly what happened to us yesterday. Except we weren’t counting an overdue-book list — we were counting intrusion records, and we’d spent twenty days writing posts on the belief that the board was a notebook.

First, what came in yesterday

FACT Yesterday, six distinct files were downloaded onto our server (a honeypot — a decoy server we leave open on purpose to watch what people do). Five of them were files we had already recorded in past logs. Even the hashes matched (a hash is a value that summarizes a file’s contents into one short string; change a single character and the whole value changes).

FACT One of them is a 306-byte shell script. 306 bytes is about the size of two lines of a text message. This file was first seen on August 17, and as of yesterday it has carried the same hash for 20 days. It comes from the same address, hxxp://185[.]93[.]89[.]72/wget. In 20 days, not one bit has changed.

INFERRED That means the attacking side has fixed nothing. More precisely, they’ve had no reason to. It means this file has kept working for 20 days straight.

FACT Yesterday, five sessions logged in successfully and left commands behind. Three of them came from different sources, yet had exactly the same 31 commands, 3 intent types, and completeness score of 16. Their durations were 67.657, 68.155, and 67.820 seconds — within a second of each other. The file all three of these sessions pulled down was one file: the 306-byte script above.

FACT The remaining one (ATK-CA5936) came in over SSH, stayed 3.738 seconds, and left. Just 1 command, but 5 intent types and 2 files pulled down. This shape matches the records from 8/19, 8/24, 8/25, 8/28, 8/30, 9/01, and 9/03 — same alias, fingerprint, duration, and command count. Yesterday was the eighth time.

One new file — and it wasn’t new either

FACT The only hash we saw for the first time yesterday was dde20835…. It’s a 1,608-byte bash script — about ten lines in text-message terms.

FACT This file came from hxxp://5[.]182[.]210[.]174/ok. But every file out of this address since 8/17 has been exactly 1,608 bytes, and every time the hash has been different. The 8/25 post counted 10 variants and the 8/29 post added 2 more, so including yesterday’s that’s at least 12.

INFERRED It reads as though the size stays fixed while the contents shift slightly each time. Blocking by hash doesn’t last a single day against this address. We’ve written down twelve of them and a thirteenth shows up anyway.

FACT Why this happens, though, we don’t know. We can’t distinguish whether it’s regenerated on each request or swapped out on a short cycle. We don’t hold the file contents, so we can’t say what changed either. We left the same item unresolved on 8/22, 8/23, 8/25, 8/27, and 8/29, and yesterday it stands unchanged.

Then our own list looked wrong

This is where yesterday’s real subject begins.

FACT Our server leaves one fingerprint for each program that connects. It’s a summary of the values the other program volunteers up front to say “this is how I talk.” Next to that fingerprint is a field called ips_all_time. Read literally, it means “the number of sources that have arrived carrying this fingerprint so far.”

FACT For twenty days we read this field as a running total and copied it into our posts. But when we cross-checked against the older posts yesterday, three of them had gotten smaller than in the past.

FACT A running total cannot shrink. For 50 sources through yesterday to become 35 today, the visits themselves would have to be cancelled.

INFERRED So that field is most likely not a notebook but a whiteboard. Meaning it doesn’t accumulate everything — it counts only some recent span. Old names get pushed off the board.

FACT But we can’t confirm this. How many days it counts, and when it started counting, is written nowhere in the data. So from now on we will not use this value as a “total so far” — only as a “recent observation window.” The sentences in past posts that read it the other way could be wrong in either direction, overstating or understating.

But one row went the other way

FACT In the same table, one row — acaa53e0… (SSH-2.0-OpenSSH_7.4) — kept climbing. 139 sources on 8/25 → 589 on 8/31 → 1,042 yesterday.

INFERRED If it rose even though the board scrolls, that means more came in than got pushed off. This increase can be read as real. Conversely, the three rows that fell must not be used as evidence that “attacks decreased.”

FACT And this top fingerprint has delivered_samples (did it leave a file behind) marked false. Of yesterday’s 11 fingerprints, the only one with that flag set was 16443846… (SSH-2.0-Go) — just one. The tool that knocked on the door most and the tool that actually left something behind are different.

FACT Let’s pause here. This value is a fingerprint of a program build, not of a person. People using the OpenSSH that ships by default with the same distribution will have the same value with no relationship to each other whatsoever. So we write only as far as “same tool,” never “same organization.” On top of that, the banner string is a value the other side sends about itself, so it can be fabricated freely, and we have no way to verify it.

The whole of yesterday

Laid out in time order, it looks like this. Watch the lines marked ‘daily aggregate · archive comparison’ — those are the things you can’t see from yesterday alone, only by setting it next to the past posts.

1. 00:26:22 ~ 00:27:30 UTC
   FACT ATK-DF93D5 (171.249.x.x, Telnet) logged in successfully. Over 67.657 seconds, 31 commands, 1 download. 3 intents — file download · granting execute permission · execute after download. completeness 16, TTY recorded (contents not included). Because it's Telnet, the fingerprint and client fields are empty strings
2. 00:29:40 ~ 00:30:41 UTC
   FACT ATK-A2FEFA (122.8.x.x, Telnet) logged in successfully. 60.894 seconds, 17 commands. 5 intents — reconnaissance (system) · file download · granting execute permission · execute after download · persistence (planting an SSH key). However, download_count is 0, and this alias is not in the 8-entry delivered_by list for the 389-byte public key a8460f44…. completeness 17
3. 01:51:27 ~ 01:52:35 UTC
   FACT ATK-C7E851 (111.246.x.x, Telnet) logged in successfully. 68.155 seconds, 31 commands, 1 download, 3 intents, completeness 16 — identical to ATK-DF93D5 at 00:26 in command count, intent combination, and completeness
4. 02:38:13 ~ 02:38:16 UTC
   FACT ATK-CA5936 (130.12.x.x, SSH) logged in successfully. 3.738 seconds · 1 command, yet 5 intents · 2 downloads (a 399-byte OpenSSH private key 43728fbf… and a 54-byte ASCII file 00b6f15c…). Fingerprint 16443846…4397 / SSH-2.0-Go. completeness 19, the highest of the day. Matches the archive entries of 8/19 · 8/24 · 8/25 · 8/28 · 8/30 · 9/01 · 9/03 in alias, fingerprint, duration, command count, intent count, and download composition — yesterday is the eighth such record
5. 03:01:05 ~ 03:02:12 UTC
   FACT ATK-6757C8 (171.249.x.x, Telnet) logged in successfully. 67.820 seconds, 31 commands, 1 download, 3 intents, completeness 16 — the third session of the same shape yesterday. This alias and ATK-DF93D5 at 00:26 share the same first two masked octets, 171.249, yet have different aliases
6. 2026-09-05 (daily aggregate · sensor 01)
   FACT All three of the 31-command sessions (ATK-DF93D5 · ATK-C7E851 · ATK-6757C8) appear in the 8-entry delivered_by list for the 306-byte shell script a6296a79…. That is, the file all three sessions pulled down is the same single file
7. 2026-09-05 (archive comparison)
   FACT Five of yesterday's six downloads are hashes present in past records — a6296a79… (306 bytes, same hash and same URL for 20 days since 8/17), 4af5a5c9… (9 bytes, 8/18 · 8/19), a8460f44… (389-byte public key, since 8/16), 43728fbf… (399-byte private key, since 8/19), 00b6f15c… (54-byte ASCII, since 8/19). The only new hash is dde20835… (1,608-byte bash)
8. 2026-09-05 (archive comparison)
   FACT That new hash dde20835… came from hxxp://5[.]182[.]210[.]174/ok and is exactly 1,608 bytes. The 8/25 post counted 10 hash variants from this URL and the 8/29 post has 2 more (801cba39… · 0c058175…) — adding yesterday's gives at least 12, and the size has been 1,608 bytes every time since the first observation on 8/17
9. 2026-09-05 (archive comparison)
   FACT Three clusters have an ips_all_time in client_fingerprints lower than in past records. dd9bcf09… (SSH-2.0-ZGrab) 8/21 34 → 8/22 38 → 8/23 42 → 8/31 50 → yesterday 35. f555226d… (SSH-2.0-libssh_0.9.6) 8/19 145 → 8/22 182 → 8/24 216 → 8/29 289 → yesterday 271. 16443846… (SSH-2.0-Go) 8/19 24 → 8/24 28 → 8/30 27 → 9/04 19 → yesterday 20. clusters_total also went 8/24 41 → 8/29 45 → yesterday 37. In contrast, acaa53e0… (SSH-2.0-OpenSSH_7.4) kept rising: 8/25 139 → 8/31 589 → yesterday 1,042
10. 2026-09-05 (daily aggregate · sensor 01)
    FACT Of 1,715 commands, 1,028 (59.9%) were classified by intent. Among those, reconnaissance — system dominates at 770 occurrences (74.9%), and granting execute permission at 184 is 6.6 times the 28 file downloads. File download at 28 and execute after download at 28 are exactly equal. Persistence — planting an SSH key 10 times, indicator removal 8 times
11. 2026-09-05 (daily aggregate · sensor 02)
    FACT 35,373 sessions, 327 unique sources. VNC (5900) accounts for 33,975 sessions, 96.05% of the total, yet only 100 sources produced them — an average of 339.75 per source. Conversely RDP (3389) had 918 contacts from 118 sources, the most of any service yesterday, at 7.78 per source
12. 2026-09-05 (daily aggregate · sensor 02)
    FACT The top 6 entries in top_sources produced 4,941~5,199 events each, totaling 30,390 — 85.9% of all sensor 02 sessions. All 12 listed sources total 31,837 (90.0%)
13. 2026-09-05 (daily aggregate · sensor 02)
    FACT The session counts across the 5 entries in service_breakdown sum to 35,262, exactly 111 short of the total of 35,373. That 111 equals the adb_sessions value — ADB contacts made it into the total but are absent from the service list
14. 2026-09-05 (daily aggregate · sensor 02)
    FACT The 180 SMB dialect proposals used only eight vocabularies — NT LM 0.12 · LANMAN1.0 · LM1.2X002 · LANMAN · PC NETWORK PROGRAM 1.0 · Windows for Workgroups 3.1 · LANMAN2.1 · Samba — with 0 SMB2-family proposals (on 9/04 there were 2 of SMB 2.???). For VNC, of the 33,806 contacts with a recorded version, 33,285 (98.46%) were 003.003. Of 768 RDP cookies, those carrying a public scanner name verbatim were nmap 3 times · zgrab 2 times

What catches the eye here is the third archive-comparison line. Every other line says “yesterday was the same again,” and that one says “yesterday we were wrong.”

Put into numbers, it looks like this.

INFERRED Sizing it by feel: 1,304 login attempts spread over a day is about once a minute. Someone spent all day jiggling the doorknob. The 1,715 commands work out to one or two a minute as well. A pace that is neither hurried nor resting.

FACT Here is the distribution of what happened inside the server yesterday.

FACT ‘File download’ at 28 and ‘execute after download’ at 28 are exactly equal. Meaning everything downloaded went on to the execution stage without exception.

‘Granting execute permission’ is the act of attaching a mark to a file saying “this file is allowed to run.” On Linux, without that mark a program won’t run even if it is one.

What was left at the door

We’re reproducing the values as-is so you can use them for defense. Click a value to copy it. The addresses are defanged so they can’t be visited — leave them that way when you use them. And compare the two lines marked ‘20 days’ and ‘12 variants’ — one is a value that holds for 20 days once written, the other goes stale the moment you write it.

FACT A note on sizes. The 389-byte public key is two or three lines of a text message, 54 bytes is one short sentence, and 9 bytes is nine English characters. Sensor 02’s 231,196 bytes is 750 copies of the 306-byte script above.

FACT And among the 6 files sensor 01 stored yesterday, there were zero ELF executable binaries. Only 2 shell scripts · 2 ASCII text files · a public key · a private key, with no ‘executable’ entry in the file classification.

FACT The 389-byte one is an SSH public key. In plain terms, it’s a spare key that gets you in without a password. Write this value as a line into the server’s authorized_keys file (the list of permitted keys) and whoever holds that key can get in from then on without being asked for a password. Yesterday this file came from 8 different aliases.

FACT The 399-byte one, conversely, is a private key. But the data doesn’t tell us whether the attacker planted it or was trying to take one that was on the server. The unresolved item we logged on 8/19 stands unchanged yesterday, the eighth observation.

What passwords they tried to get in with

FACT About 955 username/password combinations were tried yesterday. Of those, we’re publishing only 20. The remaining 935 we only count. That’s 97.9% of the total.

The reason is simple. A combination seen from fewer than 3 different IPs could be a real account leaked from somewhere. We do not reproduce such values in our posts.

The 20 below are the opposite. They repeat across many sources, so they can be treated as factory defaults belonging to no one.

FACT admin/admin alone came from 21 different sources. There were also 4 sources that tried the root account with the password left entirely empty.

Mapping the attackers’ techniques to the international classification

MITRE ATT&CK is an international list that assigns a number to each attack technique. Fitting the behavior we saw to those numbers gives this. Press an ID to go to the original description — we link them so you can check for yourself rather than take our word for it.

• T1110.001Brute Force: Password Guessing — 1,304 login attempts, roughly 955 distinct combinations (20 quoted + 935 single-source)INFERRED
• T1078.001Valid Accounts: Default Accounts — 5 sessions logged in successfully using a default-value dictionary: admin/admin from 21 sources, root/root from 9, and othersINFERRED
• T1082System Information Discovery — reconnaissance — system, 770 timesINFERRED
• T1105Ingress Tool Transfer — 28 file downloads, 2 distribution points with an external URL recordedINFERRED
• T1222.002File and Directory Permissions Modification: Linux — granting execute permission, 184 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — persistence — planting an SSH key, 10 times; the 389-byte public key brought in from 8 different sourcesINFERRED
• T1070Indicator Removal — indicator removal, 8 timesINFERRED
• T1046Network Service Discovery — sensor 02 saw contacts against 5 services (VNC · RDP · LDAP · SMB · MSSQL), with nmap appearing 3 times in RDP cookiesINFERRED
• T1595Active Scanning — zgrab 2 times in RDP cookies, plus sensor 01's SSH-2.0-ZGrab fingerprint from 2 sources and SSH-2.0-Fingerprintx-SSH2 fingerprint from 3 sources. These are contacts where the other side named its own tool, and whether the purpose was research/measurement or attack preparation cannot be confirmedINFERRED

Note that all nine lines carry the [INFERRED] badge. What we hold goes as far as the ‘intent classification results’ for the commands and ‘how many times.’ We do not have the raw commands. Mapping to a classification table is always interpretation, and we label interpretation as interpretation.

The building next door — sensor 02

FACT The same day, the low-interaction sensor 02 received 35,373 sessions. Set against sensor 01’s 1,700, that’s 21 times as many. There were 327 sources.

FACT The door with the most contacts and the door with the widest spread of sources are different. VNC: 100 sources produced 34,000 contacts. RDP: 118 sources produced 918.

INFERRED Spread over a day, VNC’s 339.75 is the pace of one source jiggling the doorknob every four minutes, all day long. RDP’s 7.78 is eight times a day. Two completely different characters happening at once, on the same server, on the same day.

FACT The top 6 sources produced 4,941~5,199 each, 30,390 combined. That’s 85.9% of all of sensor 02. Including all 12 listed sources brings it to 90.0%.

FACT In the negotiation stage, the VNC version proposed by the other side was 003.003 in 33,285 of the 33,806 recorded contacts (98.46%). On the SMB side, all 180 dialect proposals were old vocabulary, and proposals from the modern SMB2 family numbered zero. On 9/04 there were 2; yesterday there were none. Of 768 RDP cookies, those that sent a scanner name verbatim were nmap 3 times and zgrab 2 times.

FACT Sensor 02 is low-interaction, so the very concepts of successful login, commands, and credentials do not exist there. The numbers here go as far as “which door was knocked on how many times”; no sentence about “came in and did X” can be constructed.

This has happened before

INFERRED The Mirai botnet (2016). It got into IoT devices using a dictionary of default Telnet accounts. Among the 20 credentials that met yesterday’s quoting threshold are root/xc3511 (3 sources) · root/vizxv (3 sources) · root/xmhdipc (5 sources), and these combinations became known and were widely documented when the Mirai source was published. That 4 of yesterday’s 5 successful logins were Telnet also overlaps. But this does not mean yesterday’s attempts were Mirai-family. Because the same dictionary was copied verbatim into many later derivative tools, all we can say is that the dictionaries overlap. We do not reproduce figures like infected device counts or damage amounts. (Source type: US-CERT alert TA16-288A and published source-code analysis reports)

INFERRED RealVNC 4.1.1 authentication bypass, CVE-2006-2369 (2006). In yesterday’s VNC negotiations, 98.46% of the versions proposed by the other side were 003.003. RFB 3.3 is an old version in which the choice of authentication method rests with the server, and the CVE above is a flaw that let a client force ‘no authentication’ within that structure. There is a reason a tool broadly hunting for screen-sharing servers with weak authentication would propose a low version first. But this is background explanation resting on the protocol definition and a public CVE. We have no basis for saying yesterday’s contacts actually attacked this vulnerability. All we hold is the version number presented during negotiation. (Source type: CVE and vendor advisory)

So what should you do

Back to the whiteboard. What we learned yesterday is two things. A number’s meaning depends on what kind of board it’s written on, and if the board is in someone else’s hands, it can be erased. The items below all come back to that.

1. You’re still using default accounts and weak passwords · high likelihood All 20 rows in the table above are values that devices or distributions ship with. admin/admin was tried 44 times by 21 sources, root/root 12 times by 9 sources. There were empty-password combinations too. And yesterday’s five highest-completeness sessions all begin, without exception, after the door was opened with this dictionary. What followed the opening was 770 reconnaissance actions · 184 grants of execute permission · 28 downloads.

2. You’re allowing password logins and not using key-based auth · high likelihood 1,304 login attempts came in over the day, and both SSH and Telnet are paths that accept passwords. The problem is what comes next. ‘Key planting’ was classified 10 times, and the 389-byte public key came in from 8 different sources. Once someone else’s key gets one line into authorized_keys, they keep getting in with that key even if you change the password. It adds another authentication method, so neither a password change nor an account lockout helps.

3. You’re leaving management ports open straight to the internet · high likelihood 439 sources touched a server we’ve never advertised, in one day. The neighboring sensor drew RDP 118 sources · VNC 100 · SMB 57 · LDAP 15 · MSSQL 10. Combining both sensors gives at most 766 (an upper bound, since we can’t know the overlap). Some contacts even identified themselves as scanners. They didn’t pick us out — they were sweeping addresses and we came up. Move behind a VPN or a jump host and most of these contacts get cut off before the authentication stage.

4. You’re not blocking outbound connections · high likelihood ‘File download’ at 28 and ‘execute after download’ at 28 were exactly equal. The distribution points with an external address recorded yesterday were two: hxxp://185[.]93[.]89[.]72/wget and hxxp://5[.]182[.]210[.]174/ok. Login is already breached by that point, so cutting the server’s outbound connections is the last place where actual damage gets stopped. Had this been blocked, all four of yesterday’s sessions would have been cut off at the download stage.

5. You’re keeping logs only on the server · medium likelihood ‘Indicator removal’ intent was classified 8 times. The reason we could see it at all is that 913 sessions were recorded separately, off the server. If you write the list only on someone else’s classroom whiteboard, it gets erased. One configuration that ships logs off the server immediately neutralizes these 8.

6. You’re relying solely on count-based blocking (fail2ban and the like) · medium likelihood Here’s the interesting part. Sensor 02’s VNC runs 339.75 per source, so it trips any rule you like. The top 6 sources produced 85.9% of everything, so a single connection rate limit lops them off. But sensor 01 averages 2.97 per source. A threshold like “lock after 5 failures” never even fires. The same defense works on one side and not the other. And the side where the door actually opened yesterday was the side where thresholds don’t work.

What We Don’t Know

This is what sets this blog apart from others. We write down what we don’t know as not known. Yesterday, the top of that list was about ourselves.

About our own records

• [Needs correction] Three clusters have a per-fingerprint ips_all_time lower than in past records (ZGrab 8/31 50 → yesterday 35, libssh 8/29 289 → yesterday 271, SSH-2.0-Go 8/30 27 → 9/04 19 → yesterday 20). The total number of fingerprint clusters also went 8/29 45 → yesterday 37. It is most likely a value that counts only a recent window rather than a permanent running total, but the aggregation basis and start point are absent from the data, so we cannot confirm it. The statements in past posts that read this value as a “total so far” need correction.
• [Cannot confirm] The archive comparison was done by matching text across the 20 briefs from 8/16 to 9/04. It compares posts we wrote, not the raw material, so a value not written in a past post should be read as ‘not confirmed,’ not ‘did not exist.’

What the data itself cannot explain

• [Cannot confirm] For how many distinct hashes have come from hxxp://5[.]182[.]210[.]174/ok so far, we can state only a lower bound. 10 on 8/25 + 2 on 8/29 + 1 yesterday gives at least 12; this is not the result of an exhaustive hash-by-hash comparison across 20 days of archive.
• [Cannot confirm] We don’t know why the hash keeps changing at the same address and the same 1,608 bytes. We can’t distinguish whether it’s built per request or swapped on a short cycle, and since the file contents aren’t retained we can’t say what changed either. The same item from 8/22 · 8/23 · 8/25 · 8/27 · 8/29 stands unchanged.
• [Cannot confirm] The data doesn’t distinguish whether the 399-byte private key was planted or was being taken. It’s in the downloads array but the address field is empty. The unresolved item from 8/19 stands unchanged yesterday, the eighth observation.
• [Cannot confirm] Sessions total 1,700, yet both the per-port sum and the per-protocol sum come to 1,698. Where the 2 belong is not explained.
• [Cannot confirm] TTY recordings are written as 913 in one place and 224 in another. The relationship between the two values is not stated.
• [Cannot confirm] Of 1,715 commands, 687 (40.1%) were not classified under any intent. What they were, we can’t know without the raw text.
• [Cannot confirm] Sensor 02’s 111 ADB contacts made it into the total but are absent from the service list, and yesterday’s raw material has no ADB detail section at all. It is the one channel on sensor 02 where the injected content is retained, and yesterday we can’t see that content. We can’t confirm whether the 231,196-byte sample came in by this path.
• [Cannot confirm] We can’t compute whether a single source on sensor 02 swept multiple services together. The per-service source counts sum to 300, which is less than the 327 total unique sources, so the overlap can’t be back-calculated. A 0 here means ‘cannot be derived,’ not ‘none.’
• [Cannot confirm] 3356ae61… (SSH-2.0-PuTTY_Release_0.84) again shows 3 sources for the day = 3 cumulative yesterday. On 9/04 we wrote ‘first observed’ with the same value. We can’t distinguish whether the same 3 sources came two days running or whether it’s an artifact of the aggregation method. We left the same problem open on 8/21~8/23 as well.
• [Cannot confirm] ATK-DF93D5 and ATK-6757C8 share the same first two masked octets, 171.249, yet have different aliases. It looks like different addresses in the same range, but the alias generation method is not documented, so we don’t assert it. We made no attempt to reconstruct the masked values.
• [Cannot confirm] SSH banner strings and RDP cookie values are values the other side sends about itself, so they can be forged. We have no means of verifying them.

Deliberately not published · not connected

• [Excluded] For 1 Discord webhook address obtained through a separate channel, the data does not reveal which of yesterday’s sessions or samples it connects to. It appears in none of yesterday’s downloads, so we did not use it in connection with yesterday’s events. A webhook token is itself an abusable value, so we do not reproduce it in the body. Several posts since 8/17 have excluded it for the same reason.
• [Excluded] The 6,622 CVEs · 390 CISA KEV entries · 98 confirmed ransomware cases that came in as background statistics, and the top EPSS list, are values pulled from KISA security notices. There is no basis connecting them to yesterday’s honeypot observations, so we did not include them in the factual account.
• [Cannot confirm] We report observed distribution points and C2s to C-TAS, but all that gets confirmed is that the transmission succeeded. Whether KISA ingested it requires separate confirmation.

What we make no judgment about at all

• ASN · ISP — We have no such database. We do not infer. The hosting providers for yesterday’s distribution points 185[.]93[.]89[.]72 · 5[.]182[.]210[.]174 · 31[.]77[.]227[.]121 also cannot be confirmed.
• Geolocation — Same as above. IP geolocation is not a basis for attribution in the first place. The locations of the up to 766 sources that made contact yesterday cannot be confirmed, and we do not name any particular country, company, or individual as the attacker.
• VPN · Tor · cloud status — We have no means of determining this.
• Whether the samples are malicious — We have not integrated VirusTotal. The antivirus detection names and detection rates for yesterday’s 7 stored files (6 from sensor 01 + 1 from sensor 02) cannot be confirmed.
• User-Agent — Neither observation surface is HTTP. Sensor 01 is SSH and Telnet; sensor 02 is SMB, RDP, VNC, MSSQL, LDAP, and ADB.
• CVE linkage — SSH and Telnet attacks generally don’t reference a CVE, and sensor 02 is at the negotiation stage, so the same applies. There is no basis for saying any contact observed yesterday attacked a specific CVE.
• Raw commands · file contents · TTY replays — We don’t have them. We know only the fact that 913 sessions were recorded; what was on those screens we cannot say here.
• Source identity — An alias (ATK-XXXXXX) is only a marker pointing to the same source across posts; it is not an identity. We do not reconstruct the last two masked octets.

Of everything that came into our server yesterday, only one file was new, and even that was a twelfth rebuild. What remained was the same script for a 20th day and the same 3.7-second session for an eighth time.

So what got fixed yesterday wasn’t on the attacker’s side. It was our list. 50 became 35 not because there were fewer people but because the board scrolled, and it took us twenty days to notice. Writing down what kind of board a number is written on, alongside the number itself, is the most useful thing we learned yesterday.

The observation date is 2026-09-05, and sensor 01 figures are on a daily-aggregate basis. Source IPs are written with the last two octets hidden and are not reconstructed. Distribution addresses are defanged so they cannot be visited. Only the 20 credentials repeatedly observed from 3 or more distinct IPs are quoted; the 935 seen from fewer than 3 are counted only, with their values not written down.