233 Identical Footprints — Only 2 Left Anything Behind

Have you ever gone down to your apartment building’s entrance lobby the day after it rained?

The floor is covered in shoe prints. But look closely and there are only a few kinds of sole patterns. The same pattern overlaps twenty, thirty times. That doesn’t mean one person walked through thirty times. It means different people wearing the same shoes passed by. That sneaker everybody’s wearing these days.

That’s as far as footprints will take you. You can tell what shoe it was. You can’t tell who.

Yesterday, the floor of our honeypot lobby looked like that.

The footprints converged on one pattern

Let me define one term first.

When something connects to a server, the other side’s program announces up front how it intends to talk. Bundling that combination of conversational settings into a hash (a value that condenses content into a short block of letters and numbers) gives you what’s called a client fingerprint. It’s called a fingerprint, but it’s really closer to a footprint than a fingerprint. It’s a print of a shoe sole, not of someone’s fingertip.

FACT Yesterday there were 38 distinct footprint patterns left on our server. Adding up the sources for the 11 patterns that made the brief’s list gives 264. And of those 264, 233 were a single value: acaa53e0a7d7ac7d1255103f37901306. Banner string SSH-2.0-OpenSSH_7.4. Which means nine out of ten pairs of shoes (88.3%) had the same pattern.

FACT The cumulative number of sources this pattern has stepped through is 1,029. On August 16 it was 20. In twenty days it became 51 times larger. The trend goes like this: 8/16, 20 sources → 8/25, 139 → 8/26, 356 → 8/27, 543 → 8/31, 589 → 9/01, 758 → 9/02, 899 → 9/03, 1,005 → yesterday, 1,029.

FACT And yet there’s one flag on this pattern that has never once switched on across all twenty days. The delivered_samples field (did it deliver a sample?) stays false. The shoe that stepped on the lobby floor the most left nothing at the door for twenty days.

The footprint that left something behind was a different one

FACT Of the 11 patterns on yesterday’s list, exactly one had delivered_samples=true. 16443846184eafde36765c9bab2f4397, banner SSH-2.0-Go. 2 sources yesterday, 19 cumulative.

Put the numbers side by side and it looks like this.

INFERRED Yesterday, the side that came and went most noisily and the side that actually left something behind were different. This is the shape where ranking risk by contact volume inverts the ordering. 233 versus 2 — if you had lined things up by contact volume, the one that left something behind would have been far down the list.

Two pairs of shoes we’d never seen before

FACT Yesterday’s list included two patterns that had never appeared in the 19 days of archive (8/16–9/03), showing up together.

• 3356ae6145fa86124298066e281ea2d9 — banner SSH-2.0-PuTTY_Release_0.84. 3 sources yesterday = 3 cumulative. Yesterday was the first time.
• 5bd26477da5440a6187bd3f1b39a429c — the banner is just SSH-2.0-PUTTY. The version notation is missing. 3 sources yesterday, 8 cumulative.

FACT Until then the only PuTTY-family pattern in the record was 0425c279… (0.70), and that one was not on yesterday’s list.

The point where we have to stop

FACT These values are fingerprints of a program build, not of a person. Someone using the OpenSSH their distribution ships by default, or someone who downloaded the same PuTTY release, will have the same value even with no relationship whatsoever to each other. So we write “same tool” and never “same organization.”

FACT On top of that, the banner string is a value the other side sends about itself. Which means they can engrave whatever pattern they want on their own shoe before walking in, and we have no way to verify it.

FACT The ratio needs careful reading too. Dividing 233 by yesterday’s total of 419 sources gives 55.6%, but that denominator is contaminated. The 328 Telnet sessions never produce this footprint in the first place. So we use 88.3%, taking as the denominator the 264 sources that did leave a footprint — not 419.

The whole day

Laid out in time order, it goes like this. Read the daily-tally lines and the archive-comparison lines alternately — things invisible in yesterday alone become visible when you set it next to the days before and after.

1. 2026-09-04 (daily tally)
   FACT Sensor 01 (Cowrie, high-interaction): 952 sessions · 419 unique sources · 663 login attempts · 1,403 commands · 319 TTY recordings. By port, 623 on 2222 (SSH) and 328 on 2223 (Telnet). Against the previous day (9/03) with 2,378 sessions and 6,001 commands, this settled to 40.0% of sessions and 23.4% of commands
2. 2026-09-04 (daily tally)
   FACT Intent distribution: grant execute permission 237 → recon—system 147 → download-then-execute 20 / file download 20 → indicator removal 11 → persistence—planting SSH keys 10 → recon—network 2. 447 total, 31.9% of yesterday's 1,403 commands
3. 2026-09-04 (archive comparison)
   FACT Days when 'grant execute permission' outran 'recon—system': 8/29 (161 vs 75) · 8/31 (195 vs 119) · 9/01 (207 vs 144) · 9/02 (135 vs 60) · yesterday (237 vs 147) — 5 of the last 7 days. The 237 is the largest absolute value among those five inversion days, and across the full 20-day archive it ranks 5th, behind 8/16 (309), 8/17 (283), 8/22 (271) and 8/18 (257)
4. 2026-09-04 (archive comparison)
   FACT By contrast, for the thirteen days 8/16–8/28, recon was #1 without exception (8/26 recon 2,391, 8/27 1,811)
5. 2026-09-04 (daily tally)
   FACT Four kinds of files came down. A 1-byte empty file (11 times), a 389-byte OpenSSH RSA public key (from 8 sources), a 306-byte POSIX shell script (hxxp://185[.]93[.]89[.]72/wget, from 6 sources), and a 9-byte ASCII text (6 times). No executable binaries such as ELF or PE appear anywhere in file_category or file_kind
6. 2026-09-04 (daily tally)
   FACT 38 SSH client fingerprint clusters in total. The largest cluster, acaa53e0a7d7ac7d1255103f37901306 (SSH-2.0-OpenSSH_7.4), had 233 sources yesterday and 1,029 cumulative. Of the 264 IPs summed across the 11 listed clusters yesterday, 233 (88.3%) belong to this one
7. 2026-09-04 (archive comparison)
   FACT Cumulative IP trend for acaa53e0…: 8/16 20 → 8/25 139 → 8/26 356 → 8/27 543 → 8/31 589 → 9/01 758 → 9/02 899 → 9/03 1,005 → yesterday 1,029. Across all 20 days delivered_samples has remained false
8. 2026-09-04 (daily tally)
   FACT Among the 11 listed fingerprints, the only one with delivered_samples=true is 16443846184eafde36765c9bab2f4397 (SSH-2.0-Go), with 2 IPs yesterday and 19 cumulative
9. 2026-09-04 (archive comparison)
   FACT 3356ae6145fa86124298066e281ea2d9 (SSH-2.0-PuTTY_Release_0.84) had 3 sources yesterday = 3 cumulative, and this hash appears nowhere in the 19 days of archive (8/16–9/03). 5bd26477da5440a6187bd3f1b39a429c (banner 'SSH-2.0-PUTTY', no version notation) is also absent from the archive, with 3 sources yesterday and 8 cumulative
10. 05:16:21 ~ 05:17:31 UTC
    FACT ATK-1A62F3 (45.250.x.x) Telnet login succeeded. About 70.3 seconds, 31 commands, 1 download. 3 intents (file download · grant execute permission · download-then-execute). completeness 16. TTY recorded (contents not included). Present in the delivered_by list of the 306-byte shell script
11. 06:20:00 ~ 06:21:08 UTC
    FACT ATK-3C40CA (36.233.x.x) Telnet login succeeded. About 67.9 seconds, 31 commands, 1 download, 3 intents, completeness 16 — the command count, download count, intent combination and completeness are all identical to ATK-1A62F3. This alias is also in the delivered_by of the 306-byte script
12. 08:08:14 ~ 08:09:22 UTC
    FACT ATK-DB4C25 (103.205.x.x) Telnet login succeeded. About 67.3 seconds, 17 commands, 0 downloads. 5 intents, the most yesterday — recon—system · file download · download-then-execute · grant execute permission · persistence—planting SSH keys. completeness 17
13. 13:22:08 ~ 13:23:22 UTC
    FACT ATK-929E7E (165.101.x.x) Telnet login succeeded. About 73.8 seconds, 17 commands, 0 downloads, 5 intents, completeness 17 — a shape completely identical to ATK-DB4C25, repeated 5 hours 14 minutes later from a different source
14. 14:43:15 ~ 14:43:34 UTC
    FACT ATK-5392AA (122.199.x.x) Telnet login succeeded. About 19.6 seconds, the shortest yesterday, yet with 11 downloads · 20 commands · completeness 40, yesterday's highest value. And yet the intents array is empty, and all 11 files taken were sha256 01ba4719… (1 byte, no magic number)
15. 2026-09-04 (sensor 02)
    FACT Sensor 02 (Beelzebub+adbhoney, low-interaction): 51,367 contacts · 317 unique sources. VNC 5900 accounts for 50,065 (97.5%) but only 69 sources — 725.6 per source. RDP 3389: 795 contacts · 143 sources; SMB 445: 309 · 40; LDAP 389: 109 · 9; MSSQL 1433: 64 · 40
16. 2026-09-04 (sensor 02)
    FACT In VNC negotiation, the version the other side proposed was 003.003 48,103 times and 003.008 1,487 times — 003.003 at 97.0%. Of 323 SMB dialect proposals, only 2 were 'SMB 2.???'; the rest were older vocabulary like NT LM 0.12 · LANMAN1.0 · LM1.2X002 · PC NETWORK PROGRAM 1.0. RDP cookies were mostly '<ip>' 396 times and 'hello' 208 times
17. 2026-09-04 (sensor 02)
    FACT There were 25 ADB sessions but samples_captured=0 and the downloads array is empty. The previous day (9/03) had 32 ADB sessions with 4 samples, and the day before that (9/02) a 733,706-byte file came in through this channel

What catches the eye here is the difference between September 3 and 4. The number of places knocking stayed nearly the same, but what they did once inside dropped sharply.

INFERRED It looks like the number of people who stepped through the lobby stayed about the same, while only what they did once inside fell to a quarter. To get a rough feel for the scale: 663 login attempts is about one every 2 minutes on average, and 1,403 commands is about one per minute on average. A pace that kept going all day without pause, but also not especially fast.

Not the footprints — what happened inside

FACT Of the 1,403 commands, 447 (31.9%) had a classified intent. And the top item among those 447 was not looking around.

“Grant execute permission” is the act of attaching a marker to a file that says “this file is allowed to run.” On Linux, without that marker a file won’t execute no matter how much of a program it is.

FACT The days this action outran recon were 8/29 (161 vs 75) · 8/31 (195 vs 119) · 9/01 (207 vs 144) · 9/02 (135 vs 60), and yesterday (237 vs 147). Five of the last seven days. Conversely, for the thirteen days from 8/16 through 8/28, recon was #1 without exception. Yesterday’s 237 is the largest value among the five inversion days, and across all 20 days it ranks 5th.

What was left at the door

FACT Four kinds of files came down to the server yesterday. The sizes probably don’t mean much on their own, so let me put something alongside for comparison.

FACT There was not a single executable binary like an ELF or a PE. Nowhere in the file classification fields. There were 237 actions attaching execute permission, and yet no program to attach it to ever came in.

FACT The 389-byte one is an SSH public key. In plain terms, a spare key that lets someone in without a password. Write this value as one line into the server’s authorized_keys file (the list of permitted keys), and whoever holds that key gets in from then on without being asked for a password. Yesterday this file came from 8 different aliases.

We’re reproducing the values verbatim so you can use them defensively. Click a value to copy it. The addresses have been defanged so they won’t resolve — leave them as they are.

Three of the four have an empty column for where they came from. Which means no address remains to put on a blocklist. Only one address is left, and that one has been unchanged for 19 days.

What passwords did they try to come in with

FACT There were 663 login attempts yesterday, across 358 distinct username/password combinations. Of those, 338 are not printed here. A combination seen from fewer than 3 distinct IPs could be a real account leaked from somewhere, so we count them and don’t write the values.

Below is the other side. These repeated across 3 or more IPs, so they can be treated as factory defaults that belong to no one.

FACT admin/admin alone was tried 39 times from 16 different sources. Attempts on the root account with the password left entirely blank also occurred 17 times from 3 sources.

Mapping the attackers’ techniques to the international catalog

MITRE ATT&CK is an international list that assigns numbers to attack techniques. Matching the behavior we saw against those numbers gives this. Press an ID to go to the original description — we link out so you can check for yourself instead of taking our word for it.

• T1110Brute Force — 663 login attempts · 358 credential combinations (20 published + 338 withheld)INFERRED
• T1078Valid Accounts — all 5 notable_sessions had login_success=trueINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'grant execute permission' 237 times, yesterday's top intentINFERRED
• T1082System Information Discovery — 'recon — system' 147 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 20 times, 31 actual download eventsINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — 'download-then-execute' 20 times, 306-byte POSIX shell script inboundINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — planting SSH keys' 10 times, 389-byte public key inbound from 8 aliasesINFERRED
• T1070Indicator Removal — 'indicator removal' 11 timesINFERRED
• T1046Network Service Discovery — 'recon — network' 2 timesINFERRED
• T1595Active Scanning — sensor 02, 51,367 contacts · 5 services. These are negotiation-stage contacts with no logins and no commands, so we classify them only as scanningINFERRED

Notice that all ten lines carry the [INFERRED] badge. What we saw goes as far as the ‘intent classification result’ of a command and ‘how many times it happened.’ The raw command text is not in our hands. So mapping to the catalog is always interpretation, and where it’s interpretation, we say so.

The lobby next door — Sensor 02

FACT On the same day, low-interaction sensor 02 took in 51,367 contacts. Against sensor 01’s 952 sessions that’s 54 times as many. There were 317 sources.

FACT VNC is a channel for screen sharing. 50,000 contacts came from 69 sources. That’s 725.6 per source. Spread across the day, it amounts to each source turning the doorknob once every 2 minutes, all day long.

FACT In the negotiation stage, the VNC version the other side proposed was 003.003 48,103 times and 003.008 1,487 times. 97.0% was 003.003. SMB looks similar. Of 323 dialect proposals, only 2 were the modern-family SMB 2.???; the remaining 321 were older vocabulary like NT LM 0.12 (70) · LANMAN1.0 (63) · LM1.2X002 (63) · LANMAN (32) · PC NETWORK PROGRAM 1.0 (31) · Windows for Workgroups 3.1 (31) · LANMAN2.1 (31). On the RDP side, cookies were mostly <ip> 396 times and hello 208 times.

INFERRED 003.003 is the lowest version notation the RFB protocol defines. It’s a shape where the other side proposed the low end on its own, but we can’t say why, because we don’t have the raw frames.

FACT The Android debug channel (ADB) had 25 sessions but 0 samples captured. On September 3 there were 32 sessions with 4 samples, and on September 2 a 733,706-byte file came in through this channel.

FACT Sensor 02 is low-interaction, so the concepts of login success, commands, and credentials don’t exist there at all. From this observation surface you cannot construct a sentence saying “the attacker got in and did something.” Which door was knocked on how many times, and what the protocol said — that’s all there is.

This has happened before

INFERRED The Mirai botnet (2016). Its structure was to log into IoT devices with default Telnet accounts and then download a binary matched to the CPU type. The points where it overlaps with yesterday’s observations are these: the top 5 sessions by completeness were all Telnet and all succeeded at login, and the quotable credentials include a device-factory-default family (root/vizxv). We are not carrying over figures for infection scale or damage amounts, because our data can’t confirm them. (Source types: government agency alert US-CERT/CISA Alert TA16-288A; US Department of Justice public indictment and plea documents.)

INFERRED The XorDDoS Linux trojan campaign (2022). The sequence was to get into Linux servers by SSH brute force, then establish persistence and erase traces. On our sensor yesterday, 663 login attempts, 10 ‘SSH key planting’ events and 11 ‘indicator removal’ events were recorded side by side on the same day. (Source type: vendor security research public report, Microsoft Security Threat Intelligence.)

So what should you do

Let me go back to the footprints. Counting the patterns on the lobby floor is not an attempt to find out who came. Shoes can be changed anyway. There’s only one reason to count. It’s to see what state the entrance is in, that it gets stepped on this much.

Written in the order confirmed by yesterday’s data.

1. Default accounts and weak passwords are still in use · High likelihood All 12 rows in the table above are values that devices or distributions ship with from the factory. They can be tried immediately with no preparation. On a real production server, just one hit from this list opens a shell. Yesterday five sessions actually succeeded at login.

2. Password login is allowed and key-based auth isn’t in use · High likelihood All 5 successes were Telnet (2223). With Telnet, the password flows in the clear, unencrypted. And the step of planting someone else’s public key after intrusion was actually observed (10 times). Once someone else’s key gets one line into authorized_keys, they keep getting in with that key even after you change the password. This is the point where a password change alone doesn’t restore you.

3. Admin ports are left open straight to the internet · High likelihood 623 SSH, 328 Telnet, plus 50,000 VNC on the neighboring sensor. Combining both observation surfaces, as many as 736 sources knocked on the door. This wasn’t aimed at any particular organization. Simply leaving a port open attracts knocking on the order of 50,000 a day. Being a target requires no special reason.

4. Outbound connections aren’t being blocked · High likelihood Login means you’re already breached. So cutting the server’s outbound connections is the last point where actual damage can be stopped. Yesterday only one distribution point was recorded, hxxp://185[.]93[.]89[.]72/wget, and outbound connections did in fact occur after login success. Block this and yesterday’s observed sessions all break at the download step.

5. Logs are kept only on the server · Medium likelihood The ‘indicator removal’ intent was classified 11 times. We could see it only because this is a honeypot and 319 sessions were separately recorded. If logs live only on the server, those 11 succeed exactly as intended. Only the evidence of the intrusion disappears, while the planted key quietly stays.

6. Relying solely on count-based blocking (fail2ban and the like) · Medium likelihood Here’s the interesting part. On sensor 01, each source knocked an average of only 1.58 times. Rules like “block after 5 failures” mostly never fire. When 419 sources each knock once or twice, they scatter in below the threshold. The exception is the root/empty-password combination, at 17 attempts from 3 sources — about 5.7 per source. Conversely, sensor 02’s VNC runs 725.6 per source, so any rule catches it for certain. The same defense behaves in opposite ways depending on the observation surface.

What We Don’t Know

This is where this blog differs from others. We write down what we don’t know as not known.

Things the data itself doesn’t explain

• [Cannot confirm] The formula for the completeness score isn’t in the data. ATK-5392AA is at 40, yesterday’s highest, yet its intents array is empty; ATK-DB4C25 and ATK-929E7E, which went as far as key planting, are at 17. We can’t explain why a session with no intents at all scored higher. The same item was left standing in the 8/18 and 8/19 briefs.
• [Cannot confirm] ATK-5392AA has 20 commands and 11 downloads, yet an empty intents array. We can’t tell whether the classifier failed to classify any of them or whether the classification results were dropped.
• [Cannot confirm] Download events total 31 (11+8+6+6), while the ‘file download’ intent count is 20. The data doesn’t reveal whether the aggregation units differ or whether some transfers occurred without a command.
• [Cannot confirm] The TTY recording figure comes out differently in two places (218 vs 319). Nor is it stated how samples_on_honeypot 93 relates to yesterday’s 4 file kinds.
• [Cannot confirm] Three of the four file kinds have an empty distribution-point column. We can’t tell whether there never was one or whether it fell out of the record, and therefore we also can’t judge whether the 12 distribution points noted in the archive were used yesterday.
• [Cannot confirm] The VNC version proposals total 49,590, which is 475 fewer than the 50,065 VNC sessions, and the RDP cookies total 609, which is 186 fewer than the 795 RDP sessions. These look like contacts that broke off before negotiation, but the reason isn’t in the data.
• [Cannot confirm] Sensor 02’s top sources are counted in units of ‘events’ while the per-service tallies are in ‘sessions’. It isn’t stated whether the two count the same thing, so the figure of 92.2% for the top 9 sources is a number that assumes the units match. For the same reason we also can’t count whether a single source swept multiple services — that value of 0 is not ‘none’ but ‘cannot be computed’.
• [Cannot confirm] With 0 samples from 25 ADB sessions, we can’t distinguish whether nothing was actually delivered or whether capture failed. That said, there’s no basis for treating it as a collection failure by the sensor itself. The ADB port and source columns in the table are also ‘not recorded’ rather than ‘none’. The same omission was present on 9/03.

About footprints, today’s topic

• [Cannot confirm] The data doesn’t say since when the cumulative source counts have been accumulating. We can’t settle whether acaa53e0… going from 20 sources on 8/16 to 1,029 yesterday should be read as ‘actual spread’ or as ‘natural accumulation since counting began.’ This item was also left unresolved in the 8/21, 8/22 and 8/23 briefs.
• [Cannot confirm] Banner strings (SSH-2.0-OpenSSH_7.4, SSH-2.0-PuTTY_Release_0.84, etc.) are values the other side sends about itself, so they can be forged, and we have no means of verifying them.
• [Cannot confirm] The ratio of 233 to 419 (55.6%) has a contaminated denominator. The 328 Telnet contacts produce no footprint at all, and the data has no breakdown of unique IPs by protocol, so we can’t compute the actual share on the SSH side. That’s why the body of this post uses 88.3%.
• [Cannot confirm] The count of 38 pattern types is the lowest of the 14 days since 8/22 and is down from 45 on 8/26–8/28. But it isn’t defined whether this figure is the number observed that day or a cumulative count, so we can’t interpret what the decrease means.

Background material · reporting

• [Cannot confirm] We report observed distribution points and C2 to C-TAS, but only the success of the transmission itself is confirmed; whether KISA ingested them requires separate confirmation.
• [Cannot confirm] The background statistics of 6,622 CVEs · 390 CISA KEV entries · 98 confirmed ransomware cases are values pulled from KISA security notices. There is no basis connecting them to any activity observed on the honeypot yesterday.

Things we don’t judge at all

• ASN · ISP — We don’t have the relevant databases. We don’t estimate.
• Geolocation — Same as above. IP geolocation isn’t grounds for attribution in the first place. We don’t infer countries or providers from yesterday’s masked ranges (45.250.x.x, 36.233.x.x, 103.205.x.x, 165.101.x.x, 122.199.x.x, 165.22.x.x, 164.92.x.x, etc.).
• VPN · Tor · cloud status — We have no means of determining it.
• Whether samples are malicious — We haven’t integrated VirusTotal. We make no ruling on whether yesterday’s 4 file kinds are malicious.
• User-Agent — Neither observation surface is HTTP. Sensor 01 is SSH and Telnet; sensor 02 is SMB, RDP, VNC, MSSQL, LDAP and ADB.
• CVE linkage — SSH and Telnet attacks generally don’t reference a CVE. Sensor 02 is at the protocol negotiation stage, so the same applies. Not one thing observed yesterday links to a specific CVE.
• Source identity — An alias (ATK-XXXXXX) is only an identifier pointing to the same source across posts; it is not an identity. We don’t restore the two masked octets.
• Raw command text · file contents · TTY replay — Not in our hands. We can speak only to intent classification and whether something existed.

There were 233 footprints on the lobby floor, and the footprint that left something at the door belonged to just 2 sources. If your criterion for deciding which to look at first is ‘how many prints there are,’ yesterday was a day when that criterion was wrong.

The observation date is 2026-09-04, and sensor 01 figures are on a daily-tally basis. Source IPs are written with the last two octets masked and are not restored. Distribution addresses have been defanged so they won’t resolve. Credentials are quoted only for combinations repeatedly observed from 3 or more distinct IPs; the 338 kinds seen from fewer than 3 were counted only, with no values written.