They Swapped the Name Tag — Our List Missed in Two Days

The fastest way to recognize someone at school is the name tag. You just read the few letters pinned to their chest. So a rule like “these names are banned from the snack shop” works beautifully — right up until someone swaps their name tag.

Name tags can be changed. But some things are hard to change. Like the habit of walking into the snack shop and picking up the same things in the same order every time. Triangle kimbap first, then milk, then jelly. Take off the name tag and pin on a new one, and that order stays exactly the same.

What our server logged yesterday was exactly that scene. The name tag had been swapped; the order of pickup was unchanged.

First, the list of name tags we had written down

FACT We keep 12 addresses where malicious files are staged on our watchlist. All of them sit under hxxp://31[.]77[.]227[.]121/bins/: parm·parm5·parm6·parm64·parm7·pm68k·pmips·pmpsl·pppc·psh4·pspc·x86_64. The address is deliberately written in broken form (hxxp://, [.]) — copy and paste it as-is and it will not connect.

FACT See the pattern? A folder named /bins/, and file names that put a CPU type after a p. That was the list of name tags we had.

FACT Those 12 did not come for free. They are addresses that only appeared after unpacking files that had been wrapped in a compressor called UPX. Look only at the packed exterior and not a single address is visible. It was a list that took real work.

FACT And the distribution host 176[.]65[.]139[.]196, which first appeared the day before yesterday (8/21), matched that convention letter for letter. /bins/ path, px86·pmips. That is why we could recognize it as the same family on day one, even though the address was new to us.

FACT Yesterday, the file names that actually came down were these: telnet.sh·daredevil.armv7l·daredevil.mips·daredevil.mipsel. No folder path either. Not one of them overlaps with any name on the list of 12.

INFERRED They swapped the name tag. Two days. That was the shelf life of a list built on names alone.

But the first digits of the student ID matched

FACT All four of those files came down from one place: hxxp://176[.]65[.]139[.]202. This address appears nowhere in seven days of records from 8/16 through 8/22. Yesterday was the first time.

FACT But the distribution host from the day before yesterday was 176[.]65[.]139[.]196. The first three segments are identical. An IP address is four segments split by dots, and matching first three segments means they sit inside the same address block. It is like sharing the leading digits of a student ID.

FACT This is where we must not take another step. Being in the same class does not make you the same person. Companies that lease out internet addresses hand adjacent addresses to people with no relationship to each other. Living next door is not the same as living in the same house.

FACT On top of that, we do not even have the means to confirm whether those two addresses belong to the same company. We do not hold a database that tells us which operator an address belongs to. So here, “we don’t know” is the correct answer.

Yesterday in chronological order

Laid out in order, the day looks like this. Watch how closely the numbers in the top two lines and the bottom 10:19 line — these three lines — match each other. They resemble one another down to the second.

1. 00:11:46Z ~ 00:11:51Z
   FACT Yesterday's featured session ①. ATK-31C779(94.154.x.x), successful Telnet login. Over about 5.11 seconds, 3 commands and 4 downloads. 4 intent types — reconnaissance (system) · file download · granting execute permission · execute after download. completeness 25. TTY recorded (contents not included). Because it is Telnet, the fingerprint and client values are empty strings
2. 00:11:46Z ~ 00:11:51Z (sample detail)
   FACT There are exactly 4 samples for which ATK-31C779 is the sole delivery source, each observed 3 times. ① hxxp://176[.]65[.]139[.]202:80/telnet.sh — 2,107-byte POSIX shell script (ad19b70c…) ② hxxp://176[.]65[.]139[.]202/daredevil.armv7l — 48,352-byte ELF 32-bit LSB ARM EABI4, statically linked, no section header (c71d74ce…) ③ hxxp://176[.]65[.]139[.]202/daredevil.mips — 57,104-byte ELF 32-bit MSB MIPS-I, statically linked, no section header (344bbdca…) ④ hxxp://176[.]65[.]139[.]202/daredevil.mipsel — 58,848-byte ELF 32-bit LSB MIPS-I, statically linked, no section header (9f1897ce…). The four total 166,411 bytes
3. 00:12:45Z ~ 00:12:50Z
   FACT Featured session ②. The same alias ATK-31C779 came back about 53.8 seconds after the first session ended. About 5.03 seconds, 3 commands, 4 downloads, 4 intent types, completeness 25 — every value identical to the first session
4. 02:13:52Z ~ 02:14:24Z
   FACT ATK-F2B80A(121.161.x.x), successful Telnet login. Over about 32.6 seconds, 48 commands (the most yesterday), 12 downloads (the most yesterday), completeness 43 (yesterday's highest). Yet the intent array is empty. The samples for which this alias is the sole delivery source are a 1-byte empty file (01ba4719…, 11 times) and a 202-byte POSIX shell script (0c99433c…, 1 time), and 11+1=12 matches the download count. Cross-checking the archive, ATK-792ADF on 8/21 matches on all of 48 commands · 12 downloads · 2 sample hashes · 0 intents · completeness 43, with only the duration growing from about 23.7 seconds to about 32.6 seconds
5. 06:52:56Z ~ 06:53:57Z
   FACT ATK-ADE2BE(45.43.x.x), successful Telnet login. 17 commands over about 60.6 seconds. 5 intent types, the most yesterday — reconnaissance (system) · file download · granting execute permission · execute after download · persistence (planting an SSH key). Yet the download count is 0. completeness 17. This is the sixth occurrence of the same shape, following 8/18 (ATK-C17F4E) · 8/19 (ATK-103570) · 8/20 (ATK-B4B2E2) · 8/21 (ATK-4CA329) · 8/22 (ATK-5A0689), and it matches 8/21 exactly down to 17 commands · 5 intent types · 0 downloads · completeness 17
6. 10:19:30Z ~ 10:19:34Z
   FACT Featured session ③. ATK-31C779's third visit. About 10 hours 6 minutes 40 seconds after the second session ended. About 4.91 seconds, 3 commands, 4 downloads, 4 intent types, completeness 25 — every value identical to the previous two sessions. Twice before dawn, once during the day, and all three times nothing stopped it
7. Entire observation window (archive cross-check)
   FACT The distribution host 176[.]65[.]139[.]202 appears in none of the seven records from 8/16 to 8/22. It shares its first three segments with 176[.]65[.]139[.]196, recorded as a first observation on 8/21, but the convention differs — 8/21 had a /bins/ path, 'p+architecture' names (px86·pmips), statically linked stripped, 133,452~244,420 bytes, while yesterday had no path (root), 'daredevil.architecture' names, no section header, 48,352~58,848 bytes. 8/22 had 0 ELF files, so this is a return after two days
8. Entire observation window
   FACT A 1,608-byte Bourne-Again shell script came down from hxxp://5[.]182[.]210[.]174/ok again yesterday, but 2 different hashes were recorded at the same URL and the same size — d3e76949… and 31283c34…, both from a single source, ATK-10149C, once each. This is the second time after 8/21 that 2 variants appeared within one day, and the cumulative hash count for this URL from 8/18 through yesterday is 7 (6aa5054a · b7728639 · c850a285 · 7a5dcc03 · 6ff53177 · d3e76949 · 31283c34)
9. Entire observation window
   FACT A 389-byte OpenSSH RSA public key (a8460f44…) was left by 6 different sources. This hash was also present from 8/16 to 8/22, making it eight consecutive days. The source count went 8 on 8/20 → 10 on 8/21 → 8 on 8/22 → 6 yesterday. The intent classification 'persistence — planting an SSH key' appeared 7 times, declining for a third day: 11 on 8/21 → 9 on 8/22 → 7 yesterday
10. Entire observation window
    FACT Command intent distribution — reconnaissance (system) 980 times, about 52.6% of all 1,863 commands (26.1% on 8/22), granting execute permission 212 times, file download 55 times, execute after download 50 times, trace deletion 7 times, persistence (planting an SSH key) 7 times, reconnaissance (network) 1 time. 'Disabling defenses', recorded once on 8/22, has no entry at all for yesterday. The intent classification total is 1,312, a difference of 551 from the command total

FACT Two lines in the table catch the eye. One is ATK-F2B80A at 02:13 — the most commands and the most downloads yesterday, yet not a single intent was classified. The other is ATK-ADE2BE at 06:52 — the widest intent spread at 5 types, yet zero files taken. Both have big numbers with no basis for explaining what happened. That is why we did not make either of them yesterday’s subject.

Five seconds, three times a day, not a single value off

FACT What we made yesterday’s subject is ATK-31C779(94.154.x.x). It came in over Telnet. Telnet is a very old method of remote access. Put simply, it is a passage left open so someone across the internet can type directly into that machine’s command prompt, and the password travels across it unencrypted, as-is.

FACT The stay lasted about 5.11 seconds. In that span it entered 3 lines of commands and took 4 files. About the time it takes to tear open a packet of instant noodles.

FACT Then it came back 53.8 seconds later. About 5.03 seconds, 3 commands, 4 downloads. Not one value differs from the first.

FACT The third was about 10 hours 6 minutes later, at 10:19:30. About 4.91 seconds, 3 commands, 4 downloads. Identical again. Twice before dawn, once during the day. All three times the login succeeded, and all three times nothing blocked it.

FACT Here is that habit of walking into the snack shop and picking up the same things in the same order. Reconnaissance → fetch files → grant execute permission → execute. All three times the 4 intent types are the same and the completeness value is the same 25.

INFERRED A human doing this by hand does not come out this way. Repeating a five-second run three times without the command count or the file count being off even once is closer to meaning a fixed sequence was simply replayed.

FACT But even here we have to draw a line. We do not keep the source IP as-is; we record it as an alias beginning with ATK-. Because a value called a salt is mixed in when doing so, a different date produces a different alias even for the same IP. And all that survives masking is the first two segments — the 94.154.x.x range alone holds 65,536 addresses. The session that took executables on 8/21 was also written as 94.154.x.x, but we cannot say it is the same place.

What the four downloaded files were

FACT Here is what the four are.

There are four unfamiliar terms here, so let me unpack them on the spot.

• Shell script — a note with commands written down in order. Instead of a person typing them line by line, running one file makes them execute in the written order. 2,107 bytes is less text than fills a single sheet of A4.
• ELF — the executable file format used on Linux. Think of it as the equivalent of Windows’ .exe.
• statically linked — it means carrying every needed part inside itself. Since it borrows nothing from outside, it runs on any Linux using that CPU, regardless of flavor or version.
• no section header — it means the signboard that lays out the regions inside the file has been stripped off. It makes life harder for anyone taking it apart.

FACT armv7l·mips·mipsel are all CPU types. They are not compatible with each other. That is why all three were taken — not knowing which one fits, you grab all three.

FACT And here a characteristic of yesterday’s data emerges. There is not a single x86-family executable, the kind that runs on ordinary PCs and servers. ARM·MIPS·MIPSEL are common specifications on the device side — routers, IP cameras, NAS boxes. On 8/21, x86 and MIPS came together; yesterday, only the device side came.

FACT The four together come to 166,411 bytes. A single photo is usually much bigger than that. That came in within about 5 seconds, and across three runs about 487KB passed through.

INFERRED What let us follow this host across yesterday was not the name. It was ① the fact that the first three segments of the address match the host from two days earlier, and ② the shape of the behavior — ‘log in over Telnet → one small shell script → statically linked executables per CPU type’. Not the name tag, but the order of pickup.

The layer where fingerprints show up, and the layer that actually gets breached

FACT Connections coming in over SSH leave a client fingerprint. The composition 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 this fingerprint cluster count was 40, the same as 8/22 and tied for the record high (33 on 8/17 → 36 on 8/18 → 37 on 8/19 → 37 on 8/20 → 38 on 8/21 → 40 on 8/22).

FACT The largest cluster is f555226df1963d1d3c09daf865abdc9a(SSH-2.0-libssh_0.9.6), with 7 IPs yesterday and 201 cumulative. On 8/22 it was 8 IPs and 182 cumulative, so the cumulative count grew by 19 in one day.

FACT And yet not one of the 9 clusters on the list delivered any sample. That is zero for three days running.

FACT Conversely, the sessions that actually took the three executables yesterday were Telnet, so the fingerprint and client values are empty strings. All top 5 sessions by completeness are like that. Telnet has no such greeting procedure to begin with.

INFERRED Put together, the layer where fingerprints show up (SSH · 1,246 sessions) and the layer where things actually come down (Telnet · 277 sessions) have been split for three days. You can count 40 fingerprint clusters and those 40 still will not tell you where yesterday’s executable binaries came in.

FACT So the basis for tying yesterday’s three sessions together is not the fingerprint. It is the alias (ATK-31C779), the shape of the sessions (3 commands · 4 downloads · 4 intent types · completeness 25), and the fact that the delivery source for all four samples is this one alias. This means the same tool and the same automated sequence were used — not the same organization or the same person. The fingerprint value likewise is the fingerprint of a build, not of a person — strangers who have never met can share the same value simply by using the default client of the same distribution.

How they got in — passwords again yesterday

FACT Yesterday there were 1,187 login attempts. Taking the observation window as one full day, that is someone trying the doorknob about once every 73 seconds. The 1,523 sessions amount to a new connection about once every 57 seconds. (That said, the observation window is not stated in this record, so this calculation assumes a full day.)

FACT Origins numbered 222. That is the most since 8/18 (249). That averages about 6.9 sessions and about 5.3 attempts per origin.

FACT Filtering down to only the combinations observed from 3 or more different IPs gives this.

FACT Look at the eighth row. The password field is empty. Three different places each tried to log in with “just a blank.” That means they know there are machines where that works.

FACT And 1,007 combinations were not included. Those are the ones that appeared from fewer than 3 different IPs (934 on 8/16 → 830 on 8/17 → 1,388 on 8/18 → 848 on 8/19 → 440 on 8/20 → 806 on 8/21 → 703 on 8/22 → 1,007 yesterday). A combination that appeared from only one place could be someone’s actual account leaked somewhere, so we count them without printing the values.

FACT There is something odd here. The total volume of login attempts fell to about one third of 8/22’s, yet ‘combinations seen from only one or two places’ instead rose by a factor of 1.43. It could mean the bots were running non-overlapping lists, but the data does not confirm that.

FACT And adding up all attempts for the 15 combinations in the table above gives 97. That is about 8.2% of the total 1,187. It means what we can publish is only part of yesterday’s observations.

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

What they left behind

Here are all the samples and addresses observed yesterday. Click a value to copy it — hashes exist to go into blocklists, not to be read. hxxp:// and [.] are left as they are.

FACT Two lines in the list catch the eye: hxxp://5[.]182[.]210[.]174/ok. Same address, same size at 1,608 bytes, and only the hash differs. Two variants within one day. Since 8/18, seven cumulative variants have come from this single address. It means the file sitting in the same spot was quietly swapped. Why the approach of pinning a “this file is dangerous” name tag onto a hash keeps arriving late — these two lines are the answer.

FACT And the 389-byte OpenSSH RSA public key shows up with the same hash for an eighth day. 389 bytes is about two lines of a text message. If this small file goes into authorized_keys (the list of permitted keys) as a single line, a key that lets someone in without a password hangs on the front door. Change every password and that key remains.

Mapped to attack stages

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

• T1110Brute ForceINFERRED
• T1078.001Valid Accounts: Default 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
• T1608.001Stage Capabilities: Upload MalwareINFERRED

FACT Two lines need caveats. T1016 (network reconnaissance) rests on a single intent classified just once yesterday. T1070 (erasing traces) has only 7 occurrences, and since the original commands are absent we cannot say what was erased, so we did not attach a more specific sub-technique. The last one, T1608.001, rests on the fact that one host served out 1 loader script and 3 per-CPU executables together, and we cannot confirm who operates that host.

If this looks familiar

INFERRED The entry structure is the same as the Mirai botnet family and its derivatives, running since 2016. Get in via a default Telnet password, download a small shell script loader from a web server, then try, in order, statically linked executables built separately per CPU type. The combination ATK-31C779 took yesterday — one 2,107-byte loader plus three ARM·MIPS·MIPSEL statically linked ELF files, all coming down from one host in one session — fits that structure, as does the fact that all 15 quoted credentials are defaults or trivial combinations and that all 5 completed sessions went through Telnet with passwords. It is a case with U.S. Department of Justice indictments and guilty-plea records on file, and public analysis reports from multiple vendors.

INFERRED It also lines up with the Gafgyt (Bashlite/Lizkebab) family. The structure is: get into a Linux device via Telnet and a weak password, then have a shell script download and run statically linked executables per CPU. The fact that the three specifications observed yesterday consist only of device-family targets with no server-side x86, and that sample sizes are small at 48~59KB, fits this structure.

FACT These two cases point to exactly one thing. Both are open-source families, so it is common for entirely unrelated operators to each stand up their own distribution host and run the same sequence. Yesterday’s appearance of “a new host using a different naming convention than two days ago” also does not conflict with that direction.

FACT That said, these cases do not confirm any of yesterday’s individual judgments. Not the relationship between the two hosts, and not which family the name daredevil belongs to. A file name is just a name, not a family designation.

So what should you do

INFERRED Here is the order yesterday’s data points to.

1. Change default accounts and initial passwords. 1,187 login attempts, and all 5 completed sessions were successful logins. All 1,863 commands executed yesterday were run after a successful login. The featured session took about 5.1 seconds from successful login to securing three executables, and repeated the same thing three times in one day. If you are using a combination from the table above, that is all it takes.
2. Stop devices from fetching files from outside. Yesterday there were 55 file downloads, 212 grants of execute permission, and 50 execute-after-download events. Had outbound connections been blocked, ATK-31C779’s three sessions and ATK-F2B80A would all have been cut off at the download stage. Since the login was already breached, this was the last point at which actual damage could be prevented. On top of that, the three executables that came down yesterday are statically linked, so they run regardless of Linux flavor or version, and with no section header they are hard to take apart.
3. Turn off remote access like Telnet. Yesterday Telnet was 18.2% of all sessions. It came back down from 33.9% on 8/22. Yet the share of sessions that were actually breached and had commands executed was 100% both on 8/22 and yesterday. Set your defense priorities by traffic share and you will be wrong every day. In your router or home camera settings, find “remote access,” “Telnet,” or “remote management” and switch it off. Telnet sends passwords in the clear, and the option of key authentication does not exist at all — there is no method other than turning it off.
4. Limit failed login attempts. The single combination admin/admin was tried 37 times from 17 places and nothing caught it. The same origin came in twice within one minute, and then a third time ten hours later, without being blocked. At the same time, one session finishes in 5 seconds, so thresholds built around “long-lived connections” or “attempts accumulating slowly” will never trip in the first place. If your blocking decision is slower than 5 seconds, that block is an after-the-fact measure.
5. Get an alert when ~/.ssh/authorized_keys changes. Yesterday there were 7 key-planting intents and 6 sources that left the same-hash public key. ATK-ADE2BE was a session that saved not a single sample, yet it was still classified all the way to the key-planting stage. A session that downloaded no files gives antivirus no executable to scan. If you do not look at the key file directly, you will not even know you were breached.
6. Store logs off the device. Trace deletion was observed 7 times (19 on 8/18 → 13 on 8/19 → 8 on 8/20 → 12 on 8/21 → 8 on 8/22 → 7 yesterday). And the reason this post exists at all is the logs. Thanks to TTY recording we could retrace how 3 commands and 4 downloads flowed inside a five-second session (the contents are not included in this post), and because we did not erase seven days of records we could learn that “the new distribution host shares its first three segments with the host from two days ago while using a different naming convention” and that “the ATK-F2B80A session matches the 8/21 session on five values.” Look at one day alone and both are recorded as ‘something seen for the first time.’
7. Operate on the assumption that blocking rules built only from file-name and hash lists have a shelf life. Yesterday is the proof. Zero of the 12 on the list matched.

FACT “Use key authentication instead of passwords” is a medium-strength recommendation based on yesterday’s data. Every completed session with a successful login yesterday was Telnet, and Telnet has no key authentication. And the data does not break out how much of the 1,187 was SSH, so there is no basis to say “turning on key authentication would have stopped yesterday’s intrusion.”

The full day, yesterday

That averages about 6.9 sessions and about 5.3 attempts per origin.

FACT Placed next to 8/22, sessions went 3,553→1,523, commands 7,574→1,863, and login attempts 3,324→1,187 — everything came back down. Telnet also went 1,203→277, about a quarter (4.3×) of before, returning to the same band as 8/19·8/20·8/21’s 299·297·281. The executables came back on the day the numbers fell. Total traffic and actual damage do not move in the same direction.

The distribution hosts and C2 observed yesterday (176[.]65[.]139[.]202, 185[.]93[.]89[.]72, 5[.]182[.]210[.]174) and the watchlist’s 31[.]77[.]227[.]121 were reported to C-TAS. The core of yesterday’s report is the new host 176[.]65[.]139[.]202 and the hashes of the 4 samples it served out. Only transport-layer success is confirmed; whether KISA ingested it requires separate confirmation.

In 60 seconds

We also made a short video from the same observations. The video focuses on the fact that not one of the twelve names written down in advance matched.

What We Don’t Know

This blog writes what it knows and what it does not know separately. Here is what we could not confirm from yesterday’s observations.

• Whether 176[.]65[.]139[.]202 (yesterday) and 176[.]65[.]139[.]196 (8/21) are the same operator. The first three segments match, but they could be unrelated neighbors in the same address block. Companies that lease out internet addresses assign adjacent addresses to unrelated users. On top of that, we have no operator information, so we cannot even confirm whether the two addresses sit inside the same company.
• Why the 8/21 host (.196) is absent from the records again yesterday. That is 0 for two straight days. We cannot distinguish whether it is gone or alive but simply not sending requests to our honeypot. The same item left open on 8/22 remains unresolved yesterday.
• Why the 12 watchlist entries have been 0 for four straight days. Likewise, we cannot distinguish whether the distribution host stopped or simply did not come our way.
• What daredevil is. It is nothing but an observed file name. We did not interpret it as a malware family name or a campaign name, and the data gives no basis for that.
• Why ATK-31C779’s three sessions have 3 commands but 4 downloads. Whether one command fetched multiple files or something else, we cannot say without the original commands. The delivery source for all four samples is this single alias and each was observed 3 times, which lines up exactly with the three sessions, but the data contains no field directly linking sessions to samples — this is an inference based on the counts matching.
• Why three times in one day, two of them within one minute. We have no basis to distinguish whether the earlier session failed and was retried or whether that is simply how it cycles. All three logins succeeded and the download counts are the same.
• Why not a single intent was classified for ATK-F2B80A. 48 commands, yet the intent array is empty and completeness is 43, yesterday’s highest. The formula is not in the data, so we cannot explain it. The same item is on record for 8/18·8/21·8/22 as well.
• Why a 1-byte empty file was saved 11 times over. We do not know whether it is the result of failed downloads or intended behavior. The same item is on record for 8/17·8/18·8/21·8/22 as well.
• Whether ATK-ADE2BE failed to download or downloaded something that was not saved. The intents include ‘file download’ and ‘execute after download’, yet the download count is 0. This is the sixth occurrence since 8/18.
• Whether yesterday’s ATK-F2B80A session and 8/21’s ATK-792ADF session share an origin. Five values match, but aliases are generated with a salt mixed in, so they cannot be lined up. What is confirmable stops at the session shape and sample hashes being the same, and that means the same tool and the same automated sequence were used — not the same organization or the same person. We also do not know why the duration grew from about 23.7 seconds to about 32.6 seconds.
• Whether the session that took executables on 8/21 and yesterday’s featured session are the same place. Both are written in masked form as 94.154.x.x. But all that survives masking is the first two segments, so this range alone holds 65,536 addresses, and aliases cannot be compared across dates. We cannot say it is the same origin.
• Why hxxp://5[.]182[.]210[.]174/ok served two variants in one day. We do not know whether it is generated fresh per request or swapped on a short cycle, and since we do not hold the contents we cannot say what changed either. Since 8/18 this address has produced 7 cumulative hashes.
• Why 6 places left the same-hash public key. We do not know whether it is the result of using the same tool or of sharing a key. Because of the aliases, we also cannot sum source counts across dates or trace them to the same origin.
• What the three 9-byte ASCII texts (4af5a5c9…·a9b1c85a…·1193dde1…) are. The contents are not in the record. a9b1c85a·1193dde1 also appeared as a pair from one alias on 8/21, but yesterday it was a different alias, and aliases cannot be cross-checked across dates.
• Why the difference of 551 arises between the command total of 1,863 and the intent classification total of 1,312. There is no explanation of whether one command can be classified under multiple intents, or whether some commands go unclassified. The reconnaissance (system) share returning from 26.1% on 8/22 to 52.6% yesterday could have the same cause, but we cannot confirm it.
• The attempt counts for the 1,007 combinations we did not quote. The 15 quoted combinations total 97 attempts, about 8.2% of the whole. The 1,007 is a ‘combination count’, not an ‘attempt count’, so we cannot calculate how the remaining 1,090 attempts are distributed.
• Why Telnet fell from 1,203 to 277 while unique origins rose from 205 to 222. There is no explanation of what the 8/22 spike was or what caused yesterday’s decline.
• Whether the fingerprint list is a top-N or the full set. The cluster total is 40 while the list has 9. So “no cluster delivered a sample yesterday” is a fact within the scope of those 9.
• The cumulative tally for 0425c279…(SSH-2.0-PuTTY_Release_0.70). Yesterday it was 2 for the day and 3 cumulative, while the 8/21·8/22 records had 3 for the day = 3 cumulative. The start point and update method for the cumulative tally are not stated, making cross-date interpretation impossible.
• The nature of SSH-2.0-ZGrab ZGrab SSH Survey(fingerprint dd9bcf09…, 2 IPs yesterday, 42 cumulative). It is the name of a public internet scanner tool, but this data cannot distinguish whether it is for research/measurement or attack preparation.
• One Discord webhook URL. It is not stated which session or which sample it connects to, so we did not include it in yesterday’s factual record. We excluded it on 8/20·8/21·8/22 for the same reason. A webhook’s token string is itself a value that can be abused, so we do not reproduce it in the body.
• Whether the aggregate figures cover the full day. The main sessions span UTC 00:11~10:19 and the generation time is 15:05Z. The observation window is not stated. What we wrote above as “about once every 73 seconds” is also a calculation assuming a full day.
• The relationship between tty_recordings_available(148)·samples_on_honeypot(52) and the aggregate TTY recordings (1,063) and 13 sample types. There is no explanation.
• Why the background vulnerability statistics grew in a single day. Tracked CVEs rose by 1,992, from 4,556 to 6,548, CISA KEV listings rose 345→385, and ransomware associations rose 95→98. There is no explanation of whether the collection scope changed or this is a real increase. This is background statistics based on KISA security advisories and is not directly connected to yesterday’s observations — every intrusion path observed yesterday was credentials.
• Whether the C-TAS report was ingested or acted upon. Only transport-layer success was confirmed.
• Whether the intent list denotes execution order. It is not stated, so this post did not read the order of the intent array as the order of stage progression.

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 correct answer.

• ASN·ISP — we do not hold GeoIP or ASN databases. We do not guess. We also cannot say whether the new distribution host 176[.]65[.]139[.]202 and 8/21’s 176[.]65[.]139[.]196 are with the same operator or on the same network.
• Geolocation — same. IP geolocation is not a basis for attribution to begin with. We cannot say where the origin that came in three times yesterday is, and we do not name any particular country, company, or individual as the attacker.
• VPN·Tor·cloud status — we have no means of determination. We cannot distinguish whether the same origin coming in three times in one day is a fixed line or something rented temporarily.
• VirusTotal detection results — not integrated. We cannot say from this data what families the 13 samples saved yesterday, especially the 3 ELF files, are detected as. Sample classification uses MalwareBazaar tags.
• User-Agent — SSH and Telnet have no User-Agent at all. Nor can this source tell us what tool made the outbound requests to the distribution host. HTTP attacks are a separate source.
• CVE linkage — SSH and Telnet attacks mostly do not reference vulnerabilities, and yesterday’s observations were all aimed at passwords.

We started with the story of name tags.

That is about the extent of what we learned yesterday. The name tag was swapped in two days. Not one of the twelve we had written down, unpacking compressed files by hand, matched. We learned the leading digits of the student ID match, but being in the same class does not make you the same person.

What remained was the order. Come in over Telnet, take one sheet of notes, grab three executables by CPU type, and be gone in 5 seconds. They did that three times in one day. Names can be changed; the order is hard to change — change it and it stops working.

And all three of those were for devices, not PCs. The router feeding internet to the screen you are reading this on, the home camera in the corner of the living room, the NAS under the desk. What was grabbed three times in five seconds yesterday is the kind of thing that runs on those machines.

This post is based on honeypot observations from 2026-08-23. Source IPs are shown exactly in the masked form from the brief, and distribution addresses have been altered (defanged) so they will not connect. The quoted credentials include only the 15 combinations observed from 3 or more different IPs; the 1,007 combinations observed from fewer than that are reported by count only, with no values included.