One Card, 41 Places in a Day — Four Ledgers That Don't Know Each Other

Have you ever changed the code on your front-door smart lock? When you moved in, or when it felt like the number had leaked. Once you change it, you feel relieved.

But a smart lock holds one more thing besides the code: registered cards. Register a card once, and the door opens without the code. And changing the code does not erase the registered cards. Almost nobody opens the card registration list. Nothing is missing, after all.

Now picture this. Over the course of yesterday, hands from 41 different places came to our front-door lock and registered the exact same card. That is 1.7 places per hour. The card is the very same one that has been registered every single day our records go back to August 16. But among the days we compared, there has never been a day when this many places came.

That is what showed up on our server yesterday.

Our Server Is a House We Deliberately Leave Unlocked

FACT We run honeypot servers. A honeypot is a decoy server deliberately left weak so we can watch who comes in and what they do. Think of it as a house with an easy password. So what happens here is not real damage — it is an observation record. There are two servers. The first (sensor 01) is a house whose door actually opens; the second (sensor 02) is a house with no lock, only a doorbell. The first part of this post is about the first house.

FACT Today’s post does not follow a single intrusion. All five of the most densely recorded sessions were aliases we had seen and files we had seen. Instead, in the daily tally, four numbers jumped 2–3× side by side on the same day. Today’s post looks at those four.

One Card, 41 Hands Registering It

FACT Yesterday, a single 389-byte OpenSSH RSA public key was left on our server 41 times from 41 different sources. 389 bytes is about two or three lines of a text message. The value computed from the entire file contents (hash a8460f44…) is identical across all 41. Change a single character and this value changes, so it means what the 41 places left is the same card, not one character off.

FACT To unpack the terms: SSH is the door for entering a server remotely. This door opens with a password, but it also opens with a pair of keys. One of the pair, the “public key,” is hung on the server; the other, the “private key,” is held by whoever is coming in. Once a line containing a public key goes into the server’s authorized_keys file (the list of permitted keys), whoever holds the matching private key gets in without a password. It is the same as registering a card on the smart lock. And changing the password leaves this list untouched.

FACT This card is not new to us. Since August 16 it has appeared with the same hash on every day in our archive. The brief has compared this value side by side on 17 days, and the highest among them was 17 sources on September 10. September 13, 15 and 17 had 14 each. Yesterday was 41 sources, 2.4×. Please look at the two right-hand columns in the table below.

FACT The behavior-classification ledger says the same thing. Of the commands typed inside the server yesterday, 43 were classified as “persistence — planting SSH keys.” Persistence means “setting up in advance a way to get back in next time.” It was 18 on September 10 and 17 on the 13th, 15th and 17th, so that is 2.4–2.5×.

Four Ledgers That Don’t Know Each Other

FACT Two more numbers jumped the same day. One is the sources that tried a username and password that are the identical string, 345gs5662d34 / 345gs5662d34. Yesterday: 40 sources, 40 attempts, exactly once per source. The previous high among compared days was 17 sources on September 10. The other is the client-program signature. When you come in over SSH, the program you used leaves a signature (hassh) without meaning to, and yesterday 41 sources carried the signature f555226d… (SSH-2.0-libssh_0.9.6). The previous high for this signature was 16 sources on August 18.

FACT Put the four in one table and it looks like this. Note that the multipliers in the far-right column are all in the same range.

FACT As a side note, root / 3245gs5662d34 also came from 19 sources. It was 9 on September 10, 7 on the 13th, 5 on the 15th and 6 on the 17th.

INFERRED Looking at this table, one sentence comes to mind: “The same tool came in from about 40 places in the same sequence and registered the card.” The picture is: open the door with the same odd string as both username and password, use the same client program, get in, and register the same card. One wants to read it that way.

FACT But our records do not write that sentence for us. The four numbers sit in four different ledgers: the password ledger, the client-program ledger, the file ledger, the behavior-classification ledger. There is no field in the JSON that ties these four into one line. It is as if four CCTV cameras in front of the lock each count “41 people with umbrellas,” “41 people with the same shoes” — but no camera tells us whether they are the same people. It is the same limitation we pointed out in the August 18 post.

FACT If anything, there is one sign pointing the other way. The “delivered samples” field for ③, the client signature f555226d…, is false. That means it left no files at all. Yet ① says 41 files were left. Whether the public key is not counted as a “sample,” or whether ③’s 41 sources and ①’s 41 sources are different sets — the JSON does not explain which. The only certainty is “yesterday these four figures were 2–3× the previous highs among compared days.”

FACT One more. The “trace removal” intent was 42 times yesterday. That is 2.8× the 15 on September 17, and it rose by the same multiplier as key planting. It looks like two actions — registering a card and erasing the record of registering it — rose side by side, but the records do not tie these 42 to any particular session either.

Five Scenes Captured at the Lock That Day

FACT Our material separately lists the five most densely recorded sessions of the day. All five succeeded at login. But the 41 sources that registered the card do not appear by alias in any of these five scenes. Of the 41, the 10 whose aliases are disclosed are all new aliases not in the archive.

Laid out in time order, it looks like this. Note that the two lines at 20:47 are 2.43 seconds apart, and that the 22:33 line is 28 commands in 9 seconds.

1. 04:42:53Z (13:42 KST)
   FACT ATK-CA5936(130.12.x.x) SSH login succeeded. 3.74 s until 04:42:57Z · 1 command · 2 downloads · 5 intents (execute after download · grant execute permission · reconnaissance—system · plant SSH key · file download). Signature 16443846… / SSH-2.0-Go. Files are a 399-byte OpenSSH private key (43728fbf…) and 54-byte ASCII (00b6f15c…), same hashes since 8/19. Completeness 19. Not today's subject
2. 09:12:59Z (18:12 KST)
   FACT ATK-CA5936 second SSH session. 3.79 s · 1 command · 2 downloads · 5 intents — same shape as the 13:42 session. Same form 1–2 times a day on 9/13 · 9/15 · 9/17 as well
3. 11:47:14Z (20:47 KST)
   FACT ATK-BDB53E(160.119.x.x) Telnet login succeeded. 7.02 s until 11:47:21Z · 7 commands · 2 downloads. Intents: execute after download · grant execute permission · file download. Completeness 19. Screen recorded (contents not in the material). Telnet produces no client signature, so the signature field is an empty string. Command count · download count · intents · completeness match the same alias's sessions on 9/15 · 9/17
4. 11:47:16Z (20:47 KST)
   FACT Same alias ATK-BDB53E, second session. Started 2.43 s after the first session began and ended 0.02 s before the first session ended. 4.57 s · 2 commands · 2 downloads · same 3 intents · completeness 16. On 9/17 also 2 parallel sessions 2.33 s apart — appears to have settled from the 7-hour gap on 9/15 into a 'parallel 2-session' form since 9/17
5. (ATK-BDB53E samples — today's change)
   FACT hxxp://160[.]119[.]66[.]206/bins/kla.sh is a 3,241-byte POSIX shell script, 39be6853…, same hash as 9/15 · 9/17 (2 times today). By contrast hxxp://160[.]119[.]66[.]206/bins/net.x86_64 is 2cebccdc…, 192,328 bytes, ELF 64-bit x86-64 statically linked · stripped (2 times today). The file at the same URL on 9/15 · 9/17 was cd6ccc5d…, 190,632 bytes. URL · filename · type are the same; the hash changed and it grew by 1,696 bytes. 2cebccdc… appears nowhere in the archive 8/16–9/17
6. (ATK-BDB53E samples — inference)
   INFERRED The 9/17 brief wrote 'not rebuilt in the two days between.' Three days later it reads as the loader script left as-is and only the executable rebuilt and uploaded to the same place. What changed (function · C2 · packing) cannot be known because the sample contents are not in the material. The conclusion of the 8/24 post ('the hash list went stale within a day') repeated at this distribution site — a block rule built from the 9/15 hash does not catch today's file; URL · host rules do
7. 13:33:20Z (22:33 KST)
   FACT ATK-DD41EC(116.92.x.x) Telnet login succeeded. 28 commands · 11 downloads over 9.17 s until 13:33:29Z — all 11 are 1-byte empty files (01ba4719…). Intent is 'impair defenses' alone, completeness 42, today's highest. Alias not in the archive, but the 'impair defenses alone · 1 byte × 11 · completeness 42' family is a form recorded repeatedly since 8/17. Compared with prior records (9/10 66 s · 22, 9/13 64 s · 22, 9/15 69 s · 22): 6 more commands in one-seventh the time
8. (Daily tally · 01 — axis ①)
   FACT A 389-byte OpenSSH RSA public key (a8460f44…) was left 41 times by 41 different sources (delivering aliases disclosed for only 10). Of the 17 days the brief compared, the high was 17 sources (9/10); 9/13 · 9/15 · 9/17 were 14. Today is 2.4×. The 'persistence — plant SSH key' intent was also 43, 2.4–2.5× the 9/10 18 · 9/13 17 · 9/15 17 · 9/17 17
9. (Daily tally · 01 — numbers beside axis ①)
   FACT 345gs5662d34/345gs5662d34 from 40 different IPs, 40 times (exactly 1 per source). High among compared days 17 sources (9/10); 9/13–9/17 were 14. root/3245gs5662d34 also 19 sources (9/10 9 · 9/13 7 · 9/15 5 · 9/17 6). Client signature f555226d…(SSH-2.0-libssh_0.9.6) is 41 sources today — recorded daily high was 16 sources (8/18); 9/15 · 9/17 were 14. Public key 41 · signature 41 · credential 40 · key planting 43 — four values jumped into the same range on the same day
10. (Daily tally · 01 — axis ① inference and limits)
    INFERRED One wants to read the four values as pointing to one set (the same tool logging in from about 40 places by the same procedure → planting the public key), but the JSON does not link credential ↔ signature ↔ file delivery source. Same situation the 8/18 brief pointed out. Moreover the delivered-samples field for f555226d… is false — whether the public key is not counted as a 'sample' or the signature's 41 sources are a different set from the 41 that planted keys, the JSON does not explain
11. (Daily tally · 01)
    FACT 2,120 sessions · 208 unique sources · 1,932 login attempts · 2,241 commands · 1,754 screen recordings (82.7%). SSH 1,956 (port 2222 · 92.3%) · Telnet 163 (port 2223 · 7.7%). Telnet is 7.7% of sessions, yet 3 of today's 5 main sessions are Telnet. Session count is 2.7× 9/17 (791) and half of 9/15 (4,332) — an ordinary value within the archive range
12. (Daily tally · 01)
    FACT Command intents: reconnaissance—system 1,652 · grant execute permission 159 · persistence—plant SSH key 43 · trace removal 42 · file download 38 · execute after download 31 · reconnaissance—network 1 · impair defenses 1. Total 1,967, 87.8% of all commands; reconnaissance alone is 73.7%. 'Trace removal' 42 is 2.6–2.8× the 9/10 17 · 9/13 16 · 9/15 16 · 9/17 15, the same multiplier as key planting. 'File download' 38 and 'execute after download' 31 differ by 7 (9/15 differed by 5; most days they are equal)
13. (Daily tally · 01 — credentials)
    FACT 20 combinations observed from 3 or more different IPs and thus quotable verbatim; 1,208 combinations below that threshold, counted only. The 20 quotable ones total 185 attempts, so the remaining 1,747 are scattered across 1,208 combinations — 1.45 per combination. root/(empty password) is 38 attempts from 5 sources (7.6 per source), the most repetition per source; admin/admin is 14 sources, 29 attempts (2.1 per source)
14. (Daily tally · 01 — signatures)
    FACT 47 client-signature clusters (9/17: 44). Of the 15 in today's list, the only signature that delivered samples is 16443846…(SSH-2.0-Go · 2 sources today · 20 in tally), and that belongs to ATK-CA5936. 3356ae61…(SSH-2.0-PuTTY_Release_0.84) is listed as 3 sources today · 3 in tally, looking like a first arrival, but it was already in the 9/4 · 9/5 briefs — the 'tally' field cannot be read as cumulative (pointed out in the 9/5 brief). Scanner banners 4e066189…(Fingerprintx-SSH2 · 2 sources) · dd9bcf09…(ZGrab SSH Survey · 2 sources) also present
15. (Daily tally · 01 — remaining files)
    FACT 9-byte ASCII (0dc95fb4…) 4 times from ATK-CE432E (alias not in the archive) — on 9/17 ATK-A593DF left the same hash twice. 1-byte empty file (01ba4719…) 11 times from ATK-DD41EC. Of the 7 kinds stored on 01 today, the only executable is net.x86_64
16. (Daily tally · 02 — axis ③)
    FACT 71,793 sessions · 466 unique sources. VNC(5900) 39,919/228 sources (55.6%) · RDP(3389) 30,335/117 sources (42.3%) · SMB(445) 277/53 sources · LDAP(389) 148/41 sources · MSSQL(1433) 11/10 sources · ADB 1,103. The six sum to exactly 71,793, matching the total. Collection normal
17. (Daily tally · 02 — ADB)
    FACT 1,103 ADB sessions. Among archive 02 values (8/26 86 · 8/27 26 · 8/28 87 · 8/29 37 · 8/30 25 · 8/31 52 · 9/1 22 · 9/2 23 · 9/3 32 · 9/4 25 · 9/5 111 · 9/6 47 · 9/7 50 · 9/8 26 · 9/10 31 · 9/13 40 · 9/15 26 · 9/17 299), 3.7× the high of 299 and 9.9× the pre-9/17 high of 111 (9/5). 1.5% of all of 02, but by this channel's own standard a scale never seen before. The 4 stored samples (0d3c687f… 46,525 · 76ae6d57… 239,388 · a1b6223a… 334,816 · d7188b8c… 153,208 bytes · 2 each) are all hashes present since the 8/28 brief; only the source ATK-C70753 is a new alias. On 9/17 ATK-C93E77 left the same 4; on 9/15 ATK-4731EE left 2 of them
18. (Daily tally · 02 — ADB inference)
    INFERRED Contacts became 3.7× in three days, but the payload is the same 4-file set unchanged since 8/28. Only the source alias differs each time (ATK-4731EE → C93E77 → C70753). It reads as the same tool pushing the same file set from multiple sources, but ADB source count · injected commands are not in the JSON and cannot be confirmed. Reading 02 samples as ADB is itself a structural inference — 'ADB is the only channel on 02 where files get left'
19. (Daily tally · 02 — RDP returns)
    FACT RDP 30,335 is the third-highest value in the archive (8/26–9/17) after 9/13 42,578 · 9/10 34,811. The surge that seemed to end with 9/15 2,031 · 9/17 2,210 returned after four days. 117 sources is in the same band as 9/10 109 · 9/13 107; 259.3 per source. RDP cookies: mstsc 26,560 (87.6%) · <ip> 428 · hello 169 · Administr 94 · Admin 66 · Domain 2, total 27,319 (90.1%), unrecorded 3,016. 'mstsc', which vanished from the list on 9/15 · 9/17, is back in first place. 'Admin' 66 is a string absent from the 9/10 · 9/13 · 9/15 · 9/17 lists; 'Administr' 94 is 15.7× the prior high of 6 (9/10)
20. (Daily tally · 02 — source concentration)
    FACT #1 ATK-E37B01(149.50.x.x) 29,437 = 41.0% of all of 02. An alias that was #1 on 9/10 (34,229) · 9/13 (34,899) and then vanished from the top 12 on 9/15 · 9/17. RDP 30,335 − 29,437 = 898, so it is plausible this alias hammered RDP, but source ↔ service mapping is not in the JSON and cannot be confirmed. #2–#6 (ATK-4B5516 6,562 · ATK-B24952 6,550 · ATK-0D2C3B 6,540 · ATK-A9F1B3 5,659 · ATK-943F0E 5,652) form a narrow band 5,652–6,562; it breaks at #7 with 1,073. Top 12 total 63,229 (88.1%); the remaining 454 sources account for 8,564, 18.9 per source. Seven aliases — ATK-4B5516 · 0D2C3B · D4B7A8 · 78BF7F · EF5FFC · 26D240 · 457428 — were not in the archive's top lists (but the archive carries only 12 per day)
21. (Daily tally · 02 — protocol vocabulary)
    FACT VNC proposed versions 003.003 36,832 · 003.008 3,031 (92.4% : 7.6%), total 39,863, 56 fewer than sessions. VNC 39,919 is 1.9× up from 9/17 20,953 (archive low) but within the 8/26–9/13 band (29,111–65,487). Of 417 SMB dialect proposals, excluding 3 'SMB 2.???', 414 (99.3%) are SMB1 generation (NT LM 0.12 89 · LANMAN1.0 80 · LM1.2X002 80 · PC NETWORK PROGRAM 1.0 43 · Windows for Workgroups 3.1 42 · LANMAN2.1 42 · LANMAN 38). Proposals exceed the 277 sessions because one negotiation lists multiple dialects. MSSQL 11/10 sources, 1.1 per source, the sparsest channel
22. (Background)
    FACT The 12 URLs at distribution site hxxp://31[.]77[.]227[.]121/bins/ that surface only when UPX-packed samples are unpacked have recurred since the 8/16 brief and are not new indicators today. No packed executables among today's 01 stored files. 1 discord webhook URL as a plaintext indicator (kept defanged). Vulnerability background statistics (CVE 7,636 · KEV 400 · ransomware-confirmed 100) are based on KISA notices and do not connect directly to today's observations. Combined unique-source upper bound across both sensors 674 (overlap unknown)

FACT Three of the five scenes are Telnet. Telnet was only 7.7% of yesterday’s sessions, yet it took three of the five dense records. And the two lines at 20:47, just like two days earlier, ran overlapping, a little over 2 seconds apart. The two sessions that were 7 hours apart on September 15 have been arriving side by side since the 17th. With only two occurrences, we do not call it a “cycle.”

Three Days Ago We Wrote “Unchanged”

FACT In the September 17 post we wrote that the hashes of the two files ATK-BDB53E fetched were identical to the 15th. Not rebuilt in the two days between, we said. Yesterday the same alias fetched the same two file names from the same address again. One of them changed.

FACT 1,696 bytes is a little over ten lines of a text message. 192,328 bytes is about one-fifteenth of a smartphone photo. The new hash 2cebccdc… appears nowhere in the 28 days of archive (8/16–9/17). The address, the file name and the file type (ELF 64-bit x86-64 · statically linked · stripped) are all unchanged. The script that stands in front and makes the download happen, kla.sh, is unchanged too. Only the executable inside changed.

INFERRED It reads as the loader left alone and only the executable rebuilt and placed in the same spot. What changed — the function, the address it takes orders from, or the packaging — we do not know, because the file contents are not in the material. The September 18 and 19 briefs are not in the archive, so we also do not know on which of the three days it changed. One thing is certain. A block rule built from the September 15 hash does not catch yesterday’s file; a rule built from the address does. The “shelf life of a hash” story from the August 24 post repeated itself at this address.

Yesterday’s Values — To Copy Down

FACT We carry the values over as-is so you can use them for defense. Click a value to copy it. Addresses are altered so they cannot be connected to; leave them as they are. The top two lines are values first seen yesterday. The rest have not changed for weeks, so we mark them “background.”

FACT Of the nine lines, the only value first seen yesterday is the top line, one hash. The address beneath it appeared for the third time since September 15, and the public key on the fifth line has not changed once since August 16. Yesterday’s “novelty” is limited to one executable hash. Everything else changed only in quantity.

Are You Using These Passwords?

FACT Login attempts yesterday: 1,932, from 208 different sources. Divide the day into seconds and that is one every 45 seconds.

FACT Of the username/password combinations attempted, we carry over only 20 into this post. The remaining 1,208 we count but do not print. Our rule is to quote verbatim only combinations repeated from three or more different IPs. A combination seen from only one or two places could be someone’s real account leaked from somewhere. It is like not writing down a neighbor’s door code you happened to see. The 20 quotable combinations total 185 attempts. The remaining 1,747 are scattered across 1,208 combinations — 1.45 per combination, tried almost exactly once and moved on.

The 20 below are the opposite. Repeated from many places, they can be regarded as “factory defaults that belong to no one.” Please look at the first and second lines.

FACT The first line is yesterday’s ledger ②. From 40 sources, exactly once each. By contrast, root with the password field entirely empty was 38 attempts from 5 sources — each source tried it 7.6 times. It is yesterday’s most-repeated combination per source. admin/admin was 14 sources, 29 attempts.

INFERRED This list was not built to target us. It is a dictionary of values that work anywhere, tried in order. And which of these combinations the 41 card-registering sources used to get in — because the ledgers are separate — we do not know.

The Whole of Yesterday

FACT The daily tally for the side whose door actually opens (sensor 01). Read the right-hand column alongside — a lone number gives no sense of scale.

FACT By session count alone, an ordinary day. What was special yesterday was not the volume of knocking but the number of places that came in and registered a card. It was a day when the lines in the registration list jumped, not the number of times the handle was turned.

FACT Counting what happened inside the server yesterday by type:

FACT Intent-tagged commands numbered 1,967, 87.8% of the total. Reconnaissance alone dominates. “Reconnaissance — system” is the act of coming in and looking around to see what kind of house this is. Commands asking which Linux, how many CPUs, and so on.

FACT Those who came in over SSH leave a client-program signature (hassh). Yesterday’s signature clusters numbered 47 (44 on the 17th). The most frequent signature, f555226d… (libssh_0.9.6 · 41 sources), is recorded as having left no files at all. The only signature that left files is 16443846… (SSH-2.0-Go · 2 sources today), and that belongs to ATK-CA5936. A signature identifies the client program, not the person. Unrelated people using the same distribution’s default libssh get the same value.

The Server Next Door — A House With No Lock, Only a Doorbell

FACT The second server (sensor 02) is a shallow trap that lets no one inside. With no lock and only a doorbell, all that remains is “which door’s bell was rung, by how many places, how many times.” No login successes, no commands, no credentials exist here. Collection was normal yesterday. Please look at the ADB and RDP lines.

FACT Adding the six lines gives 71,793, matching the session total exactly. The doorbell rang once every 1.2 seconds all day long. ADB, at 1,103, is only 1.5% of the total, but by this door’s own standard it is a scale never seen before. The largest value in the archive was 299 three days ago, and before that 111 on September 5. 3.7× and 9.9×. Yet the 4 files left on the server next door are all hashes present since August 28; only the source ATK-C70753 is a new alias. The ringing increased, but what was left behind is the same old stuff. Today’s video covered this part with a different analogy.

INFERRED Reading these 4 files as having arrived via ADB is because of the structure: ADB is the only channel on the server next door where files get left. The data does not say so. Only the source alias changed each time (ATK-4731EE → C93E77 → C70753).

FACT Remote desktop is back. The door that surged to 34,811 on September 10 and 42,578 on the 13th, then faded to 2,031 on the 15th and 2,210 on the 17th, was 30,335 yesterday. That is the third-largest value in the archive, once every 2.8 seconds. Sources numbered 117, in the same band as the 10th (109) and 13th (107). It was not a day of more sources, but of one source ringing 259 times each.

FACT It is not only the numbers that returned. When connecting over remote desktop, the other side sends a name tag (cookie) it writes itself, and mstsc — first place on the 10th and 13th, gone from the list on the 15th and 17th — is back in first place with 26,560 yesterday. That is 87.6% of RDP. After it: <ip> 428, hello 169, Administr 94, Admin 66, Domain 2. Admin is a string absent from the lists of the 10th, 13th, 15th and 17th, and Administr at 94 is 15.7× the prior high of 6 (9/10). The name tag is a value the other side writes, so it can be faked freely.

FACT The place that rang the bell most is familiar too. ATK-E37B01 (149.50.x.x) at 29,437, 41.0% of everything on the server next door. An alias that was first on the 10th (34,229) and 13th (34,899), then vanished from the top 12 on the 15th and 17th. It is 898 short of the RDP total of 30,335, so it is plausible this alias rang the remote desktop door, but there is no field in the JSON linking source to door, so we do not confirm it. Places 2–6 cluster in a narrow band at 6,562 · 6,550 · 6,540 · 5,659 · 5,652, then drop sharply to 1,073 at 7th. The top 12 ring 88.1%; the remaining 454 average 18.9 each.

FACT Screen sharing was 39,919, up 1.9× from the low on the 17th (20,953) but within the August 26–September 13 band (29,111–65,487). Of the proposed versions, 92.4% are the old 003.003. On the file-sharing side, of 417 proposals, excluding 3 SMB 2.???, 414 (99.3%) are SMB1-generation specs. Proposals outnumber the 277 sessions because a single negotiation lists several specs in a row.

INFERRED Leading with old versions and old specs is closer to the behavior of a general-purpose scanner trying to get even old systems to respond. There is no evidence we were chosen as a target, nor that a particular vulnerability was aimed at. And every number in this paragraph is a record of doorbells ringing. This house has no door, so the sentence “they came in and did something” cannot be formed.

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. The first line is today’s axis.

• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — plant SSH key' 43 times, public key a8460f44… from 41 sources (today's axis ①)INFERRED
• T1110.001Brute Force: Password Guessing — 1,932 login attempts, 20 quotable combinations · 1,208 withheldINFERRED
• T1078.001Valid Accounts: Default Accounts — default combinations such as admin/admin 14 sources · root/root 6 sources · root/(empty) 5 sources · root/xc3511 3 sources · telnetadmin/telnetadmin 3 sources; all 5 main sessions logged in successfullyINFERRED
• T1021Remote Services — remote access via Telnet(2223) · SSH(2222)INFERRED
• T1082System Information Discovery — 'reconnaissance — system' 1,652 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 38 times, receipt of rebuilt net.x86_64 from distribution site 160[.]119[.]66[.]206INFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'grant execute permission' 159 timesINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — 'execute after download' 31 times, shell script kla.shINFERRED
• T1070Indicator Removal — 'trace removal' 42 times (2.8× 9/17). No sub-classification of whether file deletion or history deletionINFERRED
• T1562Impair Defenses — 'impair defenses' 1 time (ATK-DD41EC). Cannot tell what was disabled, so no sub-technique attachedINFERRED
• T1595Active Scanning — 02's VNC 39,919 · RDP 30,335 · ADB 1,103 contacts and observation of protocol negotiation stageINFERRED
• T1133External Remote Services — contacts against internet-exposed 3389 · 5900 · 445 · 389 · 1433 and ADBINFERRED
• T1027.002Obfuscated Files or Information: Software Packing — 12 indicators surfacing only from UPX-packed samples (background, not new today)INFERRED

FACT Note that all thirteen lines carry the [INFERRED] badge. What we have in hand is the commands’ “intent classification result” and “how many times,” and the files’ names and sizes. We have neither the raw commands nor the file contents. Matching to the classification is always interpretation, and we label interpretation as interpretation. In particular, the tenth line, T1562, rests on a count-match inference that the single “impair defenses” belongs to ATK-DD41EC.

There Has Been a Shape Like This Before

INFERRED Mirai botnet (2016). Its structure was to enter Linux devices with a dictionary of Telnet default credentials, then use a shell-script loader to download and run statically linked ELF binaries pre-built per CPU type. root/xc3511, root/root, admin/admin and telnetadmin/telnetadmin in yesterday’s table are values found in the credential list of the Mirai source code released in 2016. And ATK-BDB53E’s delivery form — “Telnet login → shell script at a /bins/ path → statically linked, stripped ELF → grant execute permission → run” — is the same. (Source types: US-CERT alert TA16-288A · publicly released source code · multiple vendor analysis reports)

INFERRED GoldBrute (2019). A botnet that mass-brute-forced remote desktop servers open to the internet. The form of a few sources hammering port 3389 at very high frequency resembles yesterday’s server next door (259.3 per source, top alias 29,437). However, only the negotiation stage was observed on the server next door yesterday, so the actual brute-force content cannot be confirmed, and there is no evidence linking it to this botnet. (Source type: public analysis on a security vendor research blog (Morphus Labs))

FACT We stop here. Because no sample-classification service (VirusTotal) is integrated, we do not rule that yesterday’s executable is Mirai-family. The resemblance goes as far as the credential values and the shape of the file.

So What Should Be Done

Whether 41 places come to our lock today is not ours to decide. What we can change is how our own lock is secured, who looks at the registration list, and how the paths leading out of our house are set up.

FACT 1. Still using default accounts and easy passwords · Likelihood high All twenty lines in the table above are values devices or distributions ship with, sequential digits, or bot-signature strings. admin/admin 14 sources, 29 attempts; root/root 6 sources; root/(empty) 5 sources, 38 attempts; root/123456 4 sources; root/xc3511 3 sources. All five sessions recorded yesterday succeeded at login, and after success went on to granting execute permission, downloading and planting keys within 3.7 to 9.2 seconds. On a real server, those few seconds are the moment of compromise.

FACT 2. Allowing password login and not using key-based authentication · Likelihood high Against yesterday’s 1,932 login attempts, there were 1,956 SSH sessions. The first thing those who got in after a password guess worked did was register their own card, and yesterday that came from 41 sources. Had only key-based login been allowed, the 1,932 attempts would have ended at the authentication stage. And if a card is already registered, changing the password later does no good. Opening the authorized_keys file yourself and checking for lines you don’t recognize comes before changing the password. Yesterday, 41 places built that back door in a single day.

FACT 3. Leaving management ports open to the internet · Likelihood high We have never announced our server address anywhere. Even so, 208 sources came to the side whose door opens yesterday, and 466 to the server next door. Combined, an upper bound of 674. This is not the trace of picking a specific target but the form of searching for open doors. If even one of SSH, Telnet, VNC, RDP, SMB or ADB is open, it becomes an entry point. Yesterday one source rang the server next door 29,437 times.

INFERRED 4. No count-based blocking (fail2ban etc.) · Likelihood medium Yesterday has two faces. The dominant form at the first house was 345gs5662d34 from 40 sources, 40 attempts, exactly 1 per source. admin/admin was 2.1 per source. A “lock after 5 failures” rule does not trigger. Conversely, remote desktop at the server next door was 259.3 per source, which that rule would certainly catch. And ATK-BDB53E ran two overlapping sessions 2.43 seconds apart. Because the result depends on the kind of defense, we do not put this at “high.” Without per-source limits, 30,000 a day pass straight through one port 3389; even with them, yesterday’s “40 sources, once each” gets through.

FACT 5. Not blocking outbound connections · Likelihood high Yesterday’s 192,328-byte executable is something the server went outside and fetched over HTTP. Had the outbound path been blocked, ATK-BDB53E’s 7 commands would have broken at the download stage. ‘File download’ 38, ‘execute after download’ 31 and ‘grant execute permission’ 159 would all stop at the same place. And that executable was rebuilt within three days and its hash changed. A hash-based block rule misses yesterday’s file; a rule blocking the outbound path blocks it regardless of hash.

INFERRED 6. Keeping logs only inside the server · Likelihood medium Yesterday the intent to erase traces appeared 42 times, 2.8× September 17. There was also 1 impair-defenses. Because we are a honeypot, we record 82.7% of sessions (1,754) separately, so they survive deletion. On a real server, unless logs are shipped out, nothing remains after deletion. You would not even be able to reconstruct later when they came in or which card they registered. But since the data does not say which sessions those 42 belong to, we leave this at “medium.”

FACT The new hash 2cebccdc… of the rebuilt net.x86_64 and the distribution site hxxp://160[.]119[.]66[.]206 are subject to reporting to C-TAS (KISA’s Cyber Threat Analysis & Sharing system). This will be the third report of this distribution site since its first observation on September 15. However, what we can confirm is only that the transmission succeeded; whether it was actually loaded on the receiving side must be verified separately.

What We Don’t Know

This is where this blog differs from others. We spend more time writing down what we don’t know than what we know. Today especially. The four ledgers don’t know each other.

What cannot be confirmed about today’s axis

• [Unconfirmable] Whether the 41 public-key sources · 41 libssh_0.9.6 signature sources · 40 345gs5662d34 sources · 43 SSH-key-planting intents are the same set — the JSON does not link them. All we have is the circumstance that the numbers jumped into the same range on the same day, the same limitation the August 18 brief pointed out. That the delivered-samples field for f555226d… is false suggests, if anything, that the two sets differ or that the public key is not counted as a “sample” — but the JSON does not explain which.
• [Unconfirmable] The aliases that delivered a8460f44… are disclosed for only 10 of 41, so we do not know the aliases of the other 31. The 10 disclosed are all aliases not in the archive, but whether the same holds for the other 31 cannot be known.
• [Unconfirmable] Which sessions the 42 “trace removal” events belong to — the JSON does not link them. None of the 5 main sessions carries a “trace removal” intent, so the value comes from sessions outside the main five.
• [Caution] “Previous high among compared days” is based on the 17 days on which the brief listed this value. The value for the remaining days of the 28-day archive is not in the brief’s list. Because 9/9 · 9/11 · 9/12 · 9/14 · 9/16 · 9/18 · 9/19 are absent from the archive, every “prior high” and “consecutive” expression is “by days present in the archive.” The September 17 brief’s “ADB prior high 52” omitted September 5’s 111; today we compared including that value.

What cannot be confirmed about the rebuilt file

• [Unconfirmable] Whether the change in net.x86_64’s hash from cd6ccc5d… to 2cebccdc… is a functional change · a C2 change · or repacking — the sample contents are not in the brief. The only fact is a 1,696-byte difference. The September 18 · 19 briefs are not in the archive, so the exact replacement time “within three days” is unknown too.
• [Unconfirmable] Whether the distribution site 160[.]119[.]66[.]206 and the intrusion source 160.119.x.x are the same machine. The last two octets are masked and not subject to restoration.
• [Unconfirmable] Whether the two ATK-BDB53E sessions came in with the same credentials — per-session credentials are not in the JSON. Whether the parallel execution 2.43 seconds apart is scheduled or coincidental — with only two occurrences (9/17 · today), we do not call it a cycle.
• [Unconfirmable] Whether the ATK-DD41EC session’s 28 commands in 9.2 seconds represent a speed change of the same tool as the prior family (62–91 s · 22) or a different tool — the raw commands are absent. Reading the single “impair defenses” as belonging to this session is an inference on a count-match basis.

What the data itself must be doubted on

• [Caution] The “tally” value in the signature list cannot be read as cumulative. f555226d… goes 9/17 205 → yesterday 310, yet 3356ae61… (PuTTY_Release_0.84), already present on 9/4 · 9/5, is recorded yesterday as tally 3 = today 3.
• [Unconfirmable] For the 1,103 ADB sessions on the server next door, source count · injected commands · port are not in the JSON. Reading the 4 files as via ADB is a structural inference, and the 4 have no file-type field, so we do not know what they are either.
• [Unconfirmable] Whether the 30,335 RDP sessions came from ATK-E37B01 alone cannot be confirmed. There is only the circumstance of 29,437 versus a difference of 898; the JSON has no per-source service mapping. We also do not judge what tool or intent the mstsc · Admin · Administr name tags signify.
• [Unconfirmable] Why the five sources at #2–#6 on the server next door cluster in the narrow band 5,652–6,562 (parallel execution of the same tool, or coincidence) and which services they hammered are not in the JSON. There is no basis for grouping aliases with different leading octets under the same operator.
• [Unconfirmable] The cause of the 56-session gap between the screen-sharing version-proposal total (39,863) and sessions (39,919), and the 3,016 gap between the RDP name-tag total (27,319) and RDP sessions (30,335) — the JSON does not explain.
• [Unconfirmable] Whether a single source on the server next door swept multiple doors together cannot be computed. Whether the difference of 17 between the sum of per-service unique sources (449) and the total (466) is ADB sources or overlap cannot be distinguished. Writing 0 would be false, so we leave it as “not computable.”
• [Caution] The judgment “hash · alias not in the archive” is a comparison against the 28 briefs of 8/16–9/17, not a full comparison against the raw logs.

What we deliberately did not connect

• [Excluded] The vulnerability indicators that arrived as background statistics (7,636 tracked CVEs · 400 KEV · 100 ransomware-linked confirmed) are values drawn from KISA security notices. They connect to no session or sample observed yesterday. All of yesterday’s observations on both servers were credential guessing and protocol negotiation referencing no vulnerability number.
• [Excluded] The 12 entries at distribution site 31[.]77[.]227[.]121/bins/ that surface only on unpacking are recurring indicators since August 16, not new indicators yesterday. There were no packed executables on the first server yesterday. The 1 discord webhook URL remaining as a plaintext indicator is also kept only in defanged form.
• [Unconfirmable] The C-TAS report is confirmed only as far as the transmission succeeding. Whether yesterday’s new hash and distribution site were loaded at KISA must be verified separately.

What we do not judge at all

• Carrier · organization (ASN · ISP) — We have no such database. We do not infer it.
• Geographic information — Same as above. IP geolocation is no basis for attribution in the first place. This post names no country, company or individual as the attacker.
• VPN · Tor · cloud status — We have no means of determining it.
• Sample classification (VirusTotal) — Not integrated. Sample classification uses MalwareBazaar tags, and yesterday’s new executable has no tag.
• Client-program string (User-Agent) — Neither observation surface is web (HTTP). 01 is SSH · Telnet; 02 is SMB · RDP · VNC · MSSQL · LDAP · ADB. HTTP attacks are a separate source.
• Vulnerability number (CVE) linkage — SSH · Telnet attacks mostly reference no specific vulnerability, and 02 is at the spec-negotiation stage, so likewise.

Forty-one places registered the same single card on our lock in one day. That is 2.4× the previous high of 17 among the days we compared. The same day, the password ledger, the client-program ledger and the behavior-classification ledger also jumped 2–3× side by side. But the four ledgers don’t know each other. Whether it was one hand or four, the records do not say.

Next to it, the file we wrote “unchanged” three days ago came back changed. What changed, we do not know. What we do not know, we leave as unknown. Writing down that we don’t know is part of observation too.

What can be done on this side, though, is clear. Open the lock’s registration list (authorized_keys) yourself and check for lines you don’t recognize; allow only key-based login instead of passwords; don’t leave management ports exposed to the internet; block the path by which the server fetches files from outside; and keep records outside the server. What the 41 places pointed to yesterday was exactly there.

The observation date is September 20, 2026, and this post was compiled the following day. Source IPs are carried over exactly as masked in the brief (130.12.x.x, 160.119.x.x, 116.92.x.x, 149.50.x.x) and were not restored. For the 41 sources that registered the card, aliases are disclosed for only 10, so no representative IP is given. Distribution addresses are kept defanged (hxxp://, [.]) in both the body and the IOC block so they cannot be connected to by accident. Credentials are quoted verbatim only for the 20 combinations repeatedly observed from 3 or more different IPs; for the remaining 1,208 we disclosed only the count and not the values. Items for which we have no instrumentation — carrier, nationality, VPN status — were not inferred and were left as “unknown.”