What's Left When There Are No Fingerprints to Group By — The Shape of a Session

People who have proctored exams tell a version of this story. Four answer sheets come in with the names covered. Getting the same questions right is one thing — but if the questions they got wrong, and the way they got them wrong, are identical too, then you may not know who wrote them, but you know the four came from the same place. No handwriting analysis required. The shape of the answer sheet already told you.

What came out of our honeypot yesterday was exactly those four sheets.

Four Places, Same Numbers

FACT Among yesterday’s top 5 sessions by completeness, 4 carry entirely identical figures. ATK-7B6CFE(221.162.x.x), ATK-2E51DB(1.165.x.x), ATK-127D9E(223.80.x.x), ATK-CC119E(220.134.x.x) — all four logged into telnet successfully, ran 31 commands, made 1 download, had 3 classified intents (file download · granting execute permission · execute after download), and share a completeness value of 16. Their dwell times cluster too: 67.9s · 68.1s · 75.8s · 68.6s.

FACT And all four of these aliases appear in the delivery-source list for the same sample (sha256 a6296a79…, a 306-byte POSIX shell script).

INFERRED Since each session has exactly 1 download and all four aliases are on that list, it’s likely that the single download is this script. That said, the data does not link sessions and samples 1:1.

But There Are No Fingerprints

This is where the method we normally use hits a wall.

Connections arriving over SSH leave behind something called a client fingerprint. The composition of the greeting the connecting program sends first differs slightly from tool to tool, so hashing that value lets you tell that “different origins, same program.” That was the subject of yesterday’s brief as well — one fingerprint tying separate origins to a single tool.

FACT But yesterday’s 5 completed sessions were all telnet, and the fingerprint and client values in the data are all empty strings. Telnet has no such greeting procedure to begin with. There were 37 SSH fingerprint clusters recorded yesterday, and these four sessions fall into none of them.

INFERRED Only two axes were left. The shape of the session (command count · download count · intent combination · dwell time) and the same sample hash. Even without a name tag, you can say this much: if the shape of the answer sheet is the same, the source is the same.

FACT But that’s as far as it goes. Identical session shape means the same tool and the same script were used — it does not mean the same organization or the same person. Entirely unrelated operators who each downloaded and ran a publicly available bot source leave behind exactly the same shape. It’s the same as four people working through the same problem book without knowing each other.

FACT And the fifth session, ATK-B4B2E2(124.221.x.x), falls outside this group. Its intents are broader at 5 kinds (adding reconnaissance and persistence via SSH key planting), and its completeness of 17 was yesterday’s highest — but it has 0 downloads.

Yesterday’s Record

1. 02:15:06Z ~ 02:16:14Z
   FACT ATK-7B6CFE(221.162.x.x) telnet login succeeded. About 67.9s · 31 commands · 1 download. 3 intents — file download · granting execute permission · execute after download. TTY recorded (contents not included). Being telnet, no SSH client fingerprint
2. 05:02:59Z ~ 05:04:07Z
   FACT ATK-2E51DB(1.165.x.x) telnet login succeeded. About 68.1s · 31 commands · 1 download. Intents, completeness (16), and download count entirely identical to ATK-7B6CFE. About 2 hours 47 minutes after the previous session ended
3. 06:26:38Z ~ 06:27:54Z
   FACT ATK-127D9E(223.80.x.x) telnet login succeeded. About 75.8s · 31 commands · 1 download. Again the same intent combination and the same completeness. About 1 hour 24 minutes after the previous session started
4. 06:40:02Z ~ 06:41:11Z
   FACT ATK-CC119E(220.134.x.x) telnet login succeeded. About 68.6s · 31 commands · 1 download. The fourth instance of the same shape. The intervals — 2 hours 47 minutes · 1 hour 24 minutes · 13 minutes 24 seconds — are not regular
5. 07:41:57Z ~ 07:43:21Z
   FACT ATK-B4B2E2(124.221.x.x) telnet login succeeded. About 84.3s · 17 commands. 5 intents (reconnaissance-system · file download · granting execute permission · execute after download · persistence via SSH key planting), yet 0 downloads. Completeness 17, yesterday's highest
6. Entire observation window
   FACT A 306-byte POSIX shell script (a6296a79…, hxxp://185[.]93[.]89[.]72/wget) observed 9 times from 8 different sources. delivered_by contains all four of the above sessions' aliases; the remaining 4 are ATK-91BE20 · ATK-CAD57F · ATK-15AAF6 · ATK-215E05
7. Entire observation window (archive comparison)
   FACT This hash and this URL are recorded identically on 8/17 · 8/18 (13 sources) · 8/19 (7 sources) as well. Yesterday, 8 sources — four consecutive days, same hash, same distribution point
8. Entire observation window
   FACT A 389-byte OpenSSH RSA public key (a8460f44…) observed 8 times from 8 sources. URL not recorded. 8/16 10 sources → 8/17 12 → 8/18 16 → 8/19 12 → yesterday 8, the same hash for five consecutive days, with the source count declining for a second day
9. Entire observation window
   FACT A 1,608-byte Bourne-Again shell script came down from hxxp://5[.]182[.]210[.]174/ok (b7728639…, from a single source ATK-10149C · 1 time). On 8/18 and 8/19 the same URL and same 1,608 bytes carried the hash 6aa5054a… — the file was swapped
10. Entire observation window
    FACT The hxxp://31[.]77[.]227[.]121/bins/ family of URLs, where actual downloads occurred on 8/19, has not a single download record yesterday. These 12 URLs remain on the watch list
11. Entire observation window
    FACT Intent classification — reconnaissance (system) 2,100, granting execute permission 172, file download 43, execute after download 41, persistence (SSH key planting) 9, indicator removal 8. 'Impair defenses' and 'reconnaissance — network' have no entries at all. Of 2,723 total commands, reconnaissance (system) is about 77%
12. Entire observation window
    FACT 2,607 sessions / 185 unique origins / 2,251 login attempts / 2,723 commands / 2,185 TTY recordings. Port 2222 (SSH) 2,310, port 2223 (telnet) 297 — telnet is about 11.4%, yet all 5 completed sessions are telnet
13. Entire observation window
    FACT 37 SSH client fingerprint clusters in total. The largest is f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6), 8 IPs yesterday · 155 cumulative, no sample delivery. Of the 9 listed, the only cluster that delivered a sample is 98ddc5604ef6a1006a2b49a58759fbe6 (SSH-2.0-Go, 2 IPs yesterday · 13 cumulative)
14. Entire observation window (archive comparison)
    FACT Fingerprint 16443846184eafde36765c9bab2f4397 (SSH-2.0-Go), which grouped 8/19's 3 completed sessions, is absent from yesterday's fingerprint list

A Day When a Few Came In Many Times

FACT Yesterday had 2,607 sessions from only 185 unique origins. Across the four archived days, that’s the most sessions and the fewest origins (8/18: 2,027 sessions / 249 origins; 8/19: 1,361 / 216). That’s about 14.1 sessions per origin.

FACT There were 2,251 login attempts, an average of about 12.2 per origin. Narrowing to combinations observed from 3 or more distinct IPs gives this.

FACT And 440 combinations are not listed. Those are the ones observed from fewer than 3 distinct IPs (8/16 934 → 8/17 830 → 8/18 1,388 → 8/19 848 → yesterday 440, the lowest of the five days). A combination that appeared from only one place could be someone’s account that actually leaked somewhere, so we don’t write the values — we only count them.

FACT Yesterday, too, no path referencing a CVE or an exploit was observed. Every one was a credential path.

What They Left Behind

The addresses are written deliberately broken (hxxp://, [.]). Pasting them as-is will not connect.

FACT The hxxp://5[.]182[.]210[.]174/ok line catches the eye. The address is unchanged, the size is still 1,608 bytes, and only the hash changed. That means the file sitting in the same spot was quietly swapped. We can’t say what changed, because we don’t retain contents.

FACT Conversely, the 12 URLs in the hxxp://31[.]77[.]227[.]121/bins/ family, where actual downloads occurred on 8/19, were not observed even once yesterday. These 12 are addresses that only surface after unpacking a compressed sample — indicators that were nowhere on the surface.

INFERRED Because we had extracted them in advance and put them on a watch list, “yesterday was quiet” also survives as an observation result. Had we not been watching, neither 8/19’s resurgence nor yesterday’s silence would have become data. That said, we cannot distinguish whether the distribution point stopped or whether it simply didn’t come our way.

Mapping to Attack Stages

Mapping the observed behavior to MITRE ATT&CK techniques gives this. 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

If This Looks Familiar

INFERRED The entry structure matches the Mirai botnet family that has continued since 2016: get in with default telnet credentials, download a shell script from a web server, then try binaries for each CPU architecture in order. The naming conventions of the 12 filenames added to yesterday’s watch list (parm, parm5, parm64, pmips, psh4, x86_64 …) match that convention, and the fact that all 5 completed sessions were telnet and credential-based fits as well. The fact that this is a family whose source is public, so unrelated operators commonly run the same routine, also points in the same direction as yesterday’s observation.

There are U.S. Department of Justice indictment and guilty-plea records for this case, and public analysis reports from multiple vendors. That said, yesterday’s subject — grouping by session shape without fingerprints — is not a part this precedent validates. This is a spot where you can’t wave it through by saying “it’s similar,” so we note it separately.

So What Should You Do

INFERRED The order yesterday’s data points to.

1. Turn telnet off. Yesterday telnet was about 11.4% of all sessions, the lowest share of the four days — yet all 5 completed sessions were telnet. Setting priorities by session-count share means missing the 11% that actually gets through. Telnet sends credentials in the clear, and the option of key-based authentication does not exist — there is no approach other than turning the protocol off.
2. Change default passwords. There were 2,251 login attempts, and all 5 completed sessions were successful logins. If you’re using a combination from the table above, that’s all it takes.
3. Limit failed login attempts. An average of 14.1 sessions per origin, and nothing caught anything. On top of that, since each session lasts a little over a minute, it won’t trip a threshold set around “long-lived connections” in the first place.
4. Block outbound connections from the device. Had outbound been blocked, all four sessions would have been cut off at the download stage. But this alone isn’t enough — ATK-B4B2E2 had 0 downloads and was still classified all the way to the key-planting stage.
5. Get alerts on changes to ~/.ssh/authorized_keys. Yesterday: 9 key-planting intents, 8 sources leaving the same-hash public key. Even if you change every password, a key that’s already in stays in.
6. Store logs off the device. Indicator removal was observed 8 times. The only reason we could learn that four places had the same shape yesterday is that 2,185 TTY recordings remained (contents not included in this post).

The Full Day

All 2,723 commands were executed after a successful login.

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

The 60-Second Version

We also made a short video of the same observation set.

What We Don’t Know

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

• Whether the four sessions ran the same commands in the same order. The figures match exactly, but the raw commands and TTY replays are not in the brief. What is confirmed goes only as far as: command count · download count · intent combination · completeness value are the same.
• Whether that 1 download really is a6296a79…. It’s likely, but the data does not connect sessions and samples 1:1.
• Whether the intent array denotes execution order. It isn’t stated, so we did not interpret it as a sequence of stages.
• Whether identical session shape means the same organization. It does not. It means the same tool and the same script were used, and unrelated operators each running a public-source bot leave the same shape.
• Whether ATK-B4B2E2 failed to download, or downloaded but the file wasn’t saved. Its intents include ‘file download’ and ‘execute after download’, yet download_count is 0. This is the third instance of the same pattern, following 8/18 (ATK-C17F4E) and 8/19 (ATK-103570).
• Why the completeness values are what they are (16 for the four sessions, 17 for ATK-B4B2E2). The formula is not in the data. The same item remains unresolved on 8/18 and 8/19 as well.
• Why the 2,723 total commands and the 2,373 total intent classifications don’t line up. There’s no explanation of whether one command can be classified under multiple intents, or whether some commands go unclassified.
• Why the start intervals of the four sessions are irregular. 2 hours 47 minutes → 1 hour 24 minutes → 13 minutes. We can’t tell whether it’s automation running on a fixed cycle or several origins each running on their own schedule.
• Whether the sources from 8/16–8/19 overlap with yesterday’s sources. The aliases (ATK-XXXXXX) are generated with a salt. ATK-CAD57F · ATK-215E05 · ATK-10149C · ATK-BECAD3 · ATK-C146AD appear in earlier briefs alongside the same samples, but since the salting method isn’t documented, we did not use that as evidence of the same origin across dates.
• Therefore we cannot sum the source counts for public-key planting (10 → 12 → 16 → 12 → 8), and the data can’t tell us why it declined for two days running either.
• Why the file at hxxp://5[.]182[.]210[.]174/ok changed. The size is the same and only the hash differs. Since we don’t retain contents, we can’t say what changed either.
• Why the hxxp://31[.]77[.]227[.]121/bins/ family was 0 yesterday. We cannot distinguish whether the distribution point stopped or whether those requests simply didn’t reach our honeypot.
• Why fingerprint 16443846…, which grouped 8/19’s completed sessions, is absent from yesterday’s list. It isn’t stated whether the fingerprint list contains only the top few or all of them (the cluster total is 37, but the list has 9).
• What the 9-byte and 12-byte ASCII texts are. The contents aren’t in the brief. 4af5a5c9… has 1 delivery source but 8 observations.
• 1 Discord webhook URL. It isn’t stated which session or which sample it connects to, so we did not include it in yesterday’s facts.
• Why 8 places left the same-hash public key. We can’t tell whether it’s the result of using the same tool or of sharing a key. The same item remains unresolved on 8/16–8/19 as well.
• Whether the aggregate figures cover the full day. The main sessions span UTC 02:15–07:43 while the generation time is 15:05Z. The observation window is not stated.
• The relationship between tty_recordings_available (116) · samples_on_honeypot (36) and the aggregate TTY recordings (2,185). There’s no explanation.
• Whether the C-TAS report was ingested or acted upon. Only transport-layer success was confirmed.
• Background vulnerability statistics (4,532 CVEs / 344 CISA KEV / 95 confirmed ransomware-linked; top EPSS CVE-2018-13379 · CVE-2022-26134 · CVE-2021-44228 · CVE-2023-4966 · CVE-2024-3400). These are background statistics based on KISA security advisories and are not directly connected to yesterday’s observation set.

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

• ASN · ISP — We do not have a GeoIP or ASN database. We do not infer them.
• Geolocation — Same. IP geolocation isn’t grounds for attribution in the first place.
• VPN · Tor · cloud status — We have no means of determining this.
• VirusTotal detection results — Not integrated. Sample classification uses MalwareBazaar tags.
• User-Agent — SSH and telnet have no User-Agent to begin with. HTTP attacks are a separate source.
• CVE linkage — SSH and telnet attacks mostly don’t reference vulnerabilities, and yesterday’s observation set was after credentials too.

Four answer sheets came in with the names covered. We will never know who was sitting there. But we know the four came from the same place — because the shape told us, not a fingerprint. The devices open on the internet right now are turning in an answer sheet every day too. If no one collects them and looks at the shape, what we know stays at zero.

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