Same Cooler Bag, All Nine Side-Dish Containers Refilled

Have you ever subscribed to a side-dish delivery service? Once a week, a cooler bag is left at your front door. The bag is the same every week. Same color, same shop nametag hanging from the zipper pull. What changes is the food inside. Last week it was stir-fried anchovies; this week it might be braised beef.

Yesterday, a bag like this was left in front of our server too. But this was a bag we had already seen twice. We first saw it on August 21, and again five days ago on September 22. The bag was not a thread different from those times. The containers inside had grown from six to nine. And all nine had been freshly filled.

Today we open this bag one container at a time.

First, our server is a house with its doors deliberately left open

FACT We run a honeypot. A honeypot is a decoy server left deliberately insecure so we can watch who comes in and what they do. So what follows is not actual damage but an observation record. There are two servers. The first (sensor 01) actually lets the door open. The second (sensor 02) only records who knocked.

FACT The party that brought the bag yesterday is ATK-9D3922. That is an alias we assigned. The source IP is written masked as 108.59.x.x. This alias appears in our records for the first time. It came in over Telnet. Telnet is an old remote access method for sending text commands to a distant machine. What passes over it is not encrypted. These days it mostly survives on small devices like routers and CCTV cameras. The port was 2223 and the login succeeded. Because it was Telnet, no client-program marker (fingerprint) was left behind.

47 seconds, the time it took to unpack one bag

FACT It came in at 4:11:07 p.m. and left 47.12 seconds later. During that time it typed 11 commands. That is one line every 4.3 seconds. It also downloaded 11 files — again one every 4.3 seconds. Our classifier assigned three names to this session’s behavior, in this order: file download → granting execute permission → execute after download. “Granting execute permission” is the step that allows a received file to be run as a program.

FACT We score how dense a record is with a number we call completeness (record density). This session scored 46, the highest yesterday. A screen recording was also kept. However, the content of the recording itself is not in our source material.

FACT The 11 files it received come in three kinds.

• One cooler bag — kla.sh. A shell script. A shell script is several command lines gathered into one file. Run it, and the commands written there execute in order. Its size is 3,013 bytes. That is about as many characters as one A4 page.
• Nine side-dish containers — executables. Programs in the ELF format used on Linux. The nine together come to 1,725,652 bytes, about 1.7 megabytes. Roughly the size of one phone photo.
• One note — a 9-byte text file. Nine English characters’ worth.

INFERRED In attacks like this, the lead script usually plays the role of the bag. It fetches the executables that follow and gets them opened one by one. However, what was written inside kla.sh is not in our source material. This is an interpretation drawn from similar structures.

Nine kinds, because you don’t know who will be eating

FACT The CPU, a computer’s brain, comes in several kinds. When the CPU differs, the program has to be built separately to match that CPU in order to run. In side-dish terms, that is a menu tailored to the eater. It is like having to serve baby food to an infant and soft porridge to a grandmother. The nine containers that came down yesterday were all for different CPU types. Look at the middle column.

FACT That is five families: x86, MIPS, ARM, PowerPC, and m68k. There are four ARM builds and two MIPS builds. Endianness is the difference between a CPU reading numbers from the front or from the back. Even for the same MIPS, a different reading direction needs a different side dish.

FACT Statically linked, in the rightmost column, means all the parts it needs are packed inside the file. It is like sending the spoon inside the container. Even if the receiving house has no spoon, it can eat. Eight of the nine are like this. Only parm5 is dynamically linked. The receiving device must already have a part called /lib/ld-uClibc.so.0 for it to run. It is a side dish that can only be eaten by pulling out the spoon the house already has.

INFERRED The party that sent the bag probably did not know which CPU was inside our server. Not knowing who lives in the receiving house, it packed all nine menus. And this lineup fits small devices like routers and CCTV cameras more than ordinary computers. It matches a setup aimed at pulling such devices into a botnet. A botnet is a herd of machines being controlled remotely without their owners’ knowledge.

The bag unchanged for 37 days, the side dishes all new

FACT Ten of the 11 files all came from the same address: hxxp://176[.]65[.]139[.]196/bins/. That is the very address we noted in the September 22 post five days ago. In other words, the same side-dish shop.

FACT Every file has a value called a hash. It is a unique number computed from the file’s entire contents. Change a single character and a completely different value comes out. In side-dish terms, it is a high-precision photo of the inside of the container. Move a single sesame seed and it becomes a different photo. We put the photos from five days ago and yesterday side by side. Look at the rightmost column.

FACT The bag kla.sh did not change a single bit for 37 days, from August 21 through yesterday. Conversely, the photos of all nine side-dish containers are values we have never seen. Searching all 30 days of the archive (8/16–9/22) turns up nothing. The six containers with the same names had every one of them refilled. 96 bytes is about the size of one text message. Even the containers that grew by only that much had completely different photos.

Three side-dish containers that match even in weight

FACT The strangest rows in the table above are the second through the fourth. The three files px86, parm5, and parm6 match five days ago in size down to the byte. Yet the photos (hashes) differ. Put them on a scale and they are identical to the gram, but open the lid and photograph them and they are three different side-dish containers.

INFERRED If the name and size are the same but the hash differs, one possibility comes to mind. They may have been rebuilt with only part of the inner contents changed while leaving the file length as it was. Like keeping the container the same size and just changing the food slightly. But the file contents are not in our source material. So we cannot say what changed.

One container that arrived with a recipe note still attached

FACT Among the three newly added containers, parm7 is the largest of the nine (259,684 bytes). And it is the only one of the nine that arrived without its debug information removed. Debug information is explanatory notes the program’s author leaves behind to consult when fixing errors. Normally it is taken off before shipping (stripped). pppc and pm68k were in a stripped state. parm7 was delivered with the recipe note stuck to the container.

FACT A side dish with the same name also came from a different shop. A different visitor called ATK-60335A fetched a 60,088-byte ARM executable from hxxp://64[.]89[.]160[.]48:80/bins/parm7. It is an address not in our records, with a hash not in our records (40b497bc…). The size is less than a quarter of yesterday’s protagonist’s parm7. This file carried a marking that said ‘no section header’ (no table of contents).

INFERRED ‘No section header’ is a look commonly seen in executables wrapped tightly by compression. If so, the small size is also explained. But today’s source material has no field telling us whether it is compressed. So we do not settle it. We also do not know what relationship the two parm7 files have to each other.

The side dishes’ names were names we already knew

FACT We have unpacked UPX-compressed malware before. UPX is a tool that wraps an executable to reduce its bulk. While wrapped, not a single address is visible on the outside. There are 12 file names that only emerged after unpacking. All are names under 31[.]77[.]227[.]121/bins/.

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

FACT Eight of yesterday’s nine containers have names that match this list character for character. The one that does not overlap is px86. Five days ago, five of six matched. The names that are only on the list and have not appeared yet are four: parm64 · psh4 · pspc · x86_64.

INFERRED We could recognize them because we had unpacked them beforehand and learned the nametag convention — that the same way of naming is used even though the shop address differs. Had we only looked at the outside, it would have been written down as nothing more than “nine files never seen before.”

FACT Here we draw two lines. First, yesterday’s addresses were visible as they were in the session. They were not obtained by decompressing anything. What the unpacking experience gave us was not the addresses but the naming convention. Second, the naming convention being the same only means a publicly available build tool from the same family was used. It does not mean the same person or the same organization. Using the same meal kit does not make it the same restaurant.

Could a list of photos have stopped this

INFERRED Let’s think about it this way. Five days ago we built a list of photos saying “we do not accept side dishes matching these photos.” A blocklist built from hashes is exactly this approach. Of the 11 that came in yesterday, how many would this list catch? Only two: the bag (kla.sh) and the 9-byte note. Not one of the nine containers is caught. Because they were all freshly filled.

INFERRED Conversely, what if the rule had been “we do not accept bags coming from this shop”? All 10 files with a recorded address are caught. The photos: all nine changed in five days. The shop address: unchanged for 37 days.

Laid out in time order

Laying out what happened on the first server yesterday in time order looks like this. Pay attention to the three lines at 16:11. From entry to exit took less than a minute.

1. 15:44:56 ~ 15:45:12 KST (06:44:56.41Z)
   FACT ATK-BDB53E(160.119.x.x) Telnet login succeeded. 7 commands · 2 downloads over 15.66 seconds. The samples are hxxp://160[.]119[.]66[.]206/bins/kla.sh(3,241B · 39be6853…) and net.x86_64(192,328B · 2cebccdc…), with the same hashes as 9/20 · 9/22. Nothing new
2. 16:11:07.50 KST (07:11:07.495199Z)
   FACT Subject session begins. ATK-9D3922(108.59.x.x) Telnet login succeeded. An alias not in the archive. Because it is Telnet, the client-program marker is an empty string
3. 16:11:07 ~ 16:11:54.62 KST (ended 07:11:54.615513Z)
   FACT 11 commands · 11 downloads over 47.12 seconds. 3 intents (file download · granting execute permission · execute after download). Record density 46, today's highest. Screen recorded (content not included). The samples listing this alias as the deliverer are kla.sh 1 + ELF 9 + 9-byte text 1 = 11, matching the download count
4. (ATK-9D3922 sample — loader)
   FACT hxxp://176[.]65[.]139[.]196/bins/kla.sh · 3,013B Bourne-Again shell script · bb36568c…. URL · size · hash are all the same as 8/21 · 9/22. Unchanged for 37 days since 8/21
5. (ATK-9D3922 samples — the 6 with the same names as 9/22)
   FACT px86 133,292B(2461a317… → 98c6780a…) · parm5 83,344B(13e3e131… → a273cd0b…) · parm6 199,324B(7aa4efe5… → 62a434f7…) have the same size with only the hash differing. pmips 244,836B(+96B) · pmpsl 248,932B(+96B) · parm 183,488B(+512B) changed in both size and hash
6. (ATK-9D3922 samples — the 3 newly added)
   FACT parm7 259,684B(ELF32 LSB ARM EABI4 · static · with debug_info, not stripped) · pppc 179,536B(ELF32 MSB PowerPC · static · stripped) · pm68k 193,216B(ELF32 MSB m68k 68020 · static · stripped). The 9 ELF files total 1,725,652B. Dynamically linked: only parm5(/lib/ld-uClibc.so.0); with debug information remaining: only parm7
7. (ATK-9D3922 samples — other)
   FACT 9-byte ASCII text(0dc95fb4… · URL not recorded). 5 times today · 3 sources (ATK-9D3922 · ATK-EA3D92 · ATK-377ED5). The same hash was also left by other aliases on 9/17 · 9/20 · 9/22
8. (Inference — the 3 with the same size and different hashes)
   INFERRED They may have been rebuilt with only part of the internal contents replaced, within a range that does not change the file length. With no sample contents, we cannot say what changed
9. (Inference — the shelf life of hash blocking)
   INFERRED A blocklist built from 9/22 hashes catches only 2 of this session's 11 files, kla.sh and the 9-byte text, and catches none of the 9 executables. Had it been a host · path based rule, it would catch all 10 files with a recorded URL
10. 16:57:43 ~ 16:58:24 KST (07:57:43.92Z)
    FACT ATK-EC7309(160.250.x.x) Telnet. 40.68 seconds · 17 commands · 5 intents (reconnaissance—system · file download · granting execute permission · execute after download · planting an SSH key). 0 downloads · record density 17
11. 20:20:45 ~ 20:20:49 KST (11:20:45.69Z)
    FACT ATK-CA5936(130.12.x.x) SSH. 4.11 seconds · 1 command · 5 intents · 2 downloads (54B text 00b6f15c… · 399B OpenSSH private key 43728fbf…). Fingerprint 16443846… · client program 'SSH-2.0-Go'. Alias · fingerprint · sample hashes are the same as those recorded repeatedly since 8/19
12. 20:48:38 ~ 20:49:40 KST (11:48:38.61Z)
    FACT ATK-015624(2.29.x.x) Telnet. 61.79 seconds · 17 commands. Its 5 intents are the same combination as ATK-EC7309, and 0 downloads · record density 17 match as well. Neither alias is in the archive
13. (A different distribution point — the same file name)
    FACT ATK-60335A fetched a 60,088B ELF(ARM EABI4 · no section header) from hxxp://64[.]89[.]160[.]48:80/bins/parm7. Host · hash(40b497bc…) · alias are all absent from the archive. This alias is not in the main session list
14. (Daily totals · 01)
    FACT 5,617 sessions · 203 unique sources · 5,233 login attempts · 9,747 commands · 5,079 screen recordings. SSH 4,989(port 2222) · Telnet 628(port 2223). Compared with 9/22(829 sessions · 790 commands), about 6.8x the sessions · about 12.3x the commands. The intent classification total of 6,682 differs from the command count by 3,065
15. (Daily totals · 01 — recurring series)
    FACT 389-byte public key(a8460f44…) from 21 sources, 21 times. The 345gs5662d34 combination from 22 sources. libssh_0.9.6 fingerprint(f555226d…) from 22 sources today · 520 sources cumulatively. Similar to 9/22's 24 · 23 · 24
16. (Daily totals · 02)
    FACT 54,243 sessions · 433 unique sources. VNC 53,038(97.8% · 211 sources) · RDP 567(113) · SMB 181(74) · MSSQL 30(10) · LDAP 19(10) · ADB 408. 0 samples on 02. RDP, at 11,698 on 9/22, dropped about 95% to 567

FACT Besides the subject session, there were four more main sessions that logged in successfully yesterday. We note why we did not pick them as the subject. ATK-BDB53E had two files identical to September 20 and 22. ATK-CA5936 is a 3–4 second session repeated since August 19, and its files are the same as then. ATK-EC7309 and ATK-015624 had the most behavior names, five. But they fetched 0 files, so there is nothing to look into.

The values from yesterday — to write down

We transcribe the values as they are so you can use them in defense. Click a value to copy it. The addresses have been altered (defanged) so they cannot be accessed by mistake. It is the form using hxxp instead of http and [.] instead of a dot. Use them as they are. Lines two through ten are the photos (hashes) seen for the first time yesterday.

FACT Look at the twenty-three lines again. Ten of the twelve hash lines are values seen for the first time yesterday. By contrast, ten of the eleven address lines share the same leading part, hxxp://176[.]65[.]139[.]196/bins/. Photos have to be taken anew every time. For the shop address, one line is enough.

Are you using this password

FACT Login attempts on the first server yesterday numbered 5,233. Spread over the day, that is someone trying the doorknob once every 16.5 seconds. More than ten tries in the time it takes to listen to one song.

FACT Of the ID/password combinations attempted, only 20 kinds are transcribed in this post. Our rule is to write out verbatim only combinations repeated from three or more different IPs. For the 356 kinds that fell short of this bar, we count them and do not write the values. A combination that appeared from only one place could be someone’s real account leaked from somewhere. The 20 below are common values belonging to no one, entered identically by many places. Look at the number in the first row.

FACT admin/admin came in 368 times from 32 sources. That works out to one source trying the same combination more than 11 times. The odd string in the second row is the exact opposite. 22 sources entered it exactly once each. root with a completely blank password field also came in from 6 sources.

All of yesterday

FACT These are the daily totals for the first server, the one whose door actually opens. Read the right column alongside. A single number alone does not convey the scale well.

FACT Sessions grew nearly 7-fold over five days ago, and commands more than 12-fold. Why they grew like this is written in the ‘What We Don’t Know’ section later. Breaking the commands typed inside the server down by kind looks like this.

FACT Adding the seven rows gives 6,682. That is a difference of 3,065 from the 9,747 commands. What those 3,065 are is not explained in the source material. ‘Planting an SSH key’ is secretly registering a key that lets you get back into the server without a password. That key file (the 389-byte public key a8460f44…) came in from 21 sources once each, 21 times in all. 389 bytes is about three or four text messages’ worth. The client-program fingerprint called libssh_0.9.6 (f555226d…) was seen from 22 sources yesterday. That is 520 sources in all so far. Similar to five days ago.

FACT The second server (sensor 02) does not open the door; it only records who knocked. So there are no successful logins, no commands, and no credentials here. Yesterday, 54,243 events came from 433 sources. That is once every 1.6 seconds. Of those, 97.8% — 53,038 — were VNC. VNC is a feature for viewing and operating another computer’s screen from a distance. Remote Desktop (RDP) dropped about 95%, from 11,698 five days ago to 567 yesterday. Files fetched: 0.

We made a separate video about the second server on the same day. It is about the time two different places knocked the exact same number of times, down to the last digit.

Mapping the attackers’ techniques to the international classification

MITRE ATT&CK is an international list that assigns a number to each attack technique. Mapping yesterday’s observed behavior to those numbers looks like this. Click an ID to go to the original description. We link so that you can check for yourself rather than taking our word for it.

• T1110.001Brute Force: Password Guessing — 5,233 login attempts, admin/admin 368 times from 32 sourcesINFERRED
• T1078.001Valid Accounts: Default Accounts — all 5 main sessions logged in successfully, the quoted combinations are 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 — 'file download' intent, 11 samplesINFERRED
• T1222.002File and Directory Permissions Modification: Linux and Mac — 'granting execute permission' intentINFERRED
• T1082System Information Discovery — 'reconnaissance — system' 4,481 times across the whole day. Not among the subject session's intentsINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — intents of ATK-CA5936 · EC7309 · 015624, public key from 21 sources. Unrelated to the subject sessionINFERRED
• T1070Indicator Removal — removing traces 23 times across the whole day. Unrelated to the subject sessionINFERRED

FACT All eight 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 command text nor the file contents. Mapping to a classification table is always interpretation. And the bottom three lines (T1082 · T1098.004 · T1070) are whole-day matters unrelated to yesterday’s cooler bag.

There have been shapes like this before

INFERRED The Mirai botnet and its derivative families (2016–). They get in with default Telnet accounts. Then they fetch multiple builds of an executable, one per CPU type, from a web path like /bins/. The structure is to get whichever one fits to run. However, since it is a family whose source code was made public, unrelated operators also use the same naming convention. (Source types: U.S. Department of Justice guilty-plea records, public analysis reports from multiple security vendors)

The Gafgyt(Bashlite) family (2014–). The structure is one shell script fetching and running static executables for each CPU type in turn. ‘One bag + several side-dish containers’ coming down in a single session has the same look as yesterday’s picture. (Source type: public analysis reports from multiple security vendors)

FACT We stop here. A sample classification service (VirusTotal) is not integrated. MalwareBazaar tags are not in today’s source material either. So we do not render a verdict that yesterday’s files are of the Mirai family. The resemblance extends to the structure and the way of naming.

So what should you do

We cannot stop the side that sends the bag. What can be changed is whether the front door is open, and whether you accept deliveries from the shop.

FACT 1. You are still using default accounts and easy passwords · high likelihood All five main sessions yesterday logged in successfully. The admin/admin in the table above was tried 368 times by 32 sources. root with a blank password also came in from 6 sources. The only entry path confirmed yesterday was credentials. The subject session got nine CPU-specific executables into its hands within 47.12 seconds of logging in.

FACT 2. You have management ports, especially Telnet, opened directly to the internet · high likelihood Telnet was only 11.2% of all sessions yesterday. Yet four of the five main sessions were Telnet. The two sessions that fetched executables (ATK-9D3922 · ATK-BDB53E) were both Telnet too. Check the settings screen of the router or camera in your home to see whether Telnet is turned on.

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

FACT 3. You are not blocking outbound connections · high likelihood Yesterday the ‘file download’ intent appeared 22 times and ‘execute after download’ 14 times. The subject session fetched 10 items from 176[.]65[.]139[.]196/bins/. Eight of the nine containers are statically linked. Because the spoon is included, they run on any Linux as long as the CPU matches. What if the server’s path outward had been blocked? This session would have ended at the stage of fetching the bag. In this post’s metaphor, that is “we do not accept deliveries from this shop.” It does not matter how many times the side dishes change.

INFERRED 4. You have no connection rate limiting (fail2ban, etc.) · medium likelihood fail2ban is a tool that “locks the door for a while after a certain number of failures.” The admin/admin side averaged about 11.5 tries per source, so it would have been caught by a rule like “lock after 5 failures.” By contrast, the 345gs5662d34 combination (22 sources, 22 times) and the public key (21 sources, 21 times) are exactly once per source. That sort cannot be blocked by rate limiting. Because the two kinds are mixed together, we put it at ‘medium.’ It is only effective when used together with eliminating default accounts.

FACT 5. You allow password logins and do not use the key method · low likelihood The subject session was Telnet. Telnet has no key-method option. On the SSH side, ATK-CA5936 logged in successfully. But the source material has no authentication-method field, so we cannot confirm it came in with a password. For Telnet, yesterday’s subject path, there is no answer other than turning it off.

INFERRED 6. You do not collect logs or have no monitoring for anomalous behavior · medium likelihood Across the whole day there were 23 instances of removing traces. There were none in the subject session. We had 5,079 screen recordings, so we could reconstruct the session flow. Without records, we would not have known the very fact that the same shop had refilled every side dish in five days.

FACT The distribution points observed yesterday — 176[.]65[.]139[.]196 · 160[.]119[.]66[.]206 · 64[.]89[.]160[.]48 — are subject to reporting to C-TAS (the Korea Internet & Security Agency’s cyber threat information sharing system). However, all we can confirm is that the transmission succeeded. Whether it actually landed on KISA’s side has to be checked separately.

What We Don’t Know

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

About the bag and the side dishes

• [Cannot confirm] The archive has no briefs for 9/9 · 9/11 · 9/12 · 9/14 · 9/16 · 9/18 · 9/19 · 9/21 · 9/23–9/26. ‘In five days’ is said in comparison with the 9/22 brief. We do not know how many times this shop changed its side dishes in between.
• [Cannot confirm] px86 · parm5 · parm6 have the same sizes as 9/22 with only the hashes differing. What changed (a configuration value, the build time, something else) cannot be judged, as the file contents are not in the source material.
• [Cannot confirm] We do not know the reason only parm7 has debug information remaining. Whether it was a mistake or intentional cannot be distinguished from this material.
• [Cannot confirm] We do not know what relationship the parm7 at 64[.]89[.]160[.]48 (60,088 bytes, no table of contents) has to the parm7 at 176[.]65[.]139[.]196 (259,684 bytes). ‘No section header’ is commonly seen in compressed executables, but with no field telling us whether it is compressed, we do not settle it.
• [Cannot confirm] The record does not distinguish which of the nine containers were actually executed. There is an ‘execute after download’ intent, but no command text and no screen-recording content.
• [Cannot confirm] The basis linking ATK-9D3922 to the 11 files is that the deliverer field and the count total (11 = the download count) match. There is no field linking sessions and files 1:1.

About the other sessions and the totals

• [Cannot confirm] ATK-EC7309 and ATK-015624 have a ‘file download’ intent but a download count of 0. The two sessions match in all of 17 commands · 5 intents · record density 17. We cannot tell whether they tried to fetch and failed, or used the same script.
• [Cannot confirm] ATK-CA5936’s fingerprint 16443846… is not in yesterday’s client-program fingerprint list (12 entries). Whether that list shows only the top portion of all 45 clusters is not stated. Because the subject session was Telnet and thus has no fingerprint at all, we did not apply cluster analysis. A fingerprint is a program’s fingerprint, not a person’s.
• [Cannot confirm] The source material does not explain what the difference of 3,065 between 9,747 commands and the intent classification total of 6,682 is.
• [Cannot confirm] We do not know the cause of the first server’s sessions jumping about 6.8x over 9/22. The first server has no top-sources list, so we cannot even confirm whether the number was made by one or two places.
• [Cannot confirm] The formula for computing record density (completeness) is not in the source material.
• [Cannot confirm] The second server’s top sources include 176.65.x.x (ATK-D4B7A8, 200 events). Because the address is masked, we cannot tell whether it is the same machine as the distribution point 176[.]65[.]139[.]196. We do not restore it. Nor is it documented that an alias is guaranteed to point to the same source across the two servers.
• [Cannot confirm] We have not confirmed whether the 53,038 VNC events are the maximum in our records. The only days compared are 9/22 (33,287) and 9/6 (48,605).
• [Cannot confirm] We do not know the cause of the RDP nametag Administr dropping from 5,159 times on 9/22 to 2 times yesterday.
• [Cannot confirm] Detailed records for the second server’s adb are not in yesterday’s source material. We do not know what came in on the 408 ADB (the channel for connecting to and operating Android devices) sessions, or from how many places.

What we deliberately left out or did not connect

• [Excluded] The one Discord webhook left as a plaintext indicator (also present on 9/22) is left out of the factual account because the source material does not say which session or file it connects to. We do not transcribe webhook tokens, as others could abuse them.
• [Cannot confirm] The C-TAS report is confirmed only as far as successful transmission. Whether it was ingested or used on KISA’s side has to be checked separately.
• [Excluded] The background statistics (7,642 CVEs in KISA security notices · 408 CISA KEV entries · 101 confirmed ransomware linkages, 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.

What we do not judge at all

• Carrier/organization (ASN · ISP) — we have no relevant database. We do not infer.
• Geographic location — unknown for the same reason. IP geolocation is not, to begin with, a basis for determining who did something. This post does not name any country, company, or individual as the attacker.
• Whether VPN · Tor · cloud — we have no means of determining it.
• Sample classification (VirusTotal) — not integrated. For sample classification we use MalwareBazaar tags. This post cannot say what family yesterday’s nine new executables are detected as.
• Client program string (User-Agent) — neither server is web (HTTP). The first is SSH · Telnet, the second SMB · RDP · VNC · MSSQL · LDAP · ADB. Web attacks are handled from a separate source.
• Vulnerability number (CVE) linkage — SSH · Telnet attacks mostly do not reference a specific vulnerability. The second server is at the stage of matching the connection specification, so the same applies.

The same cooler bag came for a third time. The bag did not change by a thread in 37 days. The containers inside grew from six to nine, and all nine had been freshly filled. Three matched even in weight but differed only inside. One had a recipe note attached. The list of photos taken five days ago recognizes not one of the nine containers.

We do not know what was refilled or who sent it. What we don’t know, we leave as unknown. Still, what can be done is clear. Close the front door (Telnet), refuse deliveries from the shop (outbound connections), and remember the shop address for a long time. The photos: all nine changed in five days. The shop address: unchanged for 37 days.

The observation date is September 27, 2026, and this post was compiled the following day. Source IPs were transcribed as they appear in the brief in masked form (108.59.x.x, 160.119.x.x, 160.250.x.x, 130.12.x.x, 2.29.x.x, 176.65.x.x) and were not restored. Distribution point addresses were kept in their defanged state (hxxp://, [.]) in both the body and the IOC block so they cannot be accessed by mistake. For credentials, only the 20 combinations repeatedly observed from three or more different IPs were quoted verbatim; for the remaining 356, only the count is given and the values are not written. Items for which we have no means of measurement — carrier, nationality, whether a VPN was used — were left as “we don’t know” rather than inferred.