SecurityHeroblog

107 Sources Yesterday, 8 Today — Four Numbers Came Down Together

On August 31, four numbers that yesterday read 107, 107, 106, and 116 all dropped to 8 in unison. That they rose together and fell together points strongly toward their having been one cluster, but the data has still never tied the four together. Instead, 324 distinct sources knocked on the door — the fourth highest of the sixteen days — while sessions per source hit a low of 2.40.

Picture yourself standing at a bus stop.

A moment ago the stop was empty, and suddenly more than a hundred people are standing there. But the information board doesn’t tell you which buses came and went. All you can see is the people standing in front of you right now.

So you start counting. 107 people carrying umbrellas. 107 wearing backpacks. 106 in shoes from the same company. And 116 holding open paper maps.

Looks like they got off one bus, doesn’t it. But you never saw that bus. All you saw was that the numbers were similar.

Now a day passes. You go back to the same stop the next day and find 8 umbrellas, 8 backpacks, 8 pairs of the same shoes, 8 maps. The things that rose together came down together.

Now the guess that “it was one bus” becomes far more plausible. And yet, still, you have never seen the bus.

The records left on our server on August 31, 2026, have exactly that shape.

First, let me unpack one unfamiliar term. A honeypot is a decoy server, deliberately made flimsy and put out on the internet. It does no real work. It’s a machine left open in order to record, in full, who comes in and what they do. Every number below was captured there.

Four Numbers Came Down Together

FACT In yesterday’s post (August 30) we took three overlapping numbers as our subject. Today we record what became of those numbers.

What August 30 August 31
Sources that threw the identical string 345gs5662d34 / 345gs5662d34 as both ID and password 107 sources (112 times) 8 sources (8 times)
Sources that left the identical 389-byte key file (a8460f44…) 107 sources (112 times) 8 sources (8 times)
Sources stamped with the client fingerprint f555226df… (SSH-2.0-libssh_0.9.6) 106 sources 8 sources
Commands classified as ‘Persistence — SSH key planting’ 116 times 8 times

FACT All four values line up at 8. From 107 to 8 is one thirteenth; from 116 to 8 is one fourteenth.

INFERRED Yesterday we read these values as “a single scattered group,” with the caveat that that was us placing them side by side, not the data tying them together. All four coming down together today strengthens that reading. If they had been four different groups that happened to be similar in size, there would be no reason for all four to fall to exactly 8 the next day.

FACT Even so, the line stays where it was. There is still no field in the raw data that connects these four to one another. This is a strengthened inference, not an established fact. Back at the bus stop: we didn’t see a bus, we counted heads twice.

INFERRED And coming down together carries another meaning as well. That surge lasted one day. Rather than having disappeared, it’s more natural to think it stood at a different bus stop today. If yesterday’s story was “scale and dispersion defeat monitoring,” today’s story is “that scale stayed for only a day.”

FACT One more piece of evidence. The aliases of the 8 sources that left the public key today (ATK-F52F12 · ATK-ECACA6 · ATK-81D609 · ATK-E5EB34 · ATK-4F20AC · ATK-7B8ADA · ATK-21F6A0 · ATK-3E7375) do not overlap at all with the ten aliases listed in yesterday’s post. The same file gets planted from different sources every day.

And Yet the Number of Sources Was Actually High

FACT Sessions recorded on our honeypot 01 that day: 779. That is the second lowest of the sixteen days we can verify, August 16–31 (the minimum is 634 on August 29). The 760 commands are also second lowest (the minimum is 612 on August 24), and the 440 login attempts are third lowest.

FACT And yet distinct sources numbered 324, the fourth highest across those same sixteen days (after 442 on August 27, 373 on August 26, and 361 on August 25).

INFERRED Divide one by the other and you get this: 2.40 sessions per source. That value is the lowest of the sixteen days. The next lowest, August 29, was 3.46, and the highest, August 22, was 17.33. Dividing login attempts the same way gives 1.36 per source, also the lowest.

INFERRED Many people stood at the stop, but the time any one person stayed was the shortest of any day. More sources came, and each did less.

The Day in Chronological Order

Laid out in time order, it looks like this. There are a lot of lines, and you don’t have to read them all. Just look at the five lines near the bottom that carry actual timestamps — how closely the elapsed times and command counts resemble one another is the heart of this day.

  1. FACT Honeypot 01 (Cowrie, high-interaction): 779 sessions · 324 unique sources · 440 login attempts · 760 commands · 195 TTY recordings. Port 2222 (SSH) 556 / 2223 (Telnet) 223
  2. FACT Position relative to the sixteen days (8/16–8/31): 779 sessions is second lowest (634 on 8/29 is the minimum), 760 commands is also second lowest (612 on 8/24 is the minimum), and 440 login attempts is third lowest (251 on 8/29, 410 on 8/24). Conversely, 324 unique sources is fourth highest (after 442 on 8/27, 373 on 8/26, 361 on 8/25)
  3. INFERRED Sessions per source is 779÷324=2.40, the lowest of the sixteen days (next is 3.46 on 8/29, maximum is 17.33 on 8/22). Login attempts per source at 440÷324=1.36 is also the lowest, though effectively the same as 1.37 on 8/29
  4. FACT All four values from yesterday's brief are 8 today — credential 345gs5662d34/345gs5662d34 from 8 distinct sources·8 times (yesterday 107 sources·112 times), 389-byte OpenSSH RSA public key a8460f44… from 8 sources·8 times (yesterday 107 sources·112 times), SSH client fingerprint f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6) at 8 sources today (yesterday 106 sources), command intent 'Persistence — SSH key planting' 8 times (yesterday 116 times)
  5. INFERRED The four values moved together both when rising (yesterday) and when falling (today). The caveat attached yesterday — 'this is numerical coincidence, not a fact the data ties together' — is retained as is; a strengthened inference, not an established fact
  6. FACT Public key a8460f44… has been the same hash for sixteen consecutive days since 8/16. Daily source-count trend: 8/18 16 sources → 8/19 12 sources → 8/23 6 sources → 8/25 21 sources → 8/27 26 sources → 8/29 9 sources → 8/30 107 sources → today 8 sources
  7. FACT The 8 aliases that left this public key today (ATK-F52F12 · ATK-ECACA6 · ATK-81D609 · ATK-E5EB34 · ATK-4F20AC · ATK-7B8ADA · ATK-21F6A0 · ATK-3E7375) do not overlap at all with the 10 aliases exposed yesterday. The same file gets planted from different sources every day
  8. FACT Command intent classification: grant execute permission 195 / reconnaissance (system) 119 / download then execute 30 / file download 30 / trace deletion 9 / persistence (SSH key planting) 8 / reconnaissance (network) 1. The classified total of 392 is 51.6% of all 760 commands
  9. INFERRED 'Grant execute permission' (195) overtook 'reconnaissance (system)' (119). Among the sixteen days this reversal is the second, after 8/29 (161 vs 75) — on the other fourteen days reconnaissance ranked first, and on 8/27 reconnaissance was 78.3% of all commands. This reads as a growing pattern of skipping reconnaissance and going straight to granting execute permission on files, but with no raw command text we do not assert it
  10. FACT 'File download' at 30 and 'download then execute' at 30 are exactly equal. Yesterday they were also equal at 42 and 42 — what gets downloaded leads to an execution step with virtually no exceptions
  11. FACT 'Trace deletion' fell sharply to 9, down from 114 yesterday. The highest values in the verified range are 70 on 8/25 and 114 on 8/30
  12. FACT The top credential today is admin/admin (15 distinct sources·35 times). Yesterday's top, 345gs5662d34/345gs5662d34, fell to 8 sources and the ordinary default-value dictionary climbed back to the top. 17 combinations cleared the citation threshold (3 or more distinct IPs)
  13. FACT 269 credential combinations did not clear the citation threshold and so their values are not published. That is on the low side within the verified range (maximum 1,388 on 8/18, minimum 142 on 8/29)
  14. FACT ATK-90AD90 (125.229.x.x, Telnet) login succeeded. 31 commands, 3 intent types (download then execute · grant execute permission · file download), 1 download, TTY recorded, completeness 16
  15. FACT ATK-5BDF54 (114.35.x.x, Telnet) login succeeded. 31 commands, 3 intent types, 1 download, TTY recorded, completeness 16
  16. FACT ATK-827EAF (114.38.x.x, Telnet) login succeeded. 31 commands, 3 intent types, 1 download, TTY recorded, completeness 16
  17. FACT ATK-14EBCD (187.109.x.x, Telnet) login succeeded. 31 commands, 3 intent types, 1 download, TTY recorded, completeness 16
  18. FACT ATK-ED706F (123.139.x.x, Telnet) login succeeded. 31 commands, 3 intent types, 1 download, TTY recorded, completeness 16. This is the last completed session of the day; no further completed sessions were added over the roughly six hours until the brief generation time (15:05Z)
  19. INFERRED The five completed sessions match entirely in command count (31), intent combination, download count, and completeness (16), and their elapsed times all fall within 66.9–79.9 seconds. All five are among the ten sources that left the 306-byte shell script. This reads as automation in which different sources ran the same script, but Telnet has no client fingerprint, so there is no means of confirming 'the same tool' by fingerprint among today's completed sessions
  20. FACT 01 collected 3 sample types today totaling 704 bytes (306 + 389 + 9). Yesterday it was 6 types·1,158 bytes. Executable binaries again number 0 today — a 306-byte POSIX shell script, a 389-byte OpenSSH public key, and 9 bytes of ASCII text are the whole of it
  21. FACT 11 SSH client fingerprint types were recorded. The top source fingerprint today is acaa53e0a7d7ac7d1255103f37901306 (SSH-2.0-OpenSSH_7.4) at 113 sources today·589 cumulative, 34.9% of 01's 324 total unique sources. Second is f555226df… (libssh_0.9.6) at 8 sources. Of the 11 types, two are marked as 'left a sample': 16443846184eafde36765c9bab2f4397 (SSH-2.0-Go, 3 sources today) and 98ddc5604ef6a1006a2b49a58759fbe6 (SSH-2.0-Go, 2 sources today)
  22. FACT Honeypot 02 (Beelzebub+adbhoney, low-interaction): 57,058 contacts · 293 unique sources. VNC (5900) at 53,310 contacts is 93.4% of the total but comes from only 46 sources (an average of 1,159 per source). RDP (3389) is 3,410 contacts from 164 sources, 20.8 per source. The rest are SMB (445) 137 contacts·47 sources, LDAP (389) 92 contacts·12 sources, MSSQL (1433) 57 contacts·15 sources, and 52 ADB sessions. The five services plus ADB sum to exactly 57,058, matching the total
  23. INFERRED 02's RDP contacts of 3,410 and 164 sources are both the maximum of the six days since 02 was added to the brief on 8/26 (previous maxima: 2,139 contacts on 8/30, 139 sources on 8/26). Over the same period VNC ranged between 29,111 contacts on 8/27 and 53,310 today, and its source count never left the 36–50 range. VNC is a fixed background made by a small number of sources; what actually changed today is the breadth of RDP sources
  24. INFERRED 02's top 9 sources (5,093–7,525 contacts each) total 53,240 contacts, equivalent to 99.9% of the 53,310 VNC contacts. However, since the data does not link sources to services, this is numerical proximity only
  25. FACT In 02's VNC negotiations the version proposed by the other side was 003.003 in 53,262 cases and 003.008 in 34 — 99.94% of proposed values are the lower one. Of the 8 proposed SMB dialects, SMB 2.??? appears only 2 times and the remaining 407 are older versions at or below NT LM 0.12
  26. FACT 02's RDP cookie values: hello 2,709 times (79.4% of the 3,410 RDP contacts) · <ip> 467 times · empty value 5 times · administrator 2 times · zgrab 1 time · BqDARFPuX 1 time. The 3,185 contacts with a recorded cookie are 225 fewer than the 3,410 RDP contacts
  27. INFERRED The single RDP cookie 'zgrab' is the day's only contact in which the other side wrote in its own tool name. On the same day 01's SSH client fingerprints also include dd9bcf093c355da7000132131cb36fd0 (SSH-2.0-ZGrab ZGrab SSH Survey, 2 sources today·50 cumulative). This is the name of a public internet-wide scanner, but this data cannot distinguish research/measurement purposes from attack preparation, nor can we confirm whether the two sensors' observations are the same actor
  28. INFERRED 02 had 52 ADB sessions but 0 samples collected. Yesterday there were 25 ADB sessions with 4 samples totaling 773,937 bytes. Session count grew 2.1× while nothing at all remained of what was delivered. ADB is the only channel on 02 where delivered content can remain, so on today's 02 observation surface there is no material for saying 'what came in'
  29. FACT Combined unique sources across the two sensors have an upper bound of 617 (01's 324 + 02's 293). Overlap between sensors is unknown, so this is not an exact value. Yesterday's upper bound was 532

FACT Look again at the bottom five lines. 66.9 seconds · 67.6 seconds · 67.0 seconds · 73.6 seconds · 79.9 seconds. All five have 31 commands, 3 intent types, 1 download, and completeness 16 — entirely identical. The times are scattered across 00, 02, 05, 06, and 09 hours, and all five sources are different.

INFERRED This is not something a person sits down and does. The chance that five people each coincidentally typed the same commands, in the same number, within a similar span of time is effectively nil. We read this as the same pre-written script replayed five times.

FACT There is a limit attached here, though. All five are Telnet. Telnet is a very old remote-access method in which the password travels unencrypted, and the client fingerprint itself does not exist. So among today’s completed sessions there is no way to confirm “it was the same tool” by fingerprint. This is the same constraint we ran into in the August 20 post.

Are You Using This Password?

FACT Login attempts that day: 440. Spread evenly across the full day, that’s someone trying an ID and password about once every 3 minutes 16 seconds.

FACT Below are the 17 combinations filtered down to only those observed from 3 or more distinct IPs. Combinations that appeared from a single source could be a real account leaked from somewhere, so we do not publish their values.

ID Password Number of sources that tried it
admin admin 15 sources (35 times)
345gs5662d34 345gs5662d34 8 sources
root 3245gs5662d34 7 sources
root admin 7 sources
root root 5 sources
root 123456 4 sources
root vizxv 3 sources
admin password 3 sources
admin adminadmin 3 sources
root 1234 3 sources
root default 3 sources
root 12345 3 sources
root 12345678 3 sources
root 123456789 3 sources
root P@ssw0rd 3 sources
root password 3 sources
root root123 3 sources

FACT Beyond these 17, there are 269 more combinations that appeared only from a single or small number of sources. We record only the count and do not write the values. For reference, 269 is on the low side within the verified range (maximum 1,388 on August 18, minimum 142 on August 29).

INFERRED The change in the table’s top row is the day’s quiet shift. 345gs5662d34, yesterday’s overwhelming leader at 107 sources, sank to 8, and admin/admin took the spot back at 15 sources. It looks as though, once the group carrying a special list moved on, the ordinary default-value dictionary that is always present climbed back to the top. In bus-stop terms: yesterday’s crowd cleared out and only the people who always stand there at that hour remained.

FACT And the rest of the table is all root/admin paired with common passwords. 123456, 1234, password, P@ssw0rd. This dictionary was not built to target a particular organization; it is a collection of defaults that work anywhere. Which means you don’t have to be conspicuous to become a target.

A Day That Skipped Reconnaissance

FACT What happened after a successful login is counted by classifying the ‘intent’ of the commands. Today’s ordering is as follows.

Intent Count
Grant execute permission 195
Reconnaissance — system 119
Download then execute 30
File download 30
Trace deletion 9
Persistence — SSH key planting 8
Reconnaissance — network 1

FACT The top spot changed. On fourteen of the sixteen days, ‘reconnaissance — system’ ranked first. On August 27, reconnaissance was 78.3% of all commands. This is the second time the order has flipped, after August 29 (161 vs 75).

Let me unpack a term here. ‘Grant execute permission’ means attaching a marker to a downloaded file saying “this is a program that may be run.” On Linux, merely receiving a file does not make it run. The marker has to be attached separately for it to work. ‘Reconnaissance’ is the step before that — looking around to see “what kind of machine is this.”

INFERRED So today reads as a pattern of cutting down the looking-around time and moving straight to execution preparation. However, since we do not have the raw command text, we cannot distinguish whether the actual sequence of behavior changed or whether this is a difference in how the classifier behaves.

FACT And ‘file download’ at 30 and ‘download then execute’ at 30 are exactly equal. Yesterday they were also equal at 42 and 42. It means what was downloaded led to an execution step with virtually no exceptions.

FACT One more thing. The 392 classified commands are 51.6% of all 760 commands. The remaining 48.4% were not classified under any intent. So every proportion in the table above is a ‘proportion within what was classified.’

What They Left Behind Comes to 704 Bytes in Total

FACT The files actually left on the server that day come to 3 types, 704 bytes total. That’s about the volume of a few lines of a short text message. Yesterday it was 6 types·1,158 bytes. Executable binaries — actual malware files, that is — again number 0 today.

Here are the values to write down. Click a value to copy it — these exist not to be read but to be put into a blocklist. The addresses are deliberately broken (hxxp://, [.]). Copying and pasting them as-is will not connect.

sha256
a6296a79f44e21b76604d2d2bbf795d2cf380f70e39d45fbf166707ff3b4a6a4306-byte POSIX shell script. About the size of two lines of a text message. Ten distinct sources (ATK-9C3568 · ATK-46EEE7 · ATK-5BDF54 · ATK-827EAF · ATK-36ADDA · ATK-357B6C · ATK-ED706F · ATK-2A42D2 · ATK-90AD90 · ATK-14EBCD) pulled the same file. All five completed sessions today are among these ten sources. It appears repeatedly in the archive, including 8/30
url
hxxp://185[.]93[.]89[.]72/wgetThe location where the above shell script was placed
sha256
a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2389-byte OpenSSH RSA public key. Source address not recorded. 8 sources·8 times today (yesterday 107 sources·112 times). The same hash for sixteen consecutive days since 8/16. With the address field empty, we treat it as a file created inside the session rather than downloaded from outside (the same judgment as the 8/17 brief). The eight aliases — ATK-F52F12 · ATK-ECACA6 · ATK-81D609 · ATK-E5EB34 · ATK-4F20AC · ATK-7B8ADA · ATK-21F6A0 · ATK-3E7375
sha256
4af5a5c98ad132095c6fbe7b02c242153a190a01cc321e50a916a0ca46fbaa629 bytes of ASCII text. The volume of nine characters. Source address not recorded. 1 source·9 times (ATK-BECAD3). The same hash was also present on 8/30 at 1 source·8 times. The content is not in the brief, so we make no judgment about what it is

FACT Of the three lines, only one has an address written on it. The other two read ‘source address not recorded.’

Two things to unpack here.

A fingerprint (sha256) is a 64-character value computed over an entire file. Change a single character inside the file and the value changes completely. That is how we judge whether two files are the same or different.

A public key works like this. A Linux server has a file called authorized_keys (the list of permitted keys). Write one public key line into it, and whoever holds its counterpart gets in without being asked for a password at all. In plain terms, it hangs a key that lets someone in without a password on the front door. And the important part: even if you change the password, that key stays hanging there.

INFERRED This public key is an annoying object for the defending side. There is no source address, so there is no address to put on a blocklist. Blocking all outbound traffic from the server does not stop it. That is because it is something that completes inside the server, at the very moment the door is successfully opened. Today the scale was merely small at 8 occurrences; the method is unchanged.

Mapping to the International Classification

The techniques attackers use carry numbers that the whole world shares. It’s a list called MITRE ATT&CK. Below, click an ID to go to the original description — we include them so you can verify directly rather than take our word for it.

  • T1110Brute Force — 440 login attempts. However, at 1.36 per source it is the lowest level in the verified range, so its shape differs from traditional brute forcingINFERRED
  • T1078Valid Accounts — all 5 completed sessions logged in successfullyINFERRED
  • T1222.002File and Directory Permissions Modification: Linux and Mac — 'grant execute permission' 195 times. The top intent todayINFERRED
  • T1082System Information Discovery — 'reconnaissance — system' 119 timesINFERRED
  • T1105Ingress Tool Transfer — 'file download' 30 times, hxxp://185[.]93[.]89[.]72/wget from ten sourcesINFERRED
  • T1059.004Command and Scripting Interpreter: Unix Shell — 'download then execute' 30 times, 306-byte POSIX shell script sampleINFERRED
  • T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — SSH key planting' 8 times + 389-byte public key from 8 sources·8 timesINFERRED
  • T1070Indicator Removal — 'trace deletion' 9 times. Down sharply from 114 yesterdayINFERRED
  • T1046Network Service Discovery — 'reconnaissance — network' 1 time. Separately, honeypot 02's contacts across five services also read as this category, but sources and services are not linked in the data, so we do not assert itINFERRED
  • T1595Active Scanning — RDP cookie 'zgrab' 1 time, SSH-2.0-ZGrab fingerprint at 2 sources on 01. The other side named itself in these contacts; the purpose cannot be confirmedINFERRED
  • T1021.005Remote Services: VNC — 02's port 5900 contacts, 53,310 from 46 sources. This is the contact and negotiation stage; no authentication success existsINFERRED
  • T1021.001Remote Services: Remote Desktop Protocol — 02's port 3389 contacts, 3,410 from 164 sources. The maximum of the six days, but likewise at the contact stageINFERRED
  • T1021.002Remote Services: SMB/Windows Admin Shares — 02's port 445 contacts, 137 from 47 sources. Of the 407 proposed dialects, 405 are older SMB1-family versionsINFERRED

FACT The largest number among the thirteen lines is the third, grant execute permission at 195. Reconnaissance, which held that spot yesterday (769 times), came down to 119 today.

INFERRED And all thirteen lines carry the ‘INFERRED’ badge. What we saw is the intent classification and counts of commands, not a purpose the attackers stated themselves.

The Whole of Yesterday

FACT Based on sensor 01 (high-interaction honeypot).

Item 2026-08-31 For comparison
Sessions 779 Spread over the day, about one every 1 minute 51 seconds. Second lowest of the sixteen days
Unique sources 324 Fourth highest of the sixteen days
Sessions per source 2.40 Lowest of the sixteen days. Next is 3.46 on 8/29, maximum is 17.33 on 8/22
Login attempts 440 Someone tried the doorknob about once every 3 minutes 16 seconds
Login attempts per source 1.36 Also the lowest. Effectively the same as 1.37 on 8/29
Commands 760 About one every 1 minute 54 seconds
Port 2222 (SSH) 556 sessions 71.4% of the total
Port 2223 (Telnet) 223 sessions 28.6% of the total
Protocol SSH 556 / Telnet 223 Matches the port figures above exactly
TTY recordings 195 —
Command intent total 392 51.6% of all 760 commands. The rest were unclassified
Samples collected 3 types · 704 bytes Yesterday 6 types·1,158 bytes. 0 executable binaries

INFERRED One number looks out of place. 71.4% of sessions are SSH, yet all 5 sessions that logged in successfully and actually did work are Telnet. Not a single session on the SSH side completed today. Far more knocking happens on the SSH side, but the only side that got in and did something was Telnet.

FACT Here are the numbers from the second server standing beside it (sensor 02) as well. This one is low-interaction, so login successes, commands, and credentials do not exist there in the first place. All it counts is ‘which door was knocked on and how many times.’ It is not a record of anyone getting in.

Service Port Contacts Unique sources Average per source
VNC 5900 53,310 46 sources 1,159
RDP 3389 3,410 164 sources 20.8
SMB 445 137 47 sources 2.9
LDAP 389 92 12 sources 7.7
MSSQL 1433 57 15 sources 3.8
ADB — 52 sessions — 0 samples collected

FACT In total, 57,058 contacts from 293 unique sources. Spread over the day, something knocked on this server about once every 1.5 seconds.

INFERRED Same server, but the picture at the two doors is the exact opposite. On the VNC side, 46 sources were attached at 1,159 contacts each. That means one source hitting the same door once every 75 seconds, all day long. The difference from yesterday (53,360 contacts·45 sources) is only 50 contacts — two consecutive days of nearly identical values. This side is background noise that doesn’t move.

FACT What actually changed today is the RDP side. 3,410 contacts, 164 sources. Since August 26, when we added this server to the brief, both contacts and sources are the maximum of those six days (8/26 1,221 contacts·139 sources / 8/27 1,425 contacts·116 sources / 8/28 2,114 contacts·120 sources / 8/29 1,064 contacts·132 sources / 8/30 2,139 contacts·127 sources).

INFERRED Back at the bus stop, it goes like this. At one stop, 46 people hold the same spot all day; at the other, 164 people stand briefly and leave. A few knocking persistently and many skimming shallowly arrive at the same server at the same time. And what grew today is the latter, the ‘number of distinct sources.’

FACT The protocols told us something too. In VNC contacts, the version the other side proposed was 003.003 in 53,262 cases, with the newer 003.008 only 34 times. 99.94% of proposed values are the lower one. Of the 8 proposed SMB dialects, SMB 2.??? appears only 2 times and the remaining 407 are older versions at or below NT LM 0.12. RDP connection cookies recorded hello 2,709 times (79.4% of RDP contacts), <ip> 467 times, empty value 5 times, administrator 2 times, zgrab 1 time, and BqDARFPuX 1 time.

INFERRED That single zgrab catches the eye. It is the day’s only contact where the other side wrote in its own tool name as-is. On the same day, 01’s SSH fingerprints also include SSH-2.0-ZGrab (2 sources today·50 cumulative). It is the name of a public internet-wide scanner, but this data does not distinguish research/measurement purposes from attack preparation. Nor can we confirm whether the two sensors’ observations are the same actor. Anyone can write in a name, so the name itself is no basis for identity.

FACT And there is one large gap on 02 today. There were 52 ADB sessions but 0 samples collected. Yesterday there were 25 sessions with 4 samples totaling 773,937 bytes. The session count grew 2.1× and not a single file remained.

INFERRED ADB is the only channel on 02 where file content can remain. That it is empty means there is no material at all, across 02’s entire observation surface today, for saying ‘what came in.’ What remains is only the count of knocks and the vocabulary the protocols have fixed in advance.

113 Sources Share a Fingerprint, but They Are Not One Group

FACT Connections coming in over SSH each open with a slightly different greeting depending on the program. The value summarizing that greeting is called a client fingerprint. It indicates which program was used to connect.

FACT There were 41 fingerprint clusters today, of which 11 types made the list. First is acaa53e0a7d7ac7d1255103f37901306 (SSH-2.0-OpenSSH_7.4) at 113 sources today, 589 cumulative. That is 34.9% of 01’s 324 total sources today. Second is yesterday’s leader, f555226df… (libssh_0.9.6), at 8 sources.

INFERRED Looking only at the number makes you want to write “113 sources are one group.” Today we attach the caveat more firmly than usual. This value is the default OpenSSH 7.4 client string that simply ships with widely used Linux distributions. It is normal for people with no relation to one another to have the same value.

FACT So what we can say goes only as far as “113 sources use the same tool.” “113 sources are one organization” does not hold up on this data. It’s the same standard by which we wrote only ‘the same tool’ about yesterday’s libssh cluster, except that today’s subject is a far more common value, so grouping it together has even less explanatory power.

INFERRED One more thing nags. The total cluster count fell for three consecutive days — 45 on August 29 → 43 on August 30 → 41 today — while over the same period the source count of the top cluster grew, 9 → 106 → 113. This appears to be tool diversity shrinking and concentrating on one side, but we cannot rule out that the aggregation criteria changed.

So What Should You Do

INFERRED Here are the six ‘had this control not been in place’ items the brief compiled, ordered by how strongly today’s data supports each.

1. Don’t leave admin ports open directly to the internet — This is today’s number one. In a single day, 324 sources contacted a server that was never advertised anywhere, and the server next to it drew RDP from 164 sources, SMB from 47, VNC from 46, MSSQL from 15, and LDAP from 12. Combining the two servers gives at most 617 sources (an upper bound, since overlap is unknown). Move the remote-access entry point behind a VPN or jump host, or restrict which sources may connect, and most of the contacts observed today disappear before they even reach the authentication stage. In particular, what grew today is the ‘number of distinct sources’ on the RDP side, a shape that blocklists collecting bad addresses have a hard time keeping up with.

2. Eliminate default accounts and common passwords — The 17 combinations in the table above are ones that 3 or more distinct IPs actually tried. On top of that there are 269 more whose values we did not publish. All 760 commands observed today were executed only after a successful login. On a real production server, that would mean an admin-privileged command prompt was handed over several times in a single day.

3. Restrict outbound connections from the server — File download at 30 and download-then-execute at 30 are exactly the same number. Had outbound traffic been blocked by default with only necessary destinations allowed, then even with the login breached it would have been cut off at the download stage. All 5 completed sessions today passed through this stage.

4. Change doors opened by passwords into doors opened by keys — 71.4% of today’s sessions are SSH. SSH can be locked down so it opens only with a key instead of a password. That said, today we rank this item lower. That’s because all 5 sessions with a successful login are Telnet. Telnet has no concept of key authentication at all, so the cause on that side is not ‘they didn’t use keys’ but ‘that service was left open.’ Since the data does not distinguish which side the credentials were attempted on, whether any SSH-side login succeeded cannot be established from today’s data.

5. Don’t rely on ‘lock out after N failures’ alone — Login attempts per source today were 1.36. An approach of ‘block an IP after N failures’ almost never reaches its trigger condition in this distribution. Yet the counter-evidence is inside the same day. The top entry admin/admin came from 15 sources at 35 attempts, 2.3 per source, and 02’s VNC had 46 sources at 1,159 each — a range where rate limiting would clearly have been effective. So this item is not ‘abandon it’ but ‘this alone is not enough.’ The two defenses do not substitute for each other; they cover different patterns.

6. Keep logs somewhere outside the server — Intent to erase traces was observed 9 times today as well. Down sharply from 114 yesterday, but not gone. The reason we can write the timeline above, and cross-check it against 195 TTY recordings, is that the records exist outside the server. If logs live only on that machine, then once they’re erased, not even the fact that they were erased remains.

FACT And a caveat on item 3. SSH key planting requires no outbound connection. Blocking all outbound traffic does not stop it. If you run a server, open the ~/.ssh/authorized_keys file once and look. If there’s a line you don’t remember adding, that’s someone else’s key. Changing the password does not remove it.

It Has Happened Before

INFERRED The Mirai botnet (2016). A case in which a single dictionary of default Telnet credentials was used to take over large numbers of devices, which were then made to download executables built separately for each CPU type. The fact that all 5 completed sessions today are Telnet, plus the per-CPU filename pattern in the indicators that only surface once the archive is unpacked (parm5·parm6·parm7·pm68k·pmips·pmpsl·pppc·psh4·pspc·x86_64), are of the same family in form. However, there is no basis for asserting that what we observed is of the Mirai family — we have no means (VirusTotal) of attaching a family name to samples, and the 3 samples collected today contain no executable binary. (Source: US-CERT/CISA alert TA16-288A, published source code)

INFERRED The FritzFrog P2P SSH botnet (2020). A case in which, after getting in via SSH credential guessing, the actor added its own public key to authorized_keys to secure continued access. The 8 occurrences of ‘persistence — SSH key planting’ observed today, and the pattern of the same 389-byte public key being planted from 8 sources for sixteen consecutive days, overlap with this technique. This is a similarity of technique, and there is no basis for saying it is the same campaign. We also note that today’s scale is small at 8 occurrences, so this item carries less weight than yesterday’s (116). (Source: published vendor report — Guardicore/Akamai)

What We Don’t Know

This is the most important part of this post. There is more that we could not write than what we wrote above.

  • [Key] There is no confirmation that the 8, 8, 8, and 8 are the same group. Credential source count, public key source count, fingerprint source count, key-planting count — we observed the four values placed side by side; that is not a fact the data tied together. That yesterday’s 107·107·106·116 and today’s 8·8·8·8 moved together strengthens the reading of ‘a single group’ but does not prove it.
  • We cannot explain from the data why the fingerprint f555226df…, at 106 sources yesterday, came down to 8 today. There is no basis for distinguishing whether a campaign ended, whether it moved to different targets, or whether our collection scope changed. Likewise, we could not explain why it spiked to 107 sources yesterday.
  • This fingerprint’s cumulative value decreased by 1, from 366 sources yesterday to 365 today. A cumulative value decreasing is by definition unexplained. Since we cannot tell whether the aggregation criteria changed or it was recomputed, we did not make any statement today that relies on this fingerprint’s cumulative value.
  • The TTY recording count is written as two different values, 195 and 208. Yesterday it was 982 and 205, with the relative sizes reversed. There is no explanation of whether the two count different things, or which is the number actually viewable.
  • ‘Grant execute permission’ at 195 and TTY recordings at 195 are exactly the same number. Since the data does not link the two, this is numerical coincidence only, and we attached no meaning to it.
  • The command intent classification totals 392 while all commands number 760. 48.4% of commands were not classified under any intent, with no explanation of why or of their nature. Accordingly, all per-intent proportions are ‘proportions within what was classified.’
  • We read ‘grant execute permission’ overtaking ‘reconnaissance’ as a shape that skips reconnaissance, but without the raw command text we cannot distinguish whether this is a change in actual behavior sequence or a difference in how the classifier behaves.
  • There are 41 fingerprint clusters but only 11 types appear in the list. The list’s source counts sum to 146, or 45% of 01’s 324 total. The distribution of the remaining 178 sources is unknown, and Telnet, which is 28.6% of today’s sessions, has no fingerprint at all.
  • The 113 sources of the top fingerprint acaa53e0… (SSH-2.0-OpenSSH_7.4) must not be read as one group. It is the default client string of a widely used distribution, so it is normal for many unrelated parties to share the value. Today this value is marked as not having ‘left a sample.’
  • We read the 5 completed sessions being identical at 31 commands and completeness 16 as ‘the same automation’, but because they are Telnet the fingerprint is empty, so there is no means of confirming tool identity. The August 20 post had the same constraint.
  • On sensor 02, we cannot compute whether a single source swept multiple services together. The sum of per-service unique sources (46+164+47+12+15=284) is smaller than the 293 total unique sources, so overlap cannot be back-calculated. This is the same constraint for six consecutive days.
  • We cannot know why 02 had 52 ADB sessions but 0 samples. The data does not distinguish whether there was no delivery attempt at all, whether an attempt was made but storage failed, or whether it was cut off at the negotiation stage.
  • We make no judgment about what the 2,709 RDP cookies reading hello mean. It is a string the connecting side fills in arbitrarily, and there is no basis for attributing it to a particular tool. The same goes for administrator at 2 times and the nine-character string BqDARFPuX at 1 time.
  • We cannot confirm whether the single RDP cookie zgrab and 01’s SSH-2.0-ZGrab fingerprint at 2 sources are the same actor. Anyone can insert a public scanner’s name as-is, so the name itself is no basis for identity. Nor can research/measurement purposes be distinguished from attack preparation.
  • The 99.94% figure for VNC negotiation version 003.003 is a distribution of ‘values the other side proposed.’ This distribution can be determined by what our honeypot presented first, so we do not draw conclusions about the nature of the other side’s tooling from this value. Nor is there an explanation for why 003.003 and 003.008 sum to 53,296, which is 14 fewer than the 53,310 VNC contacts.
  • The public key hashes being the same means ‘the same file,’ not ‘the same operator.’ Who holds the private key matching this key, and how many people do, is not in the data.
  • The 9-byte text sample (4af5a5c9…) has no content available, so we make no judgment about what it is. The same hash was also observed from 1 source on August 30.
  • We cannot know what, among today’s sessions and samples, the separately obtained Discord webhook address connects to. It did not appear in the address field of any download today, so we did not describe it in connection with today’s events.
  • The 12 distribution addresses that only surface once the archive is unpacked have a different host from the hxxp://185[.]93[.]89[.]72 observed today (hxxp://31[.]77[.]227[.]121). With no means of confirming whether it is the same campaign, we left them as background material only.
  • The 6,607 CVEs, 390 CISA KEV entries, and 98 confirmed ransomware cases we hold as background statistics are background context based on KISA security notices. They are not connected to today’s honeypot observations. No trace of a CVE being referenced was observed on the SSH or Telnet paths, and the same holds for 02, which is at the protocol negotiation stage.
  • The C-TAS report is confirmed only as far as having succeeded at the transport layer. Whether it was actually loaded on the KISA side requires separate confirmation.
  • Aliases (ATK-XXXXXX) are merely markers pointing to the same masked source across posts; they are not identities. Even for an alias that reappears, we cannot rule out that the party using that address changed in the interim.
  • The 617 combined unique sources across the two sensors is an upper bound. We cannot know whether the same IP appeared on both.
  • Finally, a honeypot is a server built to open the door. A successful login does not mean ‘these credentials also work on a real production server’; it means ‘these credentials are being tried.’

And below are the things we have no means of confirming in the first place. We do not speculate.

  • ASN·ISP — We have no such database. We cannot confirm which carrier or which hosting range. 02’s top sources each generated thousands of contacts, but this post cannot say what kind of infrastructure those addresses are.
  • Geolocation — Likewise unavailable. And IP geolocation is not a basis for attribution to begin with. We name no country, company, or individual as today’s attacker. We infer nothing from the masked positions.
  • VPN·Tor·cloud status — We have no means of determining this. That 02’s top 9 sources are evenly spread across 5,093–7,525 contacts is likewise no basis for saying they are ‘the same kind of infrastructure.’
  • VirusTotal — Not integrated. We cannot attach malware family names to the 3 samples collected today (306-byte shell script · 389-byte public key · 9-byte text). Sample classification uses MalwareBazaar tags.
  • User-Agent — Neither observation surface is HTTP. 01 is SSH and Telnet; 02 is SMB, RDP, VNC, MSSQL, LDAP, and ADB. The RDP cookies, SMB dialects, and VNC versions cited above are not substitutes for a User-Agent but negotiation vocabulary fixed by the protocols.
  • CVE linkage — SSH and Telnet attacks mostly use credentials without referencing a specific vulnerability. The same holds for 02, which is at the protocol negotiation stage. No CVE is connected to these observations today.

INFERRED To sum up, today looks like this. 779 sessions, 440 login attempts, 760 commands. The four numbers that yesterday read 107·107·106·116 all became 8, and trace deletion, at 114 yesterday, became 9. Instead, sources that came numbered 324, the fourth highest of the sixteen days, while how long each stayed was the lowest at 2.40 sessions.

The four rose together and came down together. So we can now state the guess “people who got off one bus” a little more firmly than yesterday. And yet we still have not seen the bus. All we did was count heads twice over two days. Erase that distinction and it stops being an observation record and becomes a story.

And one more thing. That group has not disappeared. If it was 107 sources yesterday and 8 today, it’s more natural to think it stood at a different bus stop today. So what today’s data points to is not “write yesterday’s crowd of sources down on a list.” That list goes stale in a day. If you have even one server, there are just two things to do today. Check whether your remote-access entry point is sitting open on the internet, and open ~/.ssh/authorized_keys once and look. The latter takes a few seconds.

The observation day is August 31, 2026 (UTC), one day. Source IPs are carried over in the brief’s masked form (125.229.x.x, 114.35.x.x, 114.38.x.x, 187.109.x.x, 123.139.x.x) and were not restored. Distribution addresses are written in altered form so they will not connect (hxxp://, [.]). Credentials are cited for only the 17 combinations observed from 3 or more distinct IPs; for the 269 combinations that did not clear that threshold, only the count is given and no values are published. ASN, nationality, and actor attribution are not speculated on, as we have no means of confirming them.