Five Visits, Five Plugs — and None of Them Fit a Server's Socket

Say you travel abroad and walk into your hotel room. You go to plug your phone charger into the wall, and it won’t go in. Instead of two round holes, there are three flat ones. The electricity is flowing just the same. But if the plug doesn’t match the shape, you can’t use it.

Computer programs work much the same way. A computer’s brain is called the CPU. There are several kinds of CPU, and an executable file is built for one of them. It’s like a plug that only turns in a socket of the matching shape.

Yesterday, someone came into our server five times in under nine minutes. Each time they came in, they fetched a plug from outside. But that plug was not the server’s shape. Today’s story is about the shape of that plug.

Our socket is bait we left open on purpose

FACT We run a honeypot. A honeypot is a bait server left deliberately insecure and open. Its purpose is to watch who comes and what they do. It amounts to putting a security camera next to a socket we’ve advertised as free for anyone to use. What follows is not an account of actual damage but a record of observation.

FACT There are two servers. The first (sensor 01) can actually be entered if the password matches. It even records what the person who got in did. The second (sensor 02) never opens. It only notes who knocked on which door and how many times. Today’s protagonist came out of the first server.

Five times in nine minutes

FACT Let’s start with the numbers. A source called ATK-3ED4D8 successfully logged in over SSH. SSH is a channel for entering a distant computer and typing commands. What travels back and forth is wrapped in encryption. Names starting with ATK- are aliases we assign to each source. The actual address is written with the trailing digits hidden, like 45.198.x.x.

Lining up the five visits side by side gives this. Look at the “Gap from previous” column on the far right.

FACT From the start of the first visit to the end of the last is 8 minutes 37 seconds. That works out to coming back in about once every 1 minute 43 seconds on average. The second visit came just 17.8 seconds after the first one ended. About the time it takes to shut the door, catch your breath, and open it again.

FACT All five times, the commands were exactly two lines. Ten lines in total. Yet 24 files were fetched. That amounts to more than two files arriving for every line typed. Adding up the time spent inside across all five visits gives about 3 minutes 46 seconds. Out of 8 minutes 37 seconds, they were inside for less than half of it.

FACT All five times, the same three behaviors were classified: file download, granting execute permission, and execution after download. “Granting execute permission” means attaching a mark to a received file that says “this is a program it’s okay to run.” It’s the step that makes the fetched plug able to go into the socket.

INFERRED What we don’t know is in what order these three happened. The classification record does not capture order. It’s tempting to write “fetched → marked → executed.” But what we can say stops at “all three were observed.”

The shape of the plug they brought

FACT The files this source brought in yesterday are of three kinds.

FACT That’s a lot of unfamiliar terms, so let’s take them one at a time.

• A Bash script is a note with several lines of commands written down in a single file. 1,872 bytes means 1,872 English characters. About half a page of a notebook.
• ARM 32-bit is a kind of CPU. This is exactly what we mean by the shape of the plug. The brief classified both executables as “for devices, not for servers.”
• Statically linked means all the needed parts are packed inside the file itself. A plug with the adapter built in as one piece.
• Dynamically linked is the opposite — it borrows parts from inside the device it’s plugged into. 0uparm5 was built to borrow a part called uClibc.
• Both executables are stripped. That means the guidance information attached inside the program, like name tags, has been removed.

INFERRED uClibc is a bundle of parts commonly used on small embedded devices. An embedded device means a small computer that does only one job, like a router or an internet camera. So this plug appears to have been built to fit the socket of a home router or camera rather than a server’s.

FACT Let’s look at the sizes too. 0uparm is 55,804 bytes, about 55 kilobytes. A single smartphone photo is usually several megabytes, so this is dozens of times smaller. It’s this small because it’s a program that has to fit into a small device.

FACT But adding up the records for all three files gives 49 times. The files fetched across the five visits above numbered 24. That leaves 25 unaccounted for.

INFERRED From that gap, it appears this source came in more times than the five we focused on. How many more times, and when, is not in the record.

The note and the plugs came from different shops

FACT The files came from two places. A place that hands files down like this is called a distribution host. The note (ssh) came from hxxp://45[.]198[.]224[.]34/ssh. The two plugs came from hxxp://151[.]243[.]24[.]225/. The [.] in the middle of the address and the hxxp at the front are deliberately broken notation so that an accidental click won’t connect.

INFERRED The note shop and the plug shop are different. So this looks like a two-stage structure where “the note called in the plugs.” Like receiving the instruction sheet first, then buying the plug from the shop named on the sheet. But the contents of the note and the order of the downloads are not in the record. We could not confirm it.

FACT There’s one more thing that stands out. The incoming address 45.198.x.x and the note shop’s address 45[.]198[.]224[.]34 share the same first two octets. In our records, this pattern is the fourth, following September 7, September 8, and September 15.

INFERRED Matching leading digits does not mean the same building. It’s similar to houses in the same neighborhood sharing the leading digits of their street number. On top of that, the incoming address has its trailing digits hidden. Whether it’s the same computer, or a place run by the same person, is something we cannot judge, and do not judge.

A common brand name, but circuitry we’ve never seen

FACT A program connecting over SSH announces its own name on the way in. This source announced itself as SSH-2.0-libssh_0.9.6. libssh is a bundle of parts you pull in when building an SSH client program. This name is common. Just yesterday there was a large cluster (f555226d…) of 12 IPs using the same name, 684 cumulatively to date.

FACT But there’s a separate value computed from the combination of the client program’s settings. This is called hassh, or in plain terms the client fingerprint. This source’s fingerprint is 3335afa7a75e84f8348f05c623c5ecf9. It differs from that large cluster. It isn’t among yesterday’s top 15 most-seen fingerprints, nor anywhere in all 33 briefs.

INFERRED In charger terms, the brand stamped on the outside is a common one, but opening it up reveals a circuit layout we’ve never seen. That said, a fingerprint only shows how the tool was built. All we can say is that it’s a tool with different settings. It does not mean a different person or a different organization.

FACT To summarize: the alias ATK-3ED4D8, the fingerprint 3335afa7…, the two distribution hosts, and the three hashes are all values that had never appeared in the 33 briefs accumulated since August 16.

Laid out in time order

Yesterday’s records laid out in time order look like this. Times are in Coordinated Universal Time (UTC); for Korean time, add nine hours. Pay attention to the seconds between the start and end times of the five entries.

1. 01:52:08Z ~ 01:52:51Z (KST 10:52)
   FACT ATK-3ED4D8(45.198.x.x) SSH login succeeded. About 43.4 sec · 2 commands · 6 downloads · log density 28. Client SSH-2.0-libssh_0.9.6, hassh 3335afa7a75e84f8348f05c623c5ecf9. Input logging (TTY) exists but its contents are not in the brief
2. 01:53:09Z ~ 01:53:48Z (KST 10:53)
   FACT 17.8 sec after the previous session ended, the same alias logged in successfully again. About 38.4 sec · 2 commands · 5 downloads · log density 25
3. 01:55:52Z ~ 01:56:49Z (KST 10:55)
   FACT Third session. About 57.3 sec · 2 commands · 5 downloads · log density 25. 2 min 4 sec gap from the previous session
4. 01:57:58Z ~ 01:58:47Z (KST 10:57)
   FACT Fourth session. About 48.9 sec · 2 commands · 4 downloads · log density 22
5. 02:00:07Z ~ 02:00:45Z (KST 11:00)
   FACT Fifth session. About 37.6 sec · 2 commands · 4 downloads · log density 22. Over the 8 min 37 sec from the first session's start: 10 commands, 24 downloads
6. Common to all 5
   INFERRED The behavior classifications of the five sessions (file download · granting execute permission · execution after download) are identical right down to their order. But this list does not capture execution order. We cannot write that it happened in the order 'download → permission → execution'; we can only say the three stages were observed
7. Whole day
   FACT ATK-3ED4D8 sent files in three records. ssh script (1,872-byte Bash) 32 times, 0uparm (55,804 bytes, ARM 32-bit statically linked) 13 times, 0uparm5 (48,112 bytes, ARM 32-bit uClibc dynamically linked) 4 times. The total of 49 is more than the 24 downloads across the five sessions above
8. Whole day
   INFERRED From the gap between 49 and 24, it appears this alias opened further sessions beyond the five above. How many more it opened is not in the record
9. Whole day
   INFERRED The distribution hosts for the script (45[.]198[.]224[.]34) and the executables (151[.]243[.]24[.]225) differ. This looks like a two-stage structure where 'the script called in the executables', but with no script contents and no download order, it cannot be confirmed
10. Archive comparison
    FACT ATK-BDB53E's kla.sh (39be6853…, 3,241 bytes) has had the same hash for 22 days since first observed on 9/15. The net.x86_64 from the same distribution host has changed hash for the third time. 9/15 · 9/17 cd6ccc5d…(190,632B), 9/20 · 9/22 · 9/27 2cebccdc…(192,328B), today 64d8f97b…(193,288B). 960 bytes larger than the previous one

FACT All five times, it was over within a minute. The shortest was 37.6 seconds, the longest 57.3 seconds. The commands were the same two lines every time. Only the number of files fetched declined a little, 6 → 5 → 5 → 4 → 4. It looks closer to an automated program repeating the same action than to a person typing by hand.

The whole of yesterday

Now let’s widen the view to the whole day on the first server. The “For comparison” column on the right is what makes these numbers land.

FACT Telnet is an older channel that does the same job as SSH. The difference is that it does not wrap its contents in encryption. You can think of a port as a door number inside a single computer.

FACT The behaviors classified over the day are as follows.

FACT Reconnaissance dominates. The first thing done after getting in was to look around inside. Yet today’s protagonist, across five visits, had no behavior classified as reconnaissance. Without looking around, they went straight to fetching plugs. “Planting SSH keys” — quietly hanging someone else’s key — and “deleting traces” also did not appear from this source. Those are numbers that came from other connections over the whole day.

Are you using one of these passwords

FACT Of the ID and password combinations attempted yesterday, 10 kinds are reproduced verbatim in this post. The criterion is a single one. Only combinations entered identically from three or more different IPs are written down. A number that many places carry around identically belongs to nobody — it’s a factory default. Look at the numbers in the third column.

FACT Combinations that fell short of this criterion are only counted. Yesterday there were 2,213 kinds. Because one of them could have leaked from somebody’s real account, we do not write the values. That amounts to about 220 unwritten combinations for every one in the table. It is fewer than the peak of 3,026 kinds two days earlier (October 4).

FACT We do not know which of these combinations today’s protagonist came in with. The information linking a connection to a password is not in the record.

The socket next door: same name, third set of innards

FACT Yesterday another source, ATK-BDB53E, also fetched a file. From hxxp://160[.]119[.]66[.]206/bins/net.x86_64. This one is for x86-64 — a differently shaped plug from ARM. x86-64 is the kind of CPU common in ordinary PCs and servers.

FACT This file kept its name but changed its innards for the third time. To check the inside of a file, we use a hash. A hash is a unique number computed from the file’s entire contents. Change a single character and you get a completely different value.

FACT That’s 960 bytes larger than the previous one. About 960 English characters. By contrast, the same source’s installer note kla.sh (3,241 bytes, 39be6853…) has not changed by a single character in the 22 days since it was first seen on September 15. It looks like leaving the note as is and swapping only the plug. Why it changed, we do not know.

Outside the second server

FACT On the second server, which never opens, all that remains is who knocked on which door and how many times.

FACT VNC accounts for 96.0% of all 38,152 contacts. 36,631 in a day is about once every 2.4 seconds. The share of the version string 003.008 presented on connection was 96.8%. It keeps growing — 63.2% on October 1, 94.1% on October 4. The three most frequent sources (ATK-F81B56 6,436 · ATK-943F0E 6,435 · ATK-A9F1B3 6,422) differ from one another by less than 16.

FACT Of the five kinds of file left on this server, four have had unchanged hashes since first being recorded on August 28. Yesterday a new alias, ATK-53E31C, sent them. The remaining one (90,164 bytes, 7e70323b…, ATK-3447C1) is a hash not seen before.

Values from yesterday — to write down

Reproduced verbatim 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.” Click a value to copy it. Addresses are left in their broken notation. Look at “new” and “count” in the description column.

FACT The six lines above (ATK-3ED4D8’s share) are all values seen for the first time yesterday. If you maintain a blocklist, yesterday produced six new lines to add. The two new distribution hosts (45[.]198[.]224[.]34, 151[.]243[.]24[.]225) are subject to C-TAS reporting. C-TAS is the threat information sharing system of the Korea Internet & Security Agency (KISA). What has been confirmed is only that transmission succeeded. Whether it actually landed on KISA’s side has to be verified separately.

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 behaviors to those numbers gives this. Click an ID to go to the original description.

• T1021.004Remote Services: SSH — ATK-3ED4D8 SSH login succeeded 5 timesINFERRED
• T1110Brute Force — based on 3,713 login attempts across the whole day. Which credentials the sessions in question came in with is not in the recordINFERRED
• T1105Ingress Tool Transfer — files received from two distribution hosts, 24 in total across five sessionsINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'granting execute permission' in all five sessionsINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — Bash script ssh (1,872 bytes)INFERRED

FACT All five lines are [INFERRED]. What we hold is the behavior classifications, the counts, and the files. We do not have the original text of the two command lines typed. So assigning numbers is always interpretation. The line to watch is T1105. The stage of bringing in a plug from outside is that number.

There has been a pattern like this before

FACT Mirai botnet (2016). It logged into Telnet and SSH with default accounts. Then it fetched executables for each CPU type and infected IoT devices. IoT devices are small internet-connected gadgets like routers and CCTV cameras. A botnet means a swarm of many such infected devices controlled all at once. (Source type: government security alert US-CERT Alert TA16-288A)

INFERRED What resembles it stops at the technique. The approach of coming in with a default account and fetching device-targeted plugs like ARM is the same. We make no determination as to whether yesterday’s files are of the Mirai family. VirusTotal is not integrated, and sample classification tags were not in yesterday’s material.

So what should you do

Coming back to the plug story, the things to do gather into three. Don’t leave the socket free for anyone to use, lock it with a key instead of a password, and make it impossible to bring in a plug from outside. Let’s go through the six items the brief singled out, in order.

FACT 1. The management port was opened directly to the internet · high likelihood Over the day, 188 places knocked on the SSH door (2222). There were 3,271 sessions. One source logged in successfully five times within 8 minutes 37 seconds.

INFERRED Had this been a production server, anyone outside arrives straight at the password entry step. And the three stages seen yesterday — “fetch, mark, execute” — happen exactly the same way on a real server.

FACT 2. Default accounts and easy passwords are left as they are · high likelihood admin/admin came in 60 times from 20 places, root/root 27 times from 8 places, root/123456 24 times from 8 places.

INFERRED If your password is in the table above, it opens on the first attempt. After that it goes, as it did yesterday, all the way to fetching a file from outside and attaching an execute mark in under a minute.

FACT 3. Password login is allowed and key-based authentication is not used · high likelihood 3,713 login attempts, with at least 2,213 kinds of combination whose values we do not write. Yesterday’s attack was password guessing.

INFERRED Key-based authentication is a method of getting in with a key file that exists only on your own computer, instead of a password. Had only this been allowed, all 3,713 attempts would have been meaningless. Allow passwords, and just one correct guess breaks through.

FACT 4. There is no repeated-attempt blocking (fail2ban or similar) · low likelihood All five sessions logged in successfully. The gaps between sessions ran from 17.8 seconds to 2 minutes 4 seconds. How many times this source got it wrong is not in the record.

INFERRED fail2ban is a tool that “blocks for a while after so many wrong attempts.” It cannot block a connection that comes straight in with the correct password. So it would have had little effect against yesterday’s protagonist. That said, a connection rate limit like “five connections from the same place within 10 minutes” could have slowed things from the second one on.

FACT 5. The server’s outbound connections are not blocked · high likelihood The ssh script 32 times, 0uparm 13 times, 0uparm5 4 times. All received over HTTP (the method of exchanging files via a web address) from two distribution hosts. Everything that happened yesterday followed the server opening a connection outward.

INFERRED If a server can reach out to external web addresses at will, a device-targeted executable comes in and even gets its execute mark. After that it can be used as a member of a botnet. What the executables actually do, we could not confirm. If the plug can’t be brought in, there’s nothing to plug in, whether the shape fits or not.

FACT 6. Logs are not collected off the box · medium likelihood Across the whole day there were 14 instances of “deleting traces.” That’s a number from other connections, not from today’s protagonist.

INFERRED Keep logs only on the server itself and, once an intruder deletes them, it becomes hard to reconstruct when they came in and what they took. The reason we could say yesterday that “this is the fourth matching-prefix pattern” was also that September’s records were kept separately.

We also made a 60-second video about the same day. The video focused on one thing: that “all five times, it opened with the right number.” This post unfolds the shape and the origin of the plug that came in then.

What We Don’t Know

This is where this blog differs from other places. There is as little that we don’t know as there is that we know.

About the five visits

• [Cannot confirm] For all five, we do not know which ID and password they came in with. The information linking a connection to a password is not in the record.
• [Cannot confirm] We do not know the contents of the two command lines typed each time. We only know that input logging (TTY) exists; the contents are not in the brief.
• [Cannot confirm] We do not know in what order the fetching, the execute marking, and the execution happened. The behavior classification has no order.
• [Cannot confirm] The 49 file records and the 24 downloads across the five sessions do not match. So we infer that they came in more times than the five. How many times, and when, we do not know.
• [INFERRED] The connection port per session is not in the record. Because the port 2222 count (3,271) exactly matches the SSH count (3,271), we mapped SSH to 2222.

About the plugs and the shops

• [Cannot confirm] We do not know whether the ssh note called in the 0uparm plugs. The note’s contents and the download timestamps are missing.
• [Cannot confirm] We do not know what 0uparm and 0uparm5 do. There is no basis to judge whether it is a service-disruption attack (DDoS), mining, or a relay server (proxy). VirusTotal is not integrated, and there are no MalwareBazaar tags.
• [Cannot confirm] 0uparm and the ‘parm’ family at the 31[.]77[.]227[.]121/bins/ path, which is only visible once unpacked, have similar names. But the distribution hosts and hashes do not connect. There is no basis to write that they are the same family. The 12 instances at that path are an indicator that has recurred since August 17, so we leave them as background only.
• [Cannot confirm] The incoming address (45.198.x.x) and the note shop (45[.]198[.]224[.]34) share only the first two octets. Because of the masking, whether it is the same computer or the same operator is something we cannot judge, and must not judge.
• [Cannot confirm] “The fourth matching-prefix instance” is the result of finding 9/7 · 9/8 · 9/15 in the brief archive. Dates not in the archive (9/9 · 9/11 · 9/12, and others) could not be counted.
• [Cannot confirm] We do not know the reason net.x86_64’s hash changed for the third time (whether a functional change or a repackaging). The file’s contents are not in the brief.

About the second server

• [Cannot confirm] We do not know the relationship between the sum of per-service source counts (272) and the total unique sources (296). Nor can we count whether a single source knocked on several doors. There is no information telling us the degree of overlap.
• [INFERRED] Because the numbers for the three most frequent sources are almost identical, it appears they swept on the same schedule. Whether it is the same tool cannot be confirmed, as this server has no fingerprints.
• [INFERRED] That the files on this server came in over the Android channel (ADB) is an inference. There is no notation of which channel they arrived through.

Deliberately left out or not connected

• [Excluded] The Discord webhook address is a recurring indicator that already appeared in the 9/15 · 9/20 briefs. Because a token is contained within the address, we did not carry the value.
• [Cannot confirm] For the C-TAS report, only transmission success was confirmed. Whether KISA ingested it has to be verified separately.
• [Excluded] We did not group today’s protagonist with the large cluster using the same name (libssh_0.9.6) as either the same side or a different side. That the fingerprint differs means only that the tool’s settings differ.

What we make no judgment about at all

• Carrier/organization (ASN · ISP) — we have no relevant database. We do not infer it.
• Geolocation — unknown for the same reason. IP geolocation is not, to begin with, a basis for identifying who did something. This post does not name any country, company, or individual as the attacker.
• Whether VPN, Tor, or cloud — we have no means to determine it.
• VirusTotal — not integrated. For sample classification we use MalwareBazaar tags, and yesterday’s material had no tags.
• Client program string (User-Agent) — neither server is a web (HTTP) server. The first is SSH and Telnet, the second SMB, RDP, VNC, MSSQL, LDAP, and ADB.
• Vulnerability number (CVE) linkage — SSH and Telnet attacks mostly do not reference a specific vulnerability. The second server is the same, as it is at the stage of matching connection rules.

Yesterday the same guest came in five times in under nine minutes. Each time they said only two words, and they fetched plugs from two shops. Those plugs were not the shape of a server’s socket. They appear to be the shape for small devices like routers or cameras.

It’s easy to wave it off with “it doesn’t fit our server, so we’re fine.” But this guest did not check the shape of the socket. Without looking around first, they just plugged in and left. It reads as meaning that in any house they can get into, they’ll try the same plug. If somewhere in your house there is a socket of that shape, the password on that device is what you should check today.

The observation date is October 6, 2026 (a single day in UTC), and this post was compiled the following day. Source IPs are reproduced exactly in the masked form given in the brief (45.198.x.x) and were not restored. Addresses were kept defanged (hxxp://, [.]) in both the body and the IOC block so that they cannot be visited by accident, and the webhook address containing a token was not carried. For credentials, only the 10 combinations repeatedly observed from three or more different IPs were quoted verbatim; for the remaining 2,213 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 is in use — were left as “we don’t know” rather than inferred.