The Same Twenty Seconds as Four Days Ago, Only 3.8× Faster

Have you ever put two videos from your phone side by side? One shot last year, one shot yesterday. Same place, same order of movements, even the same number of objects on screen. Only one thing differs: how long it took.

Two things follow from that. One is “because I recorded the same thing twice, I know it got faster” — that one holds. The other is “the same person shot both” — that one we don’t know. The person holding the camera never appears on screen.

What our server recorded yesterday was exactly that second video.

Yesterday at 20:34, or rather 11:34 UTC

FACT Yesterday at 11:34:14Z, ATK-F604B7 (45.6.x.x) logged in successfully over 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 across it unencrypted, in the clear.

FACT The session lasted about 19.7 seconds. It disconnected at 11:34:33Z. Within those 20 seconds it entered 22 commands and pulled down 11 files. That is more than one command line per second (about 1.12 per second). Files arrived at roughly one every two seconds (about 0.56 per second).

FACT And yet only one intent was classified. “Impair defenses” — commands classified as attempts to switch off whatever is doing the protecting.

FACT This session’s completeness value is 42, the highest of the entire day. Completeness is a score assigned to “how fully did we get to look at this session” — but how it is calculated is not in the data. We cannot explain why a session with only one intent scored highest either. We’ll come back to this later.

All 11 files it pulled down were empty files

FACT There is only one sample that has this alias as its sole delivery source, and it was observed 11 times. That matches the session’s download count of 11.

FACT Here is that one sample. 1 byte. A file with no identifying marker at all (very short file (no magic)). The front of a file usually carries a short marker saying “I am an executable” or “I am an image” — this file has none. There is no room for one.

FACT One byte is one character. All 11 together come to 11 bytes, eleven characters. Eleven exchanges over 20 seconds, and that was all of it.

INFERRED We stop here. Whether the download failed and left only a shell, or whether it works that way by design, we do not know. There is no raw command text and the screen recording contents are not included in this record, so we cannot say what was meant to be done with this file either.

Placing it beside the video from four days ago

FACT In the August 18 record there is a session called ATK-ABE8B7. Placed beside yesterday’s session, it looks like this.

FACT Seven rows match. Even the file’s fingerprint (sha256 hash) is the same value. The only difference is the last row: a time about 3.8× faster.

FACT But that “3.8×” is a rough comparison. The “about 75 seconds” for 8/18 is taken verbatim from what that day’s record says, while yesterday’s 19.7 seconds we calculated directly from the start and end timestamps. There is no way to confirm that the two values were measured the same way.

FACT And here is the important part. We cannot know whether they came from the same place. We do not keep the source IP as-is; we replace it with an alias beginning with ATK-. Because a value called a salt is mixed in when we do that, the same IP produces a different alias on a different date. Whether 8/18’s ATK-ABE8B7 and yesterday’s ATK-F604B7 are the same place cannot be checked from this record.

FACT What is confirmed goes this far and no further. The session’s shape is the same and the file’s fingerprint is the same. That means the same tool and the same automated execution sequence were used — it does not mean the same organization or the same person. Even when two videos match, the person who shot them doesn’t appear on screen.

FACT One more thing. The “impair defenses” classification appeared once per day on 8/16, 8/17, and 8/18, then 0 times on 8/19, and on 8/20 and 8/21 the category disappeared entirely. Yesterday it reappeared, once. On both 8/18 and yesterday, that single occurrence is attached to a session with completeness 42.

The busiest night, and zero executables came down

FACT Yesterday’s numbers look like this. 3,553 sessions, 3,324 login attempts, 7,574 commands executed. All three are the maximum across the six days in the archive. Compared with the previous maxima — 2,607 sessions (8/20) and 2,966 commands (8/18) — commands jumped two and a half times.

FACT Treating these as figures covering a full day, 3,324 login attempts means someone tried a password roughly once every 26 seconds. 3,553 sessions means a new connection came in roughly once every 24 seconds. (That said, the observation window is not stated in this record, so this calculation assumes a full day.)

FACT Telnet in particular spiked. Port 2223 (telnet): 1,203 sessions. The day before yesterday it was 281, so that is about 4.3× in a single day. The previous maximum was 370 on 8/18, so it is about 3.3× that. Telnet’s share of all sessions was 33.9%, the highest of the six days (8/16 12.0% → 8/17 22.0% → 8/18 18.3% → 8/19 22.0% → 8/20 11.4% → 8/21 15.2%).

FACT And yet, among the 5 samples stored yesterday, there is not a single Linux executable (ELF). ELF is the executable format used on Linux. Think of it as the equivalent of Windows’ .exe. What remained from yesterday is all of this.

FACT A shell script is a note with commands written down in order. Instead of a person typing them line by line, running one file makes them run in the written order. 306 bytes is about a paragraph’s worth of text; 1,608 bytes is about half a sheet of A4.

INFERRED In short, yesterday was the day the door got pounded on the hardest, but nothing was delivered inside. By the metrics alone it was the worst day since we started recording, yet the column for what actually arrived is empty.

To keep a record of what didn’t come

FACT We keep 12 URLs on a watch list. 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 addresses are deliberately written broken (hxxp://, [.]) — copying and pasting them will not connect.

FACT These 12 were not simply handed to us. They are addresses that only appeared once a file wrapped in a compression called UPX was unpacked. Looking at the compressed exterior alone, not one address is visible.

FACT Yesterday, downloads from these 12 addresses numbered 0. That is three consecutive days, following 8/20 and 8/21.

FACT Also, the distribution host 176[.]65[.]139[.]196, which first appeared the day before yesterday (8/21) and pushed out two executables, is entirely absent from yesterday’s record.

INFERRED Had we not written these 12 down in advance, yesterday’s record would not even preserve the fact that “they didn’t come.” To observe something not arriving, you have to know first what could have arrived. A blank column with nothing written in it and a column where an entire written list reads 0 are different things.

FACT Even so, we will not take a further step here. Whether the distribution host actually stopped, or whether those requests simply did not come toward our honeypot, cannot be distinguished from this data. The reading we put forward the day before yesterday — “the distribution host moved to a new address” — was neither carried forward nor overturned by yesterday’s data. The old address: 0. The new address: 0.

Yesterday in chronological order

Laid out in order, a day looks like this. Watch the seconds on the two 11:34 rows. And it’s worth looking at the three rows above them — 00:25, 02:04, 03:57 — to see how closely their durations and command counts resemble one another.

1. 00:25:24Z ~ 00:26:33Z
   FACT ATK-4D7724 (125.224.x.x) telnet login success. About 69.4 seconds · 31 commands · 1 download. 3 intents — file download · granting execute permission · execute after download. completeness 16. TTY recorded (contents not included). Being telnet, the fingerprint and client values are empty strings. This alias appears in the delivery-source list for the 306-byte POSIX shell script (a6296a79…, hxxp://185[.]93[.]89[.]72/wget)
2. 02:04:09Z ~ 02:05:17Z
   FACT ATK-383112 (125.229.x.x) telnet login success. About 67.3 seconds · 31 commands · 1 download. Intents, completeness (16), and download count are entirely identical to ATK-4D7724. This alias is also in the delivery-source list for a6296a79…
3. 03:57:01Z ~ 03:58:10Z
   FACT ATK-80B5C2 (220.80.x.x) telnet login success. About 68.9 seconds · 31 commands · 1 download. The third instance of the same shape. However, this alias is not in the listed delivery sources for a6296a79… (10 entries) — this sample's actual source count is 15, but the list only shows up to 10
4. 00:25 ~ 03:58 (archive comparison)
   FACT This shape — 31 commands · 1 download · 3 intents · completeness 16 — occurred 4 times on 8/20 (ATK-7B6CFE · ATK-2E51DB · ATK-127D9E · ATK-CC119E), once on 8/21 (ATK-E07AC3), and 3 times yesterday: 8 occurrences across three days. Durations are all in the one-minute range too — about 67.9~75.8 seconds on 8/20, about 85.0 seconds on 8/21, about 67.3~69.4 seconds yesterday
5. 08:14:30Z ~ 08:15:31Z
   FACT ATK-5A0689 (107.161.x.x) telnet login success. About 61.0 seconds · 17 commands. 5 intents, the most of any session yesterday — reconnaissance (system) · file download · granting execute permission · execute after download · persistence (planting an SSH key). And yet downloads number 0. completeness 17. The fifth instance of the same shape, following 8/18 (ATK-C17F4E) · 8/19 (ATK-103570) · 8/20 (ATK-B4B2E2) · 8/21 (ATK-4CA329)
6. 11:34:14Z ~ 11:34:33Z
   FACT Yesterday's subject session. ATK-F604B7 (45.6.x.x) telnet login success. About 19.7 seconds · 22 commands (about 1.12 per second) · 11 downloads (about 0.56 per second). Intent is "impair defenses" alone. completeness 42, the highest of the entire day. TTY recorded (contents not included)
7. 11:34:14Z ~ 11:34:33Z (sample detail)
   FACT The only sample having this alias as its sole delivery source is sha256 01ba4719…, observed 11 times — matching the session's download count of 11. It is 1 byte, an empty file with no marker identifying its kind. All 11 files pulled down within 19.7 seconds are the same empty file
8. 11:34 (archive comparison)
   FACT Seven values match the ATK-ABE8B7 session in the 8/18 record — telnet · login success · 22 commands · 11 downloads · intent "impair defenses" alone · all 11 being 1-byte empty files (identical hash 01ba4719…) · 1 source · completeness 42. The only difference is duration: about 75 seconds per the 8/18 record versus about 19.7 seconds yesterday, about 3.8× faster. Because aliases are generated with a salt mixed in, whether the two origins are the same place cannot be known
9. Entire observation window
   FACT "Impair defenses" reappeared yesterday at 1 occurrence after three days — 8/16 once, 8/17 once, 8/18 once, 8/19 zero, 8/20 no such category, 8/21 no such category, yesterday once. On 8/18 and yesterday, that single occurrence is attached to a completeness-42 session
10. Entire observation window
    FACT The observation counts of the 5 samples sum to 15+13+11+8+1=48, exactly equal to the 48 occurrences of the "file download" intent classification. Also, "file download" at 48 and "execute after download" at 48 equal each other — yesterday is the first day in the six-day archive on which these two values matched (8/19 40 vs 38, 8/20 43 vs 41, 8/21 109 vs 107)
11. Entire observation window
    FACT The 306-byte POSIX shell script (a6296a79…, hxxp://185[.]93[.]89[.]72/wget) was observed 15 times from 15 distinct sources. Following 8/17 (6 sources) · 8/18 (13 sources) · 8/19 (7 sources) · 8/20 (8 sources) · 8/21 (5 sources), that is six consecutive days with the same hash and same URL, and the 15 sources is the maximum of the six days
12. Entire observation window
    FACT The 389-byte OpenSSH RSA public key (a8460f44…) was observed 8 times from 8 distinct sources. No URL is recorded. 8/16 10 sources → 8/17 → 8/18 16 sources → 8/19 12 sources → 8/20 8 sources → 8/21 10 sources → yesterday 8 sources: seven consecutive days with the same hash
13. Entire observation window
    FACT A 1,608-byte Bourne-Again shell script came down once from hxxp://5[.]182[.]210[.]174/ok (6ff53177…, single source ATK-10149C). Same URL, same 1,608 bytes, but the hash changed: 8/17~8/19 6aa5054a… → 8/20 b7728639… → 8/21 c850a285… · 7a5dcc03… (two kinds in one day) → yesterday 6ff53177…. Five hashes over five days
14. Entire observation window
    FACT Downloads from the 12 watch-list URLs (the 31[.]77[.]227[.]121/bins/ family) were again 0 yesterday — three consecutive days, following 8/20 and 8/21. The distribution host 176[.]65[.]139[.]196, which first appeared on 8/21, is also absent from yesterday's record. As a result, ELF executable binaries among yesterday's stored samples number 0 (in the archive, ELF was recorded on 8/16 · 8/19 · 8/21, and absent on 8/18 · 8/20 · yesterday)
15. Entire observation window
    FACT A 9-byte ASCII text file (4af5a5c9…) was observed 13 times from 1 source (ATK-BECAD3). 8/18 12 times → 8/20 8 times → 8/21 5 times → yesterday 13 times, always from a single source
16. Entire observation window
    FACT Intent classification — reconnaissance (system) 1,980, granting execute permission 271, execute after download 48, file download 48, persistence (planting an SSH key) 9, indicator removal 8, impair defenses 1. Total 2,365. Out of 7,574 total commands, reconnaissance (system) is about 26.1%, a steep drop from about 77% on 8/20 and about 60.4% on 8/21. "Reconnaissance — network" has no entry yesterday
17. Entire observation window
    FACT 3,553 sessions / 205 unique origins / 3,324 login attempts / 7,574 commands / 2,988 TTY recordings. Port 2222 (SSH) 2,350 sessions, port 2223 (telnet) 1,203 sessions. Sessions, commands, and login attempts are all the maximum across the six-day archive, and telnet's 1,203 is about 4.3× that of 8/21 (281) and about 3.3× the previous maximum (8/18, 370). By contrast, 205 unique origins is the same as 8/21 and mid-range for the six days (8/18 249, 8/17 236)
18. Entire observation window
    FACT An average of about 17.3 sessions per origin (3,553÷205) and about 16.2 login attempts per origin (3,324÷205), the highest of the six days (8/20 about 14.1 sessions · 12.2 attempts). Commands per session is about 2.13
19. Entire observation window
    FACT The credential pair admin/admin was observed 105 times from 29 distinct IPs — about 3.6 times per IP. By contrast, nobody/nobody appeared 105 times from 5 IPs, about 21 times per IP, and root/admin 71 times from 5 IPs, about 14.2 times per IP. 345gs5662d34/345gs5662d34 appeared 8 times from 8 IPs — exactly once per IP
20. Entire observation window
    FACT SSH client fingerprint clusters totaled 40, the most of the six days (8/17 33 → 8/18 36 → 8/19 37 → 8/20 37 → 8/21 38 → yesterday 40). The largest cluster is f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6), 8 IPs yesterday · 182 cumulative. All 10 listed clusters delivered no samples, making it two consecutive days at 0 following 8/21

FACT Two rows in the table catch the eye. One is 08:14’s ATK-5A0689 — the widest intent spread at 5 kinds, yet 0 downloads. This shape has repeated for five days running since 8/18. The other is the top three rows. 00:25, 02:04, and 03:57 match right down to 31 commands, 1 download, and completeness 16. That means the same shape passed through three times in the early hours. And it isn’t unique to yesterday — 4 on 8/20, 1 on 8/21, 3 yesterday: eight times across three days.

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

FACT Connections arriving over SSH leave a client fingerprint. The composition of the greeting a connecting program offers first differs slightly from tool to tool, so grouping by that value tells you “different origins, same program.” Yesterday these fingerprint groups numbered 40, the most of the six days.

FACT And yet yesterday’s top 5 sessions by completeness are all telnet. The fingerprint and client values are empty strings in all five. Telnet has no such greeting procedure in the first place.

FACT And the 10 listed fingerprint groups delivered not a single sample. That is two consecutive days at 0, following 8/21.

INFERRED In short, the layer where fingerprints are captured (SSH · 2,350 sessions) and the layer that actually gets breached and runs commands (telnet · 1,203 sessions) were split apart yesterday too. And yesterday that telnet layer grew 4.3× in a single day.

FACT So the basis for linking yesterday’s subject session to the 8/18 session is not a fingerprint. It is only the session’s shape (22 commands · 11 downloads · intent combination · completeness 42) and the file fingerprint (01ba4719…). And as said above, that means the same tool was used, not that it was the same person. Fingerprint values likewise are fingerprints of a build, not of a person — people who don’t know one another, using the same distribution’s default connection program, have the same value.

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

FACT Yesterday’s login attempts numbered 3,324, from 205 origins. That is an average of about 16.2 knocks per origin, and it is the highest of the six days (8/20 about 12.2).

FACT Filtering to only the pairs observed from 3 or more distinct IPs gives this.

FACT Here the manner of knocking splits. admin/admin came from 29 IPs, 105 times — each place tries it three or four times and moves on. 29 is the most widely spread value of the six days (8/20 14, 8/21 18). Conversely nobody/nobody came from only 5 IPs yet also 105 times — each place knocked twenty-one times. root/admin likewise: 71 times from 5 IPs, about 14.2 per place. And 345gs5662d34/345gs5662d34 came 8 times from 8 places, exactly once per place. The kind that sweeps broadly once each and the kind that drills narrowly arrived together on the same day.

FACT And 703 pairs are not included. Those are ones that appeared from fewer than 3 distinct IPs (8/16 934 → 8/17 830 → 8/18 1,388 → 8/19 848 → 8/20 440 → 8/21 806 → yesterday 703). A pair that appeared from only one place may be someone’s actual account leaked from somewhere, so we count them without writing the values.

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

What they left behind

Everything observed yesterday — samples and addresses. Press a value to copy it — hashes exist to be put on blocklists, not to be read. hxxp:// and [.] are left as-is.

FACT One row in the list catches the eye: hxxp://5[.]182[.]210[.]174/ok. Same address, same size at 1,608 bytes, and yet only the hash differs. One kind on 8/17~8/19, one on 8/20, two on 8/21, another yesterday — five kinds over five days. It means the file sitting in that same spot quietly changed. Why the approach of tagging a hash as “this file is dangerous” and blocking on it keeps running late — this one row is the answer. What changed, we cannot say, because we do not retain contents.

FACT And the 389-byte OpenSSH RSA public key appears with the same hash for the seventh day. Yesterday it came from 8 sources. 389 bytes is about the size of a short text message. If this small file goes into authorized_keys (the list of permitted keys) as a single line, a key that can get in without a password hangs by the front door. Change every password and that key remains.

Mapped onto attack stages

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

• T1110.001Brute Force: Password GuessingINFERRED
• T1078Valid AccountsINFERRED
• T1059.004Command and Scripting Interpreter: Unix ShellINFERRED
• T1082System Information DiscoveryINFERRED
• T1105Ingress Tool TransferINFERRED
• T1222.002File and Directory Permissions Modification: Linux and MacINFERRED
• T1098.004Account Manipulation: SSH Authorized KeysINFERRED
• T1070Indicator RemovalINFERRED
• T1562Impair DefensesINFERRED

FACT The last row, T1562 (Impair Defenses), needs a caveat. This entry rests on a single classified intent occurring just once yesterday. Because there is no raw command text, we cannot say what was to be impaired, so we have not attached a more specific sub-technique.

If this looks familiar

INFERRED The entry structure is the same as the Mirai botnet family that has continued since 2016: get in with a default telnet password, download a small shell script from a web server, then try, one after another, the per-CPU-architecture executables under a /bins/ path. The fact that all 20 credentials quoted yesterday are defaults or trivial combinations, that all 5 completed sessions were telnet and password-based, and the naming rule of the 12 watch-list files (p + CPU type) all fit this method. It is a case with US Department of Justice indictment and guilty-plea records on file and public analysis reports from multiple vendors.

FACT This case does point out one thing. Because it is a family whose source was made public, it is common for entirely unrelated operators to each stand up distribution hosts under the same rules and run the same sequence. Yesterday’s “identically shaped sessions four days apart” does not run counter to that either.

FACT That said, this case does not confirm yesterday’s individual judgments. The same goes for the relationship between the 8/18 session and yesterday’s, and for whether the distribution host stopped. And because not a single ELF executable was observed yesterday, the distribution stage itself was not confirmed.

So what should you do

INFERRED The order yesterday’s data points to.

1. Turn off remote access like telnet. Yesterday telnet was 33.9% of all sessions, 4.3× in a single day, and all 5 completed sessions were telnet. Telnet sends passwords in the clear, and there is no key-authentication option at all — there is no method other than turning it off. In your router or home-camera settings, find “remote access,” “Telnet,” or “remote management” and switch it off. And if you set your defense priorities by share, that basis itself changes in a single day. What was 15% the day before yesterday was 34% yesterday.
2. Change default accounts and initial passwords. 3,324 login attempts, and all 5 completed sessions were successful logins. All 7,574 commands executed yesterday were run after a successful login, and that is the maximum of the six days. If you are using a pair from the table above, that’s all it takes.
3. Limit the number of failed logins. The same origin came back seventeen times in a day and retried a single pair twenty-one times, and nothing caught it. On top of that, yesterday’s subject session was over in 20 seconds. Thresholds set around “long-lived connections” or “attempts that accumulate slowly” will not catch it in the first place.
4. Stop your devices from fetching files from outside. Yesterday: 48 file downloads, 271 grants of execute permission, 48 execute-after-download. Had outbound connections been blocked, all four sessions — ATK-4D7724, ATK-383112, ATK-80B5C2, ATK-F604B7 — would have been cut at the download stage. Yesterday outbound was open and yet no executables arrived — which means yesterday’s quiet was not something our defenses produced, but circumstances on the other side.
5. Get alerted when ~/.ssh/authorized_keys changes. Yesterday: 9 key-planting intents, 8 sources leaving a public key with the same hash. ATK-5A0689 was a session that stored not a single sample, and it was still classified as far as the key-planting stage. Especially on a day like yesterday with 0 executables, there is no file for antivirus to catch at all. Unless you look at the key file yourself, you won’t even know you were breached.
6. Store logs off the device. Indicator removal was observed 8 times, impair defenses once. And the reason this post exists at all is logs. Because there were 2,988 TTY recordings, we could trace how 22 commands and 11 downloads flowed within a 20-second session (contents are not included in this post), and because we did not delete four days of records, we could tell that “the same shape as 8/18 got 3.8× faster.” That is something a single day’s data cannot show you.

FACT “Use key authentication instead of passwords” is a middling recommendation by yesterday’s data. Yesterday’s completed sessions with successful logins were all telnet, and telnet has no key authentication. And the data does not break out how much of the 3,324 belongs to SSH, so there is no basis for saying “turning on key authentication would have blocked yesterday’s intrusions.”

Yesterday, in full

An average of about 17.3 sessions and about 16.2 attempts per origin. Commands per session, about 2.13.

The distribution hosts and C2 observed yesterday (185[.]93[.]89[.]72, 5[.]182[.]210[.]174) and the watch list’s 31[.]77[.]227[.]121 were reported to C-TAS. The focus of yesterday’s report is not new addresses but 185[.]93[.]89[.]72, spraying the same hash for six consecutive days, and 5[.]182[.]210[.]174, cycling 5 hashes over five days. Only transport-layer success is confirmed; whether KISA ingested it needs separate confirmation.

The 60-second version

We also made the same observation set into a short video. The video focuses on the angle that all 11 files pulled down were empty.

What We Don’t Know

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

• Whether yesterday’s session and the 8/18 session share an origin. Seven values match, but aliases are generated with a salt mixed in, so they cannot be matched. What is confirmed goes only as far as the session shape and sample hash being the same, and that means the same tool and same automated execution sequence were used, not the same organization or the same person.
• Whether “about 3.8×” is an accurate comparison. The “about 75 seconds” for 8/18 is quoted from what that day’s record says, while yesterday’s about 19.7 seconds we calculated directly from start and end timestamps. Whether the two values were derived the same way cannot be confirmed.
• Why ATK-F604B7’s completeness is 42. Its only intent is “impair defenses,” and yet it is the highest value of the day. The formula is not in the data, so we cannot explain it. The same item remains unresolved for 8/18 (ATK-ABE8B7, 42) and 8/21 (ATK-792ADF, 43 with 0 intents).
• Why a 1-byte empty file was stored 11 times over. Whether it is the result of failed downloads or intended behavior cannot be known. With no raw command text and no screen-recording contents, we also cannot say what was meant to be done with this file. The same item remains open for 8/17 · 8/18 · 8/21.
• Whether the single “impair defenses” really belongs to this session. The data does not state it. We read it that way because this session’s sole intent is that one and yesterday’s total count is also 1, but there is no field linking sessions to intent counts 1:1.
• Whether the 5 samples’ observation-count sum of 48 matching the 48 “file download” occurrences is coincidence. The data does not connect the two values. Also, the 389-byte public key is recorded in the 8/17 record as “created within the session rather than downloaded,” so the data does not settle whether it is sound to include these 8 in a download total.
• Why the gap of 5,209 between 7,574 commands and the intent-classification total of 2,365 is this large. It is the largest gap of the six days (8/21 was 1,910 vs 1,575, a gap of 335). There is no explanation of whether one command can be classified under multiple intents, whether some commands go unclassified, or why unclassified commands surged yesterday. The drop in reconnaissance (system) share to 26.1% may share the same cause, but this cannot be confirmed.
• Why telnet grew 4.3×. Unique origins stand at 205, the same as the day before yesterday. The data does not distinguish whether the same places came in more often or different places came in.
• Why 8/21’s distribution host 176[.]65[.]139[.]196 is absent yesterday. Whether it was a one-day observation, or whether it is still alive and simply did not come our way, cannot be distinguished. The day-before-yesterday reading that “the distribution host moved” was neither carried forward nor negated by yesterday’s data.
• Why the 12 watch-list entries are at 0 for three consecutive days. Likewise, whether the distribution host stopped or whether those requests did not reach our honeypot cannot be distinguished.
• What the 1 file ATK-80B5C2 pulled down was. Its download count is 1, yet it is not in the listed delivery sources for a6296a79… (10 entries). The actual source count is 15 and the list shows only up to 10, so it could be among the remaining 5 — but this cannot be confirmed.
• Whether ATK-5A0689 failed to download, or downloaded and the file wasn’t stored. Its intents include “file download” and “execute after download,” yet the download count is 0. This is the fifth instance, following 8/18 · 8/19 · 8/20 · 8/21.
• Whether the intent list denotes execution order. It is not stated, so this post does not read the order of the intent array as the order of stage progression.
• Why hxxp://5[.]182[.]210[.]174/ok served five kinds over five days. Whether it is generated fresh per request or swapped on a short cycle cannot be known, and since we do not retain contents we also cannot say what changed.
• What the 9-byte ASCII text (4af5a5c9…) is. Its contents are not in the record. The delivery source is 1 place, yet observations number 13.
• Why 8 places left a public key with the same hash. Whether it is the result of using the same tool or of sharing a key cannot be known. Because of the aliases, the source counts across 8/16~8/21 (10 → … → 16 → 12 → 8 → 10 → yesterday 8) cannot be summed across dates or traced to the same origin either.
• Whether the fingerprint list is a top-N or the complete set. The cluster total is 40 while the list has 10. Therefore “no cluster delivered a sample yesterday” is a fact within the scope of those 10.
• When 0425c279… (SSH-2.0-PuTTY_Release_0.70) was first observed. Yesterday too it is 3 places same-day = 3 cumulative. The 8/21 record wrote the same values and described it as “a cluster first observed that day.” Whether the same 3 IPs came in on two consecutive days or the cumulative tallying method differs cannot be distinguished, and the starting point of the cumulative tally is not stated either.
• The nature of SSH-2.0-ZGrab ZGrab SSH Survey (fingerprint dd9bcf09…, 2 IPs yesterday · 38 cumulative). It is the name of a publicly available internet scanner tool, but whether it is for research and measurement or attack preparation cannot be distinguished from this data.
• One Discord webhook URL. Which session or which sample it connects to is not stated, so we did not include it in yesterday’s factual account. 8/20 and 8/21 were excluded for the same reason.
• Whether the aggregate figures cover a full day. The main sessions span 00:25~11:34 UTC and the generation time is 15:05Z. The observation window is not stated. What we wrote above as “once every 26 seconds” is likewise a calculation assuming a full day, and the possibility that the surge in session and command counts is due to a changed aggregation window cannot be ruled out.
• The relationship between tty_recordings_available (174) · samples_on_honeypot (45) and the aggregate TTY recordings (2,988). There is no explanation.
• Whether the C-TAS report was ingested or acted on. Only transport-layer success was confirmed.
• Background vulnerability statistics (4,556 CVEs / 345 CISA KEV / 95 confirmed ransomware-linked; top EPSS CVE-2018-13379 · CVE-2022-26134 · CVE-2021-44228 · CVE-2023-4966 · CVE-2024-3400). These are background statistics based on KISA security advisories and do not connect directly to yesterday’s observation set. Every intrusion path observed yesterday was credentials.

And then there are the things we have no means of confirming at all. This is different from not knowing — here, not guessing is the correct answer.

• ASN · ISP — We do not have GeoIP or ASN databases. We do not guess. We also cannot know the hosting providers for yesterday’s distribution hosts 185[.]93[.]89[.]72 · 5[.]182[.]210[.]174.
• Geographic location — Same. IP geolocation is not a basis for attribution in the first place. Telnet grew 4.3×, but we cannot say where it came from.
• VPN · Tor · cloud status — We have no means of determining this.
• VirusTotal detection results — Not integrated. We cannot say from this data what family yesterday’s 5 stored samples are detected as. Sample classification uses MalwareBazaar tags.
• User-Agent — SSH and telnet have no User-Agent at all. HTTP attacks are a separate source.
• CVE linkage — SSH and telnet attacks mostly do not reference vulnerabilities, and yesterday’s observation set was aimed at passwords too.

We started with the story of putting two videos side by side.

What we found out yesterday goes exactly that far. The same scene passed by again four days later, and this time it was 3.8× faster. Whether the person who shot them is the same person, we never find out. Because they don’t appear on screen.

But there is only one reason we could tell even this much. Because we didn’t delete the video from four days ago. Had we looked at yesterday alone, it would have ended at “a 20-second session pulled down 11 empty files.” We would not have known it got faster, nor that it was the third instance of the same shape.

The router and home camera in your house right now are being filmed every day too. Only, on our side there is no recorder. On a day like yesterday, when all that remains is eleven characters, there is nothing for antivirus to catch and nothing to play back.

This post is based on the 2026-08-22 honeypot observation set. Source IPs are written exactly in the masked form from the brief, and distribution addresses have been defanged so they will not connect. Quoted credentials include only the 20 pairs observed from 3 or more distinct IPs; the 703 pairs observed from fewer than that are disclosed by count only, with no values included.