The Shelf Life of a Hash Was One Day — The One Thing That Didn't Spoil Was the First Line

Open the refrigerator and you’ll find milk and salt sitting side by side. Both are food, but they last for different lengths of time. Milk spoils in a few days; salt stays the same for years.

So when we clean out the refrigerator, we look at a different date for each item. We don’t throw everything out on the same day, and we don’t leave everything in either.

The blocklists we use in security are exactly like a refrigerator. All sorts of values get mixed into the list. File fingerprints, addresses, file names, sequences of behavior. But these values have different shelf lives. Some spoil in a day; some last nine.

The records left on our server yesterday actually measured those shelf lives.

Yesterday, One List Spoiled in a Single Day

FACT Let’s put the numbers down first. The day before yesterday (8/23) we wrote down the fingerprints of three executables. c71d74ce… (48,352 bytes) · 344bbdca… (57,104 bytes) · 9f1897ce… (58,848 bytes). Here are the fingerprints of the three files that came down from the same address under the same names yesterday. 29fb2896… (40,372 bytes) · 95f5156a… (55,648 bytes) · 6210a1c6… (57,456 bytes).

FACT All three are different. Not one matches.

Let me unpack one unfamiliar term here. A hash (fingerprint) is a 64-character value computed from an entire file. Change a single character inside the file and the value changes completely. That’s why we use this value when we record “this file is dangerous.” Think of it as one fingerprint attached to each file, like a human fingerprint.

FACT The address where the files sit is hxxp://176[.]65[.]139[.]202, the same as the day before. The address is written in deliberately broken form (hxxp://, [.]) — copy and paste it and it won’t connect. The file names are also the same as the day before: daredevil.armv7l · daredevil.mips · daredevil.mipsel. The incoming alias is the same too, ATK-31C779 (94.154.x.x), and the way in was the same as well — telnet.

FACT Same spot, same names, different contents. The sizes shrank by 7,980 · 1,456 · 1,392 bytes respectively. The first lost about 16.5% of its original size; the other two are in the 2% range.

INFERRED The blocklist built from the three fingerprints we wrote down the day before missed entirely within 24 hours. It was milk.

Yesterday, in Chronological Order

Laid out in chronological order, it looks like this. Pay attention to the times on the top five lines. They’re spaced not in hours or minutes but in seconds.

1. 13:25:50Z ~ 13:25:55Z
   FACT Yesterday's featured session ①. ATK-31C779 (94.154.x.x), telnet login success. About 4.79 seconds, 3 commands, 3 downloads. 4 intent types — reconnaissance (system) · file download · granting execute permission · execute after download. completeness 22. TTY recorded (contents not included). Because it's telnet, the fingerprint and client values are empty strings
2. 13:26:14Z ~ 13:26:18Z
   FACT Featured session ②. Re-entry about 18.4 seconds after the first session ended. About 4.70 seconds, 3 commands, 4 downloads, same 4 intent types, completeness 25
3. 13:27:30Z ~ 13:27:35Z
   FACT Featured session ③. About 71.9 seconds after the second ended. About 4.73 seconds, 3 commands, 4 downloads, completeness 25 — every value identical to ②
4. 13:28:06Z ~ 13:28:17Z
   FACT Featured session ④. The longest (about 11.55 seconds) and heaviest of this alias's sessions yesterday — 6 commands, 6 downloads, completeness 33 (yesterday's highest). Twice the volume of the sessions before and after it
5. 13:28:41Z ~ 13:28:46Z
   FACT Featured session ⑤. About 4.99 seconds, 3 commands, 3 downloads, completeness 22. From the start of the first session to here is about 2 minutes 55.3 seconds, and the total duration of the 5 sessions is about 30.8 seconds. All 5 had login_success=true and were never blocked at any point
6. Entire observation window (sample details)
   FACT There are 6 samples for which ATK-31C779 is the sole delivery source — ① hxxp://176[.]65[.]139[.]202:80/telnet.sh, 2,107-byte POSIX shell script (ad19b70c…, 6 times) ② daredevil.armv7l, 40,372-byte ELF 32-bit LSB ARM EABI4 (29fb2896…, 5 times) ③ daredevil.mips, 55,648-byte ELF 32-bit MSB MIPS-I (95f5156a…, 5 times) ④ daredevil.mipsel, 57,456-byte ELF 32-bit LSB MIPS-I (6210a1c6…, 3 times) ⑤ daredevil.armv5l, 50,096-byte ELF 32-bit LSB ARM version 1 (eb05c127…, 1 time) ⑥ daredevil.armv6l, 55,772-byte ELF 32-bit LSB ARM EABI4 (06c0d953…, 1 time). All 5 ELFs are statically linked · no section header, and one of each adds up to 261,451 bytes
7. Entire observation window (archive comparison)
   FACT The day before yesterday (8/23), the fingerprints and sizes of the 3 ELFs from this distribution point were c71d74ce… (48,352) · 344bbdca… (57,104) · 9f1897ce… (58,848), while yesterday's 3 under the same names were 29fb2896… (40,372) · 95f5156a… (55,648) · 6210a1c6… (57,456) — all fingerprints differ and the sizes shrank by 7,980 · 1,456 · 1,392 bytes respectively. The loader telnet.sh, by contrast, is ad19b70c… · 2,107 bytes, identical two days running
8. Entire observation window (archive comparison)
   FACT ATK-CA5936, the featured alias of 8/19, reappeared after five days. The samples for which this alias is the sole delivery source yesterday are a 399-byte OpenSSH private key (43728fbf…, 1 time) and a 54-byte ASCII text (00b6f15c…, 1 time), completely identical to the fingerprints recorded on 8/19. Note, however, that on 8/19 each file appeared 3 times, while yesterday each appeared once
9. Entire observation window
   FACT SSH client fingerprint clusters totaled 41, the most in the confirmed range (8/17 33 → 8/18 36 → 8/19 37 → 8/20 37 → 8/21 38 → 8/22 40 → 8/23 40 → yesterday 41). The largest cluster is f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6) with 19 IPs yesterday · 216 cumulative, a maximum in both same-day and cumulative terms. Of the 9 listed, the only cluster that actually delivered a sample is 16443846184eafde36765c9bab2f4397 (SSH-2.0-Go, 4 IPs yesterday · 28 cumulative), and 8/21 · 8/22 · 8/23 had 0
10. Entire observation window
    FACT A 389-byte OpenSSH RSA public key (a8460f44…) was left by 19 distinct sources. Same fingerprint as 8/16~8/23, so nine days running. The source count fell for three straight days — 8/20 8 → 8/21 10 → 8/22 8 → 8/23 6 — then rebounded to 19 yesterday, and the intent classification 'persistence — planting SSH keys' rebounded alongside it: 8/21 11 → 8/22 9 → 8/23 7 → yesterday 22
11. Entire observation window
    FACT The 306-byte POSIX shell script (a6296a79…) at hxxp://185[.]93[.]89[.]72/wget came down again yesterday with the same fingerprint — eight days running, following 8/17~8/23. The sources numbered 4, however, the lowest compared with 8/17 6 · 8/18 13 · 8/19 7 · 8/20 8 · 8/21 5 · 8/22 15 · 8/23 6
12. Entire observation window
    FACT A 1,608-byte Bourne-Again shell script came down from hxxp://5[.]182[.]210[.]174/ok with yet another new fingerprint (7fc87b54…). The source was a single one, ATK-10149C, 1 time — the same alias as the day before. The cumulative fingerprints at this URL now number 8 since 8/18 — the size is 1,608 bytes every time
13. Entire observation window
    FACT Aggregate values: 809 sessions, 201 unique sources, port 2222 (SSH) 512 · 2223 (telnet) 297, 410 login attempts, 612 commands, 258 TTY recordings. The telnet share is about 36.7%, double 8/23's 18.2%. The intent distribution is reconnaissance (system) 130, granting execute permission 123, file download 54, execute after download 47, persistence (planting SSH keys) 22, trace deletion 21, totaling 397 — a difference of 215 from the 612 total commands
14. Entire observation window
    FACT Credential combinations counted but not reproduced number 308. That's fewer than any of the 8 archived records (8/16 934 · 8/17 830 · 8/18 1,388 · 8/19 848 · 8/20 440 · 8/21 806 · 8/22 703 · 8/23 1,007). Only 6 combinations cleared the quoting threshold (3 or more distinct IPs)

FACT The first thing you see in the table is the top five lines. It started at 13:25:50 and ended at 13:28:46. Five times within about 2 minutes 55 seconds. Even adding up all the time actually connected inside that window comes to only about 30.8 seconds. The rest is empty time between leaving and coming back.

Five Times in Three Minutes, and All Five Got In

FACT What we featured yesterday is the alias ATK-31C779 (94.154.x.x). It came in over telnet. Telnet is a very old remote access method. Put simply, it’s a passage left open so someone on the other side of the internet can type directly into that machine’s command prompt — and passwords flow through it unencrypted.

FACT The gaps between the five are about 18.4 seconds · 71.9 seconds · 30.8 seconds · 23.5 seconds. All five fit inside the three minutes you spend waiting after pouring water into a cup of instant noodles.

FACT And all five logins succeeded. All five times, nothing stopped anything.

FACT Only the fourth session has a different shape. The other four are about 4.7~5.0 seconds with 3 commands, but the fourth alone is about 11.55 seconds with 6 commands and 6 downloads. Exactly double the volume of the sessions on either side. Its completeness value, 33, is also the highest of yesterday.

INFERRED Four at five seconds, one at eleven. A person typing by hand doesn’t come out this even. It leans toward a fixed sequence being replayed.

FACT We have to draw a line here, though. We don’t keep source IPs as-is; we record them converted into aliases beginning with ATK-. Because a value called a salt is mixed in during that process, a different date produces a different alias even for the same IP. The ATK-31C779 in the day-before-yesterday’s records and the ATK-31C779 in yesterday’s are values you can only trace within a single day.

What Was Taken — Yesterday It Was Five Types

FACT Six files were recorded yesterday with this alias alone as the delivery source.

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 sheet of A4 paper.
• ELF — the executable file format used on Linux. Think of it as the equivalent of Windows’s .exe.
• statically linked — it means carrying every needed part inside itself. It borrows nothing from outside, so it runs on any Linux using that CPU regardless of distribution or version.
• no section header — it means the signpost describing how the file is divided into regions has been stripped out. It makes life harder for anyone taking it apart.

FACT armv5l · armv6l · armv7l · mips · mipsel are all CPU types. They aren’t compatible with each other. The day before there were three types; yesterday it became five. It’s the approach of bringing everything because you don’t know which one fits — and yesterday two more slots got added.

FACT And yesterday too, not a single x86-family build for ordinary PCs and servers. ARM and MIPS families are the common specs on devices like routers, IP cameras, and NAS boxes. Not the machines on the office desk, but the ones mounted on ceilings and walls.

FACT Adding up one of each of the five comes to 261,451 bytes. About 255KB — smaller than a single smartphone photo. This arrives inside a five-second session.

And What Didn’t Spoil — One Line at the Front

FACT telnet.sh has fingerprint ad19b70c…, size 2,107 bytes. Not one character different from the day before. It’s the only file at this distribution point that didn’t change yesterday.

FACT This file is a loader. It doesn’t contain the executables itself; it serves as a note that says “fetch this from there and run it.” It’s the first page in the sequence observed yesterday.

INFERRED So two things happened at once yesterday. The contents of the delivered list were entirely swapped out within a day, while the note holding that list stayed the same. Depending on what a fingerprint-based blocklist was aimed at, yesterday’s outcome comes out the exact opposite way.

FACT Laying out the shelf lives of the values measurable from yesterday’s data, it looks like this. These are the number of consecutive days the same value was confirmed in the archive.

FACT The one-day item and the nine-day item are in the same table. It amounts to putting milk and salt in the same compartment with the same date stuck on both.

FACT hxxp://5[.]182[.]210[.]174/ok stands out in particular. The size is 1,608 bytes every single time, yet only the fingerprint keeps changing. Since 8/18, eight cumulative types have come from this one address.

How They Got In — Passwords Again Yesterday

FACT Yesterday’s login attempts numbered 410. Lower than any value in the 8 archived records (8/17 1,168 · 8/18 1,581 · 8/19 975 · 8/20 2,251 · 8/22 3,324 · 8/23 1,187).

INFERRED Spread across a full day, that works out to someone trying the doorknob about once every 3 minutes 30 seconds. The 809 sessions come to about once every 1 minute 47 seconds. It was on the quiet side.

FACT And yet the breach happened on the quiet day. Yesterday’s top 5 sessions by completeness were all login successes, and all 5 belong to the same alias.

FACT Narrowing to combinations observed from 3 or more distinct IPs gives this.

FACT Look at the fourth row. The password field is empty. Four distinct sources each attempted to log in with “just a blank.” It means they know machines exist where that works.

FACT And 308 combinations we did not reproduce. Those are the ones that appeared from fewer than 3 distinct IPs. A combination that appeared from only one place could be someone’s actual account leaked somewhere, so we count them without writing the values. 308 is the lowest of the 8 archived days.

FACT One number overlaps in three places. The sources for the 345gs5662d34 combination number 19, the largest SSH fingerprint cluster had 19 IPs yesterday, and the sources that left the 389-byte public key number 19.

INFERRED They could be the same 19. But the data doesn’t connect these three values to each other. Because there’s no way to distinguish this from a coincidental overlap, we don’t write “the same” here.

Two Files Back After Five Days

FACT ATK-CA5936, the featured alias of 8/19, appeared again in yesterday’s records. It left two files: a 399-byte OpenSSH private key (43728fbf…) and a 54-byte ASCII text (00b6f15c…). Both are completely identical to the fingerprints recorded on 8/19. On 8/19, though, each appeared 3 times; yesterday each appeared once.

FACT Among the SSH fingerprint clusters that day, exactly one cluster actually delivered a sample. It’s 16443846184eafde36765c9bab2f4397 (SSH-2.0-Go). It’s the same value the 8/19 record noted as ATK-CA5936’s fingerprint. 8/21 · 8/22 · 8/23 had 0 such clusters, so it’s the first in four days.

FACT Here too we draw a line. Fingerprint clusters are built from the composition of the greeting a connecting program sends first. So this is a fingerprint of a build, not a fingerprint of a person. People who don’t know each other but use the same distribution and the same libraries end up with the same value. We can say “the same tool” and no further — we can’t say “the same organization.”

FACT And this method can’t be applied to yesterday’s five most complete intrusions in the first place. That’s because being telnet, the fingerprint and client values are empty strings. Telnet has no such greeting procedure to begin with.

FACT Meanwhile, the 389-byte OpenSSH RSA public key (a8460f44…) appeared with the same fingerprint for nine consecutive days. The source count fell for three straight days and then rebounded to 19 yesterday, and the ‘planting SSH keys’ intent jumped along with it, from 7 to 22. 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 gets you in without a password ends up hanging by the front door. Change every password and that key remains.

What Was Left Behind

Here are all the samples and addresses observed yesterday. Click a value to copy it — fingerprints exist to be put into blocklists, not to be read. hxxp:// and [.] have been left as they are. Read the description column alongside to see which line is a one-day item and which is a nine-day item.

FACT Read this list from top to bottom and yesterday’s story shows itself. The top six lines are the values we had to write down anew yesterday, and the bottom three lines are the same values for the seventh, eighth, and ninth day. They sit in the same list but they last different lengths of time.

Mapped onto 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’re welcome to verify rather than take our word for it. All of it is [INFERRED]. What we saw are commands, not the attacker’s intent.

• T1110Brute Force — 410 login attempts, 6 combinations above the quoting threshold + 308 unquotedINFERRED
• T1078.001Valid Accounts: Default Accounts — all 5 complete sessions logged in successfully with admin/admin, root/root, root/123456 and the likeINFERRED
• T1082System Information Discovery — 'reconnaissance — system' 130 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 54 times, 'execute after download' 47 times, 12 sample typesINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'granting execute permission' 123 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — planting SSH keys' 22 times, 389-byte public key from 19 sourcesINFERRED
• T1070Indicator Removal — 'trace deletion' 21 timesINFERRED
• T1608.001Stage Capabilities: Upload Malware — the single host 176[.]65[.]139[.]202 served one loader together with per-architecture ELFs two days running, and in between only the ELFs were replacedINFERRED
• T1027.002Obfuscated Files or Information: Software Packing — the record contains an indicator that only emerged after decompressionINFERRED

FACT A caveat has to be attached to the last line. The ‘indicator that only emerged after decompression’ underlying T1027.002 came from a sample on a different host (31[.]77[.]227[.]121). Whether yesterday’s five daredevil files are packed is not in the record. So that line is not a judgment about yesterday’s samples. For T1070 (erasing traces) as well, without the original command text we can’t say what was erased, so we didn’t attach a sub-technique.

If It Looks Familiar

INFERRED The distribution pattern overlaps with the Mirai botnet family and its derivatives, which have continued since 2016. The method is to get in via default telnet accounts, fetch a loader shell script, then download statically linked executables built separately per CPU type in sequence and run whichever fits. Yesterday’s observed lineup of armv5l · armv6l · armv7l · mips · mipsel and the absence of x86 match this family’s distribution pattern of targeting embedded Linux devices rather than servers. The fact that derivative families frequently rebuild after the source was released, so fingerprints keep changing, also overlaps with yesterday’s observation. This is an incident with a US CISA (formerly US-CERT) alert TA16-288A and public analysis reports from several vendors on record.

INFERRED It also lines up with the Gafgyt (Bashlite/Lizkebab/Torlus) family. The structure is getting in via weak telnet/SSH credentials, then fetching and running per-architecture binaries with shell commands alone. The short-session shape, where the entire process finishes in a few lines of commands, overlaps with yesterday’s roughly 4.7~11.5 seconds.

FACT That said, our data contains no basis for determining the malware’s family name. So we write no further than “the shape is similar.” daredevil is merely an observed file name, not a family name or a campaign name.

So What Should You Do

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

1. Change default accounts and initial passwords. All 5 complete sessions yesterday were login successes. If you’re using even one of the six combinations in the table above, that’s all it takes. From login success to obtaining the executables took about 4.7 seconds.
2. Turn off remote access like telnet. Telnet yesterday was 297. Total sessions fell by more than half, from 1,523 on 8/23 to 809, yet telnet stayed right in the same band as 8/19 299 · 8/20 297 · 8/21 281 · 8/23 277. It means it gets hammered constantly regardless of the total volume. And with telnet the password flows through in the clear and the option of key authentication doesn’t exist at all — there’s no method other than turning it off. Look for “remote access,” “Telnet,” or “remote management” in your router or home camera settings and turn it off.
3. Block your devices from fetching files from outside. Yesterday: file download 54 times, granting execute permission 123 times, execute after download 47 times. Login has already been breached by this point, so this is the last place where actual damage gets stopped. If there had been no path out, only the loader note would remain and the 261,451 bytes of executables would never arrive.
4. Rate-limit failed logins and repeated connections. The same source came in five times within three minutes and nothing caught it. But this alone stops only half — the 345gs5662d34 combination came from 19 sources exactly 19 times, and root/3245gs5662d34 from 11 sources 11 times, meaning exactly once per source. Per-IP limits don’t catch those who spread their knocking out this way. Both shapes were observed on the same day.
5. Get alerted when the ~/.ssh/authorized_keys file changes. Yesterday: key-planting intent 22 times, 19 sources leaving a public key with the same fingerprint. A planted key remains even if you change every password.
6. Store logs off the device. Trace-deletion intent was 21 times yesterday, triple the 7 on 8/23. If the logs aren’t outside the machine, there’s no getting them back once they’re erased. And logs are the reason this post exists at all — because the day-before’s records survived, we could tell that “the names are the same but the fingerprints diverged.” Look at a single day only, and yesterday’s six files all get recorded as ‘never seen before.’
7. Operate on the premise that fingerprint lists have a shelf life. Yesterday is the proof. The executable fingerprints didn’t survive 24 hours, while one loader fingerprint was still valid on the second day. Don’t fill the list with fingerprints alone — keeping values that change less often (addresses, naming patterns, behavior sequences) alongside them is the direction yesterday’s data points to.

FACT “Use key authentication instead of passwords” is a middling recommendation as far as yesterday’s data goes. That’s because the complete sessions where login succeeded were all telnet, and telnet has no key authentication.

Yesterday in Full

That’s an average of about 4.0 sessions and about 2.0 attempts per source.

FACT Set side by side with 8/23, sessions fell 1,523→809 and login attempts 1,187→410. The 809 sessions are the lowest of the confirmed values (8/20 2,607 · 8/22 3,553 · 8/23 1,523). And yet telnet alone held steady, 277→297. With the total volume drained away, the telnet share doubled from 18.2% to about 36.7%.

INFERRED The telnet side appears to be a separate current running independently of the overall trend. A quiet day doesn’t mean less exposure risk. Yesterday is the example — on the quietest day, the architectures grew from three types to five.

The distribution points and C2s observed yesterday (176[.]65[.]139[.]202, 185[.]93[.]89[.]72, 5[.]182[.]210[.]174) were reported to C-TAS. Only transport-layer success is confirmed; whether KISA ingested them requires separate verification.

In 60 Seconds

We also made a short video of the same observation set. The video focuses on showing the three that changed and the one that didn’t side by side.

What We Don’t Know

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

• Which session received what. The downloads across the 5 featured sessions sum to 20 (3+4+4+6+3), but the observation counts of the 6 samples for which this alias is the sole delivery source sum to 21 (6+5+5+3+1+1). They’re off by 1. The record doesn’t map sessions to samples one to one. In particular, we can’t confirm why the loader telnet.sh was observed 6 times when there were only 5 sessions.
• Why the three ELFs’ fingerprints changed. We have no basis for judging whether compile options changed, whether new configuration values such as the address to connect to got baked in, or whether it’s entirely different code. Only the fact that the sizes shrank by 7,980 · 1,456 · 1,392 bytes respectively is confirmed. Results from taking the samples apart internally are not in this record.
• What’s written inside the loader. That telnet.sh has the same fingerprint two days running is confirmed, but which architectures it tries and in what order is unknowable. Nor can we confirm whether the difference between 3 types the day before and 5 yesterday came from adding files to the distribution point without changing the loader.
• Whether 176[.]65[.]139[.]196 (8/21) and 176[.]65[.]139[.]202 (the day before yesterday and yesterday) are the same operator. There’s no basis beyond the first three octets matching. We don’t even have operator information. This item, left on 8/23, stands unchanged yesterday.
• Whether the ATK-CA5936 of 8/19 and the ATK-CA5936 of yesterday are the same person. Since the alias is the same, it does point to the same masked source. But an alias is not an identity. We can’t rule out that the party using that address changed over those five days.
• Whether the 399-byte private key was planted or was being taken. The record doesn’t distinguish the two. It’s in the download list but the address field is empty. The same item left on 8/19 remains as it was.
• Whether the fingerprint cluster list is a top-N or the full set. The cluster total is 41 but the list has 9. So “only one cluster delivered a sample yesterday” is a fact within the scope of those 9.
• Why the two TTY recording figures differ. The aggregate value is 258, but another field says 156. The difference in how the two are defined isn’t explained, so we don’t assert which is the actual count held. In either case, the recorded contents are not included in this post.
• The difference of 215 between 612 commands and the intent-classification total of 397. About 35.1% went unclassified. There may be other intents inside that we didn’t describe yesterday.
• Whether the three ’19’s are the same set. The credential combination 345gs5662d34, the libssh_0.9.6 fingerprint cluster, and the 389-byte public key are all 19. The record doesn’t connect the three values, so we can’t distinguish this from coincidence.
• One Discord webhook address. Whether it came from yesterday’s samples or is a cumulative list isn’t specified, so we didn’t use it in yesterday’s account.
• Whether the C-TAS report was ingested or acted on. Only transport-layer success was confirmed.
• Background vulnerability statistics. The 6,579 tracked CVEs · 386 CISA KEV entries · 98 confirmed ransomware cases are background figures pulled from KISA security notices. They don’t connect directly to yesterday’s honeypot observations — there was no trace of a CVE being referenced in yesterday’s SSH/telnet attacks.

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 don’t have GeoIP or ASN databases. We don’t guess.
• Geolocation — same. On top of that, IP geolocation isn’t a basis for attribution to begin with. No country, no company, and no individual is identified as an attacker in this post.
• VPN/Tor/cloud status — we have no means of determining it.
• VirusTotal detection results — not integrated. How yesterday’s five daredevil ELFs are detected by antivirus, and what family they’re called, is something we cannot say. 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/telnet attacks mostly don’t reference vulnerabilities, and yesterday’s observations were all credentials.
• Raw source material — the basis for this post does not include original command text, payload contents, or TTY session playback. Source IPs have their last two octets masked, and aliases are salted values, so they’re not something to be reversed.

We started with the refrigerator.

What we learned yesterday is exactly that much. The three fingerprints we wrote down the day before spoiled within a day. The address was the same, the names were the same, and only the contents had been swapped. And the slots for targeted devices grew from three to five.

Some things didn’t spoil. One note at the front, telnet.sh, 2,107 bytes. The same 306-byte script for the eighth day. The same 389-byte public key for the ninth. The one-day item and the nine-day item sit inside the same list.

Put milk and salt in the same compartment with the same date on both, and every morning you’ll either throw out something fine or leave something spoiled sitting there. Writing down how many days this value is good for alongside it when you build the list — that’s the one thing yesterday’s data recommends.

And the five things carried off five times over three minutes yesterday were all for devices, not for PCs. The router serving you this page right now, the home camera in the corner of the living room, the NAS under the desk. Those are the machines these things run on.

This post is based on honeypot observations from 2026-08-24. Source IPs are written in the masked form from the brief, and distribution addresses have been altered (defanged) so they won’t connect. The credentials quoted include only the 6 combinations observed from 3 or more distinct IPs; the 308 combinations observed from fewer than that are reported by count only, with no values included.