The Mailbox Overflowed Again After Three Days — Both the Sender and the Name Looked Familiar

Picture the mailbox on the ground floor of an apartment building. You open it once a day. Usually there are two or three flyers inside.

Three days ago, the mailbox was stuffed to bursting. It was a volume we had never seen. So in that day’s log we wrote “first time seeing this.”

When we opened it today, there was even more. We checked the return address on the back of the envelopes — it was the same place as three days ago. And a name we hadn’t seen in a while was written on the front of the envelopes again. On 7,039 of them.

This is what happened to our two servers yesterday. Nothing was new, but the volume alone set a new record.

Two Mailboxes

FACT We run two honeypot servers. A honeypot is a decoy server left deliberately open so we can watch who does what. In this post we’ll call the two of them two mailboxes.

FACT One (Sensor 02) is the mailbox that doesn’t open envelopes. It only counts how many came, where they came from, and what’s written on the outside. It doesn’t know what’s inside. This approach is called “low-interaction” — it accepts the conversation only up to the opening stage and then hangs up.

FACT The other (Sensor 01) is the mailbox that opens envelopes. It lets the other side go all the way to logging in, then records every command they type and every file they leave behind.

FACT Yesterday the two mailboxes were polar opposites. The one that doesn’t open envelopes broke its record, and the one that opens them had nothing new at all.

The Mailbox From Three Days Ago Overflowed Even More Today

FACT The mailbox that doesn’t open envelopes has six slots. Yesterday, 42,578 envelopes landed in the “remote desktop” slot. Remote desktop is the feature that pulls up your office computer’s screen from home. In English it’s called RDP, and its door number (port) is 3389.

FACT 42,578 envelopes works out to one every 2 seconds. From midnight to midnight, without a single pause.

FACT Three days earlier, on September 10, this slot got 34,811. That was the largest value in our records up to that day (August 26 to September 10, 15 days’ worth). Yesterday was 7,767 more, 1.22 times as many. The all-time high changed again after just three days.

FACT But the number of senders stayed the same. Yesterday 107 sources put envelopes in this slot; three days ago it was 109. Two fewer senders, 7,767 more envelopes.

FACT Broken down, it looks like this.

INFERRED One sender putting in 397.9 envelopes in a day means, on average, the same source came back every 3 minutes 37 seconds to drop one off. That interval is 53 seconds shorter than three days ago. It’s not that more sources showed up — each source is doing thicker work.

FACT One thing needs to be disclosed here. Our archive has no records for September 11 and 12. So this post’s “compared with three days ago” places two dates side by side; it does not mean the activity continued for three straight days. Whether it went quiet in between and came back, or kept overflowing the whole time, this post cannot answer.

The Sender Was the Same Too

FACT The source that put the most envelopes into this mailbox overall (all six slots combined) yesterday was alias ATK-E37B01 (149.50.x.x). 34,899 envelopes, which is 33.8% of the 103,298 total that landed in this mailbox yesterday. An alias is just a name tag we attach so we can recognize the same source again; it is not an identity.

FACT The number-one spot three days ago was the same alias. That day it was 34,229, 34.0%. The pattern of one source filling a third of this mailbox reappeared exactly, three days later.

FACT Positions 2 through 8, seven sources, cluster between 4,720 and 5,808. ATK-A9F1B3 5,808 · ATK-943F0E 5,807 · ATK-593C0D 5,472 · ATK-992AD3 5,292 · ATK-28B422 4,751 · ATK-B954FC 4,749 · ATK-AE6CC0 4,720. Position 9 is 3,252 and position 10 is 1,563, where it drops off.

FACT The top 12 sources put in 78,222 envelopes (75.7%). The remaining 605 sources put in 25,076 combined, an average of 41.4 per source. The number-one source alone put in more than the other 605 combined.

FACT Of the top 12, 8 are aliases that have appeared on the top list before. ATK-E37B01 · 992AD3 · 943F0E · A9F1B3 · B24952 on September 10; ATK-28B422 · B954FC · AE6CC0 on August 27–29. The other 4 (ATK-593C0D · 0E3BBB · A00F1F · AE264D) appear on the top list for the first time. That said, our archive only records 12 sources per day, so it remains possible they were sitting outside the top 13 the whole time.

INFERRED Put the number-one source’s 34,899 next to the remote desktop slot’s 42,578 and it’s tempting to read it this way: “That one source filled the remote desktop slot.” 42,578 minus 34,899 is 7,679, and if you add up all the envelope names below except mstsc, you get 7,456. The numbers are close.

FACT But we cannot say that. Our records do not note “which alias put envelopes in which slot.” The alias ranking is a total across six slots, and the per-slot counts don’t tell us aliases. The closeness of the numbers is as far as the circumstantial evidence goes.

The Name on the Front of the Envelope — the Vanished ‘hello’ Is Back at 7,039

FACT When remote desktop starts a connection, it sends a short string along with it. In technical terms this field is called a “cookie,” and it’s a value the sending side writes in by hand. It’s the same as a name the sender writes on the front of an envelope. We only read that name; we cannot know whether it’s real.

FACT These are the values written in that field yesterday.

FACT Envelopes with a name written on them total 40,311, 94.7% of the remote desktop slot.

FACT mstsc is the same string as the filename of the remote desktop program built into Windows. 32,855 envelopes is one every 2.6 seconds.

FACT And then hello. This name has risen and fallen in our records like this.

FACT The previous high was 2,709 on August 31. Yesterday was 2.6 times that. 7,039 envelopes is one every 12 seconds.

FACT Three days ago, hello fell to 16 as mstsc rose. It looked as though one had pushed the other out. But yesterday, both are present on the same day. 32,855 and 7,039, side by side.

INFERRED mstsc · hello · <ip> don’t look like IDs a person typed by hand. They’re closer to values a tool fills in automatically. That said, we do not judge which tool, or why these words. The only fact is that the envelopes arrived with these written on them. A name of hello doesn’t mean someone came to say hello, and mstsc doesn’t mean that program was used. It’s like how an envelope labeled “parcel” may not actually be a parcel.

How Were the Other Slots?

FACT Laying out all six slots of this mailbox, it looks like this. Yesterday’s total was 103,298 envelopes from 617 senders. That’s one every 0.84 seconds.

FACT The bottom four slots combined come to 434 envelopes, 0.4%. Yesterday this mailbox was effectively two slots: screen sharing and remote desktop.

FACT The total of 103,298 is the highest in our records. The previous high was 100,752, three days ago.

FACT The screen sharing (VNC) slot did not break a record. 60,286 is third in our records (September 10: 65,487 · September 8: 65,322). The 407 senders rank second (September 8: 416). What jumped yesterday was not screen sharing but remote desktop.

FACT There’s more written on the outside of an envelope than just a name. Before connecting, screen sharing proposes a version — “I’ll speak version such-and-such.” Versions proposed yesterday: 003.003 on 54,573 (90.5%), 003.008 on 5,616 (9.3%), and 97 with nothing written.

FACT File sharing (SMB) proposes a “dialect.” It’s choosing which manner of speech to use for the conversation. Of 259 proposals yesterday, 8 kinds appeared, and the newer family SMB 2.??? accounted for only 3. The other 256 were NT LM 0.12 · LANMAN1.0 · LM1.2X002 · LANMAN · PC NETWORK PROGRAM 1.0 · Windows for Workgroups 3.1 · LANMAN2.1. All old dialects.

FACT This mailbox saved 0 files yesterday. For Android debugging, there is only the number 40 sessions; door number, sender count, and content are not in yesterday’s records.

The Mailbox That Opens Envelopes — Nothing Was New

FACT Now for the side that opens envelopes (Sensor 01). Yesterday 2,016 sessions came in here. A session is counted as one unit “from connecting to disconnecting.” There were 322 senders, 1,759 login attempts, and 1,660 commands.

FACT 1,759 login attempts is one every 49 seconds, and 1,660 commands is one every 52 seconds. The 2,016 sessions and 322 sources fall inside our 25-day range (634–5,488 sessions · 131–457 sources). It was an ordinary day.

FACT Four file types were saved in this mailbox yesterday. All four were hashes we had seen before. A hash is a value that summarizes a file’s contents in one line. If even one character of the contents differs, the hash changes. So a matching hash means exactly the same file.

FACT For a sense of scale, 389 bytes and 399 bytes are two or three lines of a text message, 54 bytes is one sentence, and 1 byte is a single character. All four types together come to 843 bytes.

FACT The 389-byte file in the first row is an SSH public key. Put simply, it’s a spare key that lets you in without a password. Write this value as one line into a file on the server called authorized_keys (the list of permitted keys), and whoever holds that key gets in from then on without being asked for a password. This key has arrived on every single day in our records. Yesterday it came 15 times from 14 different sources.

FACT The 399-byte file in the fourth row is a private key. If the public key is the lock you hang on the front door, the private key is the key that opens that lock. Only one source left this behind yesterday: alias ATK-CA5936 (130.12.x.x). Whether it pairs with the public key above, our records do not say.

Opening Five Envelopes

FACT Five sessions stood out yesterday. All five logged in successfully, and all five were shapes we had seen before. That’s why we filed this mailbox under “nothing new” yesterday.

FACT At 03:41:46, ATK-168132 (82.157.x.x) came in over Telnet. Telnet is a remote access method older than SSH, and what passes over it is not encrypted. It typed 17 commands over 62.8 seconds, and five intents were tagged (reconnaissance · file download · download-then-execute · granting execute permission · planting SSH keys). Files saved: 0. A screen recording was kept.

FACT At 07:26:11, ATK-CA5936 (130.12.x.x) came in over SSH. It typed 1 command in 3.6 seconds, and all five intents were packed into it. It left two files behind (54-byte text, 399-byte private key). The connecting program was SSH-2.0-Go. This shape is the 11th appearance in our records since August 19 (8/19 · 8/24 · 8/25 · 8/26 · 8/28 · 8/30 · 9/01 · 9/03 · 9/05 · 9/06 · yesterday).

FACT At 08:25:56, ATK-C6FE9B (125.229.x.x) over Telnet for 83.8 seconds. 31 commands, three intents (file download · download-then-execute · granting execute permission). Files saved: 0.

FACT At 09:56:09, ATK-86979F (212.132.x.x) over Telnet for 64.1 seconds. 22 commands, but the only one classified by intent was “defense impairment,” a single one. That one is the only defense-impairment event in this entire mailbox yesterday. And it received the 1-byte empty file 11 times. This shape — the most files received, yet all of them empty — also appeared on August 17 · August 22 · September 3.

FACT At 13:10:03, ATK-D3389B (111.34.x.x) over Telnet for 91.2 seconds. 31 commands, three intents. Identical to the 08:25 session in both command count and intent combination. Files saved: 0. This Telnet 31-command shape also appeared on August 20 · September 2.

FACT Four of the five were Telnet. Yet Telnet sessions yesterday were only 8.4% (169) of the total. By session count SSH was 91.6%, but what stood out was mostly on the Telnet side.

FACT Counting the 1,660 commands typed in this mailbox yesterday by type gives this.

FACT “Granting execute permission” is the act of marking a file as “this file is okay to run.” On Linux, without this mark, even a program won’t run. “Trace removal” is erasing records of one’s own visit, and “defense impairment” is switching off the server’s security features.

Using the Same Envelope Doesn’t Make It the Same Person

FACT Every program that connects over SSH leaves one fingerprint. It’s a one-line summary of the values the other program announces first — “this is how I talk.” In envelope terms, it’s the envelope’s dimensions and paper stock.

FACT Of the 322 sources that came to this mailbox yesterday, 150 (46.6%) carried the same fingerprint (acaa53e0…, SSH-2.0-OpenSSH_7.4). Counting every source that has ever carried this fingerprint gives 1,058. It’s the overwhelming number one among the 13 fingerprints on yesterday’s list.

FACT But these 150 sources left not a single file behind. The same goes for all 13 fingerprints on yesterday’s list.

FACT Conversely, the fingerprint of ATK-CA5936, which left the private key yesterday (16443846…), is not on this top list. The list’s floor is “2 sources yesterday,” so we can’t know how many sources this fingerprint came from yesterday.

INFERRED We have to stop here. This fingerprint is a fingerprint of the program build, not of a person. It’s like how using the same envelope sold at the same stationery shop doesn’t make you the same person. Anyone using the SSH that a given distribution ships by default will produce the same value, even with no relationship between them at all. The 150 sources must not be read as one organization.

Which Passwords Did They Try to Open It With?

FACT 1,146 kinds of ID-password combinations were attempted yesterday. Of those, we publish 20 here, and for the remaining 1,126 we only count them.

There is one reason. Combinations seen from fewer than 3 different sources could be real accounts actually leaked from somewhere. We don’t transcribe those values in our posts. The 20 below are the opposite. They were repeated from 4 or more sources, so they can be regarded as “default or dictionary values that belong to no one.”

FACT The first row, 345gs5662d34, came 16 times from 14 sources. That’s 1.14 per source. It wasn’t one source knocking many times — it was many sources knocking once each.

FACT The sources that delivered the public key above also numbered 14. Whether they are the same 14, the data does not connect. Only that the number is the same.

The Whole of Yesterday

FACT Daily totals for the mailbox that opens envelopes (Sensor 01).

FACT The per-port sum is 2,015, one short of the 2,016 total. What that one session is, the records do not say.

FACT The 103,298 from the mailbox that doesn’t open envelopes (Sensor 02) is not added in, because the unit of counting is different. This side counts “sessions”; that side counts “contacts.”

FACT Adding up the sources that put envelopes in both mailboxes gives at most 939. The data doesn’t tell us whether the same source hit both mailboxes, so this is a simple-sum “upper bound.” The real value is at or below that. The previous high was 907 three days ago, so this too is a new maximum.

FACT And these two mailboxes have never had their address announced anywhere. Never advertised, never linked. Yet 100,000 envelopes arrive per day.

INFERRED For someone who walks the mailbox numbers in order from first to last, whether the address was announced doesn’t matter. If it’s open, they drop one in and move on.

Laid out in time order, it looks like this. The first seven rows are the daily totals from the mailbox that doesn’t open envelopes, and the last six rows are the envelopes we opened. Watch for the rows marked “archive comparison” — these are things you can’t see from yesterday alone; they only appear when set beside past records.

1. (Daily total · Sensor 02)
   FACT 103,298 contacts · 617 sources. VNC(5900) 60,286/407 sources · RDP(3389) 42,578/107 sources · SMB(445) 253/38 sources · LDAP(389) 92/7 sources · MSSQL(1433) 49/35 sources · ADB 40 sessions. Samples captured: 0. Sensor 02 does not export session times, so this is per-day
2. (Daily total · Sensor 02 · RDP · archive comparison)
   FACT RDP 42,578 contacts is 7,767 more (1.22x) than the 34,811 on 9/10, which had been the maximum across the archive's 15 days (8/26–9/10). Sources at 107 are nearly the same as 9/10's 109, so contacts per source rose from 319.4 to 397.9
3. (Daily total · Sensor 02 · RDP cookie)
   FACT mstsc 32,855 · hello 7,039 · <ip> 400 · rdpaudit 14 · Administr 2 · random 9 chars 1. Total 40,311 (94.7% of RDP), cookie not recorded 2,267 (5.3%). mstsc is 77.2% of RDP, hello is 16.5%
4. (Daily total · Sensor 02 · RDP cookie · archive comparison)
   FACT 'hello' 7,039 is 2.6x the archive's previous maximum of 2,709 (8/31). Trend: 8/26 604 → 8/31 2,709 → 9/03 3 → 9/07 1,391 → 9/10 16 → today 7,039. On 9/10 mstsc appeared to replace hello; today both are present on the same day
5. (Daily total · Sensor 02 · top sources)
   FACT Top-contact alias ATK-E37B01(149.50.x.x) 34,899 = 33.8% of all of Sensor 02. The same alias was number one on 9/10 too, with 34,229 (34.0%) that day. Positions 2–8, seven sources, form a narrow band of 4,720–5,808 (ATK-A9F1B3 5,808 · ATK-943F0E 5,807 · ATK-593C0D 5,472 · ATK-992AD3 5,292 · ATK-28B422 4,751 · ATK-B954FC 4,749 · ATK-AE6CC0 4,720), dropping off at 9th 3,252 → 10th 1,563. Top 12 total 78,222 (75.7%), remaining 605 sources 25,076, averaging 41.4 per source
6. (Daily total · Sensor 02 · top sources · archive comparison)
   FACT 8 of the top 12 aliases have precedent on the archive's top lists (ATK-E37B01 · 992AD3 · 943F0E · A9F1B3 · B24952 on 9/10, ATK-28B422 · B954FC · AE6CC0 on 8/27–8/29). The 4 aliases ATK-593C0D · 0E3BBB · A00F1F · AE264D appear on the top list for the first time — but the archive only lists 12 sources per day
7. (Daily total · Sensor 02 · VNC · SMB · archive comparison)
   FACT VNC 60,286/407 sources ranks 3rd in the archive by contacts (9/10 65,487 · 9/08 65,322), 2nd by sources (9/08 416). VNC versions proposed: 003.003 54,573 (90.5%) · 003.008 5,616 (9.3%), not recorded 97. SMB: of 259 dialect proposals across 8 kinds, 'SMB 2.???' is only 3; the remaining 256 are NT LM 0.12 · LANMAN1.0 · LM1.2X002 · LANMAN · PC NETWORK PROGRAM 1.0 · Windows for Workgroups 3.1 · LANMAN2.1
8. 2026-09-13T03:41:46Z ~ 03:42:49Z (62.8s)
   FACT ATK-168132(82.157.x.x) Telnet login succeeded. 17 commands, 5 intents (reconnaissance · file download · download-then-execute · granting execute permission · planting SSH keys). Files saved: 0. TTY recording present
9. 2026-09-13T07:26:11Z ~ 07:26:14Z (3.6s)
   FACT ATK-CA5936(130.12.x.x) SSH login succeeded. 1 command with 5 intents, 2 files delivered — 54-byte ASCII text (00b6f1…) and 399-byte OpenSSH private key (43728f…). Client SSH-2.0-Go, fingerprint 16443846184eafde36765c9bab2f4397. Both hashes match those that have recurred in the archive since first observed on 8/19
10. 2026-09-13T08:25:56Z ~ 08:27:20Z (83.8s)
    FACT ATK-C6FE9B(125.229.x.x) Telnet login succeeded. 31 commands, 3 intents (file download · download-then-execute · granting execute permission). Files saved: 0
11. 2026-09-13T09:56:09Z ~ 09:57:13Z (64.1s)
    FACT ATK-86979F(212.132.x.x) Telnet login succeeded. Of 22 commands, the only one classified by intent was 1 'defense impairment' (this is the only defense-impairment event across all of Sensor 01 today). Received 11 copies of the 1-byte file (01ba47…)
12. 2026-09-13T13:10:03Z ~ 13:11:34Z (91.2s)
    FACT ATK-D3389B(111.34.x.x) Telnet login succeeded. 31 commands, 3 intents — same command count and intent combination as ATK-C6FE9B at 08:25. Files saved: 0
13. (Daily total · Sensor 01 · public key · archive comparison)
    FACT The 389-byte OpenSSH RSA public key (a8460f…) was delivered 15 times from 14 different sources (only 10 aliases listed). By the archive, this is day 29 since first observed on 8/16, and it has appeared on every day the archive contains

The rows to read together are the second and the fifth. One says “sources held steady at 107,” the other says “one source is 33.8% of the total.” In the post three days ago we tried to read those same two rows together, and yesterday too, our data does not connect them.

What Was Left in the Mailbox

FACT We transcribe the values as-is so you can use them for defense. Click a value to copy it. All four from yesterday have an empty address field. They appear to have been placed directly within the session rather than downloaded from somewhere, but we can’t confirm that. Please note that all four rows carry the word “archive” — not one of them arrived for the first time yesterday.

FACT You’ll have noticed there isn’t a single distribution address (URL). All four files saved yesterday came in without an address. Not one executable either. That’s why this card has hashes only.

Mapping the Attackers’ Techniques to the International Classification

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

• T1046Network Service Discovery — contacts to 5 services on Sensor 02 (VNC · RDP · SMB · LDAP · MSSQL), observed only up to the protocol negotiation stageINFERRED
• T1110Brute Force — repeated contacts at 397.9 per source for RDP · 148.1 per source for VNC. Sensor 02 does not extract credentials, so the 'attempt contents' cannot be confirmedINFERRED
• T1133External Remote Services — access attempts against RDP · VNC ports open to the internetINFERRED
• T1110.001Password Guessing — 1,759 login attempts on Sensor 01, 20 combinations repeated from 3 or more IPsINFERRED
• T1078.001Default Accounts — admin/admin (8 sources) · root/admin (6 sources) · admin/Huawei12#$ (5 sources) · support/support (4 sources)INFERRED
• T1082System Information Discovery — 1,442 'reconnaissance — system' commandsINFERRED
• T1105Ingress Tool Transfer — 8 'file download' · 8 'download-then-execute'INFERRED
• T1222File and Directory Permissions Modification — 64 'granting execute permission'INFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 17 'persistence — planting SSH keys', public key file delivered from 14 sourcesINFERRED
• T1070Indicator Removal — 16 'trace removal'INFERRED
• T1562Impair Defenses — 1 'defense impairment' (ATK-86979F)INFERRED

Please note that all eleven rows carry the [INFERRED] badge. What we hold is the commands’ “intent classification result” and “how many times.” We don’t have the raw command text. The top three rows in particular come from the mailbox that doesn’t open envelopes, so the leap from “how many envelopes came” to “it was brute force” is itself the inference.

This Has Happened Before

INFERRED GoldBrute (2019). A botnet that picked remote desktop servers open to the internet and brute-forced them. Its form was a small number of sources knocking on door 3389 at very high frequency. The shape of our mailbox yesterday — 107 sources at 397.9 per source, one top source above 30,000 — is in the same family. However, since we only accept up to the negotiation stage, we cannot confirm which passwords were actually entered. (Source type: public analysis on the security vendor research blog Morphus Labs)

INFERRED The surge in port 3389 scanning right after BlueKeep was disclosed (2019). When a serious flaw in remote desktop (CVE-2019-0708) was published, the number of knocks on this port jumped across the entire internet. We keep this only as background context, as a public precedent of the remote desktop port becoming a mass-scan target. Yesterday’s data does not connect to any CVE. (Source type: CVE · Microsoft security advisory · CISA KEV listing)

INFERRED The Mirai botnet (2016). Its method was to get in with a dictionary of Telnet default accounts and then have the target download executables split by CPU type. Yesterday’s 4 successful Telnet default-account logins on the mailbox that opens envelopes, plus the presence in background indicators (obtained through a separate channel) of architecture-specific filenames under /bins/ such as parm · pmips · psh4 · x86_64, are in the same family. We do not judge which family the samples belong to. We have not integrated VirusTotal. (Source type: publicly released source code (2016 leak) and analysis reports from multiple vendors and research institutions)

So What Should You Do?

Back to the mailbox story. A record number of envelopes landed yesterday, but the point where things actually diverge is “was the mailbox out on the street?” Every item below is about that.

1. You have management ports open directly to the internet · Likelihood: high The mailbox that opens envelopes got 2,016 sessions from 322 sources (ports 2222 · 2223), and the one that doesn’t got 103,298 envelopes from 617 sources (ports 5900 · 3389 · 445 · 389 · 1433) — all arriving directly, with no prior contact. The combined upper bound on sources is 939. These two servers have never had their address announced anywhere. The remote desktop slot alone got 42,578 in a day, and one source put in 34,899 of them. Had they been behind a VPN or jump host (an intermediate relay server), none of the 103,298 could have arrived at all. It’s the same as moving the mailbox inside the building.

2. You are still using default accounts and weak passwords · Likelihood: high All 20 rows in the table above are values that devices or distributions ship with, or dictionary values that work anywhere. admin/admin came from 8 sources, root/admin from 6, root/0000 from 5, admin/Huawei12#$ from 5, support/support from 4. The combinations attempted yesterday totaled 1,146. All 5 sessions that stood out yesterday were sessions that logged in successfully. If even one of these combinations remains on a real server, the door opens. Once open, it proceeds in the order observed yesterday — reconnaissance (1,442) → granting execute permission (64) → planting keys (17). The 4 Telnet sessions finished within 63 to 91 seconds.

3. You allow password login and aren’t using key-based authentication · Likelihood: high There were 1,759 login attempts yesterday. As long as the password door is open, this dictionary comes back every day. And the ones getting in already know the value of key-based access. Yesterday “planting SSH keys” occurred 17 times, and the 389-byte public key came in 15 times from 14 different sources. Once someone else’s key gets one line in authorized_keys (the list of permitted keys), they keep getting in with that key even after you change the password. Conversely, had only key-based login been allowed, yesterday’s 1,759 attempts would never have reached the authentication stage.

4. You have no count-based blocking (fail2ban etc.) · Likelihood: medium fail2ban is a tool that temporarily blocks a source that knocks too often. Yesterday’s data splits in two here. The number-one source on the mailbox that doesn’t open envelopes was one source with 34,899, and remote desktop was 397.9 per source, so a per-source limit would have cut it off early. But the 345gs5662d34 combination on the mailbox that opens envelopes was 16 times from 14 sources, 1.14 per source. This kind of distributed pattern doesn’t trip a threshold. That’s why it’s “medium” rather than “high.” Rate limiting is highly effective against Sensor 02-style floods and weak against Sensor 01-style spraying.

5. You aren’t blocking outbound connections · Likelihood: medium “File download” at 8 and “download-then-execute” at 8 matched, and 4 of the 5 notable sessions carried a download intent. What was actually saved yesterday was only keys, text, and an empty file, but the intent stage was observed in every session. Background indicators include 12 /bins/ paths on one host (31[.]77[.]227[.]121), split by CPU type. If a server allows outbound connections, the step of fetching an executable from such a distribution site can succeed. If blocked, it ends there.

6. You keep logs only on the server itself · Likelihood: medium “Trace removal” intent was classified 16 times yesterday, and “defense impairment” once. The ATK-86979F session had defense impairment as its only tagged intent. The intent to erase was actually observed. The reason we could see it is that 1,496 screens were recorded separately, outside the server. Had there been only logs inside the server, after trace removal you wouldn’t even know a breach had occurred. Without EDR (a tool that catches anomalous behavior in real time inside the server) or external log collection, yesterday’s 63-, 64-, 84-, and 91-second sessions cannot be seen by human eyes.

What We Don’t Know

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

Doubts About Yesterday’s Topic Itself

• [Cannot confirm] The September 11 and 12 briefs are not in the archive. We cannot know whether the September 10 remote desktop surge “continued” through yesterday, or stopped and came back. This post’s “again after three days” is a comparison placing two points in time side by side, not a claim of continuity.
• [Cannot confirm] We cannot confirm that the 42,578 remote desktop envelopes came from the single source ATK-E37B01. The only circumstantial evidence is that 34,899 and mstsc’s 32,855 are similar in size. That 42,578 − 34,899 = 7,679 is close to hello + <ip> + others = 7,456 is circumstantial too. Our records have no per-source service pairing.
• [Cannot confirm] We cannot calculate whether one source knocked on several slots together. The difference of 23 between the per-slot source sum (407+107+38+7+35 = 594) and the 617 total cannot be distinguished as Android debugging sources or overlapping sources. Writing this value as 0 would be false, so we leave it as “not computable.”
• [Cannot confirm] We do not judge what tool or what intent hello · mstsc · <ip> signify. The only fact is that these are strings written in a protocol field.
• [Cannot confirm] From the mailbox that doesn’t open envelopes, the passwords attempted were not extracted. They’re inside binary frames. “Brute force” is an inference from contact frequency.
• [Cannot confirm] The two 68.183.x.x aliases among the top sources (ATK-A9F1B3 · ATK-992AD3) share the same first two octets, but with no ASN or ownership information we cannot know whether they are the same operator.
• [Cannot confirm] That the 4 top aliases (ATK-593C0D · 0E3BBB · A00F1F · AE264D) are “first-time” is relative to the archive’s top-12 lists. They may have been sitting outside the top 13 all along.
• [Cannot confirm] For the 40 Android debugging (ADB) sessions, source count · payload content · door number are not in yesterday’s records. We know only that there were 0 samples.

Things Yesterday’s Data Cannot Explain

• [Cannot confirm] ATK-C6FE9B and ATK-D3389B carried a “download-then-execute” intent, yet their download count is 0. We cannot distinguish whether the file never arrived or was not saved.
• [Cannot confirm] Of the 14 sources that delivered public key a8460f…, only 10 aliases are on the list. The other 4 are unknown.
• [Cannot confirm] ATK-CA5936’s fingerprint (16443846…) is not on yesterday’s top fingerprint list, so we cannot know how many sources this fingerprint came from yesterday. Whether the list is complete, the records also do not say.
• [Cannot confirm] The records do not explain what the difference means between the 1,496 screen recordings on the mailbox that opens envelopes and the 269 that are viewable.
• [Cannot confirm] The records do not say what accounts for the 1-session difference between the per-port session sum (1,846 + 169 = 2,015) and the session total of 2,016.
• [Cannot confirm] No session on the mailbox that opens envelopes yesterday connects to the 12 URLs in the background indicators. All four saved files have an empty address field. That list is background indicators.

Things Deliberately Left Out · Not Connected

• [Excluded] The 12 distribution addresses that only surface after decompression (the /bins/ paths on one host, 31[.]77[.]227[.]121) did not come from what was saved yesterday. All four of yesterday’s files have empty addresses and are not executables. We keep them as background material only and did not connect them to yesterday’s sessions.
• [Cannot confirm] Observed distribution sites and C2 are reported to C-TAS (KISA’s threat intelligence sharing system), but what is confirmed is only that the transmission succeeded. Whether they were actually ingested requires separate confirmation.
• [Excluded] For the 1,126 combinations attempted yesterday, we did not publish the values. Combinations seen from fewer than 3 different sources could be real leaked accounts, so we count them only.

Things We Do Not Judge at All

• ASN · ISP — We have no relevant database. We do not guess.
• Geolocation — Same as above. IP geolocation isn’t a basis for attribution in the first place. 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 this.
• Whether samples are malicious — We have not integrated VirusTotal. Sample classification uses MalwareBazaar tags, and yesterday’s four files have no such tag.
• User-Agent — Neither mailbox is HTTP. Sensor 01 is SSH · Telnet; Sensor 02 is SMB · RDP · VNC · MSSQL · LDAP · ADB. HTTP attacks are a separate source.
• CVE linkage — SSH and Telnet attacks generally don’t reference a CVE, and Sensor 02 is at the negotiation stage, so the same applies. We do not connect yesterday’s 42,578 remote desktop envelopes to any vulnerability.
• Client program fingerprints — A fingerprint is a fingerprint of the build, not of a person. The 150-source cluster must not be read as a single actor.
• Source identity — An alias (ATK-XXXXXX) is only a name tag for recognizing the same source across posts; it is not an identity. We do not restore masked digits, and we do not name any country, company, or individual as the attacker.

We open the mailbox once more. There were 7,767 more envelopes than three days ago. The number of senders was unchanged, and the top sender was unchanged too. The name hello, absent for a while, returned at 7,039 — this time sitting side by side with mstsc.

The neighboring mailbox opened its envelopes, and all four were files we had seen before. One key has come every single day for 29 days.

So yesterday’s record is not “something new came” but “more of what we know came.” Those are different sentences. Something new can be added to a list, but on a day when more of what we know arrives, the problem is that the mailbox is out on the street at all. What we could count was how many envelopes came and what was written on the outside. Who sent them and why, the envelopes do not say.

The observation date is 2026-09-13; Sensor 02 is a daily total, and Sensor 01 is by session time. Source IPs are written with the last two octets masked and are not restored. Distribution addresses have been altered (defanged) so they cannot be connected to. Only the 20 credential combinations observed repeatedly from 3 or more different IPs are quoted; the 1,126 seen from fewer than 3 are counted only, with values not written.