The Knocking Was Ordinary — Everything After the Door Opened Was a Ten-Day High

The ground floor of a large building usually keeps two ledgers.

One is the standing-access list. If your name is on it, you walk in without being checked each time. Tenant-company staff, the contracted cleaning crew, the regular delivery driver. Put a name on it once and it stays valid.

The other is the visitor log. A sheet of paper recording who came in at what time and left at what time. It exists so that if something happens later, you can trace it back.

When we think about building security, we usually look only at the front door. Is it locked, is the passcode hard, who keeps rattling the handle. But once an incident actually happens, the problem turns out to be not the door but the two ledgers. When did an unfamiliar name get onto the list, and which line of the log went missing.

The records left on our server yesterday told exactly that story. The number of knocks was ordinary. The number of times the two ledgers were touched was a high.

Yesterday, Only the Ledger Numbers Spiked

FACT Let me start with the numbers that didn’t spike. Yesterday we observed 1,652 sessions and 1,229 login attempts. Spread evenly across a full day, that works out to someone trying the door handle about once every 1 minute 10 seconds. That is not far from usual.

FACT Of the 1,329 commands executed, “Reconnaissance — system” accounted for 899, about 67.6%. That is the behavior of coming in and checking “what kind of machine is this?” File downloads at 89 and post-download execution at 82 are not unusually high either.

FACT But three items spiked.

FACT Here are the first two items exactly as they stood across the ten days. “SSH key implantation” ran 8/16 9 · 8/17 13 · 8/18 18 · 8/19 16 · 8/20 9 · 8/21 11 · 8/22 9 · 8/23 7 · 8/24 22. “Indicator removal” ran 8/16 9 · 8/17 13 · 8/18 19 · 8/19 13 · 8/20 8 · 8/21 12 · 8/22 8 · 8/23 7 · 8/24 21. Values that had bounced between single digits and the low twenties for ten straight days suddenly became 69 and 70 yesterday.

FACT 69 times spread over a day is about once every 21 minutes. 70 times is about once every 20 minutes 30 seconds. Once in the time it takes to grab a coffee at work, all day long.

INFERRED And the two numbers differ by exactly one. Names added to the list: 69. Lines erased from the log: 70. We cannot say these two values were executed as a pair — we’ll come back to this in “What We Don’t Know.” What we can say is that yesterday was the first day in these ten days when three post-intrusion stages all hit their maximum on the same day. We read it as an increase in “settling in after getting in,” not in “trying to get in.”

Yesterday in Chronological Order

Laid out in time order, it looks like this. It’s a long list, but pay attention to the times on the fourth and fifth lines, and on the sixth and seventh lines. They overlap by seconds, not minutes.

1. Entire observation window
   FACT "Persistence — SSH key implantation" intent, 69 times. A 389-byte OpenSSH RSA public key (sha256 a8460f44…) was observed from 21 different sources. This fingerprint matches the 8/16–8/24 records, making it the same file ten days running. The source-count trend went 8/16 10 → 8/17 12 → 8/18 16 → 8/19 12 → 8/20 8 → 8/21 10 → 8/22 8 → 8/23 6 → 8/24 19 → 21 yesterday, the maximum across the confirmed window
2. Entire observation window
   FACT "Indicator removal" intent, 70 times. From 8/16 9 · 8/17 13 · 8/18 19 · 8/19 13 · 8/20 8 · 8/21 12 · 8/22 8 · 8/23 7 · 8/24 21 to 70 yesterday — about 3.3× the maximum of the confirmed window. It differs from persistence's 69 by one
3. Entire observation window
   FACT "Impair defenses" intent, 2 times. 8/16 · 8/17 · 8/18 · 8/22 were 1 each, 8/19 was 0, and 8/20 · 8/21 · 8/23 · 8/24 had no such entry at all. Yesterday was the first time in the confirmed window that this value reached 2
4. 01:54:24Z ~ 01:54:32Z (KST 10:54)
   FACT ATK-31C779 (94.154.x.x), successful telnet login. 5 commands and 6 downloads over about 8.06 seconds. Four intents — reconnaissance (system) · file download · granting execute permission · post-download execution. completeness 33. TTY recorded (contents not included). Because it was telnet, the fingerprint and client values are empty strings
5. 01:56:12Z ~ 01:56:20Z
   FACT The same alias ATK-31C779 came back about 1 minute 48 seconds after the first session began. About 8.08 seconds, 5 commands, 6 downloads, 4 intents, completeness 33 — every value identical to the first session. Both were successful logins, and neither was stopped
6. 04:28:22Z ~ 04:29:34Z (KST 13:28)
   FACT ATK-C53A45 (45.224.x.x), successful telnet login. 22 commands and 11 downloads over about 72.10 seconds. Intent was "impair defenses" alone. completeness 42, yesterday's highest. TTY recorded
7. 04:29:02Z ~ 04:30:17Z
   FACT ATK-7A654C (124.168.x.x), successful telnet login. 22 commands and 11 downloads over about 75.06 seconds, intent "impair defenses" alone, completeness 42 — all five values identical to the previous session, differing only in the masked source. The two sessions were open simultaneously for about 32.38 seconds, from 04:29:02 to 04:29:34
8. 10:52:19Z ~ 10:52:43Z (KST 19:52)
   FACT ATK-50016C (220.135.x.x), successful telnet login. 20 commands and 11 downloads over about 24.06 seconds. The intent array is empty, yet completeness is 40. TTY recorded
9. 8/23 → 8/24 → 8/25 comparison
   FACT Sessions from the same alias ATK-31C779 were observed three days running, and grew in scale. The 8/23 record: about 5.1 seconds · 3 commands · 4 downloads · completeness 25; the 8/24 record: about 4.79 seconds · 3 commands · 3 downloads · completeness 22; yesterday: about 8.06 seconds · 5 commands · 6 downloads · completeness 33. An alias is a value that points to the same source across records; it is not an identity
10. 8/18 · 8/22 · 8/25 comparison
    FACT The combination "telnet · successful login · 22 commands · 11 downloads · intent impair-defenses alone · all 11 files 1-byte empty files · completeness 42" appears once each, standing alone, in the 8/18 record (ATK-ABE8B7, about 75 seconds) and the 8/22 record (ATK-F604B7, about 19.7 seconds). Yesterday this combination appeared twice in one day, from different sources, and overlapping in time. The durations (72.1 seconds · 75.1 seconds) are closer to 8/18's roughly 75 seconds than to 8/22's 19.7 seconds
11. Entire observation window
    FACT Download events for the 1-byte empty file with no magic number (sha256 01ba4719…) numbered 33, and the delivering sources were only three: ATK-C53A45 · ATK-7A654C · ATK-50016C. Since each of those three sessions had 11 downloads, 11×3=33 matches exactly
12. Entire observation window
    FACT The loader telnet.sh at 176[.]65[.]139[.]202 is sha256 ad19b70c… at 2,107 bytes, with fingerprint and size completely identical across 8/23, 8/24, and yesterday — three days running. By contrast, the 5 daredevil ELF binaries on the same host all have different fingerprints from 8/24, and all five grew in size — armv7l +852, mips +1,140, mipsel +1,268, armv5l +832, armv6l +856 bytes. The five together went from 259,344 bytes on 8/24 to 264,292 bytes yesterday. The targeted architectures went 3 on 8/23 → 5 on 8/24 → 5 yesterday, holding steady
13. Entire observation window
    FACT From hxxp://5[.]182[.]210[.]174/ok, a 1,608-byte Bourne-Again shell script came down yesterday under two different fingerprints (dae728b8…, 4c0c071d…), once each. Adding yesterday's 2 to the 8 cumulative fingerprints tallied for this URL through 8/24 makes 10, and since first observation on 8/17 the size has been exactly 1,608 bytes every time. It has been rebuilt ten times over nine days without the file size changing by a single byte
14. Entire observation window
    FACT A 31-byte ASCII text file (sha256 a2f3d6d2…) was yesterday's most-downloaded sample at 46 times, yet the delivering source was a single one, ATK-E150E4, and that alias does not appear in the featured session list. No URL was recorded
15. Entire observation window
    FACT A 399-byte OpenSSH private key (sha256 43728fbf…) was observed twice, from two sources, ATK-CA5936 · ATK-2DE05A. Those same two sources also left a 54-byte ASCII text file (00b6f15c…). This fingerprint also appears in the 8/23 record
16. Entire observation window
    FACT 11 SSH client fingerprints were recorded. The most common was acaa53e0… (SSH-2.0-OpenSSH_7.4) at 125 sources yesterday · 139 cumulative, followed by f555226d… (SSH-2.0-libssh_0.9.6) at 24 sources yesterday · 245 cumulative. Of the 11, only one actually delivered a sample: 16443846… (SSH-2.0-Go, 4 sources yesterday · 28 cumulative). All 5 featured sessions that logged in successfully yesterday were telnet, so their fingerprint values are empty
17. Entire observation window
    FACT Aggregate figures: 1,652 sessions, 361 unique sources, 1,387 on port 2222 · 262 on port 2223, 1,387 SSH · 262 telnet by protocol, 1,229 login attempts, 1,329 commands, 1,007 TTY recordings. The telnet share was about 15.9%, down from about 36.7% on 8/24. Of the 1,329 commands, "Reconnaissance — system" at 899 is about 67.6%. There were 15 samples and 134 download events, and the distribution hosts with recorded external URLs were three: 176[.]65[.]139[.]202 (6 samples) · 185[.]93[.]89[.]72 (1 sample) · 5[.]182[.]210[.]174 (2 samples)
18. Entire observation window
    FACT Of the 1,229 login attempts, 20 combinations were observed from 3 or more distinct IPs and are therefore quotable verbatim, while 1,017 combinations were observed from only a single source and are not published. The most frequent was 345gs5662d34/345gs5662d34 at 18 sources, followed by admin/admin at 13, root/admin at 7, and root/3245gs5662d34 at 7

FACT Two places in the table catch the eye. One is 01:54 and 01:56 — the same source came in twice about 1 minute 48 seconds apart, and both times the door opened. The other is 04:28 and 04:29 — two different sources were open simultaneously for about 32 seconds.

The Name on the List — the Same Single Line for Ten Days

FACT Let me unpack what “SSH key implantation” means here. A Linux machine has a file called authorized_keys (the list of permitted keys). If a line is in that file, the machine lets you in without asking for a password. In building terms it’s the standing-access list, and one line is one name.

FACT The public key observed yesterday is 389 bytes. About the length of two text messages. Once those two lines are on the list, the password is no longer the gate.

FACT And this file’s fingerprint (sha256) is a8460f44…, identical for ten straight days from 8/16 through yesterday. It was left by 21 sources, the maximum across the confirmed window. The trend looks like this.

FACT The same name has been written down for ten days. The number of hands doing the writing rose to twenty-one, but what gets written is unchanged. For reference, the 8/17 and 8/18 records note this file as having been created inside the session rather than downloaded from outside. That’s why the download address is empty on some days.

INFERRED Here’s what matters. No matter how many times you rattle the door handle, one failure ends it. But once a single line goes onto the list, it stays valid from then on. Change every password and the list is still there. Yesterday’s 1,229 attempts and that one line on the list are values of an entirely different nature.

FACT And the fact that this key has had the same fingerprint for ten straight days means that if any machine anywhere succeeded in getting it onto the list on any one of those ten days, it still opens to the same name today.

Lines Erased from the Visitor Log — 70 Times

FACT The second ledger. Yesterday the “indicator removal” intent was recorded 70 times. About 3.3× the previous day’s 21.

FACT But a line has to be drawn here. Our records do not contain the raw commands. Only the intent classification. So we cannot say exactly what those 70 removals erased — log files, downloaded files, or command history. That is the reason no sub-technique is attached in the MITRE mapping below.

FACT “Impair defenses” was 2. It looks like a small number, but over ten days this item was either 0 or 1 every day, and on four days there was no such entry at all. Yesterday was the first time it became 2. Here too, the records do not say what was turned off.

INFERRED Put in ledger terms, here is what happened yesterday. A name went onto the list, and a line was erased from the log. The way in was left open, and the way already traveled was covered over. That these two hit their highs side by side on the same day is the most striking part of yesterday’s record.

Two Eight-Second Sessions, Two Seventy-Two-Second Sessions

FACT Five featured sessions logged in successfully yesterday, and all of them were telnet. Telnet is a very old method of remote access. Put simply, it is a passage left open so that someone across the internet can type directly into that machine’s command prompt — and the password travels in the clear, unencrypted.

FACT The first two are the alias ATK-31C779 (94.154.x.x). Once at 01:54:24, once at 01:56:12. About 1 minute 48 seconds apart. Both sessions ran about 8.06 and 8.08 seconds, 5 commands, 6 downloads, completeness 33 — all five values identical.

FACT The same alias appeared three days running, and grew in scale.

FACT completeness is a score for how far through an intrusion, from beginning to end, a single session got. Come in, look around, leave — low. Download a file and run it — high.

FACT But a line has to be drawn about aliases. We do not record source IPs as-is; we convert them into aliases beginning with ATK-. An alias is a value that points to the same source, not an identity. We cannot rule out that whoever was using that address changed over those three days.

FACT The next two are at 04:28 and 04:29. ATK-C53A45 (45.224.x.x) for about 72.10 seconds, ATK-7A654C (124.168.x.x) for about 75.06 seconds. 22 commands, 11 downloads, intent “impair defenses” alone, completeness 42. All five values identical, differing only in the masked source. And the two sessions were open simultaneously for about 32.38 seconds.

FACT This combination is not new. “Telnet · successful login · 22 commands · 11 downloads · impair defenses alone · all 11 files 1-byte empty files · completeness 42” is recorded standing alone once on 8/18 (about 75 seconds) and once on 8/22 (about 19.7 seconds). Yesterday it appeared twice in one day, from different sources, and overlapping in time.

FACT Here the grouping method we normally use doesn’t work. When someone comes in over SSH, we can build a fingerprint from the composition of the greeting their client sends first, and group “the same tool” together. Yesterday 11 such fingerprints were captured, and the most common one, acaa53e0… (OpenSSH_7.4), groups 125 IPs in a single day. But all five doors that actually opened yesterday were telnet, so the fingerprint value is an empty string. Telnet has no such greeting procedure at all.

INFERRED So whether the two sessions that overlapped at 04:29 were the same tool cannot be determined by fingerprint. The entire basis is that the behavioral figures match — 22 commands, 11 downloads, 1-byte empty files.

FACT To add: a fingerprint is the fingerprint of a build, not of a person. Two people who don’t know each other, both using the default program from the same distribution, will have the same value. That is why this blog writes only “the same tool” and never “the same organization.”

FACT A word about those 1-byte empty files too. One byte in size — a single character’s worth — and without even the marker that identifies a file type. Observed 46 times… 33 times yesterday, from only three delivering sources, and since each of the three sessions had 11 downloads, 11×3=33 matches exactly. Whether something was being fetched and came back empty, or an empty file was what was fetched in the first place, the records do not say.

The Distribution Hosts — the First Sheet Unchanged for Three Days

FACT Three distribution hosts had external addresses recorded. The addresses are written deliberately broken (hxxp://, [.]) — copying and pasting them will not connect.

FACT From 176[.]65[.]139[.]202 came the loader telnet.sh (2,107 bytes) and 5 executables, one per CPU type. A loader does not contain the executable itself; it is a note that says only “fetch this from there and run it.” This loader, fingerprint ad19b70c…, size 2,107 bytes, is not a single character different across 8/23, 8/24, and yesterday — three days running.

FACT Conversely, the 5 executables all have different fingerprints from 8/24, and all five grew in size.

FACT Adding the five together, one each, gives 264,292 bytes yesterday, up from 259,344 bytes on 8/24. About 258KB, smaller than one smartphone photo. And this arrives inside an eight-second session.

FACT armv5l · armv6l · armv7l · mips · mipsel are all CPU types, and they are not compatible with one another. There was again not a single x86-family binary — the kind that runs on ordinary PCs and servers — yesterday. ARM and MIPS families are common specifications in devices like routers, IP cameras, and NAS units.

FACT The third distribution host, 5[.]182[.]210[.]174/ok, remains strange. In yesterday alone, two different fingerprints came down, once each. Since first observation on 8/17 the cumulative fingerprint count is 10, yet the size is exactly 1,608 bytes every time. Rebuilt ten times over nine days without the file size changing by a byte. Why, we cannot explain — we don’t have the file contents.

FACT Yesterday’s most-downloaded sample was, unexpectedly, a 31-byte text file. 46 times. Yet the delivering source was a single one, ATK-E150E4, and that alias is not in the featured session list. No address was recorded either. It was yesterday’s most-downloaded sample and we don’t know what session it was.

How They Got In — Passwords Again Yesterday

FACT Yesterday there were 1,229 login attempts from 361 distinct sources. An average of about 3.4 attempts per source.

FACT We publish verbatim only combinations observed from 3 or more distinct IPs. Yesterday that was 20.

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

FACT The top entry, 345gs5662d34/345gs5662d34, is not a string a person would come up with. Username and password are the same, and 18 different sources tried exactly this value. root/3245gs5662d34 came from 7 sources.

INFERRED We read this as carrying around a list of hardcoded factory defaults for particular devices. Which manufacturer’s devices is not in our records.

FACT And 1,017 combinations we did not publish. Those are the ones that came from only a single source. A combination seen at only one place could be someone’s actual account leaked somewhere, so we count them without writing the values.

What They Left Behind

Here are all the samples and addresses observed yesterday. Click a value to copy it — fingerprints exist to go into a blocklist, not to be read. hxxp:// and [.] are left as-is. The top two lines and the bottom line are the heart of yesterday’s story — the same public key for ten straight days, and the loader unchanged for three.

FACT Read this list top to bottom and yesterday’s two faces come into view. The middle five lines are values that had to be rewritten in a single day, while the top and the bottom are values unchanged for ten days and three days. They sit in the same list, but they endure for different lengths of time.

Mapped to Attack Stages

Mapping the observed behaviors onto the international classification table MITRE ATT&CK gives the following. Click an ID to read the original description directly — you don’t have to take our word for it. All of this is [INFERRED]. What we saw were commands, not the attacker’s intent.

• T1110.001Brute Force: Password Guessing — 1,229 login attempts, 361 unique sources, 20 quotable combinations + 1,017 non-quotableINFERRED
• T1078.001Valid Accounts: Default Accounts — many default-value combinations such as admin/admin at 13 sources · root/root at 4 · guest/guest at 3 · config/config at 3, and all 5 featured sessions logged in successfullyINFERRED
• T1082System Information Discovery — "Reconnaissance — system" 899 times, about 67.6% of all 1,329 commandsINFERRED
• T1105Ingress Tool Transfer — "file download" 89 times, 15 samples · 134 download events, 3 external distribution hostsINFERRED
• T1222.002File and Directory Permissions Modification: Linux and Mac — "granting execute permission" 145 timesINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — "post-download execution" 82 times, 4 of the delivered samples were shell scriptsINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — "Persistence — SSH key implantation" 69 times, the 389-byte public key from 21 sources. However, download events for this public key number only 21, which does not match the 69INFERRED
• T1070Indicator Removal — "indicator removal" 70 times. Without the raw commands we do not know what was erased, so no sub-technique is attachedINFERRED
• T1562Impair Defenses — "impair defenses" 2 times. We cannot tell what they tried to disable, so no sub-technique is attachedINFERRED
• T1608.001Stage Capabilities: Upload Malware — the single host 176[.]65[.]139[.]202 served one loader together with per-architecture ELF binaries for three days running, and in that span only the ELF binaries were swapped out. Who operates that host cannot be confirmedINFERRED
• T1027.002Obfuscated Files or Information: Software Packing — the records contain indicators that only emerged after decompressionINFERRED

FACT A qualifier is needed on the last line. The 12 “indicators that only emerged after decompression” underlying T1027.002 came from samples on a different host (31[.]77[.]227[.]121). They point to 12 architectures under that host’s /bins/, and from the outside not a single address is visible. Whether yesterday’s five daredevil binaries are packed is not in the records. So this line is not a judgment about yesterday’s samples.

FACT The T1098.004 line also has numbers that don’t line up. The intent classification is 69, while download events for the public key are 21. More than a threefold gap. This is the largest unresolved item in yesterday’s record, so we write it up separately below.

If This Looks Familiar

INFERRED The distribution shape overlaps with the 2016 Mirai botnet. Log in over telnet using a list of hardcoded default credentials, then fetch the per-architecture executable staged on an HTTP server that matches the device type. Yesterday’s arrangement — “successful telnet login → loader shell script → five daredevil binaries” — has the same shape. It is also commonly known that the source code was published and many derivative strains exist. The basis is the US-CERT/CISA public alert TA16-288A and the published source code.

INFERRED It meshes with TeamTNT’s 2020 Linux and cloud campaigns at a different point. Plant the attacker’s public key in authorized_keys to secure a foothold, and in the same stage disable security programs and erase logs and history. Yesterday’s 69 persistence · 70 indicator removal · 2 impair defenses all peaking on the same day connects to that shape contextually. Threat reports from multiple security vendors document it.

FACT That said, our data contains no raw commands, so there is no basis to say it is the same tool. So we write only “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 This is the order yesterday’s data points to.

1. Open ~/.ssh/authorized_keys right now. Yesterday: 69 key implantations, 21 sources leaving a public key with the same fingerprint. If there is a line in that file you don’t remember registering, that’s all it takes. Change every password and that line remains. And since this key has had the same fingerprint for ten straight days, any machine where implantation succeeded on any one of those ten days still opens today.
2. Store logs off the device. 70 indicator removals, about 3.3× the previous day. If the logs live only on that machine, there is no way to recover them once they’re erased. And the reason this article exists at all is logs — because ten days of records were kept, we can say “69 is 3× the usual.” Look at one day alone and 69 is just 69.
3. Change default accounts and factory passwords. All 5 featured sessions were successful logins. If you are using even one of the 20 combinations in the table above, it’s the same as having no lock. From successful login to obtaining the executable took about 8 seconds.
4. Turn off remote access like telnet. About 84% of yesterday’s traffic was SSH, yet all five doors that actually opened were telnet. The telnet share came down from about 36.7% on 8/24 to about 15.9% yesterday, and the outcome was the same. Meaning: the share falls, but the side that gets breached doesn’t change. On top of that, telnet sends passwords in the clear and offers no key-authentication option at all — there is no approach other than turning it off. In your router or home-camera settings, look for “remote access,” “Telnet,” or “remote management” and disable it.
5. Don’t expose management access directly to the internet. Yesterday 1,652 connections came from 361 sources. If access were permitted only from specific ranges or from behind a VPN, most of those 361 could not open a session at all.
6. Block your devices from fetching files from outside. 89 file downloads, 145 grants of execute permission, 82 post-download executions. Login has already been breached by this point, so this is the last place where real damage is actually prevented. With no outbound path, only the loader note is left behind and the 264,292 bytes of executables never arrive.
7. Rate-limit failed logins and repeat connections — but don’t stop at that alone. The same source came in twice, 1 minute 48 seconds apart, and succeeded both times, and at 04:29 two sources were open simultaneously for 32 seconds. Up to here, IP-level blocking can cut it off. But the 345gs5662d34 combination came from 18 sources exactly 18 times, and root/3245gs5662d34 from 7 sources 7 times — exactly once per source. IP-level limits don’t catch someone knocking in that scattered way. Both shapes arrived together yesterday, so blocking alone stops only half.

FACT We reordered the list. Normally “passwords first” is number one, but in yesterday’s data checking the list and getting logs off the box come first. No matter how well you change the password, it makes no difference if a name is already on the list.

The Whole Day

That’s an average of about 4.6 sessions and about 3.4 attempts per source. Spread across the day, 1,652 sessions is about one every 52 seconds.

FACT Three more values to add here. 1,007 TTY recordings, 15 samples, 134 download events. A TTY recording is a record left so that the screen exchanged within that session can be rewound and watched as it was. It’s thanks to these recordings that we could reconstruct the order in which 5 commands flowed inside an eight-second session. The recording contents themselves are not included in this article.

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

In 60 Seconds

We also made a short video from the same observation set. The video focuses on placing 1,229 attempts and one key side by side.

What We Don’t Know

This blog writes what it knows and what it doesn’t know separately. Here is what could not be confirmed in yesterday’s observations.

• The gap between 69 and 21. “Persistence — SSH key implantation” is 69, but download events for the 389-byte public key number 21. A gap of more than threefold, and the records do not link intent counts to sample counts. We cannot confirm whether all 69 planted this key, or whether some involved a different key or a method not captured as a download. This article’s title hangs on this number, so it is the largest unresolved item.
• Whether 70 and 69 are a pair. We have no basis to determine whether the one-count difference between the two values results from being executed as a pair within the same session, or whether two unrelated streams simply happened to land close together. There is no value giving per-session intent counts.
• Whose the 2 “impair defenses” were. We read them as belonging to the two sessions at 04:28 and 04:29, but that is an inference based on count matching — those two sessions each had “impair defenses” as their sole intent, and yesterday’s total count was also 2. The records do not state it.
• Where 3 sessions went. The aggregate is 1,652, but the per-protocol sum (SSH 1,387 + telnet 262) is 1,649. We cannot tell how the 3 were classified.
• The difference of 27 between 1,329 commands and an intent total of 1,356. It appears multiple intents can attach to a single command, but the formula is not in the records.
• Which port they came in on. We recorded the featured sessions’ connection port as 2223 on the basis that the 262 telnet sessions exactly match the 262 on port 2223. The records do not directly link individual sessions to ports. In addition, 2222 and 2223 are ports our observation equipment left open, and are not the same as 22 and 23 on an ordinary server.
• How many sessions ATK-31C779 had. The two sessions listed sum to 12 downloads, but the observation counts for the 6 samples whose sole delivering source is this alias sum to 24 (5+5+5+5+2+2). It appears there were additional sessions from the same alias not in the list, but we cannot tell how many.
• The completeness formula. ATK-50016C has no intents at all yet scores 40, while ATK-C53A45 and ATK-7A654C have one intent each and score 42. The formula is not in the records, so we cannot explain it. The same item also remains in the 8/18 · 8/21 · 8/22 records.
• Why the five ELF binaries’ fingerprints changed. We have no basis to judge whether compile options differed, whether new configuration values such as an address to connect to were baked in, or whether it is entirely different code. Only the fact that sizes grew by 832 to 1,268 bytes is confirmed. Results from taking the samples apart internally are not in these records.
• Why 5[.]182[.]210[.]174/ok is always 1,608 bytes. Ten fingerprints emerged over nine days while the size stayed exactly the same every time. It could be a method of swapping in strings of the same length, but without the file contents this stays speculation.
• What session yesterday’s most-downloaded sample belonged to. A single source, ATK-E150E4, pulled the 31-byte text 46 times, but there is no address and the alias is not in the featured session list either.
• How the 399-byte private key appeared in the session. The records do not distinguish whether the attacker brought it or it was generated on the server.
• One Discord webhook address. It is not stated which session or which sample it connects to, so we did not use it in yesterday’s write-up. We have excluded it for the same reason for eight days since 8/17. A webhook’s token string is itself a value that can be abused, so we do not reproduce it in the body.
• Background vulnerability statistics. 6,579 tracked CVEs · 387 CISA KEV entries · 98 confirmed ransomware cases and the top 5 CVEs by EPSS are background figures drawn from KISA security advisories. They do not connect directly to yesterday’s honeypot observations.
• A miswritten total on 8/24. The 8/24 record put the 5-ELF total at 261,451 bytes, but adding the individual sizes in the same record gives 259,344 bytes. Yesterday’s increase/decrease comparison was calculated using the re-summed individual sizes.
• Whether the C-TAS report was ingested or acted on. Only transport-layer success was confirmed.

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

• ASN and ISP — we do not have GeoIP or ASN databases. Which provider 176[.]65[.]139[.]202 · 185[.]93[.]89[.]72 · 5[.]182[.]210[.]174 · 31[.]77[.]227[.]121 each sit with, or whether they are on the same network, we cannot say.
• Geolocation — likewise not held. In addition, IP geolocation is not a basis for attribution to begin with. From the masked sources 94.154.x.x · 45.224.x.x · 124.168.x.x · 220.135.x.x we do not read a country.
• VPN / Tor / cloud status — we have no means of determining it. Whether the 361 sources are genuinely 361 distinct actors, or how many are the same relay, cannot be confirmed.
• VirusTotal detection results — not integrated. How yesterday’s 5 daredevil ELF binaries and 4 shell scripts are detected by antivirus, and what family names they are given, 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 and telnet attacks mostly do not reference vulnerabilities, and yesterday’s observations were all credential-based. We did not link any session to a specific vulnerability.
• Raw material — the basis for this article does not include raw commands, payload contents, or TTY session playback. So what exactly the 70 “indicator removal” events erased, and what the 2 “impair defenses” turned off, we cannot say.
• The name daredevil — it is merely an observed file name. We did not interpret it as a malware family name or a campaign name.
• Who they are — we do not name any specific country, company, or individual as the attacker. We don’t even have geolocation.

We started with the ledgers.

That is about all we learned yesterday. The number of knocks was ordinary. 1,229 attempts, about one every 1 minute 10 seconds. On that number alone, yesterday would have gone down as a quiet day.

But what happened after the door opened was different. A name added to the standing-access list 69 times, a line erased from the visitor log 70 times. Both ten-day highs, and exactly one apart. And “impair defenses,” which had been 0 or 1 every single day for ten days, became 2 for the first time.

The name on the list is the same single line for the tenth day running, 389 bytes. The length of two text messages. What those two lines do lasts longer than rattling the door handle 1,229 times.

So what yesterday’s data recommends is one thing. Don’t just watch the front door — look at the two ledgers. Whether there’s a name on the list you don’t recognize, and whether the log lives only inside that building in the first place. Check after it’s been erased and there’ll be nothing left there.

This article is based on honeypot observations from 2026-08-25. Source IPs are shown in the masked form used in the brief, and distribution addresses have been defanged so they will not connect. The credentials quoted include only the 20 combinations observed from 3 or more distinct IPs; for the 1,017 combinations observed from a single source, we state only the count and do not publish the values.