264 Sources Each Brushed Past Once — The Day the Doorway Got Thin

Open your apartment’s front door in the morning and there are flyers stuck to it. Say there were thirty yesterday and thirty again today.

Is it the same thirty?

Yesterday, three people each stuck up ten and left. Today, thirty people each stuck up one. The paper piled at your door is the same thirty sheets, but the number of people who walked past it went up tenfold.

Count only the paper and the two days are identical. Count the people and they become different days.

That is exactly what happened on our server yesterday. The paper stuck to the door rose 1.4x, but the number of places doing the sticking rose 2.6x.

First, the numbers

FACT We run two honeypot servers. A honeypot is a decoy server we deliberately leave open to watch who does what. Yesterday, the number of places that knocked on the screen-sharing port of one of them (sensor 02) was 264. The day before, it was 100.

FACT Those 264 are the highest across 12 days of observation (8/26–9/6). Laid out in order, the 12 days read 40 · 38 · 50 · 36 · 45 · 46 · 78 · 62 · 135 · 69 · 100 · 264. Against the previous high of 135 places on September 3, that is 1.96x; against the 100 of the day before yesterday, 2.64x.

FACT But the number of knocks went from 33,975 to 48,605. That is 1.4x.

INFERRED The two moved in different directions. Paper rose 1.4x while people rose 2.6x. Divide them out and the answer appears.

FACT The number of knocks per place was cut in half in a single day. Divide the day into minutes and it lands. On August 29, one place turned the doorknob once every 1 minute 20 seconds, all day long. The day before yesterday it was once every 4 minutes; yesterday, once every 8 minutes.

INFERRED We read this not as the hard hitters weakening, but as a thin, grazing layer newly stacked on top. The people posting a hundred flyers each are still there; there are just far more people posting a single one on their way past.

That thin layer is actually visible

FACT Of the 483 places that touched sensor 02 yesterday, the top 12 generated 44,439 events. That is 88.1% of the day’s total of 50,417.

FACT Even inside those 12 there are layers. The top 9 generated 3,499–5,379 each, 42,990 (85.3%) combined. From 10th place down it drops off a cliff: 700 · 514 · 235.

FACT The remaining 471 places outside the top 12 generated 5,978 in total. That is an average of 12.7 each.

INFERRED Put back into flyers: the nine who come every day each post 4,000 sheets. The other 471 each posted twelve on their way past. Two completely different crowds overlap at the same door, and what grew yesterday was the second one.

Up to 897 places came by the door

FACT Combining both servers, the unique sources that made contact yesterday number at most 897. That is the largest value across 22 days of archive; the previous maximum was 777 places on September 3.

FACT There is a reason we write “at most.” Our data does not tell us whether the same place hit both servers. So it is an upper bound from simply adding the two values. To the extent they overlap, the real number is smaller.

FACT These two servers have never announced their address anywhere. Never advertised, never linked.

INFERRED So this is not someone picking us out. It is someone sweeping addresses end to end and catching us. Simply leaving a port open puts you on the list within a day.

The same day, and every door behaved completely differently

FACT Sensor 02 has six doors open. Yesterday it saw 50,417 contacts from 483 unique sources. Adding the six services’ contacts gives exactly 50,417, matching the total.

FACT Same day, same server, and the distributions are opposites. 264 places knocked on the screen-sharing door 48,000 times; 46 places knocked on the database door exactly 77 times. That is only 1.67 touches per place.

FACT The LDAP door’s 14 contacts are the lowest across 12 days of observation. The previous low was 36 on September 3.

INFERRED We read this not as a difference in how many sheets got posted per door, but as a difference in why they came. Some doors are things you rattle all day; others are things you note down once — “ah, there’s a door here” — and walk past.

Things the other side said about itself

FACT Before connecting, screen sharing has both sides agree: “I’ll talk in version such-and-such.” Yesterday the versions the other side proposed were 003.003 47,446 times and 003.008 889 times. 98.2% of the 48,335 contacts with a recorded version were the old version.

FACT File sharing looks similar. Of 243 dialect (mode of conversation) proposals from the other side, only 2 (0.8%) were the modern SMB 2.??? family; the other 241 were old vocabulary like NT LM 0.12 · LANMAN1.0 · Windows for Workgroups 3.1.

FACT On the remote desktop side there is a short string called a “cookie” that comes along with the connection. Yesterday’s values were hello 897 · <ip> 427 · Administr 3 · empty 3 · nmap 1 · eltons 1. One contact wrote the name of a public scanner straight into it.

FACT That said, we do not judge what a cookie value means. It is a field the client can fill with any string at all, so it is not grounds for saying a particular tool came by.

FACT And on sensor 02 there are no login successes, no commands, and no credentials. This server is low-interaction, so it never actually opens the door. What we can say here goes as far as “which door, how many places, how many times.” We count how many flyers got stuck, but what someone did after coming inside cannot be recorded in the first place.

FACT So yesterday this server took 48,000 knocks and came away with 0 files. 47 sessions came into the Android debugging channel and 0 samples remained. This channel has left samples before — 1 sample from 23 sessions on September 2, 4 samples from 32 sessions on September 3, 4 samples from 87 sessions on August 28 — but yesterday there was nothing.

The side where the door actually opens — sensor 01

Flyers only stick to the door. Opening the door is a different story. The server next to it is one where the door actually opens.

FACT Yesterday sensor 01 took 2,207 sessions. 414 unique sources, 1,889 login attempts, 2,711 commands, 1,536 screen recordings.

FACT 1,889 login attempts divided across the day is once every 46 seconds. 2,711 commands is once every 32 seconds. A pace that is neither rushed nor resting.

FACT Counting what happened inside the server yesterday by category:

FACT The 1,374 “recon” count is 1.78x the day before yesterday’s 770, and the highest in the 9 days since August 28 (995).

FACT “Granting execute permission” is the act of marking a file as “this one is allowed to run.” On Linux, without that mark a program simply will not run.

FACT “File download” 34 and “execute after download” 34 are exactly equal. It means what was downloaded went to the execution stage without exception. These two values matching has repeated almost every day since August 22.

FACT That said, only 1,667 of the 2,711 commands (61.5%) have an intent attached. What the other 1,044 were, we cannot say — the raw text is not in our hands.

48 commands in 34 seconds, and zero classifications

FACT One of the 5 sessions that logged in successfully and left commands yesterday catches the eye. From 07:05:15 to 07:05:49 — a 34-second telnet session. The alias is ATK-60E535 (218.161.x.x).

FACT That session had 48 commands and 12 downloads. 48 commands in 34 seconds is one every 0.7 seconds. It had the highest completeness score of yesterday’s sessions.

FACT But the intent list is empty. It was yesterday’s busiest session, and our classifier could not attach meaning to a single one of its 48 commands. The reason cannot be determined from the data.

FACT What this session took away was of two kinds: a 1-byte empty file (11 times) and one 202-byte shell script. A byte is one character’s worth; 202 bytes is about a line and a half of a text message.

FACT That 202-byte script (0c99433c…) is a file that appeared in the 22-day archive only on August 21 and August 23. It reappeared yesterday after 14 days, making it the third observation.

A 3.7-second session, the ninth time

FACT From 11:19:01 to 11:19:04 there was a 3.7-second SSH session (ATK-CA5936, 130.12.x.x). The time it takes to draw one breath.

FACT There was exactly 1 command, yet all five intents attached (recon · file download · granting execute permission · execute after download · planting SSH keys), and it took away 2 files. A 399-byte OpenSSH private key and 54 bytes of text.

FACT Both hashes appear in 8 archive files since August 19. Yesterday was the ninth. The client program marker is SSH-2.0-Go, the same every time.

INFERRED Back to the flyer analogy: while 264 places walked past the door posting paper, one place came in and left within 3.7 seconds. The former is easy to count; the latter is hard to see.

The marker that came most, and the marker that left something behind

FACT Every connecting program leaves a fingerprint. It is a value summarizing, in one lump, the things the other program announces up front about “how I talk.”

FACT Of the 15 fingerprints recorded yesterday, the one that came from the most places was acaa53e0… (SSH-2.0-OpenSSH_7.4) at 199 places. That is 48.1% of sensor 01’s 414 total sources. And that 199-place cluster left behind not a single sample.

FACT The only marker that actually left files yesterday was 16443846… (SSH-2.0-Go), and the places carrying that marker numbered 2.

FACT Let us stop here for a moment. This value is a fingerprint of a program build, not of a person. People using the SSH that their distribution ships by default will have the same value with no relationship to each other whatsoever. You must not read 199 places as one organization. Nor does yesterday’s 37 fingerprint clusters mean there were 37 actors.

The whole of yesterday

FACT Here is the daily tally for the side where the door actually opens (sensor 01).

FACT The per-port sum (1,883 + 324) matches the session total of 2,207 exactly. The day before yesterday 2 were off; yesterday nothing was off.

FACT And the session unit on the neighboring server (sensor 02) is different from this one, so we do not add them. The sum of unique IPs across the two servers is likewise written only as an upper bound of 897, because we do not know the overlap.

Laid out in time order it comes to this. Watch the lines marked “archive comparison” — they are things invisible from yesterday alone, visible only when set against past records.

1. (Daily tally · sensor 02)
   FACT 50,417 contacts / 483 unique sources. By service: VNC(5900) 48,605 · RDP(3389) 1,474 · SMB(445) 200 · MSSQL(1433) 77 · LDAP(389) 14 · ADB 47, and adding these six gives exactly 50,417, matching the total. VNC is 96.4% of everything
2. (Daily tally · sensor 02 · archive comparison)
   FACT The 264 VNC unique sources are the maximum across 12 days of observation (8/26~9/6: 40·38·50·36·45·46·78·62·135·69·100·264), 1.96x the previous high of 135 (9/3) and 2.64x yesterday's 100. Sensor 02's 483 total unique sources also falls outside the 12-day band of 247~327, 1.48x the previous high of 327 (9/5)
3. (Daily tally · sensor 02)
   FACT VNC contacts per source is 48,605 ÷ 264 = 184.1. Yesterday it was 33,975 ÷ 100 = 339.8, and 8/29 was 40,525 ÷ 36 = 1,125.7. Total contact volume is similar, but as the number of actors grows the load per place keeps thinning out
4. (Daily tally · sensor 02 · top sources)
   FACT The top 12 aliases' events sum to 44,439, 88.1% of the total 50,417. Of those, 9 places generated 3,499~5,379 each (42,990 total, 85.3%), and from 10th place it drops off to 700 · 514 · 235. The remaining 471 places outside the top 12 account for 5,978, an average of 12.7 each
5. (Daily tally · sensor 02)
   FACT On the same day the distribution is opposite for each service — VNC had 264 places make 48,605 contacts (184.1 per source), MSSQL had 46 places make 77 (1.67 per source), LDAP had 8 places make 14 (1.75 per source). LDAP's 14 is the lowest across 12 days of observation (previous low 36, 9/3)
6. (Daily tally · sensor 02 · protocol observation)
   FACT In VNC negotiation the RFB versions proposed by the other side were 003.003 47,446 times and 003.008 889 times — 98.2% of the 48,335 contacts with a recorded version were 003.003. Of 243 SMB dialect proposals only 2 were 'SMB 2.???', and the other 241 were SMB1-family vocabulary such as NT LM 0.12 · LANMAN1.0 · LM1.2X002 · PC NETWORK PROGRAM 1.0 · Windows for Workgroups 3.1. RDP cookies were hello 897 · <ip> 427 · Administr 3 · empty 3 · nmap 1 · eltons 1
7. (Daily tally · sensor 02 · ADB)
   FACT Samples stored from 47 ADB sessions: 0. In the archive, ADB is a channel that left 23 sessions·1 sample on 9/2, 32 sessions·4 samples on 9/3, and 87 sessions·4 samples on 8/28. Today's contact count is down from yesterday (111 sessions) but is the second highest since 8/31 (52), and yet the input is 0
8. (Daily tally · sensor 01)
   FACT 2,207 sessions / 414 unique sources / 1,889 login attempts / 2,711 commands / 1,536 TTY recordings. Port 2222(SSH) 1,883 + port 2223(telnet) 324 = 2,207, matching the session total (on 9/5, 2 were off). SSH is 85.3%, telnet 14.7%
9. (Daily tally · sensor 01 · command intents)
   FACT Recon — system 1,374 · granting execute permission 192 · execute after download 34 · file download 34 · persistence (planting SSH keys) 18 · removing traces 15. The sum is 1,667, 61.5% of all 2,711 commands, and recon alone is 50.7% of all commands. Recon went from 770 yesterday → 1,374 today, 1.78x, and is the highest in the 9 days since 8/28 (995)
10. (Daily tally · sensor 01)
    FACT 'File download' 34 and 'execute after download' 34 are exactly equal — the act of downloading led to the execution stage without exception. This matching pattern repeats on most days since 8/22
11. 2026-09-06T00:02:18Z ~ 00:03:56Z (98 seconds)
    FACT ATK-0B4A6E(122.97.x.x) telnet session. Login succeeded, 31 commands, 1 download, TTY recording present. The intents are three stages: file download → granting execute permission → execute after download. This alias is one of 9 aliases that delivered the 306-byte shell script from hxxp://185[.]93[.]89[.]72/wget
12. 2026-09-06T07:05:15Z ~ 07:05:49Z (34 seconds)
    FACT ATK-60E535(218.161.x.x) telnet session. completeness 43, today's highest, with 48 commands·12 downloads, yet the intents array is empty — the session that logged in successfully and moved the most, and our classifier attached not one intent. What this session took away was of two kinds: a 1-byte empty file (01ba4719…, 11 times) and a 202-byte POSIX shell script (0c99433c…)
13. (Archive comparison · 0c99433c…)
    FACT The 202-byte POSIX shell script 0c99433c… is recorded in the 22-day archive only on 8/21 and 8/23. Today, reappearing after 14 days, is the third observation
14. 2026-09-06T11:19:01Z ~ 11:19:04Z (3.7 seconds)
    FACT ATK-CA5936(130.12.x.x) SSH session. With 1 command all five intents attached (recon · file download · granting execute permission · execute after download · planting SSH keys) and it left 2 downloads — a 399-byte OpenSSH private key (43728fbf…) and 54 bytes of ASCII text (00b6f15c…). Both hashes are in 8 archive files since 8/19, and today is the ninth. The client is SSH-2.0-Go, fingerprint 16443846184eafde36765c9bab2f4397
15. (Daily tally · sensor 01 · client fingerprints)
    FACT Of the 15 fingerprints recorded today, the only one that delivered a sample is 16443846…(SSH-2.0-Go, 2 IPs today). The fingerprint with the most IPs today is acaa53e0…(SSH-2.0-OpenSSH_7.4) at 199 places — 48.1% of sensor 01's 414 total sources — and it delivered not a single sample
16. (Daily tally · sensor 01 · archive comparison)
    FACT Of the 9 kinds stored today, 7 are hashes present in past briefs — a8460f44…(389-byte public key) for 22 straight days since 8/16, a6296a79…(306-byte shell script) with the same hash·same URL for the 21st day since 8/17, 43728fbf…·00b6f15c… for the 9th time since 8/19, 4af5a5c9…(9 bytes) in 19 files, and 01ba4719…(1 byte) and 0c99433c…(202 bytes) also have records. The only new hashes are 32b813f0… and ba9ca1f7…
17. (Daily tally · sensor 01 · new hashes)
    FACT Both new kinds came from hxxp://5[.]182[.]210[.]174/ok, both are exactly 1,608-byte Bourne-Again shell scripts, and both were delivered by the same alias ATK-99DE57. Two files with the same URL·same size·different hashes appearing in one day also happened on 8/29. The 8/25 brief recorded 10 kinds of hash for this URL, 8/29 added 2, and 9/5 added 1, so including today's that is at least 14 kinds, and the size has been 1,608 bytes every time since the first observation on 8/17
18. (Daily tally · sensor 01 · credentials)
    FACT There are 20 combinations observed from 3 or more distinct IPs, making them quotable verbatim. The most frequent is admin/admin (22 places·47 times), followed by 345gs5662d34/345gs5662d34 (15 places·15 times), support/support (8 places·11 times), user/user (7 places·9 times), root/3245gs5662d34 (7 places·7 times). Single-source combinations counted but not quoted number 911
19. (Daily tally · both sensors combined)
    FACT Unique IP upper bound 897. It is an upper bound because the intersection of unique IPs between sensors is unknown. It is the maximum across 22 days of archive; the previous maximum was 777 places on 9/3. These two servers have never announced their address anywhere

What catches the eye above is the fourth line and the last line. One says “a thin layer of 471 places was newly stacked on,” and the other says “and so the day’s total became the 22-day maximum.” They are the front and back of the same story.

What was left at the door

FACT So you can use them for defense, here are the values verbatim. Click a value to copy it. The addresses have been defanged so they cannot be connected to — leave them as is when you use them. Compare the top two lines with the two below them — one is a value that goes stale the moment you write it down, the other has not gone stale in 22 days.

FACT Let us attach a sense of scale. 1,608 bytes is about ten lines of a text message, 389 bytes is two or three lines, 306 bytes two lines, 202 bytes a line and a half. 54 bytes is one short sentence, 9 bytes is nine English characters, and 1 byte is one character’s worth.

FACT The 389-byte one is an SSH public key. Put simply, it is a spare key that gets you in without a password. Write this value as one line into the server’s authorized_keys file (the list of permitted keys), and whoever holds that key gets in from then on without being asked for a password. Yesterday this file came from 15 distinct places, and the hash has been the same for 22 straight days since August 16.

FACT The 399-byte one, conversely, is a private key. But the data does not distinguish whether it was planted there or whether someone was trying to take one that was on the server. The unresolved item logged on August 19 is unchanged yesterday, at the ninth observation.

INFERRED And the two new files from yesterday came from the same address, at the same 1,608 bytes, with different hashes. This also happened on August 29. For this address alone, blocking by hash does not last a single day. You write down thirteen and a fourteenth shows up.

FACT Among the 9 kinds stored yesterday there were no executable binaries. That does not mean “there is no next stage,” though. We separately hold 12 distribution addresses that only appear once you unpack the archive. Looking at the surface, not one line of address is visible. However, these 12 are not connected to the 9 kinds stored yesterday. We note them only as background.

What passwords were used to try to get in

FACT The username·password combinations attempted yesterday numbered at least 931 kinds. Of those, only 20 are printed here. The remaining 911 kinds are only counted. That is a ratio of 1 to 45.6.

The reason is singular. A combination seen only from fewer than 3 distinct IPs may be a real account leaked from somewhere. We do not carry such values into our writing.

The 20 below are the opposite. They repeat from many places, so they can be regarded as factory defaults belonging to no one.

FACT admin/admin alone came 47 times from 22 distinct places. Nearly all twenty lines are either username identical to password, or exactly the path a finger traces across the keyboard.

INFERRED This is not a list built to target us. It is a dictionary running through values that work anywhere, in order. Meaning our server was opened not because it was ours.

Mapping the techniques used to the international catalog

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

• T1595.001Active Scanning: Scanning IP Blocks — up to 897 places contacted two servers that were never publicized, the maximum across 22 daysINFERRED
• T1046Network Service Discovery — 483 places contacted sensor 02's six services, with nmap appearing once in an RDP cookieINFERRED
• T1110.001Brute Force: Password Guessing — 1,889 login attempts, at least 931 distinct combinations (20 quoted + 911 single-source)INFERRED
• T1082System Information Discovery — recon (system) 1,374 times, 50.7% of all commandsINFERRED
• T1105Ingress Tool Transfer — 34 file downloads, 2 distribution points with an external URL recordedINFERRED
• T1222.002File and Directory Permissions Modification: Linux and Mac — granting execute permission 192 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — planting SSH keys 18 times, a 389-byte public key brought in from 15 distinct placesINFERRED
• T1070Indicator Removal — removing traces 15 timesINFERRED

Please note that all eight lines carry the [INFERRED] badge. What we hold goes as far as the ‘intent classification result’ for commands and ‘how many times.’ We do not have the raw commands. Fitting things to a catalog is always interpretation, and where it is interpretation we write that it is.

There have been cases like this before

INFERRED The Mirai botnet (2016). It got into IoT devices using a dictionary of default telnet accounts. The method described in the published source code and the US-CERT advisory (TA16-288A) is of the same family as what we saw on sensor 01 yesterday. It feeds combinations like admin/admin · root/root · support/support into management ports in dictionary order, and on success immediately downloads a script and grants it execute permission. Yesterday’s exact match of ‘file download 34 = execute after download 34’ has the same shape. That said, we have no grounds to say yesterday’s contacts were Mirai-family. Neither the file contents nor sample classification results are in our hands, and we do not integrate external verdicts. (Source types: published source code · government CERT advisory)

INFERRED RealVNC 4.1.1 authentication bypass, CVE-2006-2369 (2006). A flaw where the server accepted the authentication method proposed by the client as-is, letting authentication be skipped. In yesterday’s screen-sharing negotiation, 98.2% of the versions proposed by the other side were 003.003, and this old version touches the same point. RFB 3.3 is structured so that the choice of authentication method sits with the server, so there is a reason a tool broadly hunting for weakly authenticated screen-sharing servers would propose a low version first. That said, this is background explanation leaning on the protocol definition and a public CVE. There are no grounds to say yesterday’s contacts actually attacked this vulnerability, and since sensor 02 is low-interaction, the stage after authentication does not exist at all. On top of that, this distribution is ‘what the other side proposed,’ so it could also change depending on what we put forward first. (Source types: CVE and vendor advisory)

So what should you do

Back to the flyers. The number of people who walked past the door yesterday was the highest yet, but whether the door was locked is where things actually divided. Every item below is about that.

1. You are leaving management ports open straight to the internet · High likelihood Up to 897 places reached two servers that were never publicized. On the neighboring sensor alone, 264 places reached screen sharing · 111 remote desktop · 46 the database · 38 file sharing · 8 account lookup, all directly, with no prior contact. On the side where the door opens, 414 places came. There was even a contact that wrote a scanner’s name in itself. The grounds for writing likelihood as ‘High’ are not the neighboring sensor but the side where the door opens. All 5 of yesterday’s complete sessions logged in successfully. Move these behind a VPN or a jump host and most of this contact is cut off before the authentication stage.

2. You are using default accounts and weak passwords as-is · High likelihood All 20 lines in the table above are values that devices or distributions ship with from the factory. There were 1,889 attempts in a day, and yesterday’s five complete sessions all begin, without exception, after this dictionary opened the door. What followed after it opened was recon 1,374 · granting execute permission 192 · execute after download 34 · key planting 18. If this were a real production server, it opens if even one of those twenty lines is still there.

3. You allow password login and are not using key-based authentication · High likelihood The breadth of combinations attempted yesterday is at least 931 kinds. As long as password login is open, this dictionary keeps running. And the ones who get in hang their own key on the way in the moment they succeed. Yesterday key planting happened 18 times, and a 389-byte public key came in from 15 distinct places. Once someone else’s key gets one line into authorized_keys, they keep getting in with that key even if you change the password. Conversely, allow only key-based authentication and turn off passwords, and all 1,889 attempts end at the authentication stage.

4. You are not blocking outbound connections · High likelihood ‘File download’ 34 and ‘execute after download’ 34 were exactly equal. Yesterday’s distribution points with a recorded external address are hxxp://185[.]93[.]89[.]72/wget and hxxp://5[.]182[.]210[.]174/ok, two of them. Login has already been breached at that point, so cutting the server’s outbound connections is the last place where actual damage gets stopped. On top of that, the /ok side keeps changing hashes at the same size and has reached at least 14 kinds. A hash blocklist is not valid for even one day against this distribution point.

5. You are relying only on count-based blocking (fail2ban etc.) · Medium likelihood This is yesterday’s core. Sensor 02’s top 9 places knocked 3,4995,379 times each, so they trip any threshold. But on the side where the door opens, the average per place is 4.6. A common setting like ‘lock after 5 failures’ simply lets a good many through. Even among the 20 quoted combinations, the attempt counts run 447 while the observed places run 4~22 — it is not one place hitting many times, it is many places splitting one hit each. That is why it is ‘Medium’ and not ‘High.’ Per-IP lockout definitely cuts the thick layer, but it lets the thinly spread layer through. In the end, turning off password login itself is what is certain.

6. You are keeping logs only inside the server · Medium likelihood The ‘removing traces’ intent was classified 15 times yesterday. That is 1.88x the day before yesterday’s 8, but low compared to August 30’s 114 or August 25’s 70. The reason we could see it at all is that 1,536 screens were recorded separately, outside the server. Of the five sessions that logged in successfully yesterday, the longest was 98 seconds and the shortest 3.7 seconds. That is not a length a person watching a screen can notice.

What We Don’t Know

This is where this blog differs from others. We write down what we do not know as not known.

Doubts about yesterday’s subject itself

• [Cannot confirm] It is a fact that VNC unique sources jumped from 100 to 264. It is highly likely the sources actually increased, but we cannot rule out that the counting basis or the deduplication method changed. Just the day before yesterday (9/5) we discovered that another field was not a ‘cumulative’ value but one counting only a recent window. There is reason to doubt this data’s aggregation basis. Yet the counting window is not written down anywhere, so we cannot settle it.
• [Cannot confirm] Sensor 02’s total unique sources is 483, but adding up the per-service sources gives 467. 16 places were not caught by any service. Since there is no ADB row in the service list, it is highly likely they are ADB-only sources, but the data does not say so.
• [Cannot confirm] Whether one source swept several doors together cannot be computed. The per-source service pairings are not in the data, and the per-service sum (467) is smaller than the total (483), so we cannot back out the overlap either. Writing this value as 0 would be false, so we leave it as ‘cannot be derived.’ We handled August 29 the same way.

Things in yesterday’s data that are not explained

• [Cannot confirm] ATK-60E535 had yesterday’s highest completeness and a successful login·48 commands·12 downloads, yet the intent list is empty. We cannot know why our classifier attached nothing to 48 commands. It may be the same problem as only 1,667 of yesterday’s 2,711 commands (61.5%) being classified.
• [Cannot confirm] ATK-7F4B44 and ATK-DFBDF7 have ‘file download’·‘execute after download’ in their intents, yet their download count is 0. The data does not distinguish whether the download failed or whether it was dropped at the storage stage.
• [Cannot confirm] ADB contact was 47 sessions, yet stored samples were 0. There were samples on September 2 (23 sessions·1 sample) · September 3 (32 sessions·4 samples) · August 28 (87 sessions·4 samples). We have no grounds to distinguish whether the other side did not put anything in or whether we failed to receive it.
• [Cannot confirm] Against 48,605 screen-sharing contacts, version records number 48,335, so 270 are missing; against 1,474 remote desktop contacts, cookie records number 1,332, so 142 are missing. The reason for either difference is not explained.
• [Cannot confirm] The 243 file-sharing dialect proposals exceed the 200 sessions. This appears to be a property of one session proposing several dialects together, but since it is not stated, we cannot assert the relationship between sessions and proposals.
• [Cannot confirm] The data does not distinguish whether the 399-byte private key was planted or whether someone was trying to take it. It is in the download list, but the address field is empty. The unresolved item from August 19 is unchanged yesterday, at the ninth observation.
• [Cannot confirm] From hxxp://5[.]182[.]210[.]174/ok, two different hashes at the same 1,608 bytes came from the same alias on the same day. What differed cannot be confirmed, since we do not hold file contents. Nor can we distinguish whether it is regenerated per request or swapped out on a short cycle. The same item from 8/22 · 8/23 · 8/25 · 8/27 · 8/29 · 9/5 stands unchanged.
• [Cannot confirm] For the cumulative number of hash kinds at this address we can state only a lower bound. 10 kinds on 8/25 + 2 on 8/29 + 1 on 9/5 + 2 yesterday gives at least 14 kinds, and it is not a value from an exhaustive hash-level comparison across the 22-day archive.
• [Cannot confirm] 4 of yesterday’s 5 complete sessions were telnet, yet telnet is only 324 of 2,207 (14.7%). This points the same direction as the August 16 observation that ‘the door most knocked on and the door that actually opens are different,’ but this is a top-5 sample, so we cannot compute a per-protocol success rate.
• [Cannot confirm] Screen recordings are written as 1,536 in one place and 230 in another. The relationship between the two values is not stated.
• [Cannot confirm] The total number of fingerprint clusters is 37, yet only 15 are listed. What values the other 22 are, we cannot know.

Things deliberately not printed · not connected

• [Excluded] For 1 Discord webhook address obtained through a separate channel, the data does not reveal which of yesterday’s sessions·samples it connects to. It does not appear in any of yesterday’s download items, so we did not use it in connection with yesterday’s events. A webhook token is itself an abusable value, so we do not carry it into the body. Several posts since August 17 have excluded it for the same reason.
• [Excluded] The background statistics that came in — 6,622 CVEs · 390 CISA KEV · 98 confirmed ransomware — are values pulled from KISA security notices. They are not connected to yesterday’s observations on the two servers, so we did not use them as grounds for anything written here.
• [Cannot confirm] We report observed distribution points·C2 to C-TAS, but what gets confirmed goes only as far as the transmission succeeding. Whether yesterday’s report was actually reflected requires separate confirmation.
• [Cannot confirm] The 12 distribution addresses that only appear once you unpack the archive are not connected to the 9 kinds stored yesterday. We used them only as background for the point that ‘zero executable binaries yesterday’ does not mean ‘there is no next stage.’

Things we do not judge at all

• ASN·ISP — We have no relevant database. We do not infer. The hosting providers for yesterday’s distribution points 185[.]93[.]89[.]72 · 5[.]182[.]210[.]174 are likewise unconfirmable.
• Geolocation — Same as above. IP geolocation is not grounds for attribution in the first place. The locations of the up to 897 places that made contact yesterday cannot be confirmed.
• VPN·Tor·cloud status — We have no means of determining it. Whether sensor 02’s top sources yesterday came from the cloud we cannot say either.
• Whether samples are malicious — We have not integrated VirusTotal. We cannot back up whether yesterday’s 2 new kinds are malicious with an external verdict.
• Client program markers — A fingerprint is a fingerprint of a build, not of a person. Unrelated people using their distribution’s default SSH have the same value. You must not read a 199-place cluster as one actor.
• User-Agent — Neither observation surface is HTTP. Sensor 01 is SSH·telnet; sensor 02 is SMB·RDP·VNC·MSSQL·LDAP·ADB.
• CVE linkage — SSH·telnet attacks generally do not reference a CVE, and sensor 02 is the same since it is at the negotiation stage. The CVE-2006-2369 written above is background explanation, not a link to yesterday’s contacts.
• Raw commands · file contents · screen replays — Not in our hands. We know only the fact that 1,536 were recorded; what was on the screens cannot be said here.
• Source identity — An alias (ATK-XXXXXX) is merely a marker pointing to the same source across posts; it is not an identity. We do not restore masked positions, and we do not name any country, company, or individual as an attacker.

The paper stuck to the door yesterday rose 1.4x, but the places doing the sticking rose 2.6x. What each place did actually thinned by half, and 471 places posted an average of just twelve sheets on their way past.

So yesterday’s record is not “we got hit harder” but “more of them brushed past.” These are different sentences, and the response differs too. In the face of many places brushing past once each, a rule that says “lock after N failures” does not even fire.

And while those 264 places were walking past the door, on the neighboring server one 3.7-second session hung a key and left. Counting the people who came by the door will not catch that. Because it is not a thing to count but a door to lock.

The observation date is 2026-09-06, and both sensor 01 and 02 are on a daily-tally basis. Source IPs are written with the last two segments hidden and are not restored. Distribution addresses have been defanged so they cannot be connected to. Credentials are quoted for only the 20 kinds repeatedly observed from 3 or more distinct IPs; the 911 kinds seen from fewer than 3 places are only counted, with their values not written down.