Seven Seconds, Twice — And the Name Tag's Front Half Matched Again

A kid you’ve never seen before walks into your classroom at school. You look at the name tag: you can read “Grade 3, Class 2”, but the name itself is covered with tape. The kid is empty-handed. Yet within 7 seconds, they’ve fetched two items from somewhere and set them on your desk. They switch one on. Then they leave.

The items have locker tags on them. Those tags also say “Grade 3, Class 2.”

Is it that kid’s own locker? Another kid’s locker in the same class? The name on the tag is covered, so we don’t know that far. There’s only one thing we can say: the front half of the name tag and the front half of the locker tag match.

This is the third time in nine days. And that kid came back in the evening and did the exact same thing once more, without a single step out of order.

That’s what landed on our server yesterday.

Our Server Is a Classroom We Deliberately Leave Unlocked

FACT We run a honeypot server. A honeypot is a decoy server deliberately left poorly secured so we can watch who comes in and what they do. Think of it as an empty classroom with the door left unlocked. So what happened here is an observation record, not real damage.

FACT We assigned the alias ATK-BDB53E to whoever entered this classroom yesterday. An alias is not an identity. It is just a label so we can refer to the same masked source consistently from post to post. The source IP is 160.119.x.x. We masked the last two octets ourselves, and we do not restore them. That’s the tape over the name on the tag. This alias is a new one that appears nowhere in the 26 days of our archive (August 16 through September 13).

FACT The way in was Telnet. Telnet is a very old remote-access method in which the characters exchanged travel unencrypted, in the clear. On our server that path is port 2223, and yesterday there were 675 Telnet sessions.

12:07:46 PM, and Then 7 Seconds

FACT September 15, 12:07:46 PM. ATK-BDB53E came in over Telnet and logged in successfully. From then until 12:07:53, over 7.01 seconds, it typed 7 commands. Roughly one per second. In that window, 2 files came in.

FACT The commands were classified under three intents: file download → grant execute permission → download-then-execute. In order: “fetch it, mark it as a file that’s allowed to run, run it.” No reconnaissance, no track-covering. Just those three things.

FACT The two files that came in are these. One is kla.sh, a 3,241-byte shell script. A shell script is a file of instructions for Linux written out as text, and at that size it’s about twenty lines of text messages. The other is net.x86_64, a 190,632-byte ELF executable. ELF is the name of the format Linux program files use, and the x86_64 after the name is the CPU type this file runs on. By size, it’s 59 times the script.

FACT The executable is statically linked and stripped. Statically linked means the program was built with every part it needs packed inside as a single piece. It runs fine on someone else’s machine because it never has to borrow parts. Stripped means the internal labels the author left in were removed before distribution. That makes it harder to take apart.

FACT This session was screen-recorded. But the recording’s contents are not in the material for this post. The client fingerprint field is empty, too — because Telnet leaves no fingerprint (hassh).

Laid out in time order, it looks like this. Put the 12:07 line and the 19:07 line side by side — how far the numbers match is today’s point.

1. 02:18:50Z (11:18 KST)
   FACT ATK-CA5936(130.12.x.x) SSH login success. 3.97s · 1 command · 2 downloads · 5 intents (recon · download · execute permission · download-then-execute · SSH key planting). An alias observed repeatedly since 8/19, so not today's subject
2. 02:42:58Z (11:42 KST)
   FACT ATK-E09588(94.68.x.x) Telnet login success. 69.3s · 22 commands · 11 downloads — all 11 are 1-byte empty files (01ba4719…). Only one intent, 'impair defenses', yet completeness 42, today's highest. A lineage recorded eight times in the archive, so excluded from the subject
3. 03:07:46Z (12:07 KST)
   FACT Today's subject, round 1. ATK-BDB53E(160.119.x.x) Telnet login success. Until 03:07:53Z, 7.01s · 7 commands · 2 downloads. Intents: file download → grant execute permission → download-then-execute. Screen recorded. Fingerprint field empty (Telnet has no hassh)
4. (same session)
   FACT Files fetched: hxxp://160[.]119[.]66[.]206/bins/kla.sh (3,241-byte POSIX shell script · 39be6853…) and hxxp://160[.]119[.]66[.]206/bins/net.x86_64 (190,632-byte ELF 64-bit x86-64 · statically linked · stripped · cd6ccc5d…). Both from a single source today, ATK-BDB53E, each observed 4 times
5. (same session)
   FACT The distribution host's first two octets, 160.119, match the masked source 160.119.x.x. The last two octets are masked, so whether it is the same machine cannot be known
6. (comparison)
   FACT 9/7: 131.123.x.x ↔ 131[.]123[.]40[.]104 · 9/8: 94.154.x.x ↔ 94[.]154[.]43[.]221 · today: 160.119.x.x ↔ 160[.]119[.]66[.]206. Third time in nine days, and all three are Telnet · shell script + statically linked ELF combinations
7. (comparison)
   FACT The name 'kla.sh' also appeared in the 8/21 brief. The distribution host then was 176[.]65[.]139[.]196, and today's hash 39be6853… is not in the archive — same name, different file
8. 10:07:02Z (19:07 KST)
   FACT Subject, round 2. Same alias ATK-BDB53E Telnet login success. Until 10:07:09Z, 7.48s · 7 commands · 2 downloads · same 3 intents · same completeness 19. 6h 59m 15.3s after round 1 began
9. (inference)
   INFERRED Matching command count · download count · intents · duration (7.0s/7.5s) looks like a script running the same procedure twice, not a human. Whether the 7-hour gap is scheduled execution or coincidence cannot be known
10. (inference)
    INFERRED On 9/8 the whole nine-CPU executable set was fetched, but today only the x86-64 one. The script may check the CPU first and pick only the matching one, but the script's contents are unavailable, so this cannot be confirmed
11. 11:06:08Z (20:06 KST)
    FACT ATK-CA5936's second SSH session. 3.86s · 1 command · 2 downloads · 5 intents — same shape as the 11:18 session
12. (daily totals · 01)
    FACT 4,332 sessions · 198 unique sources · 3,620 login attempts · 4,088 commands · 3,487 screen recordings. Compared with 9/13 (2,016 sessions · 322 sources), sources down by 124 and sessions 2.1x. 21.9 per source (9/13 was 6.3)
13. (daily totals · 01)
    FACT Intents: recon—system 3,337 · grant execute permission 180 · file download 45 · download-then-execute 40 · SSH key planting 17 · indicator removal 16 · recon—network 2 · impair defenses 1. Sum 3,638, 89.0% of all commands; recon alone 81.6%. 'File download' 45 vs 'download-then-execute' 40, a difference of 5, departs from most days when the two were equal
14. (daily totals · 01)
    FACT 44 SSH fingerprint clusters. Of today's 14 fingerprints, only 16443846… (SSH-2.0-Go · 2 sources today · 21 cumulative) delivered a sample. The most common fingerprint f555226d… (libssh_0.9.6 · 14 sources today · 175 cumulative) delivered no files at all. The subject sessions are Telnet, so they belong to no cluster
15. (daily totals · 02)
    FACT 37,557 sessions · 539 unique sources. VNC 35,120 (351 sources · 93.5%) · RDP 2,031 (110 sources) · SMB 218 (39 sources) · LDAP 132 (12 sources) · MSSQL 30 (11 sources) · ADB 26, 3 samples
16. (daily totals · 02)
    FACT RDP went 9/10 34,811 → 9/13 42,578 (archive high) → today 2,031, one twenty-first. The cookie 'mstsc', in the 30,000s back then, is absent from today's list, and ATK-E37B01, then #1, is not in today's top 12. Today's cookies: 'hello' 1,461 (71.9%) · '<ip>' 405 · 4 random strings at 1 each
17. (daily totals · 02)
    FACT VNC's 351 unique sources is the fourth-highest after 9/8 416 · 9/13 407 · 9/10 387, and 35,120 contacts is the lowest since 9/6. Proposed VNC versions: 003.003 30,437 · 003.008 4,589 (86.9% : 13.1%)
18. (daily totals · 02)
    FACT Of 276 SMB dialect proposals, excluding 26 'SMB 2.???', 250 are SMB1 generation (NT LM 0.12 77 · LANMAN1.0 43 · LM1.2X002 43 · PC NETWORK PROGRAM 1.0 22 · Windows for Workgroups 3.1 22 · LANMAN2.1 22 · LANMAN 21). More proposals than the 218 sessions because one negotiation lists multiple dialects
19. (daily totals · 02)
    FACT Top 4 sources (ATK-943F0E 5,736 · ATK-A9F1B3 5,723 · ATK-AE6CC0 4,691 · ATK-0E3BBB 1,436) account for 17,586, 46.8% of all of 02. Which services they knocked on is not in the data
20. (daily totals · 02)
    INFERRED All 3 samples on 02 are from ATK-4731EE (an alias not in the archive). 0d3c687f… (46,525 bytes) · d7188b8c… (153,208 bytes) are hashes seen on 8/28·8/30·9/3·9/7; only 7a656791… (231,196 bytes) is new. ADB is the only channel on 02 that leaves files, so we read them as ADB, but the data does not state it
21. (background)
    FACT The 12 distribution URLs under 31[.]77[.]227[.]121/bins/ that appear only after UPX unpacking have repeated since 8/16 and are not today's new indicators. As a plaintext indicator, there is 1 discord webhook URL (kept defanged)

FACT Between the 12:07 line and the 19:07 line, the only number that differs is the 0.47-second duration. 7 commands, 2 files, 3 intents, completeness 19. Everything else is identical.

7:07 PM, Once More

FACT 6 hours 59 minutes 15.3 seconds after the first session began, at 7:07:02 PM, the same alias came back in over Telnet. This time, 7.48 seconds. 7 commands, 2 files, the same three intents. The two files fetched were the same two.

INFERRED It’s hard to read this as a person coming twice. A person is faster or slower the second time. For everything from command count to duration to line up this closely, it looks like a script with the same procedure written down, run twice. Like the kid in the classroom reading off the same note both times.

INFERRED But we will not write “it comes every 7 hours.” There were only two. You can’t draw a period through two points. Whether it was scheduled execution or coincidence, our data cannot tell.

The Name Tag’s Front Half Matched — Third Time in Nine Days

FACT The intruder’s IP is 160.119.x.x. The address the files were pulled from is hxxp://160[.]119[.]66[.]206/bins/. The first two octets match. Writing the address in this odd way is not a typo. It’s a convention: http becomes hxxp and dots become [.] so that nobody connects to it by an accidental click. It’s called defanging — pulling the teeth out.

FACT And this shape is not a first. Look only at the first two octets in the three rows below.

FACT Third time in nine days. All three were Telnet, all three were the “one shell script + statically linked executable” combination, and all three fetched files from under /bins/ or the root path. And the six addresses across the three sources and three distribution hosts do not overlap with each other at all.

INFERRED That is as far as we can say. With the last two octets masked, we cannot determine whether it’s the same computer or a different, neighboring one. Just as we wouldn’t write “same kid” because the front of the name tag matches. We did not restore the mask to check, and we will not. What is fact is that the shape — “the front of the source and the front of the file storage match” — appeared three times in nine days, and that each time it was a new cast.

FACT The file name kla.sh also appeared in our August 21 post. It came from 176[.]65[.]139[.]196 then. But yesterday’s file hash, 39be6853…, is not in the archive. A hash is a fingerprint computed from the entire contents of a file, so a single changed character changes the value. In other words, same name, different file inside. Like a different kid attaching a locker tag with the same name.

INFERRED On September 8, the whole set of nine builds, one per CPU type, was fetched; yesterday only the x86_64 build was. The script may check the CPU of the machine it landed on and pick only the matching one. But the script’s contents are not in our material, so this cannot be confirmed. We leave it as a possibility only.

Why This Session, and Not the Loudest One

FACT Five sessions left records yesterday, and the one with the most commands and the densest record (completeness 42) is a different one: ATK-E09588 at 11:42 AM. 69.3 seconds, 22 commands, 11 downloads. But all 11 are 1-byte empty files. A single character’s worth. And this “1 source · 11 times · empty file” combination has been written identically in the briefs eight times since August 18.

FACT The same goes for ATK-CA5936, which came in twice, at 11:18 AM and 8:06 PM. It’s an alias that has appeared repeatedly since August 19, and the two files it left yesterday (a 54-byte text file · a 399-byte SSH private key) are already in the August 19, September 1, and September 6 posts.

FACT ATK-BDB53E, on the other hand, has an alias, a distribution host, and two hashes, none of which are in the archive. Three stages of intent ran in sequence within one session, and it repeated twice in one day. We chose not the loudest session but the one where a face we’d never seen opened a locker we’d never seen.

What Came Out of the Locker Yesterday — Values to Write Down

FACT We copy the values as-is so you can use them defensively. Click a value to copy it. The addresses are altered so they can’t be connected to; use them as they are. The top four lines are values that first appeared yesterday; the rest is background that hasn’t changed in weeks.

FACT In the top four lines, note “4 times today.” The two subject sessions’ download counts add up to 4, but the per-file observation counts add up to 8. Where it doubled, our data cannot tell. Retries may have been counted, or there may have been more sessions that didn’t make it into the record. We write this again under “What We Don’t Know” below.

We Deliberately Hid 962 of Them

FACT Yesterday there were 3,620 login attempts, from 198 distinct sources. Divide the day into seconds and that’s one every 24 seconds. An average of 18.3 per source.

FACT Of the username/password combinations attempted, we reproduce only 20 in this post. The remaining 962 we count but do not write out. Our rule is to quote verbatim only combinations repeated from three or more distinct IPs. A combination seen at only one or two places could be someone’s real account leaked from somewhere. It’s the same reason we cover the name on the name tag. We don’t show what might belong to someone we don’t know.

The 20 below are the opposite. Repeated from many places, they can be taken as “factory defaults that belong to no one.”

FACT admin/admin came in 39 times from 20 sources. A little over twice per source. The eleventh row is a combination whose password field is completely empty. That means six sources tried entering just the username and hitting Enter.

INFERRED This list was not built to target us. It’s a dictionary of values that work anywhere, tried in order. Meaning the classroom door opened yesterday not “because it was us.”

FACT But we don’t know which combination the two subject sessions came in with. Per-session credentials are not in our material. The table above is for the whole day, not the key that kid used.

Yesterday as a Whole

FACT Daily totals for the side where the door actually opens (sensor 01). Read the right-hand column too — one number alone gives no sense of scale.

FACT Compared with September 13, the shape flipped. That day, 322 sources came 6.3 times each; yesterday, 198 sources came 21.9 times each. Fewer places are coming, and what each one does has grown 3.5x. The per-port sum (3,656 + 675) matches the session total of 4,332 exactly.

FACT Counting what happened inside the server yesterday by type:

FACT “Grant execute permission” is the act of attaching a mark to a file that says “this one is allowed to run.” On Linux, without that mark, even a program simply won’t run. This was the second stage of yesterday’s subject session.

FACT “File download” at 45 and “download-then-execute” at 40 differ by 5. On most days in the archive these two values were exactly equal. That means yesterday there were five commands that downloaded but did not go on to execute. Which session they belong to is not in the data.

FACT One more thing. Those who come in over SSH leave a client fingerprint (hassh). Yesterday there were 14 fingerprints, and of those, only one, 16443846… (SSH-2.0-Go), actually left a file behind. 2 sources today, 21 cumulative. The fingerprint that came most often yesterday, f555226d… (libssh_0.9.6 · 14 sources today · 175 cumulative), left no files at all. Coming often doesn’t mean leaving something behind. And yesterday’s main character is Telnet, so it appears nowhere in this fingerprint list.

The Server Next Door — The Side That Lets No One In

FACT We keep two servers. The second (sensor 02) is a shallow trap that doesn’t let anyone inside, so it only records “which door, how many sources, how many knocks.” No login successes, no commands, no credentials exist here. Collection was normal yesterday.

FACT 35,120 screen-sharing knocks spread over a day is one every 2.5 seconds. Split among 351 sources, that’s an average of 100 knocks per source. Yet this is the lowest day since September 6. The 351 sources also rank after 9/8 (416) · 9/13 (407) · 9/10 (387).

FACT The biggest change on the server next door yesterday was remote desktop. September 10, 34,811; September 13, 42,578 — the archive high. Yesterday, 2,031. One twenty-first. A door that rang every 2 seconds went back to once every 43 seconds. The connection label mstsc, which was in the 30,000s back then, is absent from yesterday’s list, and the alias ATK-E37B01, then #1, is not in yesterday’s top 12. Yesterday’s labels were hello 1,461 (71.9%) · <ip> 405 · 4 random strings at 1 each.

INFERRED That what flooded in for three days has vanished is as far as the facts go. Why it ended, we don’t know. Whether they stopped or went elsewhere, we have no way of knowing.

FACT The protocol versions the other side proposes first are also recorded. For screen sharing, 003.003 came 30,437 times and 003.008 4,589 times — the older 003.003 at 86.9%. For file sharing, of 276 proposals, excluding 26 SMB 2.???, 250 are SMB1 generation (NT LM 0.12 77 · LANMAN1.0 43 · LM1.2X002 43 · PC NETWORK PROGRAM 1.0 22 · Windows for Workgroups 3.1 22 · LANMAN2.1 22 · LANMAN 21). There are more proposals than the 218 sessions because a single negotiation lists several dialects in a row.

INFERRED Leading with an old version means the other side is using a scanner that accommodates old systems, not that our server is old.

FACT The top 4 sources on the server next door (ATK-943F0E 5,736 · ATK-A9F1B3 5,723 · ATK-AE6CC0 4,691 · ATK-0E3BBB 1,436) account for 17,586, 46.8% of the total. Four places made nearly half. Which door they knocked on is not in the data. With screen sharing at 93.5% it’s tempting to read it that way, but that isn’t evidence.

FACT The server next door retained 3 samples, all from a never-before-seen alias, ATK-4731EE. Two are hashes seen four times since August 28; only 7a656791… (231,196 bytes) is a new hash. The sum of unique sources across both servers has an upper bound of 737 because overlap is unknown, and the true value is smaller.

Mapping the Attacker’s Methods to the International Classification

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

• T1078.001Valid Accounts: Default Accounts — 2 Telnet login successes. Which credentials were used is not in the data at the session levelINFERRED
• T1110.001Brute Force: Password Guessing — 3,620 login attempts in the day, 20 quotable combinations · 962 withheldINFERRED
• T1021Remote Services — Telnet (2223) remote accessINFERRED
• T1105Ingress Tool Transfer — 'file download' intent, receipt of kla.sh · net.x86_64INFERRED
• T1222.002File and Directory Permissions Modification: Linux and Mac — 'grant execute permission' intentINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — 'download-then-execute' intent, receipt of a POSIX shell scriptINFERRED
• T1608.001Stage Capabilities: Upload Malware — distributed from the /bins/ path of an address whose first two octets match the sourceINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 17 'persistence — SSH key planting' that day (not the subject session)INFERRED
• T1070Indicator Removal — 16 'indicator removal' that day (not the subject session)INFERRED
• T1562Impair Defenses — 1 'impair defenses' that day. What was disabled is unknown, so no sub-technique is assignedINFERRED

FACT Note that all ten lines carry the [INFERRED] badge. What we hold is the “intent classification result” of the commands and “how many times.” We don’t have the raw commands. Fitting to the classification is always interpretation, and we label interpretation as interpretation.

FACT And of the ten lines, yesterday’s main character stepped on four: T1021 (entering via Telnet) · T1105 (fetching files) · T1222.002 (granting execute permission) · T1059.004 (executing what was received). The last three lines — key planting, indicator removal, impairing defenses — are what other aliases did yesterday. Just because they’re in the daily totals, we don’t transcribe them to this session.

This Shape Has Been Seen Before

INFERRED The Mirai botnet (2016). Its structure was to enter Linux devices through weak Telnet credentials, then have a shell-script loader download and execute statically linked ELFs built per CPU type. After the source was published in 2016, many derivatives appeared. The combination in yesterday’s subject session — Telnet login success → 1 shell script + 1 statically linked, stripped ELF from the /bins/ path → grant execute permission → execute — is consistent with this structure. (Source types: US-CERT alert TA16-288A · the published source code · numerous vendor analysis reports)

FACT We stop here. There are no raw commands, and no sample-classification service is connected. We make no determination that the two files received yesterday belong to this family. What resembles is the way it’s built, not the label.

So What Should You Do

There’s no way for us to stop an unfamiliar kid from opening a locker in another class. What we can change is how our classroom door is locked, and how the corridor from the classroom to the outside is set up.

FACT 1. You’re still using default accounts and easy passwords · Likelihood high All twenty rows in the table above are values that devices or distributions ship with. Five sessions that succeeded at login yesterday are real, and the top attempted combinations are all defaults and sequential digits. Once a single password fell, a script and an executable came down within 7 seconds. On a real server, those 7 seconds are the moment of compromise.

FACT 2. You allow password login and don’t use key authentication · Likelihood high Telnet has no key-authentication option at all. On the SSH side too, 3,656 sessions brought 3,620 password guesses. If only key authentication were allowed, all 3,620 would end at the authentication step. And once intruders succeed, the first thing they do is install their own key. Yesterday there were 17 key plantings, and a 389-byte SSH public key showed up from 14 distinct sources. An SSH public key is, simply put, a spare key that lets you in without a password. Once it’s written as a line in the server’s authorized_keys (the list of allowed keys) file, that key keeps working even after the password is changed later.

FACT 3. You leave management ports open to the internet · Likelihood high We have never announced our server’s address anywhere. Yet yesterday 198 sources came to the side where the door opens, and 539 to the server next door. Across both, an upper bound of 737. The screen-sharing door alone was hit 35,000 times in a day. Exposure itself is the condition.

INFERRED 4. You have no count-based blocking (fail2ban, etc.) · Likelihood medium Yesterday was a day when single sources knocked many times. 21.9 sessions per source, 3.5x September 13. admin/admin came 39 times from 20 sources, so each source entered the same combination about twice. A rule that blocks repeats from the same source looks like it would be effective. But which attempt the subject session succeeded on is not in the data. A combination that’s correct on the first try can’t be stopped by this rule. That’s why we don’t set it to “high.”

FACT 5. You don’t block outbound connections · Likelihood high Of the 7 commands in yesterday’s subject session, the step that creates actual damage was the server reaching outward to fetch files. If the outbound path had been blocked, this session would have been cut off at the download stage. All 45 “file download” attempts yesterday would stop at the same spot. If the corridor from the classroom to the lockers is locked, the kid has to leave empty-handed. Intrusion is a key problem, but arming is a communication problem.

INFERRED 6. You keep logs only on the server itself · Likelihood medium Yesterday, 16 intents to erase traces and 1 to disable defenses were classified. Because we’re a honeypot, 80.5% of sessions (3,487) are recorded separately, so they survive deletion. On a real server, if logs aren’t shipped out, nothing remains after deletion. But yesterday’s main character’s sessions had neither indicator removal nor impairing of defenses. Those 16 and 1 belong to other sessions, so we set this to “medium.”

FACT The newly confirmed distribution host hxxp://160[.]119[.]66[.]206/ is subject to reporting to C-TAS (the Cyber Threat Analysis & Sharing system run by KISA, the Korea Internet & Security Agency). But what we can confirm is only that the transmission succeeded; whether it was actually ingested on their end has to 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.

What we cannot confirm about yesterday’s subject

• [Unconfirmable] Whether the distribution host 160[.]119[.]66[.]206 and the intrusion source 160.119.x.x are the same machine cannot be known. The last two octets are masked and are not subject to restoration. We say only “the first two octets match.” The same applies to the September 7 and 8 cases.
• [Unconfirmable] The download counts don’t reconcile. The two subject sessions’ downloads sum to 4, but kla.sh at 4 and net.x86_64 at 4 sum to 8. Whether the per-file count includes retries, or whether there were additional ATK-BDB53E sessions that didn’t make it into the record, cannot be distinguished.
• [Unconfirmable] Whether the two sessions came in with the same credentials cannot be known. Per-session credentials are not in the data.
• [Unconfirmable] Whether the 6-hour 59-minute 15-second gap between 12:07 and 19:07 is scheduled execution or coincidence cannot be known. With only two, we do not call it a period.
• [Unconfirmable] What kla.sh does, and what net.x86_64 is, cannot be known. Neither the script’s contents nor a sample-classification tag is in the data, and VirusTotal is not connected. Whether “only the x86-64 build was fetched” is the result of a choice by the script also cannot be confirmed.
• [Unconfirmable] The formula for the completeness score is not in the data. We cannot explain why ATK-E09588, with a single intent, scores 42, higher than the subject session (19) with three intents.
• [Unconfirmable] The reading that the 1 “impair defenses” belongs to the ATK-E09588 session is an inference based only on the counts matching. There is no field that links sessions to intent counts 1:1.

Where the data itself must be questioned

• [Unconfirmable] Which services the top 12 sources on the server next door knocked on is not in the data. With screen sharing at 93.5% it’s tempting to read it that way, but that isn’t evidence.
• [Unconfirmable] The data does not state that the 3 samples on the server next door arrived via ADB. We read it only from the figures of 26 ADB sessions · 3 samples and the structure that “ADB is the only channel on 02 that leaves files.”
• [Unconfirmable] The sum of screen-sharing version proposals (35,026) is 94 short of the session count (35,120), and the sum of remote-desktop labels (1,870) is 161 short of the session count (2,031). These look like sessions that never reached the negotiation stage, but the data does not explain it.
• [Unconfirmable] The 389-byte SSH public key (a8460f44…) was left by 14 sources, but aliases are listed for only 10, so we don’t know the other 4.
• [Unconfirmable] Whether a single source on the server next door swept multiple doors together cannot be computed. The sum of per-service unique sources (523) is smaller than the total (539), so the overlap can’t be back-calculated either. Writing 0 would be false, so we leave it as “not computable.”

What we deliberately did not connect

• [Excluded] The vulnerability indicators that came in as background statistics (7,628 tracked CVEs · 397 KEV · 100 confirmed ransomware-linked) are values drawn from KISA security notices. They are not linked to any session or sample observed yesterday, and yesterday’s intrusion was credential guessing that used no CVE.
• [Excluded] The 12 distribution URLs under 31[.]77[.]227[.]121/bins/ that surface only after unpacking are indicators repeated since August 16, not new ones from yesterday. There is no value connecting them to yesterday’s subject either.
• [Unconfirmable] The C-TAS report is confirmed only to the point that the transmission succeeded. Whether yesterday’s new distribution host was ingested at KISA has to be verified separately.

What we do not judge at all

• Carrier / organization (ASN · ISP) — We have no such database. We do not guess. This is also why we do not derive “same carrier” from the fact that the first two octets match.
• Geolocation — Same as above. IP geolocation was never a 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 connected. Sample classification uses MalwareBazaar tags, and yesterday’s two files have none.
• Client string (User-Agent) — Neither observation surface is web (HTTP). 01 is SSH · Telnet; 02 is SMB · RDP · VNC · MSSQL · LDAP · ADB.
• Vulnerability number (CVE) linkage — SSH and Telnet attacks mostly reference no specific vulnerability, and 02 is at the protocol-negotiation stage, so the same applies.

A kid whose name tag’s front half matched came three times in nine days. Three different name tags each time, and each time the items came from a locker tagged with the same class. And yesterday, once more in the evening, in a little over 7 seconds, exactly the same.

We write down only that the front halves matched three times. Whether it’s the same kid or a different kid in the same class, we do not peel back the tape over the name to check. Writing down that we don’t know what we don’t know is part of observation, too.

What we can do on our side, though, is clear. Change factory-default passwords, don’t expose management ports like Telnet directly to the internet, and block the path by which the server fetches files from outside. Where yesterday’s two 7-second sessions pointed was exactly there.

The observation date is September 15, 2026, and this post was compiled the following day. The source IP is carried over exactly as masked in the brief (160.119.x.x) and was not restored. Distribution addresses are kept defanged (hxxp://, [.]) in both the body and the IOC block so they can’t be connected to by accident. For credentials, only the 20 combinations observed repeatedly from 3 or more distinct IPs are quoted verbatim; for the remaining 962, we disclose only the count and not the values. Items for which we have no means of measurement — carrier, nationality, VPN status — were not guessed at and are left as “unknown.”