The Same 109 Callers, but the Bell Rang 24× More

Suppose your home phone shows 300 missed calls.

There are two ways to read that. It could be 300 people calling once each, or three people calling 100 times each. If you only look at the missed-call number, both cases are identically 300.

Counting calls doesn’t work. You have to count the numbers to tell them apart.

That is exactly what happened on our server yesterday. The bell rang 24× more, but the numbers calling were 109 — the same as usual.

First, how many times did the bell ring

FACT We run two honeypot servers. A honeypot is a decoy server left open on purpose so we can watch who does what. On one of them (Sensor 02), knocks on the remote desktop port came to 34,811 yesterday. Remote desktop is that feature where you pull up your office computer’s screen from home, and the port number is 3389.

FACT The number alone doesn’t land, so let me put something next to it. Add up every knock on this door across the 14 days from August 26 to September 8 and you get 21,483. That is an average of 1,534 per day.

FACT Yesterday alone was 1.62× that 14-day total. Against the previous high of 3,410 on August 31, it is 10.21×; against 1,443 on September 8, 24.1×.

FACT Divide the day into seconds and it looks like this. 34,811 knocks means the bell rang once every 2.5 seconds, all day long.

FACT Lay the 14 days out in order and you can see how far yesterday sticks out.

FACT You’ll notice September 9 is missing. That day’s record file is not in our archive. So every “previous” in this post is measured against September 8. What happened on the 9th is something this post cannot answer.

But the number of callers was 109

FACT This is yesterday’s core. Those 34,811 knocks came from 109 unique sources. Over the past 14 days this value ranged between 102 and 164. Yesterday’s value is inside that range — in fact it is the second lowest.

FACT Divide it out and the answer appears.

INFERRED Back to the phone. On September 8, 110 people each called about thirteen times a day. Yesterday, the same 109 people each called 319 times. One person redialing once every 4 minutes 30 seconds, from midnight to midnight, without a break. The number of callers stayed the same while what one caller does became 24.4× larger.

INFERRED In the September 6 post we wrote down exactly the opposite shape. That day the number of people went up and what each one did got thinner. Yesterday the people stayed the same and each one got thicker. Look only at the total and both read as “it went up” — but the ways to block them differ.

What was written in the caller-name field

FACT Remote desktop sends a short string along when it starts a connection. It is a field called a “cookie,” and the calling side fills in the value itself. It has the same character as the caller name that shows up on your phone screen.

FACT Here is what was written in that field yesterday.

FACT That sums to 32,489. It is 93.3% of yesterday’s 34,811 remote desktop contacts, and the remaining 2,322 (6.7%) had this field empty. mstsc alone is 92.0% of all contacts, and 98.6% if you count only the ones where a value was recorded.

FACT mstsc is the same string as the executable file name of the remote desktop program that ships with Windows.

FACT And this name appeared out of nowhere yesterday. The same field for the previous three days looked like this.

FACT In our records the daily maximum for this name was 11 (September 7). Yesterday it was 32,042.

FACT We read the 6 Administr entries as the shape you get when an account name is written into this field and it gets cut off at nine characters. Those are the first nine characters of Administrator. But we do not export the raw negotiation frames, so we cannot confirm this.

INFERRED Let’s stop here for a moment. That this field’s value is mstsc means the other side wrote it that way — it is not evidence that they actually used that program. It’s the same as how “delivery” showing up as a caller name doesn’t make someone a delivery driver. What we have is only the distribution of strings.

Did one number make all the calls

FACT The alias with the most contacts on Sensor 02 yesterday was ATK-E37B01 (149.50.x.x) with 34,229. That is 34.0% of this server’s 100,752 total for the day.

FACT From second place it runs 8,090 · 7,995 · 7,323 · 5,364 · 5,316 · 2,844 · 2,840 · 2,163, then drops off a cliff from tenth place at 681 · 648 · 238. The top 12 produced 77,731 (77.2%), and the remaining 599 places produced 23,021 all together. That is an average of 38.4 per place.

INFERRED The 34,229 from first place and yesterday’s remote desktop total of 34,811 differ by 582. When numbers line up like that, it’s tempting to read most of yesterday’s increase as coming from this one place.

FACT But we cannot say that. Our data does not record which service each source knocked on. The data does not tell us whether this alias knocked on remote desktop or on screen sharing. All we have is the circumstantial fact that the numbers are close.

How were the neighboring lines

FACT This server has six doors left open. Yesterday’s contacts came to 100,752 with 611 unique sources. Divide the day into seconds and it is once every 0.86 seconds. Add up the contacts across the six services and you get exactly 100,752, matching the total.

FACT Same day, same server, and yet each door has a completely different character. The database door was knocked on exactly 59 times by 43 places. Each place touched it 1.37 times and moved on. The directory lookup door had only 12 places but 166 knocks — a concentrated-few shape — and those 166 sit in the upper part of the 14-day band (5–222).

FACT What jumped yesterday was not screen sharing. Screen sharing came to 65,487 · 387 places, effectively the same as September 8’s 65,322 · 416 places. Contacts rose 0.25% and sources fell 7.0%.

FACT This door had been on a rising curve — August 26 at 40,791 → September 6 at 48,605 → September 7 at 58,811 → September 8 at 65,322 — and it now looks like it has stalled around 65,400 for a second day.

The version the other side declared for itself

FACT Before connecting, screen sharing has both sides agree: “I’ll speak version such-and-such.” The versions proposed by the other side yesterday were 003.003 63,144 times and 003.008 1,852 times. Of the 64,996 where a version was recorded, 97.2% were the oldest one. 491 had no version recorded.

FACT File sharing looks the same. The dialects (ways of talking) proposed by the other side numbered 336, and of those, the modern SMB 2.??? family is only 2 (0.6%). The remaining 334 were old vocabulary like NT LM 0.12 73 · LANMAN1.0 65 · LM1.2X002 65 · PC NETWORK PROGRAM 1.0 33 · Windows for Workgroups 3.1 33 · LANMAN2.1 33 · LANMAN 32.

INFERRED Leading with the oldest version is closer to the behavior of a general-purpose tool trying to get a reply even out of old systems. It’s like dialing random numbers and opening with the words that are easiest to understand. It does not mean our server is outdated, and it does not mean a specific vulnerability was being targeted. We do not connect yesterday’s contacts to any CVE.

The one file this server picked up yesterday

FACT Sensor 02 saved exactly one file yesterday. It is 46,582 bytes (7a48c93c…), dropped once by the alias ATK-2DD9A8.

FACT This hash is the same value and the same size as the one recorded in the September 3 notes as “a new file that had not appeared once in 18 days of archive.” The alias that delivered it then was ATK-5A7674. This is the second observation, a week later.

FACT And here we have to stop once more. This server does not actually open the door. It is low-interaction, so successful logins, commands, and credentials do not exist here to begin with. What we can say here goes as far as “which door was knocked on, by how many places, how many times” and “what the other side said as an opener.” We count how many times the bell rang, but since we never picked up, what they were going to talk about cannot be recorded.

The phone that actually answers — Sensor 01

The other server next to it answers the phone. The door actually opens, and what happens after it opens is left behind.

FACT This side took in 2,412 sessions yesterday. 296 unique sources, 2,017 login attempts, 2,293 commands, 1,783 screen recordings.

FACT 2,017 login attempts divided across the day is once every 43 seconds. 2,293 commands is once every 38 seconds. A pace that is neither rushed nor resting.

FACT By port: 2222 (SSH) 2,071 + 2223 (Telnet) 341 = 2,412, exactly matching the total. SSH is 85.9%, Telnet 14.1%, and 73.9% of sessions left a screen recording.

FACT Counting by type what happened after the door opened looks like this.

FACT The sum is 1,973, which is 86.0% of all commands. Reconnaissance alone is 74.1% of all commands. That is larger than September 6’s 1,374 and August 28’s 995.

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

FACT “File download” at 23 and “execute after download” at 23 are exactly the same. It means what was downloaded went on to the execution step without exception. These two values matching up repeats on most days since August 22.

Three times within 18 minutes, in the same shape

FACT From 00:41:45 to 00:44:45 there was a 180-second Telnet session (ATK-B108F9, 180.233.x.x). The login succeeded, with 26 commands and 1 download. The order was three steps: download the file → grant execute permission → execute.

FACT The same shape repeated three times within 18 minutes. At 00:55:57, ATK-F5E7E2 (85 seconds · 31 commands); at 00:59:12, ATK-B949E7 (68 seconds · 31 commands). All three are among the 8 aliases that delivered the 306-byte shell script from hxxp://185[.]93[.]89[.]72/wget.

FACT From 08:19:36 to 08:20:39, one 63-second session was the only session yesterday with as many as five intents attached (reconnaissance · file download · granting execute permission · execute after download · planting an SSH key) (ATK-6BC9D8, 108.165.x.x). And yet the stored downloads number 0. The download intent was classified, but there is no file.

FACT From 11:08:00 to 11:09:06, a 66-second session (ATK-6C52B2, 91.81.x.x) had yesterday’s highest completeness score (42) and 11 downloads. But the only intent attached was “impairing defenses,” and nothing else. Since yesterday’s total for impair-defenses commands is 1, that 1 is this session.

FACT All 11 things this session took away were 1-byte empty files. One byte is the size of a single character. This shape — the one that moved the most came away with empty files — also appears in the August 17 · August 22 · September 6 records.

Everything that came in yesterday adds up to 705 bytes

FACT Four kinds of files were stored on this server yesterday, and zero of them are executable binaries. Add up the four sizes and you get 705 bytes — about four or five lines of a text message. That is 1/66th of the single file (46,582 bytes) the neighboring server picked up yesterday.

FACT All four are hashes we have seen before. The 389-byte public key (a8460f44…) is in all 24 archived files, and yesterday alone 17 aliases delivered it 17 times. The 306-byte shell script (a6296a79…) is in 23 files under the same hash, and 8 aliases delivered it yesterday. The 1-byte empty file is recorded in 13 files, and the 9-byte text in 22 files.

FACT The 389-byte one is an SSH public key. Put simply, it is a spare key that lets 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 afterward without ever being asked for a password.

The marker that came from the most places, and the marker that dropped things off

FACT Every program that connects leaves one fingerprint behind. It is a value that summarizes, in one lump, the things the other program announces up front about “this is how I talk.”

FACT Of the 12 fingerprints recorded yesterday, the one that came from the most places was acaa53e0… (SSH-2.0-OpenSSH_7.4) with 112 places. That is 37.8% of this server’s 296 total sources. And yet this group left behind not a single sample.

FACT The only marker that actually dropped a file yesterday was 16443846… (SSH-2.0-Go), and the places arriving with this marker numbered 3.

FACT This value is a fingerprint of a program build, not a fingerprint of a person. People using the SSH that a given distribution ships by default will have the same value even with no relationship to one another. You must not read 112 places as one organization.

FACT And Telnet leaves no such fingerprint at all. So the 5 notable sessions written above all have an empty string in the fingerprint field. These sessions cannot be attached to any group.

What passwords did they try to get in with

FACT The ID/password combinations attempted yesterday numbered 1,836 kinds. Of those, only 8 kinds appear here. The remaining 1,828 kinds are only counted.

The reason is one thing. A combination seen from fewer than 3 different IPs could be a real account leaked from somewhere. We do not transcribe such values into our posts.

The 8 below are the opposite. They repeat across many places, so they can be seen as “factory defaults belonging to no one.”

INFERRED Let me attach one number here. Add up the attempts for these 8 kinds and you get 101. Since yesterday’s login attempts were 2,017, the remaining 1,916 are spread across 1,828 kinds. That is an average of 1.05 per combination.

INFERRED Rather than hammering the same password many times, it has the shape of sweeping through different passwords once each. 99.6% of the combinations used yesterday were used effectively only once for the day. This is not a list built to target us; it is a dictionary of values that work anywhere, fed in order.

The whole of yesterday

FACT Here is the daily tally for the side that actually answers the phone (Sensor 01).

FACT The 100,752 from the neighboring server (Sensor 02) are not added in, because the unit of counting differs. This side counts “sessions” and that side counts “contacts.” The source data forbids summing them for the same reason.

FACT The unique sources across both servers combined is at most 907. It is an upper bound arrived at by simple addition, because the data does not tell us whether the same place came to both servers. To the extent they overlap, the real number is smaller. The maximum across 24 days of archive was 897 on September 6, so yesterday is a new maximum.

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

Laid out in chronological order, it looks like this. Pay attention to the lines marked “archive comparison” — those are the things you cannot see by looking at yesterday alone, only by placing it alongside past records.

1. (Daily aggregate · Sensor 02)
   FACT 100,752 contacts / 611 unique sources. By service: VNC(5900) 65,487 · RDP(3389) 34,811 · SMB(445) 198 · LDAP(389) 166 · MSSQL(1433) 59 · ADB 31, and adding these six gives exactly 100,752, matching the total. RDP is 34.6% of the whole, VNC 65.0%
2. (Daily aggregate · Sensor 02 · RDP · archive comparison)
   FACT RDP's 34,811 is 1.62× the 21,483 total across 14 observed days (8/26~9/8: 1,221 · 1,425 · 2,114 · 1,064 · 2,139 · 3,410 · 2,030 · 808 · 568 · 795 · 918 · 1,474 · 2,074 · 1,443). The previous high was 3,410 on 8/31, so today is 10.21× that, and 24.1× compared with 1,443 on 9/8
3. (Daily aggregate · Sensor 02 · RDP)
   FACT RDP unique sources number 109. The 14-day band is 102~164 and today's value is the second lowest. Contacts per source is 34,811 ÷ 109 = 319.4, an order of magnitude apart from 9/8's 13.1 (1,443÷110) and 8/31's 20.8 (3,410÷164)
4. (Daily aggregate · Sensor 02 · protocol observation)
   FACT Cookie values recorded in RDP negotiation were mstsc 32,042 · <ip> 418 · hello 16 · Administr 6 · empty 4 · Test 3, totaling 32,489, which is 93.3% of the 34,811 RDP sessions. The remaining 2,322 (6.7%) had no cookie value recorded. mstsc alone is 92.0% of all RDP and 98.6% of recorded cookies
5. (Daily aggregate · Sensor 02 · archive comparison · RDP cookies)
   FACT The cookie distribution flipped in a single day. 9/6 was hello 897 · <ip> 427 · Administr 3 · empty 3 · nmap 1 · eltons 1 with mstsc at 0; 9/7 was hello 1,391 · <ip> 448 · mstsc 11 · eltons 2 · empty 2 · Test 2; 9/8 was hello 845 · <ip> 442 · empty 5 · random 9-digit 3 with mstsc at 0. Today it is mstsc 32,042 · hello 16
6. (Daily aggregate · Sensor 02 · RDP cookie interpretation)
   INFERRED mstsc is the same string as the executable file name of the default Windows remote desktop client. This value arrived in a field the client fills in itself on the connection request; it is not evidence that the other side actually used that program. The 6 'Administr' entries read as the shape produced when an account name is written into this field and cut off at 9 characters — since we do not export the raw frames, this cannot be confirmed
7. (Daily aggregate · Sensor 02 · top sources)
   FACT The most-contacting alias ATK-E37B01(149.50.x.x) has 34,229, which is 34.0% of Sensor 02's 100,752 total. From second place it runs 8,090 · 7,995 · 7,323 · 5,364 · 5,316 · 2,844 · 2,840 · 2,163, dropping sharply from tenth place at 681 · 648 · 238. The top 12 sum to 77,731 (77.2%), while the remaining 599 places account for 23,021, an average of 38.4 per place
8. (Daily aggregate · Sensor 02 · correspondence)
   INFERRED The top alias's 34,229 and the RDP total of 34,811 differ by 582. We read this as a strong possibility that most of today's RDP surge came from this single source. However, the data has no per-source service mapping, so we cannot confirm whether this alias knocked on RDP or on VNC — it is only the circumstance that the numbers line up
9. (Daily aggregate · Sensor 02 · VNC · archive comparison)
   FACT VNC is 65,487 · 387 places, effectively the same as 9/8's 65,322 · 416 places (contacts +0.25%, sources −7.0%). The curve that had been rising — 8/26 40,791 → 9/6 48,605 → 9/7 58,811 → 9/8 65,322 — appears to have stalled around 65,400 for a second day. What jumped today is not VNC but RDP
10. (Daily aggregate · Sensor 02 · protocol observation)
    FACT The RFB versions proposed by the other side in VNC negotiation were 003.003 63,144 times and 003.008 1,852 times, so 97.2% of the 64,996 recorded were the oldest 003.003 (491 had no version recorded). For SMB, the proposed dialects were NT LM 0.12 73 · LANMAN1.0 65 · LM1.2X002 65 · PC NETWORK PROGRAM 1.0 33 · Windows for Workgroups 3.1 33 · LANMAN2.1 33 · LANMAN 32 · SMB 2.??? 2, so of 336 total only 2 (0.6%) are the SMB2 family
11. (Daily aggregate · Sensor 02 · interpretation)
    INFERRED Proposing the oldest versions and dialects first is closer to the behavior of a general-purpose scanner trying to draw a response even from old systems. It does not mean our server is outdated, nor that a specific vulnerability was targeted — we have no basis for a CVE link
12. (Daily aggregate · Sensor 02 · remaining services)
    FACT The shape is opposite from service to service. VNC had 387 places knocking 65,487 times (169.2 per source) and RDP had 109 places knocking 34,811 times (319.4), whereas MSSQL had 43 places knocking 59 times (1.37) and SMB 42 places knocking 198 times (4.71). Only LDAP is a concentrated-few shape, with 12 places knocking 166 times (13.8), and those 166 sit in the upper part of the 14-day band (5~222)
13. (Daily aggregate · Sensor 02 · samples)
    FACT The one file Sensor 02 stored today is 7a48c93c…(46,582 bytes, ATK-2DD9A8, once), matching the tallied sample count of 1. This hash is the same value and the same size as the one recorded in the 9/3 brief as 'new, not in 18 days of archive,' and the delivering alias at that time was ATK-5A7674 (3 times). This is the second observation, a week later
14. (Daily aggregate · Sensor 01)
    FACT 2,412 sessions / 296 unique sources / 2,017 login attempts / 2,293 commands / 1,783 TTY recordings. Port 2222(SSH) 2,071 + port 2223(Telnet) 341 = 2,412, exactly matching the session total. SSH is 85.9%, Telnet 14.1%, and 73.9% of sessions left a TTY recording
15. (Daily aggregate · Sensor 01 · command intent)
    FACT Reconnaissance — system 1,700 · granting execute permission 191 · execute after download 23 · file download 23 · persistence (planting an SSH key) 18 · erasing traces 17 · impairing defenses 1. The sum of 1,973 is 86.0% of all 2,293 commands, and reconnaissance alone is 74.1% of all commands. That is larger than 9/6's reconnaissance count of 1,374 and 8/28's 995. 'File download' at 23 and 'execute after download' at 23 being exactly equal is a shape that repeats on most days since 8/22
16. (Daily aggregate · Sensor 01 · credentials)
    INFERRED Only 8 combinations were observed from 3 or more different IPs and can therefore be quoted verbatim, while 1,828 combinations came from a single source and were only counted. The 8 quotable ones total 101 attempts, so the remaining 1,916 are spread across 1,828 combinations — an average of 1.05 per combination. It means 99.6% of the 1,836 distinct combinations observed today were used effectively only once for the day
17. 2026-09-10T00:41:45Z ~ 00:44:45Z (180초)
    FACT ATK-B108F9(180.233.x.x) Telnet session. Login succeeded, 26 commands, 1 download, TTY recording present. The intents are three steps: file download → granting execute permission → execute after download. The same shape repeated three times within 18 minutes at 00:55:57 with ATK-F5E7E2 (85 sec · 31 commands) and at 00:59:12 with ATK-B949E7 (68 sec · 31 commands), and all three are among the 8 aliases that delivered the 306-byte shell script from hxxp://185[.]93[.]89[.]72/wget
18. 2026-09-10T08:19:36Z ~ 08:20:39Z (63초)
    FACT ATK-6BC9D8(108.165.x.x) Telnet session. Login succeeded, 17 commands, and it is today's only session with 5 kinds of intent attached (reconnaissance · file download · granting execute permission · execute after download · persistence, planting an SSH key). And yet the download count is 0 — the download intent was classified, but no file was stored
19. 2026-09-10T11:08:00Z ~ 11:09:06Z (66초)
    FACT ATK-6C52B2(91.81.x.x) Telnet session. Completeness 42, today's highest, with 11 downloads, and yet the only intent attached is 'impairing defenses.' Since today's total for impair-defenses commands is 1, that 1 is this session. All 11 items taken away are the 1-byte empty file 01ba4719… — the same 'moved the most but came away with empty files' shape also appears in the 8/17 · 8/22 · 9/6 briefs
20. (Daily aggregate · Sensor 01 · downloads · archive comparison)
    FACT Of the 4 kinds stored today, 0 are executable binaries. a8460f44…(389-byte OpenSSH RSA public key) is in all 24 archived files and was delivered 17 times by 17 aliases today. a6296a79…(306-byte POSIX shell script, hxxp://185[.]93[.]89[.]72/wget) is in 23 files under the same hash and was delivered by 8 aliases today. 01ba4719…(1 byte) is recorded in 13 files, and 4af5a5c9…(9-byte ASCII) in 22 files. Adding the four file sizes gives 705 bytes
21. (Daily aggregate · Sensor 01 · client fingerprints)
    FACT Of the 12 fingerprints, the one with the most IPs today is acaa53e0a7d7ac7d1255103f37901306(SSH-2.0-OpenSSH_7.4) at 112 places — 37.8% of Sensor 01's 296 total sources — yet it delivered no samples. The only fingerprint that delivered samples today is 16443846184eafde36765c9bab2f4397(SSH-2.0-Go, 3 places today). Telnet leaves no hassh, so the 5 notable sessions all have empty strings for fingerprint and client
22. (Daily aggregate · both sensors combined)
    FACT Unique IP upper bound of 907. It is an upper bound because the intersection of unique IPs between sensors is unknown, and the real value is at or below it. The maximum across 24 days of archive (8/16~9/8) was 897 (9/6) and 9/8 was 850, so today is a new maximum. These two servers have never announced their address anywhere

The ones to read together from above are the third line and the eighth line. One says “the places calling were 109, as usual,” and the other says “and yet one place produced 34% of the whole.” They are the front and back of the same story, but our data does not connect the two.

What was left at the door

FACT Here are the values transcribed as-is so you can use them for defense. Click a value to copy it. The addresses have been defanged so they cannot be visited — leave them as they are and use them. Compare the top two lines with the bottom two — the top ones are values that did not change across all 24 days, and the bottom ones are re-appearances for which yesterday was not the first day.

FACT Let me attach a sense of size. 389 bytes is two or three lines of a text message, 306 bytes is two lines, 9 bytes is nine English characters, and 1 byte is a single character. Add up all four that Sensor 01 received yesterday and you still get 705 bytes.

FACT The 46,582-byte one at the bottom is 66× all four above combined. But this server’s records have no field for file type at all, so what it is cannot be said here.

Mapping the attackers’ techniques to the international classification

MITRE ATT&CK is an international list that assigns a number to each attack technique. Matching yesterday’s behavior to those numbers gives this. Press an ID to go to the original description — we link it so you don’t take our word for it and can check directly.

• T1595Active Scanning — Sensor 02's 34,811 RDP and 65,487 VNC contacts, and observations at the protocol negotiation stageINFERRED
• T1133External Remote Services — contacts against internet-exposed 3389 · 5900 · 445 · 389 · 1433INFERRED
• T1110Brute Force — Sensor 01's 2,017 login attempts across 1,836 combinationsINFERRED
• T1082System Information Discovery — command intent 'reconnaissance — system' 1,700 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 23 times, 4 kinds of stored filesINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'granting execute permission' 191 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence, planting an SSH key' 18 times, 389-byte public key delivered 17 timesINFERRED
• T1070Indicator Removal — 'erasing traces' 17 timesINFERRED
• T1562Impair Defenses — 'impairing defenses' 1 time (ATK-6C52B2 session)INFERRED

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

There have been times like this before

INFERRED The surge in 3389 scanning right after BlueKeep was disclosed (2019). When a serious flaw in remote desktop (CVE-2019-0708) was made public, the number of knocks on this one port across the entire internet jumped by a single-digit multiple. The shape of yesterday’s record — the other doors unchanged while one door jumps tenfold — is in the same family as that. However, we have no basis for connecting yesterday’s observations to that vulnerability. Our sensors stop at the negotiation stage, and we have no CVE-linking data. (Source types: vendor security advisories · CISA alerts · NVD)

INFERRED SMB1 scanning becoming permanent after WannaCry / EternalBlue (2017). After the incident that targeted an old version of the file sharing protocol, tools that throw that old vocabulary first started running on the internet permanently. Of the 336 dialect proposals we received yesterday, 334 were of that old family. We use this only as background context. Our observation goes as far as “what words the other side opened with,” and whether they actually attempted an attack is unknown. (Source types: vendor security advisory MS17-010 · national CERT advisories)

INFERRED The Mirai botnet (2016). The method was to get into IoT devices with a dictionary of default Telnet accounts and then immediately have them download a file. The shape we saw on Sensor 01 yesterday — the sequence of downloading a file and granting execute permission within 63 to 180 seconds after a successful login, and the use of defaults like admin/admin · root/root — is in that same family. However, not one of the files taken away yesterday was an executable binary. (Source types: government agency alert US-CERT/CISA TA16-288A · subsequent U.S. Department of Justice indictment materials)

So what should you do

Let’s go back to the phone. The bell rang 24× more yesterday, but the point where things actually diverged is “did you pick up.” Every item below is about that.

1. You are leaving management ports open to the internet as-is · High likelihood Yesterday in one day, 34,811 contacts from 109 places reached remote desktop, 65,487 from 387 places reached screen sharing, 198 from 42 places reached file sharing, 166 from 12 places reached directory lookup, and 59 from 43 places reached the database — all landing directly, with no prior contact. On the side that answers the phone, 2,071 came in on port 2222 and 341 on 2223. These two servers have never announced their address anywhere. Just leaving them open brings contacts on the order of 100,000 a day. Yesterday one source knocked on remote desktop 319.4 times. If a single account is weak, all of those knocks turn into attempts. Move them behind a VPN or a jump host and most of these contacts get cut off before the authentication stage.

2. You are still using default accounts and weak passwords · High likelihood All eight rows in the table above are values that devices or distributions ship with. admin/admin was attempted 38 times from 16 different places, root/123456 from 7 places, root/root from 3, root/default from 3, support/support from 3, and admin/empty password 14 times from 3 places. All 5 of yesterday’s notable sessions are sessions where the login succeeded. If even one of these combinations is left on a real server, the door opens that same day. The sessions that opened moved on to the next step within 63 to 180 seconds.

3. You allow password logins and aren’t using keys · High likelihood The breadth of combinations attempted yesterday was 1,836 kinds. As long as the password door is open, this dictionary comes back every day. And the intruding side already knows how useful key-based access is. Yesterday ‘planting an SSH key’ occurred 18 times, and the 389-byte public key came in from 17 different places. Once someone else’s key gets one line into authorized_keys (the list of permitted keys), they keep getting in with that key even if you change the password. That public key planted yesterday is present under the same hash in all 24 days of archive.

4. You are not blocking outbound connections · High likelihood ‘File download’ at 23 and ‘execute after download’ at 23 were exactly equal. It means the act of downloading led to the execution step without exception. In practice, a 306-byte shell script came down from hxxp://185[.]93[.]89[.]72/wget to 8 aliases. Since login has already been breached at that point, cutting off the server’s outbound connections is the last place where actual damage gets prevented. Had outbound connections been blocked, yesterday’s 23 downloads are the step that would all have failed.

5. You are relying only on count-based blocking (fail2ban and the like) · Medium likelihood This is the point where yesterday’s data splits in two. Sensor 02’s remote desktop was knocked on 319.4 times by a single place, so a per-source rate limit would definitely have caught it. But on the side that answers the phone, the average per combination is 1.05. Per-account defenses like “lock after 5 wrong attempts on one account” most likely never fired even once yesterday. That is why this is ‘medium’ rather than ‘high.’ The result splits in opposite directions depending on the kind of defense. Without per-source limits, 30,000-plus events a day on port 3389 alone eat straight into your logs and session resources.

6. You are keeping logs only on the server itself · Medium likelihood ‘Erasing traces’ intent was classified 17 times yesterday, and ‘impairing defenses’ once. The intent to erase was actually observed. The reason we could see it is that the 1,783 screens were recorded separately, outside the server. If you rely only on logs inside the server, incident reconstruction breaks down wherever those 17 passed through. Yesterday’s notable sessions were 63 seconds · 66 seconds · 68 seconds · 85 seconds · 180 seconds. That is not a length a person watching a screen can catch.

What We Don’t Know

This is where this blog differs from other places. We write down what we don’t know as not known.

Doubts about yesterday’s subject itself

• [Cannot confirm] We cannot confirm whether yesterday’s 34,811 remote desktop contacts came from a single source. All we have is the circumstance that it differs by 582 from the top alias ATK-E37B01’s 34,229. The data has no per-source service pairing, the service list doesn’t tell us the sources, and the top-source list isn’t broken out by service.
• [Cannot confirm] We have no basis to judge whether the name field flipping to mstsc means the tool changed, the same tool’s settings changed, or an entirely different party newly arrived. What we have is only the distribution of strings.
• [Cannot confirm] The reading that the 6 Administr entries are Administrator cut off at nine characters is inference. Since we do not export the raw negotiation frames, it cannot be confirmed.
• [Cannot confirm] We cannot calculate whether a single source swept several doors together. The sum of per-service sources (387+109+42+12+43=593) is 18 short of the overall 611, and this appears to be because the ADB sources have no row in the list — but the data does not say so. Writing this value as 0 would make it false, so we leave it as ‘cannot be calculated.’
• [Cannot confirm] The archive has no file for September 9. So every “previous” comparison in this post is measured against September 8, and the comparison band is the 14 days from August 26 to September 8. What happened on the 9th is something this post cannot answer.

Things in yesterday’s data that can’t be explained

• [Cannot confirm] ATK-6BC9D8 had ‘file download’ and ‘execute after download’ intents attached, and yet the download count is 0. We cannot distinguish whether the download failed, whether the hash already existed and so wasn’t stored, or whether the classifier over-classified the commands.
• [Cannot confirm] ATK-6C52B2 had completeness 42 and 11 downloads, and yet the only intent attached is ‘impairing defenses’ and nothing else. What the other 21 commands were survives only as a classification result; the raw text is not in our hands.
• [Cannot confirm] Yesterday’s 18 ‘planting an SSH key’ events, the 17 aliases that delivered the 389-byte public key, and the 17 sources of the 345gs5662d34/345gs5662d34 combination — the data does not connect them to say whether they are the same set. We cannot say anything beyond the fact that the numbers are close.
• [Cannot confirm] It is not stated through which channel the 46,582-byte file stored by Sensor 02 came in. All we have is the circumstance that Android debugging is the only channel on this server that can store a file, and that the sample count of 1 matches. There is no field for file type, so we also cannot know what it is.
• [Cannot confirm] The ‘IPs seen so far’ column in the fingerprint list is still not monotonically increasing. f555226d… went 289 places on August 29 → 366 on August 30 → 226 on September 8 → 158 yesterday. The ‘cumulative is not cumulative’ condition pointed out in the September 5 post is unchanged five days later. This column must not be read as cumulative.
• [Cannot confirm] Telnet leaves no client program fingerprint, so all 5 of yesterday’s notable sessions have an empty fingerprint field. These sessions cannot be attached to any of the 42 fingerprint groups.
• [Cannot confirm] The contents of the 4 kinds of files stored yesterday are not in our hands. We have no basis for judging what the 306-byte script does, or why the 1-byte empty file and the 9-byte text keep coming down.
• [Cannot confirm] The judgment “a hash that was in the archive” is a comparison against 24 records from August 16 to September 8, not an exhaustive comparison against the raw logs. Samples not carried in the records don’t get caught by this comparison.

Things deliberately not included · not connected

• [Excluded] The 12 distribution addresses that only surface after decompression, and the Discord webhook address obtained through a separate path, did not come from yesterday’s stored files. Not one of Sensor 01’s 4 kinds yesterday was a compressed executable. We leave them only as background material and did not connect them to yesterday’s events.
• [Excluded] The 7,619 tracked CVEs · 395 CISA KEV entries · 99 confirmed ransomware cases that came in as background statistics are values pulled from KISA security notices. They are not connected to any contact, session, or sample observed yesterday, so they were not used as a basis for anything written here.
• [Cannot confirm] We report observed distribution points to C-TAS, but what is confirmable goes only as far as the transmission having succeeded. Whether it was actually ingested requires separate confirmation.

Things we do not judge at all

• ASN · ISP — We have no relevant database. We do not infer.
• Geolocation — Same as above. IP geolocation is not a basis for attribution to begin with. We attach no country or region to any of the masked IPs that appeared yesterday.
• VPN · Tor · cloud status — We have no means of determining it.
• Whether samples are malicious — We have not integrated VirusTotal. Sample classification uses MalwareBazaar tags, and yesterday’s data has no such tags.
• Client program markers — A fingerprint is a fingerprint of a build, not a fingerprint of a person. Unrelated people using the same distribution’s default SSH will have the same value. A group of 112 places must not be read as one actor.
• User-Agent — Neither observation surface is HTTP. Sensor 01 is SSH · Telnet, and Sensor 02 is SMB · RDP · VNC · MSSQL · LDAP · ADB.
• CVE linkage — SSH and Telnet attacks generally do not reference a CVE, and Sensor 02 is the same since it stops at negotiation. We do not connect yesterday’s 34,811 remote desktop contacts to any vulnerability.
• 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 restore the masked positions, and we name no country, company, or individual as an attacker.

The bell rang 34,811 times yesterday. More than all 14 days added together. And yet the places calling were 109 — on the low side even for the past two weeks.

So yesterday’s record is not “more places came to visit” but “the same places called far more often.” These are different sentences, and the ways to block them differ too. The shape of one place redialing every 4 minutes 30 seconds is definitely caught by a per-source rate limit. Conversely, what happened on the neighboring server — the shape of sweeping through 1,836 passwords once each — doesn’t even trigger a “lock it after N wrong attempts” rule.

And those 32,042 knocks wrote mstsc in the caller-name field. That field is written by the calling side. If it were a door you could filter by name, yesterday would have been the day that got through best. What we were able to count is not who said what, but how many times it rang.

The observation date is 2026-09-10, and both Sensor 01 and 02 are on a daily aggregate basis. Source IPs are written with the last two octets masked and are not restored. Distribution addresses have been defanged so they cannot be visited. Credentials are quoted only for the 8 kinds repeatedly observed from 3 or more different IPs; the 1,828 kinds seen from fewer than 3 were only counted, and their values were not written down.