559 Lines of a Checklist, Five Times Over — and Two of Them Read It Side by Side

Picture the day the water purifier technician comes by your apartment. In the technician’s hand is a single checklist. Check the filter, run some water, swap the parts, get a signature. The order is the same at every home. So roughly how many minutes it will take is set in advance, too.

The nice thing about a checklist is that whoever carries it does the job the same way. But you can also think about this in reverse. What if three different technicians showed up and finished the job without a single line of difference between them, in nearly the same amount of time? What worked in that home was the checklist more than the person.

Yesterday something like that happened on our server. The difference is that this checklist was 559 lines long. And nobody called a technician.

First, about our house

FACT We run a honeypot. A honeypot is a decoy server left deliberately open and flimsy. We keep it around to watch who comes by and what they do. What follows is an observation record, not an account of actual damage.

FACT There are two decoy servers. The first one (sensor 01) is a house with an easy numeric code set on the front door. If the code matches, you really can come in, and what you do inside gets recorded. The second one (sensor 02) is a house whose door never opens. It only writes down who touched which door and how many times. Today’s story comes mostly from the first house.

FACT The technicians who came by yesterday all arrived over Telnet. Telnet is a very old passage for connecting to a distant computer and typing commands. What passes back and forth is not wrapped in encryption. It is often still present on small devices like routers and CCTV cameras. At our house, door number 2223 is the Telnet door. “Door number” here is what’s called a port.

Five times, not one line different

FACT Among yesterday’s successful logins at the first house, five sessions stood out. A session means “from coming in once to leaving.” Here are the numbers for the five.

Scan the commands column and the files column from top to bottom. All five rows are the same.

FACT Names starting with ATK- are aliases we attach to each source. The source IPs are written with the back portion masked. There are three sources. Among them, ATK-447569 came three times.

FACT Time spent ranges from 79 to 105 seconds. Within that, 559 commands were typed. That is five to seven lines per second. The 22 files came down at a rate of about one every 4 seconds. The score showing how dense the record is (completeness) was 81 for all five — no session yesterday scored higher.

INFERRED A person cannot type seven lines per second on a keyboard. On top of that, three sources repeated 559 lines without a single line of difference. It is natural to read this as a machine reading straight down the same checklist. This sort of thing is called an automation script.

What was written on the checklist

FACT We do not have the original text of the 559 lines. What we do have is a classification of what the commands were “trying to do.” All five sessions matched on the same four.

• File download. Bringing in parts from an outside warehouse.
• Granting execute permission. On Linux, you cannot run a file you just received as-is. You have to attach a marking that says “this file may be run.” This is fitting the part with a power switch.
• Execute after download. Flipping the switch on the part you brought in.
• Deleting traces. Erasing your own line from the visitor log at the front door.

INFERRED The four are a list, not an order. “Bring in → attach switch → turn on → erase” is plausible as a sequence, but the record does not tell us the order. And one thing is missing. A mechanism for getting back in next time (persistence) was not present in these five sessions. For example, something like quietly hanging up a key that lets you in without a password. So this checklist ends at “install, tidy up, and leave.”

4:50 PM, two technicians in the same house

FACT The first session was at 12:10 PM Korea time, ATK-00D1AA. The next was 4 hours 38 minutes later, at 4:49 PM, ATK-447569. From here, the activity piled up over 4 minutes and 34 seconds.

FACT ATK-447569 finished its first job and left. 0.397 seconds later it came back in. And 0.886 seconds after that, a different source, ATK-225FF4, came in. The two sources differ starting from the first two segments of their IPs (181.233 · 180.190). From this point the two sessions ran side by side for 87–89 seconds. It amounts to two technicians entering the same house less than a second apart and reading the same checklist at the same time.

FACT ATK-225FF4 left first, and about a second later ATK-447569 left too. Then 0.405 seconds later ATK-447569 came in for a third time. Over 4 minutes 34 seconds, this one alias typed 1,677 commands (559×3).

INFERRED It left and came right back, and did the same work simultaneously with another source. This looks like automated repetition rather than a person. But there is no basis for saying the two sources are the same operator. The same checklist can be copied and used by many people. We go only as far as “the same tool.”

FACT There was also no clue available for checking whether they belong to the same batch. With SSH connections, you can take a “fingerprint” (hassh) of the connecting program and group matching tools together. But with Telnet that fingerprint is not produced. The fingerprint field is empty for all three sources.

Laid out in time order

Times are in Coordinated Universal Time (UTC). For Korea time, add 9 hours. Look at the digits after the decimal point around 07:50. Less than a second passes between one session ending and the next starting.

1. 03:10:48.856Z (KST 12:10:48)
   FACT ATK-00D1AA(103.40.x.x) Telnet session starts, login succeeds
2. 03:12:17.091Z (KST 12:12:17)
   FACT ATK-00D1AA session ends. 559 commands over 88.23 seconds, 22 downloads. 4 intent types, input record (TTY) present
3. 07:49:01.508Z (KST 16:49:01)
   FACT ATK-447569(181.233.x.x) first session starts. 4 hours 38 minutes 12.65 seconds after ATK-00D1AA started
4. 07:50:46.241Z (KST 16:50:46)
   FACT ATK-447569 first session ends (104.73 seconds, 559 commands, 22 downloads)
5. 07:50:46.638Z (KST 16:50:46)
   FACT 0.397 seconds later, ATK-447569 second session starts
6. 07:50:47.524Z (KST 16:50:47)
   FACT 0.886 seconds after that, a different source ATK-225FF4(180.190.x.x) starts a session. From this point the two sessions ran concurrently
7. 07:52:14.923Z (KST 16:52:14)
   FACT ATK-225FF4 ends (87.40 seconds, 559 commands, 22 downloads)
8. 07:52:15.930Z (KST 16:52:15)
   FACT ATK-447569 second session ends (89.29 seconds)
9. 07:52:16.335Z (KST 16:52:16)
   FACT 0.405 seconds later, ATK-447569 third session starts
10. 07:53:35.603Z (KST 16:53:35)
    FACT ATK-447569 third session ends (79.27 seconds). This alias came in three times over 4 minutes 34 seconds and typed 1,677 commands (559×3)
11. —
    FACT The commands from the five sessions total 2,795, which is 6.7% of yesterday's 41,776 total commands on sensor 01
12. —
    INFERRED Judging by the 0.4-second reconnect intervals and the concurrent execution from a different source, this looks like automated repetition rather than a person typing. That said, there is no basis for saying the two sources are the same operating party

FACT Please look at the second-to-last line as well. 1 out of every 15 commands typed at the first house all day yesterday came from these five sessions. Out of 4,180 sessions in a day, five accounted for that much.

Where did the parts come from — same street, fourth warehouse

FACT Among the files the technicians pulled down is an install script called wget.sh. It is 1,487 bytes. That’s 1,487 characters in English letters — about seven pages of manuscript paper. The address that served this script is hxxp://176[.]65[.]139[.]40/wget.sh. It was downloaded from this address 60 times yesterday.

FACT Internet addresses that share their first three segments are grouped into the same “range.” Like house numbers on the same street. This is the fourth address on the 176.65.139 street to serve files.

FACT Put one warehouse on a blocklist, and another warehouse on the same street opens its doors. Our records have been writing down that pattern for two months now.

INFERRED That gives grounds for considering watching at the street (range) level rather than blocking one address at a time. That said, there is no basis for concluding that being on the same street means the same owner.

FACT This newly appeared address was reported to C-TAS. C-TAS is the threat information sharing system run by the Korea Internet & Security Agency (KISA). What’s confirmed on our end goes only as far as “transmission succeeded.” Whether it was actually registered with KISA has to be checked separately.

Parts that aren’t for servers

FACT Among the files that came in alongside, two executables stand out. One is for a CPU called Renesas SH. At 1,196 bytes, it’s about six pages of manuscript paper. The other is for a CPU called MIPS, at 160 bytes. That’s a size that can’t even fill one page of manuscript paper. The MIPS file was sent only by ATK-447569.

FACT The CPU is the computer’s brain. An executable has to match the type of CPU to run. Renesas SH and MIPS belong to families found in small devices like routers and set-top boxes rather than ordinary servers or PCs. It’s similar to a water purifier technician showing up carrying boiler parts instead of purifier parts.

INFERRED It looks like they didn’t check what kind of machine this house is and just brought along parts for several kinds of machines. But this too is only an interpretation. What happened inside the 559 lines, we do not know, because we don’t have the original text.

FACT One piece of background to add. There is a compressed file that has shown up repeatedly since August 16. This file only reveals the address written inside once it’s unpacked. Unpacked, it yields 12 files with CPU names attached under hxxp://31[.]77[.]227[.]121/bins/. Among them are the Renesas SH family (psh4) and the MIPS family (pmips · pmpsl). What is factual goes only as far as the CPU types overlapping with yesterday’s executables. There is no basis for saying yesterday’s files came from that list.

Values to write down

Reproduced as-is so you can use them for defense. Values like these are called IOCs (indicators of compromise). They are markers that say “if you see this value, be suspicious.” sha256 is a unique number computed from the entire contents of a file. Change one character and you get a completely different value. Tap a value to copy it. Look for ‘first’ / ‘repeat’ at the end of each description.

FACT The top four lines are values that appeared for the first time yesterday; the bottom two are values we’ve seen before. The sender lists include aliases beyond today’s five sessions, such as ATK-F3C363 · ATK-706401 · ATK-A72B17. That means the set of houses that pulled down the same parts is wider than the five sessions.

All of yesterday

Widening the view, here is the first house’s day. The “for comparison” column on the right makes the numbers tangible.

FACT Of the 41,776 commands, 2,795 belong to the five sessions we looked at today. The per-port total and the per-protocol total both come to 4,177, but total sessions is 4,180. Three are unaccounted for. The reason is noted below under “What We Don’t Know.”

The house that doesn’t open — the screen-sharing door rewrote the record

FACT The second house’s door doesn’t open. So all that remains is who touched it and how many times. Yesterday the VNC door stood out. VNC is a screen-sharing feature that puts a distant computer’s screen on your own screen so you can operate it. Compare the “per source” figures.

FACT 74,372 VNC contacts works out to about one every 1.2 seconds. Both the 438 sources and the contact count are the largest values across the 26 briefs since August 26. The previous maximums were 65,487 contacts (9/10) and 416 sources (9/8). The average per source is 169.8.

FACT The version string presented when connecting to VNC changed too. 003.008 appeared 61,601 times, 003.003 12,478 times. The 003.008 share was 83.2%, down from 98.7% on October 11. Looking at 003.003 alone, it grew 19.0-fold in two days.

FACT The tags (cookies) attached to Remote Desktop (RDP) door contacts were ‘hello’ 2,747 times, '<ip>' 412 times, and ‘zgrab’ once. The sender can write anything they like into that tag, so we don’t group identities on that alone. At the SMB door, only names from the era of a very old method (SMB1) came in.

INFERRED This record is not a story about intrusion. We can speak only to the scale and shape of the door-touching. Why it increased, we do not know.

Are you using these numbers?

FACT Of the IDs and passwords tried at the first house’s front door yesterday, 10 types are reproduced verbatim in this post. There is one criterion. We write down only combinations tried identically from three or more distinct sources. If many places are carrying around the same number, it’s likely a factory default belonging to no one. Look at the third column.

FACT admin/admin came in 311 times total from 45 sources. That’s about 7 times per source. The bottom row is the case where the password was left entirely blank.

FACT Combinations that fall short of this criterion are only counted. Yesterday there were 2,633 types. They could have leaked from someone’s real account, so we do not write down the values. That works out to roughly 260 unwritten combinations for every one in the table. The highest on record was 3,212 types on October 8.

FACT We do not know which combination today’s five sessions used to open the door. The information linking a connection to a password is not in the record.

Mapping the attacker’s techniques to the international classification

MITRE ATT&CK is an international list that assigns a number to each attack technique. Matching yesterday’s observed behavior to those numbers gives this. Tap an ID to go to the original description.

• T1078Valid Accounts — 5 successful Telnet loginsINFERRED
• T1110.001Brute Force: Password Guessing — 3,278 login attempts on sensor 01, admin/admin tried from 45 sourcesINFERRED
• T1105Ingress Tool Transfer — 22 downloads per session, wget.sh brought inINFERRED
• T1222.002File and Directory Permissions Modification: Linux — intent 'granting execute permission'INFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — intent 'execute after download', shell script brought inINFERRED
• T1070Indicator Removal — intent 'deleting traces' (the specific sub-technique can't be pinned down without the original commands)INFERRED

FACT All six lines are [INFERRED]. What we hold goes as far as behavior classifications and counts; we don’t have the original commands. The middle three lines (T1105 · T1222.002 · T1059.004) correspond to the checklist’s bring in the part → attach the switch → turn it on. The bottom one, T1070, is erasing the visitor log.

There has been a shape like this before

FACT Mirai botnet (2016). A group that got into IoT devices using default Telnet passwords and scattered executables for several CPUs. IoT devices means small internet-connected gadgets like routers and CCTV cameras. A botnet is a group of infected devices controlled all at once. root/vizxv in today’s table is known to be a combination in the default password list of Mirai’s public source. (Source types: government alert US-CERT/CISA Alert TA16-288A · academic paper USENIX Security 2017 ‘Understanding the Mirai Botnet’)

INFERRED Telnet login succeeds → files brought in from outside → execute permission granted → executed. And executables for small-device CPUs (Renesas SH · MIPS) rather than servers. That skeleton is the same. But we are not ruling this to be the Mirai family. There have been many derivatives since the source was made public. The malware classification tags (MalwareBazaar) for yesterday’s files are also not in our brief.

So what should you do

Going back to the checklist story, what to do is simple. Keep uninvited technicians from getting in. If they do get in, keep them from bringing parts in. And keep a copy of the logbook outside the house, too. Here are the six items the brief singled out, in order.

FACT 1. Default accounts and easy passwords left as-is · high likelihood of compromise All five of today’s sessions logged in successfully. On the same day, admin/admin came in 311 times from 45 sources, root/12345 from 7 sources, and root/vizxv from 3 sources.

INFERRED The moment a login succeeds, within 1 minute 30 seconds 22 outside files come in, switches get attached, and they get turned on. That device ends up taking orders from someone else. That said, we do not know which combination the five sessions came in with. The connection to the combinations above is circumstantial only.

FACT 2. An administrative door (Telnet) left open directly to the internet · high likelihood of compromise 1,266 sessions came to the Telnet door (2223) yesterday. All five of today’s sessions were Telnet too.

INFERRED Telnet has no encryption and no key-based authentication. Match one password and you’re inside. Then the four steps we saw today happen all over again. If there’s a ‘Telnet’ item on your router or camera settings screen, it’s best to turn it off.

FACT 3. Password-only login with no key-based method (on the SSH side) · medium likelihood of compromise Separate from today’s five sessions, this is from the SSH door’s records. There were 2,911 SSH sessions and 17 behaviors classified as ‘planting an SSH key.’ The same public key file (a8460f44…) was downloaded 15 times by 15 aliases.

INFERRED Planting an SSH key is quietly hanging a key that lets you in without a password at the front door. The server lets in anyone whose key is listed in authorized_keys (the list of permitted keys). Once this is done, they can get back in later even if you change the password.

FACT 4. No reconnection limits (fail2ban · rate limit) · high likelihood of compromise ATK-447569 came back in three times over 4 minutes 34 seconds, at intervals of 0.397 and 0.405 seconds. ATK-225FF4 came in alongside 0.886 seconds later. Nothing restricted them at all.

INFERRED fail2ban is a tool that briefly blocks a source that comes too often in a short span. Without something like this, the same installation repeats at the same house over and over. In checklist terms, it’s the rule that “if a technician who just left rings the bell again a second later, you don’t open the door.”

FACT 5. Outbound connections from devices not blocked · high likelihood of compromise The five sessions each pulled down 22 files. From the wget.sh address alone there were 60 downloads. For the whole day, 110 ‘file download’ and 96 ‘execute after download’ behaviors were classified.

INFERRED The device fetched parts directly from an outside warehouse. Had it been set up to connect only to designated suppliers (an allowlist), the flow would have been cut at the bring-in-the-part step. No matter how long the checklist is, without parts you can’t install.

FACT 6. Records not collected outside (no log collection, no EDR) · medium likelihood of compromise All five sessions included ‘deleting traces.’ For the whole day there were 78. Because ours is a decoy server, an input record (TTY) was kept separately.

INFERRED EDR is a monitoring program that records and alerts on suspicious movement inside a computer. If the visitor log exists only inside the house, it’s over the moment it’s erased. You can’t trace back when someone brought in what. Records have to be sent outside the device in real time to survive.

We also made a 60-second video about the same day. The video focuses on the 0.4 seconds in which ATK-447569 came right back after leaving. This post unfolds why those five sessions look like the same checklist, and where the parts came from.

What We Don’t Know

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

About the five sessions

• [Cannot confirm] We do not know which ID and password the five sessions came in with. The connection to combinations like admin/admin is circumstantial only.
• [Cannot confirm] We do not have the actual contents of the 559 lines. We have only the 4 behavior classifications. We also don’t know how many of the 559 were classified.
• [Cannot confirm] We cannot break down which files make up the 22 pulled in each session. The ‘sender’ lists have other aliases’ shares mixed in (the 1-byte file’s 1,190 times, etc.).
• [Cannot confirm] We do not know why ATK-447569 and ATK-225FF4 did the same thing at the same time. There is circumstantial evidence of the same tool, but no basis for the same organization.

About the parts brought in

• [Cannot confirm] We cannot confirm what wget.sh (1,487 bytes) fetches as its next step, because we don’t have its contents.
• [INFERRED] The Renesas SH executable (7c34c76b…) is small at 1,196 bytes. It looks like a small stage that fetches another file, but we have not verified this.
• [INFERRED] The 160-byte MIPS file (48f9b3ea…) has a section header offset (1960) that exceeds the file size. It may be a file truncated in transit, but we have not confirmed this.
• [Cannot confirm] The files’ MalwareBazaar tags are not in the brief, so we have not attached a malware family name.

About the addresses and the report

• [Cannot confirm] We do not know whether 176[.]65[.]139[.]40 and the earlier .196 · .202 · .206 are the same operator. Only the range is the same.
• [Cannot confirm] The C-TAS report is confirmed only as far as transmission success. Whether it was actually registered with KISA, we still do not know.
• [Cannot confirm] ‘First-seen value’ is the result of searching past briefs by text for the hash, alias, and address. We could not compare against days with no brief (9/9 · 9/11, etc.).

About the nature of the numbers

• [Data inconsistency] The per-port total (4,177) and the per-protocol total (4,177) are off by 3 from the total sessions (4,180). We do not know the cause.
• [Cannot confirm] We do not know why VNC contacts hit a maximum, or why the 003.003 string increased again. We cannot tell whether the other side’s tooling changed or something changed on our sensor side.
• [Cannot confirm] It is not stated whether the contact counts in the top-sources list and the total session count are in the same unit, so we did not compute a ratio.
• [Cannot confirm] The 441 contacts at the ADB door have no detailed record of what came in, so we did not cover them today.

What we do not judge at all

• Carrier / organization (ASN · ISP): We have no associated database. We do not estimate.
• Geographic location: 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 of determining this.
• VirusTotal: Not integrated. For file classification we use MalwareBazaar tags.
• Client program string (User-Agent): Neither server is a web (HTTP) server. The first is SSH · Telnet, the second SMB · RDP · VNC · MSSQL · LDAP · ADB.
• Vulnerability number (CVE) linkage: SSH and Telnet attacks mostly do not reference a specific vulnerability. The second server is at the stage of matching connection protocols, so the same applies.

Yesterday, uninvited technicians came by our house five times. There were three sources. But there was one checklist. They read 559 lines without changing a single one. They brought in 22 parts, attached the switches, turned them on, erased the visitor log, and left in a minute and a half. At 4:50 PM, two technicians came in less than a second apart and read the same checklist side by side. The warehouse that served the parts was the fourth one to open its doors on the same street.

The side holding the checklist doesn’t ask who owns the house. It only looks at whether the front door code is still the factory setting. So the way to stop it is as simple as the checklist. Close the Telnet door if you don’t use it. Change factory passwords. Keep the device from fetching parts from just anywhere. And keep a copy of the logbook outside the house.

The observation date is October 13, 2026 (a single day, UTC), and this post was written up the following day. Source IPs are reproduced in the masked form given in the brief (103.40.x.x, 181.233.x.x, 180.190.x.x) and were not restored. Addresses are kept defanged (hxxp://, [.]) so they aren’t accessed by accident. For credentials, only the 10 combinations repeatedly observed from 3 or more distinct IPs are quoted verbatim. For the remaining 2,633 types, we state only the count and do not write down the values. Items we have no means of measuring — carrier, nationality, VPN status — are left as “we don’t know” rather than estimated.