Three Files from an Address We'd Never Seen — The Nameplate Looked Familiar

Suppose a new shop opens up in your neighborhood. A spot you’ve never seen before, a name you’ve never heard. But you step inside and it feels oddly familiar. The lettering on the sign is the same, the way the menu items are numbered is the same, and one of the dish names is even spelled character for character the same.

Two things can be said here. One is “this shop was set up from the same manual” — that one holds. The other is “the owner moved here” — that one we don’t know. It could be a different owner entirely, someone who got the manual from the same franchise headquarters and has never met the other one.

What landed on our server yesterday was exactly that new shop.

10.4 seconds, and an address we’d never seen

FACT Yesterday at 08:24:58, ATK-377ED5 (94.154.x.x) logged in successfully over Telnet. Telnet is a very old remote-access method. Put simply, it is a channel left open so that someone across the internet can type directly into that machine’s command prompt — and the password travels across it unencrypted, in the clear.

FACT The stay lasted about 10.4 seconds. In that window it entered 8 commands and pulled down 3 files. That works out to one line every 1.3 seconds. The whole thing was over in the time it takes to put a pot of water on and set the lid down.

FACT All three files came from under hxxp://176[.]65[.]139[.]196/bins/. We have deliberately broken the address as written (hxxp://, [.]) — copy-pasting it as-is will not connect.

FACT And this address, 176[.]65[.]139[.]196, appears nowhere in the five days of records for 8/16, 8/17, 8/18, 8/19, or 8/20. Yesterday was the first time.

What the three files were

FACT Here is what the three of them are.

Three unfamiliar terms in there, so let’s unpack them on the spot.

• Shell script — a note with commands written out in order. Instead of a person typing them one line at a time, you run a single file and it goes through them in the written order. At 3,013 bytes, that’s roughly a page of text.
• ELF — the executable file format used on Linux. Think of it as the equivalent of Windows’ .exe.
• statically linked · stripped — statically linked means it carries every part it needs inside itself. It borrows nothing from outside, so it will run on whatever Linux you drop it on. Stripped means the human-readable name labels have been removed, which makes analysis harder.

FACT The three together come to 380,885 bytes. That came in over roughly ten seconds.

FACT px86 is an executable that runs on ordinary PC-class hardware; pmips runs on device-class hardware like routers and home cameras. The two formats are not compatible with each other. Across five days of the archive, whenever an ELF file came down it was always pmips — one kind, one at a time. Yesterday was the first time a single session pulled down both formats together.

Why the nameplate looked familiar

Here we come back to the new-shop story.

FACT We had 12 URLs on a watchlist. All of them under hxxp://31[.]77[.]227[.]121/bins/: parm, parm5, parm6, parm64, parm7, pm68k, pmips, pmpsl, pppc, psh4, pspc, x86_64. Do you see the pattern? The folder name /bins/, and file names formed by putting a CPU type after p.

FACT Those 12 did not come for free. They are addresses that only surfaced after unpacking files that had been wrapped in a compression scheme called UPX. Looking at the compressed outer shell alone, not one address is visible.

FACT The folder name used by 176[.]65[.]139[.]196, the address we saw for the first time yesterday, was also /bins/, and the file names were also p + CPU type. pmips matches a name on the watchlist character for character.

INFERRED That is why we recognized it as the same family at first observation, even though the address was new to us. If we had not copied down the menu in advance, yesterday’s record would have said only “three files from an IP we’ve never seen.”

FACT One thing to make clear. Yesterday those three addresses were visible in the session as they were. We did not learn them by unpacking anything. What the unpacking gave us was not addresses but the pattern.

FACT And a matching sign means a matching manual, not a matching owner. This file-naming convention belongs to a family whose source is public, so operators with no relationship to each other each use it identically.

FACT Meanwhile, the 12 URLs in the older 31[.]77[.]227[.]121/bins/ family saw 0 downloads yesterday as well. That’s the second straight day, following 8/20.

INFERRED This is the point where you want to say “the old shop closed and moved to a new one.” But we will not say it. The data does not distinguish between the old address having stopped and those requests simply not coming our honeypot’s way.

Yesterday, in order

Laid out in sequence, the day looks like this. Pay attention to the seconds on the 08:24 line. And it’s worth watching how much the download counts at the end of each line differ from one another.

1. 00:25:46Z ~ 00:27:11Z
   FACT ATK-E07AC3 (183.95.x.x) Telnet login succeeded. About 85.0 seconds · 31 commands · 1 download. 3 intent types — file download · granting execute permission · execute-after-download. completeness 16. The numeric shape matches the four sessions that were the subject of the 8/20 brief. TTY recorded (contents not included). Being Telnet, the fingerprint and client values are empty strings
2. 00:49:37Z ~ 00:49:42Z
   FACT ATK-A64398 (112.46.x.x) Telnet login succeeded. 19 commands within about 5.1 seconds (about 3.7 per second) · 2 downloads. 2 intent types — file download · granting execute permission. completeness 17. What it took were two 9-byte ASCII text files (1193dde1… · a9b1c85a…), and no URL was recorded
3. 05:51:55Z ~ 05:52:58Z
   FACT ATK-4CA329 (223.123.x.x) Telnet login succeeded. About 63.0 seconds · 17 commands. 5 intent types, the most of any session yesterday — reconnaissance (system) · file download · granting execute permission · execute-after-download · persistence (planting an SSH key). And yet 0 downloads. completeness 17. The fourth session of this same shape, following 8/18, 8/19 and 8/20
4. 08:24:58Z ~ 08:25:09Z
   FACT Yesterday's subject session. ATK-377ED5 (94.154.x.x) Telnet login succeeded. About 10.4 seconds · 8 commands · 3 downloads. 3 intent types — file download · granting execute permission · execute-after-download. completeness 22, the highest value among sessions with recorded intent. Three samples totaling 380,885 bytes came in over roughly ten seconds
5. 08:24:58Z ~ 08:25:09Z (sample detail)
   FACT The samples for which ATK-377ED5 is the sole delivery source number exactly 3, and the session's download count is also 3. ① hxxp://176[.]65[.]139[.]196/bins/kla[.]sh — 3,013-byte Bourne-Again shell script (bb36568c…) ② hxxp://176[.]65[.]139[.]196/bins/px86 — 133,452-byte ELF 32-bit LSB Intel 80386, statically linked · stripped (979bd80a…) ③ hxxp://176[.]65[.]139[.]196/bins/pmips — 244,420-byte ELF 32-bit MSB MIPS-I, statically linked · stripped (ed6bae21…)
6. 08:24:58Z ~ 08:25:09Z (archive comparison)
   FACT The host 176[.]65[.]139[.]196 appears in none of the five briefs from 8/16 to 8/20. Yesterday was its first observation. Also, in the archive the only URL from which an ELF came down was hxxp://31[.]77[.]227[.]121/bins/pmips, and it was always one per session — yesterday was the first time a single session took both x86 and MIPS together
7. 14:00:33Z ~ 14:00:56Z
   FACT ATK-792ADF (218.154.x.x) Telnet login succeeded. About 23.7 seconds · 48 commands (most of any session yesterday) · 12 downloads (most of any session yesterday) · completeness 43, the highest value of the whole day. And yet the intent array is empty — nothing was classified at all. The samples for which this alias is the sole delivery source are a 1-byte file (01ba4719…, 11 times) and a 202-byte POSIX shell script (0c99433c…, 1 time), and 11+1=12 matches the download count
8. Whole observation window
   FACT A 1,608-byte Bourne-Again shell script came down from hxxp://5[.]182[.]210[.]174/ok, and two different hashes were recorded for it in a single day yesterday — c850a285… and 7a5dcc03…. Both 1,608 bytes, both from a single source, ATK-10149C, once each. The same URL at the same size was 6aa5054a… on 8/18 and 8/19, and b7728639… on 8/20. That is 4 hash variants over four days, 2 of which appeared within yesterday alone
9. Whole observation window
   FACT A 306-byte POSIX shell script (a6296a79…, hxxp://185[.]93[.]89[.]72/wget) observed 5 times from 5 sources. The delivery sources are ATK-3F4FA3 · ATK-42B427 · ATK-D9B325 · ATK-E07AC3 · ATK-338C04. Following 8/17, 8/18 (13 sources), 8/19 (7 sources) and 8/20 (8 sources), that is five straight days with the same hash and the same URL, and the source count is the lowest yet
10. Whole observation window
    FACT A 389-byte OpenSSH RSA public key (a8460f44…) observed 10 times from 10 different sources. URL not recorded. 8/16 10 sources → 8/17 12 → 8/18 16 → 8/19 12 → 8/20 8 → yesterday 10, six straight days with the same hash
11. Whole observation window
    FACT The 12 URLs that only surfaced after unpacking (the 31[.]77[.]227[.]121/bins/ family) again saw 0 downloads yesterday — the second straight day, following 8/20. These 12 remain on the watchlist
12. Whole observation window
    FACT Intent classification — reconnaissance (system) 1,154, granting execute permission 181, file download 109, execute-after-download 107, trace removal 12, persistence (planting an SSH key) 11, reconnaissance (network) 1. Of 1,910 total commands, reconnaissance (system) accounts for about 60.4%. 'Reconnaissance — network' had no entry at all on 8/20 but reappeared once yesterday, and 'impairing defenses' again has no entry yesterday
13. Whole observation window
    FACT 1,845 sessions / 205 unique origins / 1,519 login attempts / 1,910 commands / 1,250 TTY recordings. Port 2222 (SSH) 1,564, port 2223 (Telnet) 281 — Telnet is about 15.2% of the total, yet the top 5 sessions by completeness were again all Telnet yesterday (8/20 11.4%, 8/19 22%, 8/18 18%)
14. Whole observation window
    FACT The credential pair nobody/nobody came from only 4 different IPs, but with 151 attempts — about 37.8 per source. Conversely admin/admin came from 18 IPs with 35 attempts, about 2 per source. Even among the same 'frequent pairs', the knocking style is the exact opposite
15. Whole observation window
    FACT 38 SSH client fingerprint clusters in total (8/17 33 → 8/18 36 → 8/19 37 → 8/20 37 → yesterday 38). The largest cluster is f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6), 11 IPs yesterday · 169 cumulative. None of the 8 clusters on the list delivered any sample — on 8/20 there was 1 cluster that delivered, yesterday there were 0. 0425c279610910d2d9aef3b285e59b86 (SSH-2.0-PuTTY_Release_0.70) had 3 IPs yesterday · 3 cumulative, so the cumulative and same-day figures match

FACT Two lines in that table catch the eye. One is ATK-4CA329 at 05:51 — the widest intent spread at 5 types, and yet 0 downloads. The other is ATK-792ADF at 14:00 — the most commands and the most downloads of the day, and yet not a single intent was classified. That is exactly why we did not make either of them yesterday’s subject. The numbers are large, but there is no basis for explaining what happened.

The layer where fingerprints are caught, and the layer that actually gets breached

FACT Connections coming in over SSH leave behind a client fingerprint. The makeup of the greeting a connecting program sends first differs slightly from tool to tool, so grouping those values tells you “different origins, same program.” Yesterday these fingerprint groups numbered 38, the most of the five days in the archive.

FACT And yet yesterday’s top 5 sessions by completeness were all Telnet, with fingerprint and client values all empty strings. Telnet has no such greeting procedure to begin with.

FACT Not one of the 8 fingerprint groups on the list sent down a sample. On 8/20 there was one; yesterday there were 0.

INFERRED To put it together: the layer where fingerprints are caught (SSH · 1,564 sessions) and the layer where files actually come down (Telnet · 281 sessions) were split apart again yesterday. By session count alone, Telnet is 15.2%. Set your defensive priorities by that share and you miss the 100% that actually got breached.

FACT And a fingerprint is a fingerprint of a build, not of a person. People who don’t know each other but use the same distribution’s default connection program end up with the same value.

How they got in — yesterday, again, it was passwords

FACT Yesterday there were 1,519 login attempts. Treating the observation window as a full day, that amounts to someone trying the doorknob about once a minute. With 205 origins, that averages about 7.4 attempts each.

FACT Narrowing to only the pairs observed from 3 or more different IPs gives this.

FACT This is where the knocking styles diverge. admin/admin came from 18 IPs with 35 attempts — each source tries it about twice and moves on. nobody/nobody, by contrast, came from only 4 IPs but 151 times — each source knocked about thirty-eight times. The ones sweeping wide with a single try and the ones drilling narrow arrived on the same day.

FACT And 806 pairs are not listed here. Those are the ones that appeared from fewer than 3 different IPs (8/16 934 → 8/17 830 → 8/18 1,388 → 8/19 848 → 8/20 440 → yesterday 806). A pair that appeared from only one source could be some real person’s account leaked somewhere, so we count them without writing the values.

FACT Yesterday, again, there was no intrusion path referencing a CVE or an exploit. It was all credentials.

What they left behind

Every sample and address observed yesterday. Click a value to copy it — hashes exist to be put on block lists, not to be read. The hxxp:// and [.] have been left as they are.

FACT Two lines in the list catch the eye: the pair for hxxp://5[.]182[.]210[.]174/ok. Same address, same size at 1,608 bytes, and only the hash differs. It means the file sitting in that same spot was quietly swapped out. 8/18, 8/19, 8/20, and twice yesterday — four variants over four days, two of them within yesterday alone. If you want to know why the approach of tagging a hash as “this file is dangerous” and blocking it keeps running late, these two lines are the answer. What changed, we cannot say, because we do not hold the contents.

FACT And the 389-byte OpenSSH RSA public key comes up with the same hash for a sixth day. Yesterday it was 10 sources. 389 bytes is about the size of two text messages. Once that small file goes into authorized_keys (the list of permitted keys) as a single line, a key that gets in without a password is hanging by the front door. Change every password and that key stays.

Mapped to attack stages

Mapping the observed behavior onto the international classification table MITRE ATT&CK gives this. Click an ID to read the original description directly — you’re welcome to verify rather than take our word for it. These are all [INFERRED]. What we saw were commands, not the attacker’s intent.

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

FACT The last line, T1027.002 (hiding via compression/packing), needs a qualifier. That entry rests on the earlier UPX-packed samples that produced the 12 watchlist URLs. For the two ELF files that came down yesterday, the record goes only as far as statically linked stripped, so whether or not packing was applied cannot be stated from this data.

If it looks familiar

INFERRED The entry structure matches the Mirai botnet family that has been running since 2016. The method is: get in with a default Telnet password, then download per-CPU-type executables from a /bins/ path on a web server and run whichever one fits. The names taken yesterday (px86, pmips) and the naming convention of the 12 watchlist entries are consistent with that method, and the fact that all 5 completed sessions went through Telnet and passwords fits as well. It is a case with U.S. Department of Justice indictment and guilty-plea records on file and public analysis reports from multiple vendors.

INFERRED It also lines up with the Gafgyt (Bashlite) family. There, a shell script comes down first, and that script tries statically linked executables for each CPU type in turn. Yesterday’s combination — one shell script kla[.]sh plus two statically linked, stripped ELFs (x86 and MIPS) coming down together in one session from under the same /bins/ — matches that structure.

FACT But there is exactly one thing these two cases point out. Both are families whose source is public, so it is common for unrelated operators to each stand up distribution hosts following the same conventions. It is as though the franchise manual has been dumped onto the internet in full. So yesterday’s observation, “a new shop appeared under the same sign,” runs in the same direction as these cases, and “are the two shop owners the same person” is not something these cases answer.

So what should you do

INFERRED The order yesterday’s data points to.

1. Turn off remote access like Telnet. Yesterday Telnet was 15.2% of all sessions, yet all 5 completed sessions were Telnet. Telnet sends the password in the clear, and it does not even offer key authentication as an option — there is no method other than turning it off. In your router or home camera settings, look for “remote access,” “Telnet,” or “remote management” and switch it off.
2. Change default accounts and initial passwords. 1,519 login attempts, and all 5 completed sessions were successful logins. All 1,910 commands were executed after a successful login. If you are using one of the pairs in the table above, that’s all it takes.
3. Block your devices from fetching files from outside. Yesterday: 109 file downloads, 181 grants of execute permission, 107 execute-after-download. Had outbound connections been blocked, ATK-377ED5 would have been cut off at the download step. In particular, the two executables that came down yesterday are statically linked, so they run regardless of distribution and version. This was the last point at which it could have been cut.
4. Limit failed login attempts. Four sources knocked with the single pair nobody/nobody about thirty-eight times each and nothing caught it. On top of that, a session finishes in 5–10 seconds, so thresholds set around “long-lived connections” will not trip at all.
5. Get alerted when ~/.ssh/authorized_keys changes. Yesterday: 11 key-planting intents, 10 sources leaving the same-hash public key. ATK-4CA329 was a session in which not a single sample was saved, and it was still classified all the way to the key-planting step. If there is no executable for antivirus to catch and you don’t look at the key file directly, you don’t even know you’ve been breached.
6. Store logs off the device. Trace removal was observed 12 times (8/18 19 → 8/19 13 → 8/20 8 → yesterday 12). For a case like yesterday’s — a 10-second session leaving behind nothing but two executables — without logs you cannot even find out that a first-time distribution host was there. It was because 1,250 TTY recordings remained that we could retrace the flow inside those 10 seconds (contents are not included in this post).

FACT “Use key authentication instead of passwords” is, by yesterday’s data, a middling recommendation. All the completed sessions with successful logins yesterday were Telnet, and Telnet has no key authentication. And the data does not break out how much of the 1,519 belongs to SSH, so there is no basis for saying “turning on key authentication would have stopped yesterday’s intrusion.”

The whole day

That averages about 9.0 sessions and about 7.4 attempts per origin.

The distribution hosts and C2 observed yesterday (176[.]65[.]139[.]196, 185[.]93[.]89[.]72, 5[.]182[.]210[.]174, and others) were reported to C-TAS. The new address 176[.]65[.]139[.]196 is the core of yesterday’s report. Only transport-layer success is confirmed; whether KISA ingested it requires separate confirmation.

In 60 seconds

We also made a short video of the same observation set. The video focuses on why both files were taken.

What We Don’t Know

This blog writes down what it knows and what it doesn’t, separately. Here is what could not be confirmed in yesterday’s observation set.

• Whether the three files really were taken by that one session. ATK-377ED5 has a download count of 3 and there are exactly 3 samples that have this alias as their only delivery source, but the data does not link sessions to samples one-to-one. ATK-792ADF (12 = 11+1) and ATK-A64398 (2) are matched the same way.
• Whether 176[.]65[.]139[.]196 and 31[.]77[.]227[.]121 are the same operator or the same infrastructure. What is confirmable goes only as far as this: the /bins/ folder convention and the p+CPU naming convention are the same, and the name pmips matches character for character. Because this is a public-source family, unrelated operators use the same conventions too.
• Why the older address had 0 for two straight days. We cannot distinguish between the distribution host having stopped and those requests simply not coming to our honeypot. There is likewise no basis in this data for saying “they moved to a new host.”
• Whether pmips grew yesterday. At 244,420 bytes it is about 4.7 times the 8/16 (51,104) and 8/19 (52,272) figures, but the host is different. They could be two different files that merely share a name.
• Why only the two types, x86 and MIPS, were taken. The data does not distinguish between this being the result of narrowing to those two for this server and more having been attempted and failed. Without the raw commands and a TTY replay, the order is unknown as well.
• Why none of ATK-792ADF’s intents were classified. It has completeness 43, the day’s highest value, with 48 commands and 12 downloads, and yet the intent array is empty. There is no explanation of whether the classifier failed to catch them or the commands were not subject to classification. This is also why we did not make this session the subject.
• Why the completeness values are what they are. The formula is not in the data. ATK-792ADF has 0 intents but a 43, while ATK-4CA329 with 5 intent types has a 17. The same item remains unresolved on 8/18, 8/19 and 8/20.
• Why hxxp://5[.]182[.]210[.]174/ok put out two variants in a day. We cannot tell whether it is regenerated per request or rotated on a short cycle, and since we do not hold the contents, we also cannot say what changed.
• Why the 1-byte file was saved 11 times over. We cannot tell whether it is the result of failed downloads or intended behavior. The same shape appeared on 8/17 as well.
• Whether ATK-4CA329 failed to download, or downloaded but the save failed. Its intents include ‘file download’ and ‘execute-after-download’, yet the download count is 0. This is the fourth instance, following 8/18, 8/19 and 8/20.
• Why the command total of 1,910 and the intent-classification total of 1,575 don’t line up. There is no explanation of whether one command can be classified under multiple intents, or whether some commands go unclassified.
• Whether the sources from 8/16–8/20 overlap with yesterday’s sources. Aliases (ATK-XXXXXX) are generated with a salt mixed in. ATK-10149C and ATK-BECAD3 appear in earlier briefs alongside the same samples, but the salting method is not documented, so we did not use it as a basis for treating origins as identical across dates. Therefore the source counts for public-key planting (10 → 12 → 16 → 12 → 8 → 10) cannot be summed either.
• Whether the fingerprint list is a top-N or the complete set. The cluster total is 38 while the list has 8. So “no cluster delivered a sample yesterday” is a fact within the scope of those 8.
• The nature of SSH-2.0-ZGrab ZGrab SSH Survey (fingerprint dd9bcf09…, 2 IPs yesterday · 34 cumulative). It is the name of a public internet scanner tool, but this data cannot distinguish between research/measurement purposes and attack preparation.
• Whether 0425c279… (SSH-2.0-PuTTY_Release_0.70) really was observed for the first time yesterday. It looks that way since 3 same-day = 3 cumulative, but the start point of the cumulative tally is not stated.
• What the three 9-byte ASCII text files (4af5a5c9…, 1193dde1…, a9b1c85a…) are. The contents are not in the brief. 4af5a5c9… has 1 delivery source but 5 observations.
• Why 10 sources left the same-hash public key. We cannot tell whether it is the result of using the same tool or of sharing a key. The same item is unresolved for 8/16–8/20 as well.
• One Discord webhook URL. Which session or which sample it connects to is not stated, so we did not include it in yesterday’s facts. 8/20 was excluded for the same reason.
• Whether the aggregate figures cover the full day. The main sessions span 00:25–14:00 UTC and the generation time is 15:05Z. The observation window is not stated. The “about once a minute” written above is also a calculation that assumes a full day.
• The relationship between tty_recordings_available (127) / samples_on_honeypot (43) and the aggregate TTY recordings (1,250). There is no explanation.
• Whether the C-TAS report was ingested or acted upon. Only transport-layer success was confirmed.
• Background vulnerability statistics (4,555 CVEs / 344 CISA KEV / 95 confirmed ransomware-linked, top EPSS CVE-2018-13379 · CVE-2022-26134 · CVE-2021-44228 · CVE-2023-4966 · CVE-2024-3400). These are background statistics based on KISA security advisories and are not directly connected to yesterday’s observation set. Every intrusion path observed yesterday was credentials.

And then there are the things we have no means of confirming in the first place. This is different from not knowing — here, not guessing is the right answer.

• ASN · ISP — we do not have a GeoIP or ASN database. We do not guess. The hosting provider for the new distribution host 176[.]65[.]139[.]196 is likewise unknown.
• Geolocation — same. IP geolocation is not a basis for attribution to begin with.
• VPN · Tor · cloud — we have no means of determining this.
• VirusTotal detection results — not integrated. What family the two ELFs obtained yesterday (979bd80a…, ed6bae21…) are detected as cannot be stated from this data. Sample classification uses MalwareBazaar tags.
• User-Agent — SSH and Telnet have no User-Agent at all. HTTP attacks are a separate source.
• CVE linkage — SSH and Telnet attacks mostly do not reference vulnerabilities, and yesterday’s observation set was aimed at passwords.

A new shop opened in the neighborhood. We never do find out who the owner is. But we do know that the lettering on the sign and the dish names look familiar — because we copied down the old menu. If we hadn’t, yesterday’s record would have said only “an address we’ve never seen, three files.”

The router and home camera in your house right now walk past that sign every day. If nobody writes down the menu, what we know stays at 0.

This post is based on the 2026-08-21 honeypot observation set. Origin IPs are written exactly in the masked form from the brief, and distribution addresses have been altered (defanged) so they will not connect. The credentials quoted include only the 20 pairs observed from 3 or more different IPs; for the 806 pairs observed from fewer than that, only the count is disclosed and the values are not listed.