Six Cables, and the Pouch Was Exactly as It Was a Month Ago

Say you’re visiting a friend’s place and your phone is down to 5% battery. You need to borrow a charger. But will your friend’s charging port be the same as yours? It could be USB-C, it could be an 8-pin, it could be an old 5-pin.

That’s why some people carry a cable pouch in their bag. One small pouch holding cables with every different connector shape. You don’t need to know what the other machine is. Try them one by one and one of them will fit.

Yesterday someone brought a pouch like that to our server. Inside were six cables. But this was a pouch we had seen once before, a month ago. The pouch itself was identical to back then, but all six cables were new.

Today we talk about that pouch.

First, our server is a house we left open on purpose

FACT We operate a honeypot. A honeypot is a decoy server left deliberately insecure so we can watch who comes in and what they do. So the story below is not actual damage — it’s an observation record. There are two servers. The first (sensor 01) is the one whose doors actually open. The second (sensor 02) is a shallow server that only records who knocked.

FACT Yesterday’s main character is ATK-DD0862. The source IP is written masked as 87.58.x.x. The alias is one that appears in our records for the first time. This visitor came in over Telnet. Telnet is an old remote access method that sends text commands to a distant machine. What passes back and forth is not encrypted. Today it mostly survives on small devices like routers and cameras. The port was 2223, and the login succeeded.

19.30 seconds, the time it took to open the pouch

FACT From login to leaving took 19.30 seconds. In that time they typed 11 commands. That’s one command every 1.75 seconds. Hard for a person to type by hand. In the same span they downloaded 8 files. One every 2.4 seconds. Our classifier attached three names to this session’s behavior: file download → granting execute permission → execute after download, in that order.

FACT The first of the 8 is a shell script named kla.sh. A shell script is several lines of commands gathered into one file. Run it, and the commands inside run in order. It is 3,013 bytes. In English, about a page’s worth of characters.

INFERRED In attacks like this, the script at the front usually plays the role of the pouch. It’s the pouch that fetches the executables that follow and has them tried one after another. That said, what was written inside kla.sh is not in our source material. This is an interpretation based on similar structures.

FACT Six of the rest are executables — the cables. They are programs in the ELF format used on Linux. All six together come to 1,092,512 bytes, a little over a megabyte. Smaller than one smartphone photo.

Why six cables at once

FACT The CPU, a computer’s brain, comes in many types. Just as charging connectors differ in shape, if the CPU type differs the program has to be built separately to match, or it won’t run. The six that came down yesterday were each for a different CPU type. Look at the middle column of the table.

FACT x86, MIPS, ARM. Three families packed at once. MIPS comes in two copies. Endianness is the difference between a CPU reading numbers front-to-back or back-to-front. Even for the same MIPS, a different direction needs a different cable.

FACT Static linking in the right-hand column means every needed part is packed inside the file. One cable and you’re done — no adapter required. Five of the six are like this. Only parm5 is dynamically linked. It needs a part called /lib/ld-uClibc.so.0 to already be present on the target device in order to run. It’s a cable that only fits once you attach an adapter. All six also have their internal descriptive notes removed (stripped).

INFERRED The visitor probably didn’t know what CPU our server had. That’s why they brought all six cables. And this lineup fits small devices like routers and CCTV better than ordinary servers. It matches a setup aimed at pulling such devices into a botnet. A botnet is a herd of machines being remotely controlled without their owners’ knowledge. The five statically linked ones will run on any Linux as long as the CPU matches.

The pouch unchanged, only the cables new

FACT This is where today’s core begins. All these files were fetched from hxxp://176[.]65[.]139[.]196/bins/. This address appears in our records exactly once, on August 21. That day’s post was titled “Three files from an address we’d never seen.” By the archive, it reappeared after 32 days.

FACT Every file has a value called a hash. It’s a unique number computed over the file’s entire contents. Change one character and you get a completely different value. Think of it as the serial number stamped on each cable. We lined up a month ago’s serial numbers next to yesterday’s. Look at the far-right column.

FACT The pouch kla.sh did not change by a single bit over 32 days. Conversely, the serial numbers of all six cables are values we’ve never seen. We searched all 29 days of the archive (8/16–9/20) and they aren’t there. Even px86, which kept its name, changed in size by about 0.1%, and its serial number changed completely. The pouch that held two cables on August 21 held six yesterday.

INFERRED It looks like the pouch is left in place at the same spot while only the cables are newly built and uploaded. This is the third time this pattern has shown up in our records. It also appeared on August 24 (the 31[.]77 family) and September 20 (net.x86_64 from 160[.]119[.]66[.]206).

INFERRED Why does this matter? Suppose you locked up using August 21’s serial number list. Not one of the six cables that came in yesterday would be caught. Only the pouch would. Now what if the rule were “we don’t accept goods from this shop”? All seven files with a recorded address would be caught. Serial numbers all change within a month. The address of the shop the pouch comes from stayed the same.

The name tags were something we already knew

FACT There’s one more interesting point. We have previously unpacked malware that was compressed with UPX. UPX is a tool that wraps an executable tightly to shrink its bulk. While wrapped, not a single address is visible from the outside. It’s like a box where you have to tear the wrapping to see the spec name tags on the cables inside. There are 12 names we obtained only by tearing that open. All of them are files under 31[.]77[.]227[.]121/bins/.

parm · parm5 · parm6 · parm64 · parm7 · pm68k · pmips · pmpsl · pppc · psh4 · pspc · x86_64

FACT Five of yesterday’s six cables match this list character for character: parm · parm5 · parm6 · pmips · pmpsl. The one that doesn’t overlap is px86. The list has x86_64. On August 21, only one name overlapped — pmips.

INFERRED If our records had been gathered only from the outside, yesterday’s six would have remained just “six files we’ve never seen.” We could recognize them because we had torn open the box and learned the naming convention in advance. Even though the shop address is different, we saw at a glance that it was the same family’s way of assigning names.

FACT Let us draw two lines. First, yesterday’s seven addresses were visible as-is in the session. They were not obtained by tearing open a box. What the unpacking experience gave us was not addresses but the naming convention. Second, the same naming convention only means the same family of publicly available build tooling was used. It does not mean the same person or the same organization. Using the same brand of cable doesn’t make you the same person.

Laid out in chronological order

Here is what happened on the first server yesterday, in chronological order. Pay attention to the two lines at 17:02 and the sample lines below them. Opening one pouch took under 20 seconds.

1. 09:10:42 ~ 09:12:14 KST (00:10:42Z)
   FACT ATK-040C4F(222.86.x.x) Telnet login succeeded. 91.94 seconds · 31 commands · 3 intents (execute after download · grant execute permission · file download). 0 downloads · completeness 13. No files stored, so not today's subject
2. 15:51:17 ~ 15:51:27 KST (06:51:17Z)
   FACT ATK-DD41EC(116.92.x.x) Telnet login succeeded. 9.58 seconds · 28 commands · 11 downloads, all 11 being 1-byte empty files (01ba4719…). The only intent is 'impair defenses' and completeness 42, the highest today. The whole day's 'impair defenses' tally is 1, so that 1 appears to be this session (an inference based on the counts matching). On 9/20 the same alias was 9.17 seconds · 28 commands
3. 17:02:10.87 KST (08:02:10Z)
   FACT Today's subject session begins. ATK-DD0862(87.58.x.x) Telnet (port 2223) login succeeded. An alias not in the archive. Being Telnet, the client program marker is an empty string
4. 17:02:10 ~ 17:02:30 KST (ended 08:02:30Z)
   FACT 11 commands · 8 downloads over 19.30 seconds. 3 intents (file download · grant execute permission · execute after download). Completeness 37. Screen recorded (contents not in the source material). The sum of files delivered by this alias alone is 8, matching the download count
5. (ATK-DD0862 sample — loader)
   FACT hxxp://176[.]65[.]139[.]196/bins/kla.sh · 3,013-byte Bourne-Again shell script · bb36568c…. The 8/21 brief has the same URL · same size · same hash. It did not change over the 32 days from 8/21 to 9/22
6. (ATK-DD0862 samples — 6 executables)
   FACT All fetched from 176[.]65[.]139[.]196/bins/. px86 133,292B ELF32 LSB Intel 80386 static · pmips 244,740B ELF32 MSB MIPS-I static · pmpsl 248,836B ELF32 LSB MIPS-I static · parm 182,976B ELF32 LSB ARM static · parm5 83,344B ELF32 LSB ARM dynamic (/lib/ld-uClibc.so.0) · parm6 199,324B ELF32 LSB ARM EABI4 static. All six stripped, 1,092,512 bytes in total
7. (ATK-DD0862 samples — compared with 8/21)
   FACT At the same URL on 8/21, px86 was 133,452B (979bd80a…) and pmips was 244,420B (ed6bae21…). Today px86 is 160 bytes smaller and pmips is 320 bytes larger, and both hashes differ. Two architectures on 8/21, six copies today. pmpsl · parm · parm5 · parm6 are file names seen for the first time on this host today
8. (ATK-DD0862 samples — other)
   FACT One 9-byte ASCII text file (0dc95fb4…, URL not recorded). The same hash as what ATK-A593DF left on 9/17 and ATK-CE432E left on 9/20. Today ATK-DD0862 left it
9. (Inference — the loader stays, only the payload is swapped)
   INFERRED The pattern of leaving the loader at the same path while rebuilding and uploading only the executables is the third instance, after 8/24 (the 31[.]77 family) · 9/20 (160[.]119[.]66[.]206 net.x86_64). A blocklist built from 8/21 hashes catches none of today's six executables and only catches kla.sh. A URL- or host-based rule catches every file with a recorded address
10. (Inference — relationship with 9/17's .206)
    INFERRED On 9/17, .206 in the same /24 range served files under a kworkerd-* naming scheme. Today .196 came back with 8/21's 'bins/p + architecture' scheme. Whether the two hosts are used alternately, run simultaneously, or are unrelated, we cannot know. Because days are missing from the archive, we also cannot say it 'rested for 32 days'
11. 18:56:18 ~ 18:56:25 KST (09:56:18Z)
    FACT ATK-BDB53E(160.119.x.x) Telnet session A: 7.01 seconds · 7 commands · 2 downloads. Session B, started 2.38 seconds later: 4.67 seconds · 2 commands · 2 downloads, ending 0.04 seconds after A ended. The samples kla.sh (39be6853…, 3,241B) · net.x86_64 (2cebccdc…, 192,328B) both have the same hashes as on 9/20. The fourth instance, after 9/15 · 9/17 · 9/20
12. (Daily totals · 01)
    FACT 829 sessions · 207 unique sources · 542 login attempts · 790 commands · 302 screen recordings. SSH 560 (port 2222) · Telnet 269 (port 2223). Telnet is 32.4% of sessions, yet all 5 principal sessions are Telnet. The intent classification total of 491 differs from 790 commands by 299
13. (Daily totals · 01 — compared with 9/20)
    FACT Sources leaving the 389-byte public key (a8460f44…) went 41 → 24. The 345gs5662d34 combination 40 → 23 sources. The libssh_0.9.6 marker (f555226d…) 41 → 24. The SSH key planting intent 43 → 24 times. The four values that spiked together on 9/20 came down together
14. (Daily totals · 02)
    FACT 45,461 sessions · 461 unique sources. VNC 33,287 (73.2%, 214 sources) · RDP 11,698 (119 sources) · SMB 250 · MSSQL 61 · LDAP 35 · ADB 130. Being a low-interaction sensor, successful logins · commands · credentials do not exist
15. (Daily totals · 02 — RDP cookies)
    FACT 'Administr' 5,159 times · 'Admin' 5,151 times, together 88.1% of RDP contacts. 'Administr' is about 54.9 times the archive maximum (9/20, 94 times), and 'Admin' about 78.1 times 9/20's 66. 'mstsc', which recurred from 9/10 to 9/20, is absent from today's list

FACT The five sessions with the densest records were all Telnet. Telnet was only a third (32.4%) of yesterday’s sessions. Yet the ones that took files were all Telnet. Let us also write down why we didn’t choose the other sessions as the subject. ATK-DD41EC ranks first in completeness (42). But the pattern of receiving 11 one-byte empty files is a family that has repeated nine times since August 18. ATK-BDB53E is a fourth visit and the files are the same as on September 20. ATK-040C4F had 31 commands but no files stored.

Values observed yesterday — to write down

We reproduce the values as-is so you can use them in defense. Tap a value to copy it. Addresses have been altered (defanged) so they aren’t accessed by mistake. That’s the form using hxxp instead of http and [.] instead of a dot. Use them as they are. Lines two through seven are the serial numbers seen for the first time yesterday.

FACT Look at the fifteen lines again. There are eight hash lines, six of them new. The seven address lines all share the same leading part, hxxp://176[.]65[.]139[.]196/bins/. Serial numbers have to be memorized anew every time. The shop address fits in one line.

Are you using these passwords

FACT Login attempts on the first server yesterday numbered 542. Spread over the day, that’s someone trying the door handle once every 2 minutes 40 seconds. The sources numbered 207. About 2.6 attempts per source.

FACT Of the username/password combinations attempted, only 13 kinds are reproduced in this post. Our rule is to write out only combinations repeated from three or more distinct IPs. The 366 kinds that fall short of this bar are counted but their values are not written down. A combination that appeared from only one source could be someone’s real account that leaked from somewhere. The 13 below, by contrast, are common values that many places tried identically — they belong to no one. Look at the first row and the fourth row.

FACT The odd string in the first row was at 40 sources on September 20 and fell to 23 yesterday. root with an entirely blank password field was tried 22 times from 6 sources. That’s 3.7 times per source — the highest repetition per source in the table.

The whole of yesterday

FACT These are the daily totals for the first server, the one whose doors actually open. Read the right-hand column alongside. A single number alone doesn’t convey scale.

FACT Breaking the commands typed inside the server down by kind:

FACT Adding the seven rows gives 491. That differs by 299 from the 790 commands. What those 299 are, the source material does not explain. “Planting an SSH key” means secretly registering a key that lets you back into the server without a password. It spiked to 43 on September 20 and came down to 24 yesterday. The sources that left that key file (the 389-byte public key a8460f44…) also dropped from 41 to 24. The four numbers that spiked together two days ago came down together.

FACT The second server (sensor 02) doesn’t open the door; it only records who knocked. So no successful logins, no commands, and no credentials appear here. Yesterday there were 45,461 events from 461 sources. That’s one every 1.9 seconds. Screen sharing (VNC) accounted for 33,287, or 73.2%. Remote Desktop (RDP) accounted for 11,698.

FACT When connecting over Remote Desktop, the other side writes and sends its own name tag (a cookie). Yesterday Administr appeared 5,159 times and Admin 5,151 times. Together that’s 88.1% of RDP. Administr is about 54.9 times our previous record high of September 20 (94 times). Admin is about 78.1 times September 20’s 66. mstsc, seen steadily from September 10 through 20, vanished from yesterday’s list. The name tag is a value the other side writes at will, so it cannot be taken at face value.

Mapping the attacker’s techniques onto the international catalog

MITRE ATT&CK is an international list that assigns a number to each attack technique. Matching yesterday’s behavior to those numbers gives the following. Tap an ID to go to the original description. We link so you can check for yourself rather than simply taking our word for it.

• T1110.001Brute Force: Password Guessing — 542 login attempts, 13 quotable combinationsINFERRED
• T1078.001Valid Accounts: Default Accounts — the subject session's successful login, the quotable combinations being of the default-value familyINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — 11 commands in a Telnet shell, the shell script kla.shINFERRED
• T1105Ingress Tool Transfer — the 'file download' intent, 8 samplesINFERRED
• T1222.002File and Directory Permissions Modification: Linux and Mac — the 'grant execute permission' intentINFERRED
• T1027.002Obfuscated Files or Information: Software Packing — based on a UPX sample we previously unpacked. For today's 6 ELF files, whether they are packed is not in the record, so we cannot say today's files were packedINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — from the whole-day totals (SSH key planting 24 times, public key from 24 sources). Unrelated to the subject sessionINFERRED
• T1070Indicator Removal — from the whole-day totals, deleting traces 25 times. Unrelated to the subject sessionINFERRED
• T1562Impair Defenses — once across the whole day (appears to be ATK-DD41EC). With no raw command text, we do not attach a sub-techniqueINFERRED

FACT All nine lines are [INFERRED]. What we hold is the commands’ ‘intent classification results’ and counts, plus the files’ names, sizes, and types. We have neither the raw commands nor the file contents. Matching to the catalog is always interpretation. And the bottom three lines (T1098.004 · T1070 · T1562) are whole-day matters unrelated to yesterday’s pouch.

There have been shapes like this before

INFERRED The Mirai botnet and its derivative families (2016~). The structure is: get in with default Telnet credentials, then fetch multiple copies of an executable, one per CPU type, from a web path like /bins/. Whichever one fits is the one that runs. This matches yesterday’s single session fetching x86 · MIPS (both endiannesses) · ARM all at once. That said, the source code was released in 2016, so unrelated operators also use the same naming conventions. (Source types: U.S. Department of Justice indictments and guilty-plea records, public analysis reports from numerous security vendors)

The Gafgyt (Bashlite) family (2014~). The structure is: one shell script fetches and runs static executables for each CPU type in turn. It looks the same as yesterday’s shape, where ‘one pouch + several cables’ came down in a single session from the same path. (Source type: public analysis reports from numerous security vendors)

FACT We stop here. A sample classification service (VirusTotal) is not integrated. Yesterday’s files also carry no MalwareBazaar tags. So we do not render a verdict that yesterday’s files are of the Mirai family. What resembles it is the structure and the naming approach — that far and no further.

So what should you do

We cannot stop the side that brings the pouch. What we can change is whether there’s an open port on our machine to plug into, and whether there’s an open path to fetch the cables.

FACT 1. You’re still using default accounts and weak passwords · likelihood high All five principal sessions recorded yesterday succeeded at login. In the table above, admin/admin was tried 26 times from 13 sources, and root with a blank password 22 times from 6 sources. Every entry path observed yesterday was credentials. The subject session had six executables in hand 19.30 seconds after logging in.

FACT 2. You have management ports, Telnet especially, open directly to the internet · likelihood high Telnet was 32.4% of sessions, yet all five sessions that took files were Telnet. On the SSH side, the only client program marker that left files behind was 16443846… (3 sources). Check the settings screen of the router or camera in your home for whether Telnet is turned on.

INFERRED The ARM and MIPS executables that came down yesterday are a lineup aimed at devices with Telnet open, like routers and CCTV. If one is breached, the whole device goes over.

FACT 3. You’re not blocking outbound connections · likelihood high Yesterday the ‘file download’ intent occurred 39 times and ‘execute after download’ 37 times. 7 files were fetched from 176[.]65[.]139[.]196/bins/ and 2 from 160[.]119[.]66[.]206/bins/. Five of the six cables are statically linked, so they run on any Linux as long as the CPU matches. What if the server’s path outward had been blocked? Yesterday’s session would have ended at the step of fetching the cables. In this post’s metaphor, that is “we don’t accept goods coming from the shop.” It doesn’t matter how many times the serial numbers change.

INFERRED 4. You have no connection rate limiting (fail2ban and the like) · likelihood medium Login attempts run about 2.6 per source. admin/admin is 2 per source. Most would not have tripped a rule like “lock out after 5 failures.” Because the method is knocking broadly with few attempts, rate limiting alone is hard to stop it with. It only works combined with eliminating default accounts. That’s why we didn’t mark it ‘high’.

FACT 5. You allow password logins and don’t use key-based authentication · likelihood low Every session that took files yesterday was Telnet. Telnet has no key-based option at all. How many login attempts were over SSH is not broken out separately. So we have no grounds to say key-based authentication could have stopped yesterday’s intrusions. For Telnet, there is no answer other than turning it off.

INFERRED 6. You don’t collect logs or have no anomalous-behavior monitoring · likelihood medium Across the whole day there were 25 instances of deleting traces and 1 of impairing defenses. Neither appeared in the subject session. We had 302 screen recordings, so we could reconstruct the flow of a 19-second session. Without records we would not have known the very fact that a shop from a month ago had reopened.

FACT The distribution points observed yesterday, 176[.]65[.]139[.]196 and 160[.]119[.]66[.]206, are subject to reporting to C-TAS (the Korea Internet & Security Agency’s cyber threat information sharing system). That said, what we can confirm is only that the transmission succeeded. Whether it was actually ingested on KISA’s side has to be checked separately.

What We Don’t Know

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

About the pouch and the shop

• [Unverifiable] The archive has no briefs for 9/9 · 9/11 · 9/12 · 9/14 · 9/16 · 9/18 · 9/19 · 9/21. “176[.]65[.]139[.]196 appeared again after 32 days” is based on 29 days of archive. Whether this shop rested in between, we don’t know.
• [Unverifiable] Whether 176[.]65[.]139[.]196 (8/21 · yesterday), .202 (8/23–25), and .206 (9/17) are the same operator, we don’t know. What is confirmed is only that they’re in the same /24 range (a block of 256 addresses sharing the first three octets), and that .196’s naming convention overlaps with the list obtained by unpacking (31[.]77[.]227[.]121). Because it’s a publicly released source family, unrelated operators also use the same convention.
• [Unverifiable] px86 · pmips have the same address, name, and type as on 8/21, differing only in size by −160 / +320 bytes. Whether the same program was rebuilt, or a different program was given the same name, cannot be judged without the sample contents.
• [Unverifiable] We don’t know why only parm5 is dynamically linked and needs an adapter (uClibc). All that can be read from the file type is that running it requires /lib/ld-uClibc.so.0 on the target device.
• [Unverifiable] Which of the six cables actually ran (or was attempted) is not distinguished in the record. There is an ‘execute after download’ intent, but no raw command text and no screen recording contents.
• [Unverifiable] The basis linking ATK-DD0862 to the 8 files is that the deliverer column and the count total (8 = the number of downloads) match. There is no column linking sessions and files 1:1.
• [Caution] The brief wrote that “an address-based rule catches all eight.” But of the 8, the 9-byte text file has no address recorded. So this post narrowed it to “the seven files with a recorded address.”
• [Unverifiable] The 9-byte text file (0dc95fb4…) came from a different alias on each of 9/17 · 9/20 · yesterday. With no contents, we don’t know what it is, or why the same file comes from multiple sources.

About the other sessions and the totals

• [Unverifiable] Among the second server’s top sources is 176.65.x.x (ATK-D4B7A8, 89 events). Because the address is masked, we cannot know whether it’s the same machine as the distribution point 176[.]65[.]139[.]196. We do not restore it. Nor is it documented that an alias points to the same source across the two servers.
• [Unverifiable] ATK-DD41EC appeared under the same alias on 9/20 and yesterday. Because the method of generating aliases is not documented, we did not use it as grounds to tie two records from different dates to the same source.
• [Unverifiable] ATK-040C4F has a ‘file download’ intent but a download count of 0. We cannot distinguish whether a fetch was attempted and failed, or succeeded but wasn’t stored.
• [Unverifiable] The formula for completeness is not in the source material. We cannot explain why ATK-DD41EC (42), with 1 intent, is higher than ATK-DD0862 (37), with 3 intents.
• [Unverifiable] What the difference of 299 between 790 commands and an intent classification total of 491 consists of, the source material does not explain.
• [Unverifiable] We don’t know the cause of the RDP name tags Administr · Admin growing by tens of times versus 9/20. With no column linking sources to services, we can’t even confirm whether one or two sources produced the number.
• [Unverifiable] Detailed adb records for the second server are not in yesterday’s source material. What came in over the 130 ADB (Android Debug Bridge) sessions, and from how many sources, we don’t know. Nor can we confirm whether the second server’s 4 files (all hashes already seen on 8/28 · 8/30 · 9/3 · 9/20) came in over ADB.
• [Unverifiable] Whether the 11 client program markers are part of a total of 47 groupings, or everything seen yesterday, is not stated. The subject session was Telnet, so there is no marker at all, and we did not apply the grouping analysis. A marker is a marker of a program, not of a person.

What we deliberately left out or did not connect

• [Excluded] Three kinds that appear to be HTTP and SIP requests landing in the login field by mistake were treated as noise rather than passwords and removed from the quotable list. The host string in one of their password fields is not written down.
• [Excluded] One Discord webhook left as a plaintext indicator was removed from the factual account because the source material does not say which session or file it connects to.
• [Excluded] Background statistics (KISA security advisories 7,640 CVEs · CISA KEV 404 · 100 confirmed ransomware-linked, top EPSS CVE-2018-13379 · CVE-2022-26134 · CVE-2021-44228 · CVE-2023-4966 · CVE-2024-3400) do not connect directly to yesterday’s observations. Yesterday’s intrusion paths were all credentials.
• [Unverifiable] For the C-TAS report, only the transmission’s success is confirmed. Whether it was ingested or used on KISA’s side has to be checked separately.

What we do not judge at all

• Carrier/organization (ASN · ISP) — we have no relevant database. We do not infer. We also don’t know the hosting provider for the distribution point 176[.]65[.]139[.]196.
• Geolocation — unknown for the same reason. IP geolocation is not grounds for identifying who did something in the first place. This post does not name any country, company, or individual as the attacker.
• VPN · Tor · cloud status — we have no means to determine it.
• Sample classification (VirusTotal) — not integrated. This post cannot say what family yesterday’s six new executables are detected as.
• Client program string (User-Agent) — neither server is web (HTTP). The first is SSH and Telnet; the second is SMB · RDP · VNC · MSSQL · LDAP · ADB. Web attacks are covered from a separate source.
• Vulnerability number (CVE) linkage — SSH and Telnet attacks mostly don’t reference a specific vulnerability. The second server is at the stage of matching protocol specs, so the same applies.

A pouch we saw a month ago came back yesterday. The pouch itself had not changed by a single bit. The cables inside grew from two to six, and the serial numbers were all new. A month-old serial number list catches none of the six. What stayed the same instead was the address of the shop the pouch comes from. And the name tags on the cables were the very names we had seen earlier by tearing open a box.

What changed, and who brought it, we don’t know. What we don’t know, we leave as not known. Even so, what we can do is clear. Close the port to plug into (Telnet), block the path for fetching cables (outbound connections), and remember the shop address for a long time. Serial numbers changed within a month. The shop address was the same 32 days later.

The observation date is September 22, 2026, and this post was written up the following day. Source IPs are reproduced as masked in the brief (87.58.x.x, 222.86.x.x, 116.92.x.x, 160.119.x.x, 176.65.x.x) and not restored. Distribution point addresses are kept defanged (hxxp://, [.]) in both the body and the IOC block so they aren’t accessed by mistake. For credentials, only the 13 combinations repeatedly observed from 3 or more distinct IPs are quoted verbatim; for the remaining 366 only the count is disclosed and no values are written down. Items for which we have no means of measurement — carrier, nationality, VPN status — are left as “we don’t know” rather than inferred.