The 'Additional Data' That Arrived a Week Late — The Device Meant to Receive It Was a Router

Think back to the day you installed a new game on your phone. The app you download from the store is smaller than you’d expect. But the first time you open it, a message appears: “Downloading additional data.” The real game comes after that. And it’s far bigger than the app you downloaded first.

Additional data follows one rule: the version that comes down is the one that matches your device. Different devices have different chips inside. So a file meant for a different device won’t run even if you download it.

Yesterday we saw these two stages on our server. Except there was a week wedged between the two stages. And the version that came down wasn’t for the computers we use every day.

First, about our house

FACT We run a honeypot. A honeypot is a bait server left deliberately wide open. We keep it so we can watch who comes and what they do. The story below is not actual damage. It is an observation record.

FACT There are two bait servers. Sensor 01 is a server you can actually get into if you get the password right. The commands typed inside and the files taken are recorded. Sensor 02 is a server whose doors don’t open. It only notes who knocked on which door and how many times. Today’s story comes mostly from Sensor 01.

FACT The names starting with ATK- in this post are aliases we assign to each source. Source IPs are written with the trailing parts hidden. Addresses that served files are written like 143[.]20[.]154[.]42, with the dots wrapped in brackets. It’s notation deliberately broken so that it won’t connect even if you click it by accident. This is called defanging.

A week ago: only a small installer file came

FACT On October 8, a file named wget.sh came down 15 times from an address called 143[.]20[.]154[.]42. wget is a command that fetches files from the internet. .sh means it’s a note with commands written in order (a shell script). Its size was 1,670 bytes. Only one place took it: ATK-713362.

FACT The number of executables stored on Sensor 01 that day was 0. That day’s log said this: “We cannot know what wget.sh was trying to fetch as its next stage.”

In game terms, it was like having downloaded only the installer app and stopping at the ‘additional data’ screen.

Yesterday: three copies of the main feature from the same address

FACT A week later, October 15. This time executables came down from the /bins/ folder at the same address. Three kinds.

Compare the size column with the number from a week ago. bot.arc alone is about 60 times the October 8 wget.sh. It’s exactly the shape of a big main feature arriving after a small installer app.

FACT Adding up the three files gives 44 downloads. The only place that took those 44 is ATK-7E40FB — one place. This alias and the fingerprints (hashes) of the three files are values that appear nowhere in our previous 37 logs. A hash is a unique number calculated from a file’s contents. Change a single character and you get a completely different number. That’s why we use it like a file’s fingerprint.

FACT The three files have two more things in common. First, they are statically linked. That means every part needed to run was bundled into the one file. It runs on its own no matter what is installed on the receiving device. Second, their debug information has been removed (stripped). That means the maker took off the name tags left behind while working. So even if you look inside, it’s hard to read which part does what.

There was no ‘computer’ in the version list

FACT A CPU is a machine’s brain chip. Each kind of chip understands a different language. So a program has to be built separately for each kind of chip. The arc, arm4, arm5 at the end of the file names are exactly those chip kinds. They sit in the same slot as a game’s ‘version per device model’.

FACT An ARC executable has appeared in our past records exactly once. On September 8, as one of a nine-item bundle served by a different address.

INFERRED ARC is a chip that almost never goes into desktops or servers. So it’s more natural to read this file as built to target small devices like routers and set-top boxes. The computer on our desk was never in the version list to begin with.

INFERRED In the empty ‘next stage’ slot from a week ago, an executable from the same address appeared. There was an installer app, and a week later the main feature came. That’s why today we put this address’s continuation at the center.

FACT But there’s something to be careful about. Yesterday, wget.sh came down from this address not even once. We don’t know whether the October 8 wget.sh was really the script that fetches today’s bot.* files. Because the script’s contents are not in our records. It means we could not confirm that the installer app and the main feature are the same game.

We can’t see the person who pressed ‘download’

FACT Here a blank appears. ATK-7E40FB has a name only in the download records. It is not in that day’s list of major sessions. A session means ‘from one entry until exit’. So about this source, we don’t know the following.

• The source IP (not even a masked form is in the records)
• When it came in, and through which door (port)
• Whether it succeeded at logging in
• How many commands it typed and what it was trying to do
• Whether the 44 downloads happened in one visit or were spread across several

FACT There was one SSH client fingerprint with a record of delivering files yesterday (98ddc560…, SSH-2.0-Go, 4 places). But whether this fingerprint is the same source as ATK-7E40FB is not in the records. So we do not connect the two.

The ‘download complete’ record is there on the game screen. But the face of the person who pressed the button is not on screen. Today’s story starts from a download record, not from a person.

The third address that showed up when we unpacked it

FACT Yesterday there were two distribution points visible on the surface (addresses where the files sat): 143[.]20[.]154[.]42 (bot.*) and 176[.]65[.]139[.]40 (wget.sh).

FACT But there was one more. UPX is a tool that compresses an executable to shrink its size. With a compressed file, you can’t see the text inside from the outside. When we unpacked this compression, 12 distribution addresses came out. All of them were under hxxp://31[.]77[.]227[.]121/bins/. The file names were parm, parm5, parm6, parm64, parm7, pm68k, pmips, pmpsl, pppc, psh4, pspc, x86_64. That’s 12 kinds by chip type.

FACT Had we looked only at the surface addresses, this address wouldn’t have had a single line in yesterday’s list. The naming style is different too. The side visible on the surface is bot.chiptype; the side that came out of unpacking is p+chiptype.

INFERRED The fact that the naming conventions differ alone cannot tell us whether the two addresses belong to the same operator or different ones. The only thing they share is the shape of having several ‘versions per device model’ prepared.

The same day, faces we’ve already seen

FACT The five sessions with the densest records on Sensor 01 yesterday all came in over Telnet and succeeded at logging in. Telnet is an old channel for connecting to a distant machine and typing commands. What travels back and forth is not wrapped in encryption. On our server, door 2223 is the Telnet door.

Look at the command column. Two with 559, three with 61. Only two shapes.

FACT The 559-command shape is one we saw five times in the log two days ago. Back then it was also 559 commands and 22 files. The 61-command shape has the same shape as ATK-8FB338 from October 11. Only the source alias is new. The two 559-command sessions took the wget.sh (1,487 bytes) from 176[.]65[.]139[.]40 and an executable for the Renesas SH chip (1,196 bytes). These two files are also fingerprints first recorded two days ago.

INFERRED Even as the sources changed, the 559-command bundle was executed seven times in two days. It’s closer to the shape of the same automated tool running from several already-infected devices than of a person.

FACT There are also two files that all five sessions took. One is a 202-byte shell script. It’s a file we’ve seen almost every day since August 21. The other is a 1-byte file. The size of exactly one character. It came down 181 times yesterday alone.

Laid out in time order, it looks like this. Note that a week sits between the first line and the ‘time unknown’ lines.

1. 2026-10-08 (archive)
   FACT 143[.]20[.]154[.]42/bins/wget.sh (81a7cdbb…, 1,670 bytes) came down 15 times, and the only place that took it is ATK-713362. The number of executables stored on 01 that day is 0.
2. 2026-10-15T01:11:36.827Z ~ 01:13:21.076Z (10:11 KST)
   FACT ATK-5F31BC (133.232.x.x) succeeded at logging in over Telnet. Over 104.25 seconds there were 559 commands and 22 downloads. intents were 4 kinds — execute after download, grant execute permission, file download, indicator removal — with completeness 81 and a TTY recording present.
3. 2026-10-15T01:52:26.484Z ~ 01:54:14.170Z (10:52 KST)
   FACT ATK-A600B8 (123.216.x.x) came in 40 minutes 49.66 seconds after the previous session started. Over 107.69 seconds, 559 commands, 22 downloads, and the same 4 kinds of intents. Both sessions are in the delivered_by of wget.sh (7b8cd695…, 1,487 bytes, 176[.]65[.]139[.]40) and the Renesas SH executable (7c34c76b…, 1,196 bytes).
4. 10/13 comparison
   FACT On 10/13, three different aliases executed the same 559-command bundle five times (79~105 sec). Today's 107.69 seconds is 2.7 seconds longer than that range. The aliases ATK-5F31BC and ATK-A600B8 are not in the archive.
5. 10/13 comparison
   INFERRED Even as the sources changed, the same 559-command bundle was executed seven times in two days. It's closer to the shape of the same automated tool running from other infected devices than of a person.
6. 2026-10-15T08:10:15Z ~ 08:10:43Z (17:10 KST)
   FACT ATK-B34D3D (171.113.x.x) succeeded at logging in over Telnet. Over 28.54 seconds there were 61 commands and 20 downloads. intents were one — indicator removal — with completeness 69.
7. 2026-10-15T11:45:18Z ~ 11:45:38Z (20:45 KST)
   FACT ATK-BBC079 (201.145.x.x) succeeded at logging in over Telnet. Over 20.00 seconds there were 61 commands and 20 downloads, and intents were one — indicator removal.
8. 2026-10-15T11:58:42Z ~ 12:00:07Z (20:58 KST)
   FACT ATK-74E36B (116.72.x.x) succeeded at logging in over Telnet. Over 84.84 seconds there were 61 commands and 20 downloads, and intents were one — indicator removal. The same shape is recorded on 10/11 as ATK-8FB338.
9. whole day
   FACT All 5 major sessions are in the delivered_by of the 202-byte shell script (0c99433c…, recorded repeatedly in the archive since 8/21) and the 1-byte file (01ba4719…, 181 times today).
10. whole day (time unknown)
    FACT hxxp://143[.]20[.]154[.]42/bins/bot.arc (ARC700 32-bit, 100,156 bytes) came down 16 times, bot.arm4 (ARM 32-bit, 66,756 bytes) 16 times, and bot.arm5 (ARM 32-bit, 63,468 bytes) 12 times. All three are statically linked with debug information removed (stripped), and delivered_by for all three files is ATK-7E40FB alone.
11. whole day
    FACT Today, wget.sh did not come down from 143[.]20[.]154[.]42. Whether the 10/8 wget.sh was the script that fetches today's bot.* cannot be confirmed, because the script's contents are not in the brief.
12. whole day
    INFERRED An ARC executable was recorded once in the archive, on 9/8 (one of a nine-item set from a different distribution point). Since it's a CPU almost never found in desktops or servers, it's more natural to read this file as aimed at embedded devices like routers and set-top boxes.
13. whole day
    FACT The same 389-byte SSH public key (a8460f44…) was planted 21 times from 21 different places. The same day, the credential 345gs5662d34:345gs5662d34 was also from 21 places, and the libssh_0.9.6 fingerprint (f555226d…) is also 21 places today.
14. whole day
    INFERRED Because all three values are 21 places, they may be the same group. But the value from cross-checking the source lists against each other is not in the JSON, so there is no basis beyond the numbers matching.

Every line with a timestamp is a session of a shape we’ve already seen. The three newly appeared bot.* files are precisely the ones with no timestamp. The blank mentioned earlier shows up in the table too.

The number 21, three times

FACT Yesterday, one and the same SSH public key was planted 21 times from 21 different places. SSH is a remote-access channel similar to Telnet. The difference is that it wraps the contents in encryption. A public key is a key used instead of a password. If you write this key into the server’s authorized_keys file (the list of allowed keys), the owner of that key can get in without a password. This key’s size is 389 bytes. 389 English characters — the length of one short paragraph.

FACT The same day, a combination with both the ID and the password being 345gs5662d34 also came from 21 places. The client fingerprint called libssh_0.9.6 is also 21 places.

INFERRED Since all three numbers are 21, they may be one group. But the basis is only that the numbers match. There is no value from matching the lists of the 21 sources against each other. On top of that, libssh_0.9.6 is a value that unrelated people using the same program also have.

Values to write down

These are values the defending side can put in a blocklist. Click a value to copy it. Addresses are left in their defanged state.

The top six lines are today’s new values. The bottom four lines are values that should already be in your blocklist. They appeared two days ago, and in August too.

Yesterday’s full day

FACT These are Sensor 01’s numbers for the day.

FACT There are also daily totals with commands sorted by ‘what they were trying to do’. Grant execute permission 2,298, file download 291, execute after download 291, system reconnaissance 92, indicator removal 32, planting an SSH key 22, impairing defenses 1. ‘Grant execute permission’ is the act of putting an ‘it’s okay to run this’ mark on a received file. On Linux, without that mark you cannot start a file.

The house whose doors don’t open: the screen-sharing door broke the record again

FACT On Sensor 02, VNC contacts came to 84,222. VNC is a screen-sharing channel that lets you see and operate another computer’s screen as-is. A day is 86,400 seconds, so someone knocked on this door almost once a second. That’s 9,850 more than the record of 74,372 set two days ago (October 13).

FACT Sources came to 436 places, 2 fewer than two days ago (438 places). Instead, the average number of knocks per place rose from 169.8 to 193.2. Of Sensor 02’s 85,729 total contacts, VNC accounts for 98.2%.

FACT The version numbers negotiated during a VNC connection also changed. 003.008 was 62,224 times and 003.003 was 21,746 times. 003.008’s share came down from 83.2% two days ago to 74.1%.

FACT RDP, the remote desktop channel, went the other way and fell. 611 times from 111 places. That’s less than a fifth of the 3,323 from two days ago. Cases where hello was written in the name-tag field (the cookie) attached to the first RDP connection request nearly vanished, from 2,747 two days ago to 16. By contrast, cases where <ip> was written came to 413 times, almost the same as two days ago (412).

FACT On the SMB side, the protocol names the other party offered were mostly very old versions (the SMB1 era). New version names appeared only 2 times. This server’s doors don’t open. So there are no records of login successes, commands, or passwords to begin with.

Are you using this password?

FACT Of the ID/password combinations that came into Sensor 01 yesterday, we reproduce only those that came from 3 or more different sources.

FACT admin / admin appeared 330 times from 22 places. That works out to each place trying the same combination about 15 times on average. The 345gs5662d34 combination, by contrast, is 21 times from 21 places. Exactly once per place.

FACT Combinations that appeared from fewer than 3 places number 197 kinds. Since they could be actually leaked accounts, we don’t carry the values and only state the count. It’s 6.1% of the past maximum (October 8, 3,212 kinds).

Mapping the methods to the international classification table

Matching the methods the attackers used to the numbers in the international classification table called MITRE ATT&CK gives this. Click an ID to see the original description.

• T1110.001Brute Force: Password GuessingINFERRED
• T1078Valid AccountsINFERRED
• T1105Ingress Tool TransferINFERRED
• T1222.002File and Directory Permissions Modification: Linux and MacINFERRED
• T1059.004Command and Scripting Interpreter: Unix ShellINFERRED
• T1070Indicator RemovalINFERRED
• T1098.004Account Manipulation: SSH Authorized KeysINFERRED
• T1027.002Obfuscated Files or Information: Software PackingINFERRED

Today’s lead role is T1105 (bringing in tools from outside). Both the installer app and the main feature coming down fall under it. The last line, T1027.002, is the UPX compression we saw earlier. There’s a reason they are all ‘INFERRED’. It’s because we attached the results of classifying the commands to the table ourselves.

There has been a shape like this before

INFERRED The Mirai botnet of 2016 had a similar shape. A botnet is a group of many infected devices driven all at once by one person. Mirai got into IoT devices (small devices connected to the internet) using Telnet’s factory-default passwords. Then it sent down executables for various chip types. Telnet login → bring in a file → attach the execute mark → execute. And the structure matches right down to files for ARC, ARM, and Renesas SH chips — not server chips — being prepared per chip. The root / xc3511 in the table above is known to be a combination found in the default password list of the published Mirai source.

INFERRED That said, we do not conclude it’s the Mirai family. After the source was published, a great many variants came out. Malware classification tags for yesterday’s files are also not in our records. (For reference: US CISA alert TA16-288A, USENIX Security 2017 paper ‘Understanding the Mirai Botnet’)

So what should you do

A game’s main feature only installs if the device permits the ‘download’. A router is the same. The six items below are about where to cut off that permission. The likelihood of compromise is carried over exactly as the brief judged it.

1. Using factory-shipped accounts and easy passwords as-is · high likelihood of compromise INFERRED admin / admin appeared 330 times from 22 places. All five major sessions yesterday succeeded at logging in. If the factory account is still in place, the door opens within the first bundle of attempts. What follows is the sequence where an executable for the device comes down and it becomes one more machine in a botnet.

2. Using only password login and not key-based login · high likelihood of compromise INFERRED ‘Planting an SSH key’ came 22 times, and the same public key came from 21 places. If someone gets in with a password and plants their own key, even if you change the password they get back in with the key. Unless you open the authorized_keys file yourself, it goes unnoticed.

3. Leaving an administration door open directly to the internet · high likelihood of compromise INFERRED Over one day, 175 places came to Sensor 01 and 695 places to Sensor 02. That means an open administration door gets found within a day. If it’s a channel like Telnet that doesn’t wrap the contents in encryption, the risk of the password leaking rises along with it.

4. No reconnection limits (fail2ban, rate limit) · medium likelihood of compromise INFERRED The style where one place knocks 15 times, like admin / admin, is blocked by count limits. But the style where one place knocks exactly once, like 345gs5662d34, doesn’t trip per-source limits. That’s why it’s ‘medium’. It only works if used together with removing factory accounts.

5. Not blocking the device’s outbound connections · high likelihood of compromise INFERRED Every stage after login was the device going out to an outside address to fetch a file. Today’s ‘downloading additional data’ is exactly that. If the device couldn’t go out to just any outside address, the executable ingress we saw yesterday would have failed.

6. Not collecting records off the device (no log collection, no EDR) · high likelihood of compromise INFERRED Indicator removal commands appeared 32 times in a day. They were present in all five major sessions. If the records exist only inside the device, then after they’re erased you cannot reconstruct who took what and when. EDR is a security program that watches for suspicious behavior inside a device and reports it separately.

What We Don’t Know

This section is the most important part of this log. Because it is the boundary line of everything said above.

About the side that took the main feature

• [Cannot confirm] ATK-7E40FB is not in the list of major sessions. So we don’t know the connection time, the channel, the door number, whether login succeeded, the intent classification, or the command count. We also don’t know whether the 44 downloads were one visit or spread across several.
• [Cannot confirm] For the only SSH fingerprint with a file-delivery record yesterday (98ddc560…, SSH-2.0-Go, 4 places yesterday, 16 places cumulative), which files it delivered is not in the records. The five major sessions were Telnet, so their fingerprint field is empty.

About the relationship between the installer app and the main feature

• [Cannot confirm] We don’t know whether the October 8 wget.sh (same address, 81a7cdbb…) was the script that fetches today’s bot.* files. The script’s contents are not in the brief. We also don’t know what relationship October 8’s ATK-713362 and yesterday’s ATK-7E40FB have.
• [Cannot confirm] We don’t know which malware family bot.arc, bot.arm4, and bot.arm5 belong to. MalwareBazaar classification tags are not in the records.
• [Cannot confirm] There is no basis for judging whether 143[.]20[.]154[.]42 (bot.*), 31[.]77[.]227[.]121 (the p+chiptype inside the compression), and 176[.]65[.]139[.]40 (wget.sh) are the same operator.

About the sessions we’ve already seen

• [Cannot confirm] For the five major sessions, we confirmed only that screen recordings (TTY) exist. The contents are not in the brief. The intent classification list does not carry the order of execution.
• [Cannot confirm] The public key, the 345gs5662d34 account, and the libssh fingerprint all being 21 places is only the fact that the numbers match. Whether the source lists are the same cannot be cross-checked.

About addresses and reporting

• [Cannot confirm] In the address list within the records there is 1 Discord webhook address. A webhook is an address that automatically sends messages into a messenger room. We don’t know which file or session it came from, or what it was used for. Since a secret token is contained inside the address, we do not carry the original.
• [Cannot confirm] The distribution points seen yesterday were reported to C-TAS (the Korea Internet & Security Agency’s threat information sharing system). However, only transmission success was confirmed. Whether it was actually registered with KISA has to be checked separately.
• [For reference] The vulnerability statistics carried in the brief (7,689 CVEs, 414 KEV entries with confirmed real-world exploitation, 101 confirmed used in ransomware. Top 5: FortiOS CVE-2018-13379, Confluence CVE-2022-26134, Log4j2 CVE-2021-44228, NetScaler CVE-2023-4966, PAN-OS CVE-2024-3400) are background information from a KISA security notice. They are not directly connected to yesterday’s honeypot observations.

About the nature of the numbers

• [Cannot confirm] The 870 places from adding the two sensors’ sources together is a maximum. Since we don’t know how many sources came to both sensors, the actual figure could be lower.
• [Cannot confirm] Sensor 02’s top-sources list has no breakdown of which door was knocked on. So we cannot establish that the top 12 places knocked on VNC. Whether the contact counts in the top list and the total contact count are in the same unit is also not stated.
• [Cannot confirm] Whether one source moved around several doors was not calculated, because there are no per-source records. The 446 contacts at the ADB door have no detailed record of what came in. The number of files stored from there is 0.

What we don’t judge at all

• Carrier/organization (ASN, ISP): We have no relevant database. We do not infer it.
• Geographic location: Unknown for the same reason. An IP’s geographic information cannot serve as a basis for identifying who did it in the first place. This post does not name any country, company, or individual as an attacker.
• Whether VPN, Tor, or cloud: We have no means to determine it.
• VirusTotal: Not integrated. For file classification we use MalwareBazaar tags.
• Client string (User-Agent): Neither sensor is a web (HTTP) server. Sensor 01 is SSH and Telnet; Sensor 02 is SMB, RDP, VNC, MSSQL, LDAP, and ADB.
• Linking to vulnerability numbers (CVE): SSH and Telnet attacks mostly do not reference a specific vulnerability. Sensor 02 is the same, since it’s at the stage of negotiating connection protocols.

A week ago one small installer file came into our server. That day it stopped there. Yesterday the main feature came down from the same address. The size was 60 times larger, and there were three versions. But all three were not for the computer on our desk. They were for small devices left switched on in a corner of the living room, like routers or set-top boxes.

With a game, ‘download additional data’ is a button I press. With a router it’s different. If the factory password is still in place and the path out is open, someone else presses that button. So there are two things to do. Change the router’s admin password today. And turn off remote management features you don’t use.

The observation date is October 15, 2026 (one day in UTC), and this post was written up the following day. The comparison targets are the October 8, October 11, and October 13 logs. Source IPs were carried over exactly in the masked form given in the brief (133.232.x.x, 123.216.x.x, 171.113.x.x, 201.145.x.x, 116.72.x.x) and were not restored. ATK-7E40FB was not written down because not even a masked IP is in the records. Addresses were kept in a defanged state (hxxp://, [.]) so they won’t connect by accident. For credentials, we quoted verbatim only the 11 combinations observed from 3 or more different IPs. For the remaining 197 kinds we state only the count and do not write the values. 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.