Same Building, Third Apartment — This Time the Boxes Wore Maintenance-Office Stickers

Picture one building in an apartment complex. On August 21, someone from one apartment in that building left three boxes at our front door. A few days later, a different apartment in the same building left boxes again. The labels were different every time.

Yesterday a third apartment in that building left boxes at our door. Seven of them this time. Five carry a sticker that reads “Maintenance Office Supplies.” Nobody opens maintenance-office property. One box is five times bigger than the other five combined. And that big box still has the factory serial-number sticker on it, never peeled off.

But there’s one strange thing. We replayed all five hallway CCTV feeds, and the person who carried the boxes in appears on none of them.

That is what our server recorded yesterday.

Our Server Is a House We Deliberately Leave Unlocked

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

FACT We assigned the alias ATK-5165FA to the party that brought the seven boxes yesterday. An alias is not an identity. It is merely a label for referring to the same masked source consistently from post to post. This alias is a new alias that appeared nowhere in our 27-day archive (August 16 – September 15). And in this post we cannot write this alias’s IP even in masked form. The reason is explained below in “The Carrier Was Never Filmed.”

Same Building, Third Apartment

FACT An internet address (IP) is four numbers separated by dots. The address the seven files came from yesterday is hxxp://176[.]65[.]139[.]206/. Writing the address in this odd way is not a typo. It is a convention of changing http to hxxp and dots to [.] so that nobody connects to it by accidental click. It is called defanging — pulling the teeth out.

FACT The first three fields of this address, 176.65.139, we saw twice in August. Addresses with the same first three fields and only the last field different are like different apartments in the same building. Please look at the last field and the labels in the table below.

FACT The first apartment first appeared in the August 21 post as “a place never seen in 5 days of records.” The second apartment appeared three days running from August 23. And 23 days after the second apartment was last seen on August 25, the third apartment appeared yesterday. Each time the apartment changed, the label convention changed too — all three times.

INFERRED That is as far as we can say. The last field differs, so they are not the same machine. Just as living in the same building does not make people the same family, we have no means of confirming whether the three apartments belong to the same person. The only fact is that the first three fields match.

Opening the Seven Boxes

FACT Here are the seven. Please look at row ⑦ in the size column.

FACT To unpack the terms: ELF is the name of the format program files use on Linux. ARM and MIPS are CPU types, the kind commonly found in small devices like routers and home cameras. The x86 family common in PCs and servers is absent from all seven. Statically linked means the program was built with every part it uses packed inside. It runs well on someone else’s machine because it never needs to borrow parts. “Stripped” means the internal markers the author left were removed before distribution, which makes the file harder to take apart. Big-endian in ④ refers to a CPU type that reads numbers in the reverse order.

FACT The five files ①–⑤ average 297,882 bytes. That is roughly a tenth of a smartphone photo. But ⑦ is 7,405,752 bytes — the size of two or three smartphone photos. It is 24.9 times the average of the five, and even all five together (1,489,408 bytes) come to less than a fifth of ⑦ alone. Of the 13 files stored on this server yesterday, it is by far the largest. The daredevil.armv5l that arrived under the same naming convention on August 24 was 50,096 bytes, so next to that it is 148 times larger.

FACT There is one more thing about ⑦. Its BuildID is retained. A BuildID is a value stamped automatically when a program is built, like a serial number. The other five had their name tags erased, but this one big file came with its serial-number sticker still attached. We do not reproduce the value itself, because its notation may be truncated in our material.

FACT All seven were stored exactly once each, totaling 8,896,397 bytes. And the hashes of all seven are absent from the 27-day archive. A hash is a fingerprint computed from the entire contents of a file, so even a one-character difference changes the value. In other words, all seven are contents we have never seen before.

The Maintenance-Office Sticker

FACT Look at the five names again. kworkerd, irq, softirq, blkcg, netns. There are small programs Linux runs on its own the whole time it is powered on. Open the list of running programs and you will always see names like kworker, ksoftirqd, irq/…, blkcg, netns. They are called kernel threads. In apartment terms, they are the maintenance-office staff. They are always in the hallway, so nobody asks “who are you?”

INFERRED The names of yesterday’s five files are strings resembling those maintenance-staff names. It reads as a naming choice meant to avoid notice from an eye scanning the program list. But we stop here. What name the file actually shows in the list when it runs, we cannot confirm, because the file contents are not in our material. That the sticker is attached is the fact; whether the sticker fooled anyone, we do not know.

FACT One more thing stands out. The first apartment (px86, pmips) and the second (daredevil.armv5l, daredevil.mips…) wrote the CPU type plainly on the label. Yesterday’s five erased it. They put a maintenance-office name in its place.

INFERRED ⑥ w.sh uses CRLF line endings. CRLF is the default line ending in Windows editors, so this script may have been written on Windows. But it can be produced on Linux too, so we do not assert it. Whether this script is the instruction sheet (loader) that downloads the other six, we also cannot know, since the contents are absent. That said, the shape of seven files coming once each from one alias and one distribution point is consistent with their being pulled down together in a single procedure.

The Carrier Was Never Filmed

FACT Our material separately lists the five sessions with the densest records of the day. Think of them as five hallway CCTV feeds. The aliases caught on those five feeds yesterday were ATK-A593DF, ATK-BDB53E (twice), ATK-73181C, and ATK-CA5936. ATK-5165FA is not among them. This alias has its name only in the “where the files were delivered from” column.

FACT So there is much we do not know about this intrusion. What time it came, whether it was telnet or SSH, how many commands it typed, whether the screen was recorded, what its masked IP is. None of it is in the JSON. The only fact is that seven boxes were left; the person who left them appears on no feed.

INFERRED If the five feeds are “the top 5 by record density,” then this intrusion’s record was less dense than the fifth (completeness 14). But the selection criterion is not written in the JSON, so this too is inference. That is why today’s post is not “following one intrusion” but “following seven boxes from one apartment.”

Laid out in time order, it looks like this. Please note that the subject row has no timestamp, and that the two rows at 12:06 are 2 seconds apart.

1. 00:56:14Z (09:56 KST)
   FACT ATK-A593DF(61.245.x.x) telnet login success. 22.7 s until 00:56:36Z · 8 commands · 1 download. Intent: grant execute permission · file download. File taken: 9-byte ASCII text (0dc95fb4… · observed 2×). Neither alias nor hash is in the archive. Screen recorded (contents not in material). Completeness 14
2. 03:06:34Z (12:06 KST)
   FACT ATK-BDB53E(160.119.x.x) telnet login success. 6.98 s until 03:06:41Z · 7 commands · 2 downloads. Intent: download-then-execute · grant execute permission · file download. Completeness 19. Command count · download count · intent · completeness all identical to the 9/15 subject session
3. 03:06:36Z (12:06 KST)
   FACT Second session from the same alias ATK-BDB53E. Started 2.33 s after the first and ran overlapping before the first ended. 4.75 s · 2 commands · 2 downloads · same 3 intents · completeness 16. On 9/15 the two sessions were 6 h 59 min apart; today they run in parallel 2 s apart
4. (ATK-BDB53E samples)
   FACT 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 observed 2× today. sha256 identical to 9/15 — not rebuilt in the two days between
5. 04:39:30Z (13:39 KST)
   FACT ATK-73181C(124.158.x.x) telnet login success. 65.4 s until 04:40:35Z · 17 commands — the longest and most command-heavy of today's recorded sessions. 5 intents: recon—system · file download · grant execute permission · download-then-execute · persistence—SSH key planting. Yet download count is 0. Completeness 17. Alias not in the archive
6. (ATK-73181C inference)
   INFERRED 'File download' and 'SSH key planting' intents are tagged, but 0 files stored. Either the download failed, or the key was planted as a string inside a command rather than as a file. Raw commands are not in the material, so we cannot confirm which. Same shape as 8/18 (63 s · key planting · 0 stored files)
7. 14:19:42Z (23:19 KST)
   FACT ATK-CA5936(130.12.x.x) SSH login success. 3.72 s · 1 command · 2 downloads · 5 intents. Fingerprint 16443846… / SSH-2.0-Go. Files are a 399-byte OpenSSH private key (43728fbf…) and 54-byte ASCII (00b6f15c…), same hashes since 8/19. Not today's subject
8. (time unknown)
   FACT Today's subject. 7 samples with ATK-5165FA as the sole source came from hxxp://176[.]65[.]139[.]206/. This alias appears in none of the 5 recorded sessions, so time · protocol · command count · masked IP are unknown
9. (subject samples — list)
   FACT ① kworkerd-irq-bal 274,516 bytes ELF 32-bit LSB ARM(0603941e…) ② kworkerd-blkcg 265,836 bytes ARM EABI4(c45ff1d6…) ③ kworkerd-irq 275,476 bytes ARM(89ec6a69…) ④ kworkerd-netns-rt 386,320 bytes ELF 32-bit MSB MIPS32 rel2(951258ff…) ⑤ kworkerd-softirq 287,260 bytes ARM EABI4(93d12190…) ⑥ w.sh 1,237 bytes ASCII · CRLF line endings(a05b90af…) ⑦ armv5l 7,405,752 bytes ARM EABI5 · BuildID retained(2dbdb379…). All 7 observed 1×, total 8,896,397 bytes. None of the 7 sha256 values is in the 27-day archive (8/16–9/15)
10. (subject samples — form)
    FACT ①–⑤ are all statically linked · stripped. 4 ARM + 1 MIPS (big-endian), no x86 family. Only ⑦ armv5l lacks the stripped marking and retains BuildID[sha1]. ⑦ is 24.9× the ①–⑤ average (297,882 bytes), by far the largest of the 13 samples stored on 01 today. 148× the 8/24 daredevil.armv5l (50,096 bytes)
11. (subject samples — names)
    INFERRED kworkerd · softirq · irq · blkcg · netns are strings resembling the worker-thread and subsystem names the Linux kernel spawns itself (kworker, ksoftirqd, irq/…, blkcg, netns). Reads as a naming choice meant to look like kernel threads in the process list, but how the process name actually displays at runtime cannot be confirmed since sample contents are absent. 8/21 · 8/23–25 exposed the CPU type in the name; today's five erased the CPU type from the name
12. (subject samples — w.sh)
    INFERRED w.sh is 'ASCII text with CRLF line terminators'. CRLF is the default line ending in Windows editors, so the authoring environment may have been Windows, but it can be produced on Linux too, so we do not assert it. Whether this script is the loader that downloads the other six cannot be known without contents. That said, 7 samples arriving once each from one alias · one distribution point is consistent with a single bundled procedure
13. (archive cross-check)
    FACT 176[.]65[.]139[.]196 first appeared on 8/21, distributing /bins/kla · px86 · pmips (x86 included). 176[.]65[.]139[.]202 distributed telnet.sh + daredevil.{armv5l, armv6l, armv7l, mips, mipsel} three days running 8/23–8/25, with 0 x86. Today's .206 distributed 5 kworkerd-* + w.sh + armv5l, again 0 x86. Three addresses sharing the first three octets have appeared in turn with three naming conventions. Last octet differs, so not the same machine; no means to confirm the same operator
14. (blocklist view)
    INFERRED The 8/24 post wrote 'the list built from names · URLs held, the hash list missed within a day.' Today is the reverse — the 8/21 · 8/24 URL · filename lists catch none of today's 7, and the hash list misses too. What remains is only the first three octets 176.65.139
15. (daily totals · 01)
    FACT 791 sessions · 196 unique sources · 403 login attempts · 1,081 commands · 285 screen recordings. Third-lowest of 28 archive days, after 8/29 634 · 8/31 779. Telnet 421 (2223) > SSH 369 (2222), telnet share 53.2% — the exact reverse of 8/16 (SSH 88%)
16. (daily totals · 01)
    FACT Intent: grant execute permission 131 · recon—system 82 · file download 34 · download-then-execute 29 · persistence—SSH key planting 17 · trace removal 15. Total 308, 28.5% of all commands. Second day after 9/4 where #1 is 'grant execute permission' rather than recon. On 9/15 recon was 91.7% of intents
17. (daily totals · 01)
    FACT 389-byte OpenSSH RSA public key (a8460f44…) left by 14 distinct sources (aliases listed only up to 10). Same hash on every archive day since first observed 8/16. Roughly matches today's 17 'SSH key planting'
18. (daily totals · 01)
    FACT 44 SSH fingerprint clusters (same as 9/15). Most frequent fingerprint f555226d…(libssh_0.9.6) is 14 sources today · 205 tallied, yet delivered no files at all. The only fingerprint that delivered a sample is 16443846…(SSH-2.0-Go · 3 sources today · 21 tallied), belonging to ATK-CA5936. The subject alias's protocol is unknown, so it cannot be mapped to any cluster. Scanner banners 4e066189…(Fingerprintx-SSH2 · 3 sources) · dd9bcf09…(ZGrab SSH Survey · 2 sources) are also on the list
19. (daily totals · 02)
    FACT 24,064 sessions · 513 unique sources. VNC 20,953 (258 sources · 87.1%) · RDP 2,210 (118 sources · 9.2%) · SMB 387 (92 sources) · LDAP 157 (12 sources) · MSSQL 58 (13 sources). ADB 299 sessions · 4 samples
20. (daily totals · 02)
    FACT VNC 20,953 is lower than any value in 17 days of 02 archive (8/26–9/15 · low 8/27 29,111 · high 9/10 65,487). 258 sources is similar to 9/6 (264), so the shape is fewer per source at 81.2. Offered VNC versions 003.003 17,315 · 003.008 3,562 (82.6% : 17.0%), total 20,877, 76 fewer than the session count
21. (daily totals · 02)
    INFERRED ADB 299 sessions is 5.7× the archive maximum of 52 (8/30 25 · 8/31 52 · 9/1 22 · 9/3 32 · 9/4 25 · 9/6 47 · 9/15 26). Yet the 4 samples (0d3c687f… 46,525 · 76ae6d57… 239,388 · a1b6223a… 334,816 · d7188b8c… 153,208 bytes) are all hashes present on 8/28 · 8/30 · 9/7; only the source ATK-C93E77 is a new alias. Contact rose while the payloads stayed old. Reading 02 samples as ADB is because ADB is the only channel on 02 that leaves files; the data does not state it
22. (daily totals · 02)
    FACT #1 and #2 ATK-A9F1B3(68.183.x.x) · ATK-943F0E(129.212.x.x) at 5,675 each, exactly identical. Together 11,350 = 47.2% of all 02, top 4 (+ATK-0E3BBB 1,323 · ATK-AE264D 671) 55.5%. These two were also side by side at the top on 9/10 · 9/13 · 9/15, and close at 5,736 · 5,723 on 9/15. Which service they knocked on is not in the data
23. (daily totals · 02)
    FACT RDP cookies: hello 1,514 (68.5%) · <ip> 469 · nmap 6 · rdpaudit 6 · (blank) 2 · Domain 1. 'mstsc', in the 30,000s on 9/10 · 9/13, is absent today. 'nmap' · 'rdpaudit' match scanner tool names but are values the other side writes itself, so forgeable. Of 491 SMB dialect offers, excluding 28 'SMB 2.???', 463 (94.3%) are SMB1 generation (NT LM 0.12 121 · LANMAN1.0 86 · LM1.2X002 86 · LANMAN 46 · PC NETWORK PROGRAM 1.0 44 · Windows for Workgroups 3.1 40 · LANMAN2.1 40)
24. (background)
    FACT The 12 distribution URLs under hxxp://31[.]77[.]227[.]121/bins/ that only appear after UPX unpacking have repeated since 8/16 and are not today's new indicators. Plaintext indicators: 1 discord webhook URL (kept defanged). Vulnerability background stats (CVE 7,628 · KEV 397 · ransomware confirmed 100) are based on KISA notices and are not directly tied to today's observations

FACT Only the subject row has an empty timestamp. The other five feeds have times down to the second, but the row for the seven boxes alone reads “time unknown.” And the two rows at 12:06, unlike two days ago when the same alias came twice 7 hours apart, ran overlapping, 2.33 seconds apart.

Lists Can’t Catch It — What Remains Is the First Three Fields

FACT In the August 24 post we wrote this: the blocklist built from filenames and addresses held, and the one built from hashes missed within a day. That was because boxes with the same labels came from the same apartment, and only the contents changed.

INFERRED Yesterday is the reverse. The address and filename lists from August 21 and 24 catch none of yesterday’s seven. The apartment changed, and so did the labels. The hash list naturally misses too — all seven are contents never seen before. Of the values on those lists, exactly one survived until yesterday: the first three fields, 176.65.139. Memorize the apartment number and you miss when they move; memorize the building name and you also catch the other apartments in that building. Which is the right choice differs from server to server, and this post does not decide it for you.

The Others Caught on the Hallway Feeds That Day

FACT We note the ones caught on the five feeds as well. ATK-BDB53E at 12:06 p.m. is the protagonist of the post from two days ago. The hashes of its two files (kla.sh 3,241 bytes · net.x86_64 190,632 bytes) are identical to two days ago. That means they were not rebuilt in the two days between. 7 commands · 2 files · 3 intents · completeness 19 also unchanged. One thing differed: the second session started 2.33 seconds later, overlapping. Two days ago it was 6 hours 59 minutes later.

FACT ATK-73181C at 1:39 p.m. is the intrusion that stayed longest (65.4 seconds) and typed the most commands (17) of yesterday’s five feeds. It also has the most intents, at five: recon, file download, grant execute permission, download-then-execute, and SSH key planting. Yet 0 files were stored.

INFERRED It may have tried to fetch a file and failed, or it may have planted the key as text inside a command sentence rather than as a file. An SSH public key is, simply put, a spare key that lets you in without a password, and it can be set with a single command line without downloading any file. The raw commands are not in the material, so we do not know which. It has the same shape as the “63 seconds · key planting · 0 stored files” in the August 18 post, so today we leave it as a side note.

FACT ATK-A593DF at 9:56 a.m. typed 8 commands over 22.7 seconds and took away one 9-byte text file. Nine characters’ worth. Both the alias and the hash are new, but the contents are not in the material. ATK-CA5936 at 11:19 p.m. is an alias recurring since August 19, and its two files have carried the same hashes since then.

What Came Out of Yesterday’s Boxes — Values to Write Down

FACT We reproduce the values as-is so you can use them for defense. Click a value to copy it. Addresses have been altered so they cannot be connected to; leave them that way when you use them. The top fourteen rows are values that first appeared yesterday, below them are values from two days ago, and at the bottom is background unchanged for weeks.

FACT What to watch in the top fourteen rows is the path in the addresses. The first apartment, the second apartment, and 160[.]119[.]66[.]206 from two days ago all handed out files under a /bins/ folder. Yesterday’s third apartment handed them out at the top level, with no folder. A rule built on the folder name also misses yesterday.

We Deliberately Withheld 196 of Them

FACT Yesterday there were 403 login attempts, from 196 different sources. Dividing the day into seconds, that is once every 3 minutes 34 seconds. An average of 2.1 per source. Compared with two days ago (3,620, once every 24 seconds), it is one-ninth.

FACT Of the username/password combinations attempted, we reproduce only 10 in this post. For the remaining 196, we count them but do not write the values. Our rule is to quote verbatim only combinations repeated from three or more distinct IPs. A combination seen from only one or two places could be someone’s real account leaked from somewhere. It is the same as not writing down a neighbor’s door code you happened to glimpse.

The 10 below are the opposite. Repeated from many places, they can be regarded as “factory defaults that belong to nobody.”

FACT admin/admin came 31 times from 14 sources. That is 2.2 per source. root/root came 15 times from 7 sources, root with the password field entirely blank 23 times from 5 sources, and root/xc3511 15 times from 3 sources. Each source tried the same combination about five times.

INFERRED This list was not built to target us. It is a dictionary of values that work anywhere, tried in order. And we do not know which combination the intrusion that left the seven boxes yesterday used to get in. That intrusion was never on the feeds to begin with.

The Whole of Yesterday

FACT Daily totals from the side where the door actually opens (sensor 01). Please read the right-hand column too — a single number gives no sense of scale.

FACT It was a quiet day. Yet on a quiet day, seven never-before-seen files arrived. A noisy day and a dangerous day are not the same thing. And yesterday telnet outnumbered SSH. Telnet is a very old remote-access method in which the characters exchanged travel unencrypted, in the clear. On August 16 SSH was 88%; yesterday telnet passed half.

FACT Counting what happened inside the server yesterday by type:

FACT “Grant execute permission” is the act of attaching a marker to a file that says “this file is okay to run.” On Linux, without this marker a file simply will not run even if it is a program. Yesterday this was #1. Commands with an intent attached number 308, 28.5% of the total; the remaining 71.5% are unclassified commands.

FACT Those coming in over SSH leave a fingerprint (hassh) of their client program. Yesterday’s most frequent fingerprint f555226d… (libssh_0.9.6 · 14 sources today · 205 tallied) left no files at all. The only fingerprint that left files is 16443846… (SSH-2.0-Go · 3 sources today), and that belongs to ATK-CA5936. Yesterday’s protagonist, whose protocol itself is unknown, cannot be placed anywhere on this list. A fingerprint is the fingerprint of a client program, not of a person.

The Server Next Door — The Side That Doesn’t Let Anyone In

FACT We keep two servers. The second (sensor 02) is a shallow trap that never lets anyone inside, so it only records “which door, how many sources, how many knocks.” Think of it as a building with a security booth but no apartments. Login successes, commands, credentials — none of those exist here. Collection was normal yesterday.

FACT The six rows add up to 24,064, matching the session total exactly. Screen sharing at 20,953 is about once every 4 seconds, and this value is lower than any day in 17 days of 02 archive (low 8/27 29,111 · high 9/10 65,487). The 258 sources are similar to September 6 (264). The sources are the same, but the knocks per source dropped to 81.2.

FACT What rose instead is ADB. ADB is the debugging channel used to control Android devices from a computer. Yesterday it was 299, whereas the largest value recorded in the archive is 52 on August 31. That is 5.7 times. Yet the 4 files left on the server next door are all hashes already present on August 28, 30, and September 7; only the source ATK-C93E77 is a new alias. The knocking rose, but what was left behind is the same old stuff.

INFERRED Reading these 4 as having come in through ADB is due to the structure — ADB is the only channel on the server next door that leaves files. The data does not say so itself.

FACT #1 and #2 on the server next door, ATK-A9F1B3 (68.183.x.x) and ATK-943F0E (129.212.x.x), are exactly identical at 5,675 each. Together 11,350, 47.2% of the total. These two were also side by side at the top on September 10, 13, and 15, and two days ago they were close at 5,736 and 5,723. Which door they knocked on is not in the data.

FACT Remote-desktop name tags are hello 1,514 (68.5%) · <ip> 469 · nmap 6 · rdpaudit 6 · blank 2 · Domain 1. mstsc, which registered in the 30,000s on September 10 and 13, is absent from yesterday’s list. nmap and rdpaudit match scanner tool names, but they are values the other side writes itself, so they can be faked freely. On the file-sharing side, of 491 offers, excluding 28 SMB 2.???, 463 (94.3%) are SMB1-generation dialects. Offers outnumber the 387 sessions because one negotiation lists several dialects in a row.

Mapping the Attackers’ Techniques to the International Catalog

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

• T1110.001Brute Force: Password Guessing — 403 login attempts, 10 quotable combinations repeated from 3–14 IPsINFERRED
• T1078.001Valid Accounts: Default Accounts — login success with default combinations such as admin/admin · root/root · root/(blank) · root/xc3511INFERRED
• T1021Remote Services (telnet 2223 · SSH 2222) — all 5 recorded sessions logged in successfullyINFERRED
• T1082System Information Discovery — 'recon — system' 82×INFERRED
• T1105Ingress Tool Transfer — 'file download' 34×, distribution points 176[.]65[.]139[.]206 7 samples · 160[.]119[.]66[.]206 2 samplesINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'grant execute permission' 131× (today's #1 intent)INFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — 'download-then-execute' 29×, shell scripts kla.sh · w.shINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — SSH key planting' 17×, public key a8460f44… from 14 sourcesINFERRED
• T1070Indicator Removal — 'trace removal' 15× (no sub-classification of file deletion vs. history deletion)INFERRED
• T1036.005Masquerading: Match Legitimate Name or Location — kernel-thread-style filenames kworkerd-irq · softirq · blkcg · netns. Process-name masquerading at runtime unconfirmedINFERRED
• T1027.002Obfuscated Files or Information: Software Packing — 12 indicators that appear only in UPX-packed samples (background, not new today)INFERRED

FACT Please note that all eleven rows carry the [INFERRED] badge. What we have in hand is the “intent classification result” and “how many times” for commands, and the names and sizes of files. We have neither the raw commands nor the file contents. Fitting things to a catalog is always interpretation, and interpretation is labeled as interpretation. Especially the tenth row, T1036.005 — the maintenance-office sticker — is assigned on the filename alone. Whether it actually appeared under that name when run, we do not know.

There Has Been a Shape Like This Before

INFERRED The Mirai botnet (2016). Its structure was to enter Linux devices with a dictionary of default telnet credentials, then download and run statically linked ELF binaries prebuilt for each CPU type, ARM, MIPS, and so on. The root/xc3511, root/root, and admin/admin in yesterday’s table are values found in the credential list of the Mirai source code published in 2016. And the delivery form — “telnet login → shell script → statically linked ELF per CPU type” — is the same. (Source type: analysis of published source code · US-CERT alert TA16-288A)

FACT We stop here. Since no sample-classification service (VirusTotal) is integrated, we make no determination that yesterday’s seven belong to this family. The resemblance extends to the credential values and the shape of the files, no further.

So What Should You Do

We cannot decide what labels the third apartment in the same building will put on the boxes it sends. What we can change is how our own front door is locked, and how the path from our house to the outside is laid out.

FACT 1. You are still using default accounts and easy passwords · Likelihood high All ten rows in the table above are values that devices or distributions ship with. admin/admin 14 sources 31 times, root/root 7 sources 15 times, root/(blank) 5 sources 23 times, root/xc3511 3 sources 15 times. All five sessions recorded yesterday succeeded at login, and after succeeding they reached execute-permission grants, downloads, and key planting within 4 to 65 seconds. On a real server, those few seconds are the moment of compromise.

FACT 2. You allow password login and don’t use key-based authentication · Likelihood high Of yesterday’s 403 login attempts, 369 sessions were SSH. ATK-CA5936 succeeded at SSH password login and completed five intents with 1 command in 3.72 seconds. Had only key-based authentication been allowed, the password-guessing part ends at the authentication stage. And once an intruder succeeds, the first thing they do is set their own key. Yesterday: 17 key plantings, a 389-byte public key from 14 sources. Once a line is written to the server’s authorized_keys (the list of permitted keys) file, that key keeps getting in even if you change the password later.

FACT 3. You leave management ports open to the internet as-is · Likelihood high We have never announced our server’s address anywhere. Yet yesterday 196 sources came to the side where the door opens, and 513 to the server next door. Combined, an upper bound of 709 sources. This is not the trace of a chosen target but the shape of searching for open doors. If any one of telnet, SSH, VNC, RDP, or SMB is open, it becomes an entry point.

INFERRED 4. You have no count-based blocking (fail2ban, etc.) · Likelihood medium Yesterday, attempts per source were around 5. admin/admin 2.2 per source, root/xc3511 5.0, root/(blank) 4.6. A “lock after 5 failures” rule either never triggers or is already too late. Moreover, ATK-BDB53E ran two overlapping sessions 2.33 seconds apart. Even with a lockout rule, yesterday’s kind of distributed, low-frequency attempts pass beneath that threshold. That is why we do not rate it “high.”

FACT 5. You don’t block outbound connections · Likelihood high Of the 13 files stored yesterday, the 9 with an address were fetched over HTTP by the server reaching outward from two distribution points (7 from the 176 side, 8,896,397 bytes · 2 from the 160 side, 193,873 bytes). Had the outbound path been blocked, these 9 would not have arrived at the server. All 34 “file download” attempts stop at the same spot. If the road from our house to that building is closed, no boxes get left at our door. And what arrived yesterday is for ARM and MIPS. Devices on the same network, rather than the server itself, may be the actual target.

INFERRED 6. You keep logs only on the server · Likelihood medium Yesterday, intent to erase traces was classified 15 times. And the names of five files resemble maintenance-staff names, so it reads as designed to slip past anyone scanning the program list by eye alone. Because we are a honeypot, we separately record 285 sessions, so they survive even if erased. On a real server, unless logs are shipped out, nothing survives once erased. But since the data does not say which sessions those 15 belong to, we leave it at “medium.”

FACT The distribution point hxxp://176[.]65[.]139[.]206, first confirmed yesterday, and the hashes of the seven files are subject to reporting to C-TAS (the Korea Internet & Security Agency’s Cyber Threat Analysis & Sharing system). .196 (8/21) and .202 (8/23–25) from the same building were also reportable at the time, so on the national threat-intelligence side this building is being reported three times within a month. But what we can confirm is only that the transmission succeeded; whether it was actually ingested on the other end must be checked 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 so. The protagonist was not on the feeds.

Things we cannot confirm about yesterday’s subject

• [Unconfirmable] The subject alias ATK-5165FA exists only in the “where the files were delivered from” column and not in the five recorded sessions. Session time · duration · protocol (SSH/telnet) · port · command count · intents · whether the screen was recorded · masked IP — none can be confirmed from the JSON. This is why this post has no port for this alias.
• [Unconfirmable] If the five recorded sessions are “the top 5 by completeness,” that would mean this intrusion’s completeness is below 14, but the selection criterion is not written in the JSON, so this is inference.
• [Unconfirmable] We cannot know whether the seven came down in one session or across several. Each “observed 1×” means only that it was stored once.
• [Unconfirmable] Whether the 7,405,752-byte armv5l was actually executed, and what language or runtime it was built with beyond being a large statically linked executable, we cannot know. We do not quote the BuildID value itself, since the JSON notation may be truncated.
• [Unconfirmable] The contents of w.sh, i.e., whether it is the loader that downloads the other six, cannot be confirmed. Nor do we assert that CRLF line endings mean a Windows authoring environment.
• [Unconfirmable] Whether 176[.]65[.]139[.]196 · .202 · .206 are the same operator, we have no means to confirm. The only fact is that the first three fields match.
• [Unconfirmable] That both of yesterday’s distribution points end in 206 (160[.]119[.]66[.]206 · 176[.]65[.]139[.]206) may be coincidence, and we do not use it as the basis for any inference.
• [Unconfirmable] The relation between ATK-73181C’s “SSH key planting” intent and its 0 stored files — whether the key was planted as a command string rather than a file, or the download failed — cannot be known without the raw commands. The delivering aliases for the 389-byte public key are listed for only 10 of 14 sources, so we also cannot know whether ATK-73181C is among them.

Things where the data itself must be questioned

• [Unconfirmable] Why #1 and #2 on the server next door are identical at exactly 5,675 (parallel runs of the same tool, or coincidence) and which services they knocked on are not in the JSON.
• [Unconfirmable] Reading the 4 files on the server next door as having come via ADB is a structural inference. The number of sources for the 299 ADB sessions is also not in the JSON.
• [Unconfirmable] The cause of the 76-count gap between the screen-sharing version-offer total (20,877) and sessions (20,953) is unknown.
• [Unconfirmable] On the side where the door opens, the per-port sum (421 + 369 = 790) differs from the session total of 791 by 1. The cause is not in the data.
• [Unconfirmable] We cannot compute whether one source on the server next door swept multiple doors together. The sum of per-service unique sources (493) is smaller than the overall total (513), so the overlap cannot be back-calculated either. Writing 0 would be false, so we leave it as “not computable.”
• [Coincidence] That the 196 withheld credentials and the 196 unique sources are the same number is a coincidence of values in different units, and we attach no meaning to it.
• [Caution] The “tallied” values in the fingerprint list, as the September 5 post pointed out, do not increase monotonically, so we do not read them as “cumulative” (f555226d… 9/15 175 → yesterday 205).
• [Caution] Since 9/9 · 9/11 · 9/12 · 9/14 · 9/16 are missing from the archive, expressions of “consecutive” are restricted to “on every day present in the archive.”

Things we deliberately did not connect

• [Excluded] The vulnerability indicators that arrived as background statistics (7,628 tracked CVEs · 397 KEV · 100 confirmed ransomware-linked) are values pulled from KISA security notices. They are not connected to any session or sample observed yesterday.
• [Excluded] The 12 entries under the distribution point 31[.]77[.]227[.]121/bins/, which appear only after unpacking, have been repeating indicators since August 16 and are not new to 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 distribution point was ingested at KISA must be checked separately.

Things we do not judge at all

• Carrier / organization (ASN · ISP) — We have no relevant database. We do not infer it. This is also why we do not draw “same carrier” from the fact that the first three fields match.
• 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 determination.
• Sample classification (VirusTotal) — Not integrated. Sample classification uses MalwareBazaar tags, and yesterday’s seven have no tags.
• Client 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 and telnet attacks mostly reference no specific vulnerability, and 02 is likewise at the dialect-negotiation stage.

A third apartment in the same building left boxes. The labels were different all three times, and this time a maintenance-office sticker was attached too. One box was unusually large and came with its serial number never peeled off. And the person who carried them was on no feed.

We write down only that the first three fields match. Whether the three apartments belong to one person, whether the sticker actually fooled anyone, what time the person absent from the feeds arrived — what we do not know, we leave as unknown. Writing down that we don’t know is also part of observing.

What can be done on our side, by contrast, is clear. Change factory default passwords, don’t expose management ports like telnet to the internet as-is, block the path by which the server fetches files from outside, and keep records outside the server. Where yesterday’s seven boxes pointed was exactly there.

The observation date is September 17, 2026, and this post was compiled the following day. Source IPs are reproduced exactly as masked in the brief (160.119.x.x, 124.158.x.x, etc.) and were not restored. The subject alias ATK-5165FA is not written with an IP because even the masked IP is absent from the brief. Distribution-point 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 for only the 10 combinations observed repeatedly from 3 or more distinct IPs; for the remaining 196 we disclosed only the count and not the values. Items we have no means of measuring — carrier, nationality, VPN status — were not inferred and were left as “unknown.”