Only One New Thing — And It Didn't Come Through the Front Gate

The front gate of a school is crowded every morning. Hundreds of people walk past it. The security guard is stationed there, and the CCTV camera is mounted there. It’s the most visible door in the school.

But that isn’t the door things come in through.

Cafeteria ingredients, new desks, printer toner. Those arrive on a truck through the back gate. The back gate opens only a few times a day. Almost nobody passes through it. So nobody watches it.

Here’s a question. If one thing you’d never seen before entered the school today, which gate did it come through?

On September 2, 2026, our server looked exactly like that. The doorknobs turned more than forty thousand times all day, and the number of new things that actually made it inside was one.

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

Our School Has Two Kinds of Doors

FACT We run two honeypots. They have very different personalities.

No. 01 is a server where a person can actually get in and type commands. It has two doors. One is SSH, the other is Telnet. Both are ways to connect to a distant computer and issue commands. Telnet is the far older method, and passwords travel across it unencrypted, in the clear.

No. 02 is a server with nothing but doorknobs attached. When someone knocks, it just answers “there’s a door here.” It doesn’t let anyone inside. So on this side, there are no successful logins, no commands, and no password records to begin with. Here, the word “contact” means the number of times a door was knocked on, not the number of times one opened.

FACT Here are the numbers the two servers took that day. No. 01 had 931 connections; No. 02 had 44,140 contacts.

INFERRED Divide 44,140 across the day and it works out to about once every 2 seconds. On a machine we never advertised anywhere.

The Front Gate Side — Five Visitors, 67 Seconds Each

FACT On No. 01, a door actually opened five times. All five were Telnet.

Laid out in chronological order, it looks like this. Pay attention to the seconds in the third field. The five lines are hours apart from each other, and what happens to the time spent and the number of commands typed is the starting point for the whole day.

1. 2026-09-02T00:14:33Z
   FACT ATK-A16118 (Telnet) logs in successfully. 31 commands over 67.0 seconds, 1 download. TTY recording exists. (09:14 KST)
2. 2026-09-02T05:48:12Z
   FACT ATK-862174 (Telnet) logs in successfully. 69.6 seconds, 31 commands, 1 download. 5 hours 34 minutes after the previous session
3. 2026-09-02T08:30:49Z
   FACT ATK-E78846 (Telnet) logs in successfully. 68.0 seconds, 31 commands, 1 download
4. 2026-09-02T11:08:49Z
   FACT ATK-33BCCE (Telnet) logs in successfully. 67.8 seconds, 31 commands, 1 download
5. 2026-09-02T11:19:53Z
   FACT ATK-DC5B7B (Telnet) logs in successfully. 67.5 seconds, 31 commands, 1 download. 11 minutes 4 seconds after the previous session
6. 2026-09-02 (time unknown)
   FACT All five sessions pulled down the same hash a6296a79… (306-byte shell script, hxxp://185[.]93[.]89[.]72/wget). A total of 6 sources fetched the same file today (the sixth is ATK-B07E97)
7. 2026-09-02 (time unknown)
   FACT A 389-byte OpenSSH RSA public key (a8460f44…) observed 11 times, from different source aliases. The same day's "persistence — planting an SSH key" intent also totals 11, matching exactly
8. 2026-09-02 (time unknown)
   FACT One 733,706-byte sample captured on 02 (honeypot 02) (deacb991…, ATK-89DA24). 02's samples_captured for today is 1
9. 2026-09-02 (daily totals)
   FACT 01: 931 sessions · 437 unique IPs · 887 commands. Down to 1/15.9 from yesterday's (09-01) 14,085 commands, while unique IPs actually rose from 414 → 437. At 2.13 sessions per source, this is the lowest of the 18 days in the archive
10. 2026-09-02 (daily totals)
    FACT Of 02's 44,140 contacts, 42,905 (97.2%) went to a single port, VNC 5900, and only 62 sources produced them

FACT Look at those five lines again. 67.0 seconds · 69.6 seconds · 68.0 seconds · 67.8 seconds · 67.5 seconds. And the commands were 31 all five times, and the files taken were 1 all five times.

INFERRED The arrival times are all over the place. Between the first and the second: 5 hours 34 minutes. Between the fourth and the fifth: 11 minutes 4 seconds. They didn’t coordinate when they showed up, but what they did matches down to the second. This isn’t something a person sits and does. We read it as the same pre-scripted sequence being replayed.

INFERRED All five together add up to 5 minutes 40 seconds. That’s the total time the front gate stood open all day. And in those 5 minutes 40 seconds, 155 commands went through.

FACT Here’s the number that looks most out of joint that day. The SSH door got 577 connections; the Telnet door got 349. SSH got 1.65 times more. And yet all five doors that actually opened were Telnet.

INFERRED The door that got knocked on most is not the door that opened. This mismatch comes up once more later on.

What the Five Carried Off Is the Same Thing, on Day 17

FACT The file the five sessions fetched is a single 306-byte shell script. About the size of a two-line text message.

Let me unpack two terms here.

A hash (sha256) is a 64-character value computed from an entire file. Change a single character inside the file and the value changes completely. So this value is what we use to judge whether “this file and that file are the same thing.”

A shell script is a file like a memo listing commands in order — “do this, then do that.” At 306 bytes, it’s very short.

INFERRED Judging by size and type, this isn’t the weapon itself but the errand runner that goes and fetches the weapon. Commonly called a loader. That said, we don’t have the raw text of what commands these sessions actually typed, so we couldn’t confirm what happens inside the script.

FACT And this file’s hash, a6296a79…, appears in all 16 days of records from August 17 through September 1. Counting today, that’s 17 consecutive days. The fetch address hxxp://185[.]93[.]89[.]72/wget is unchanged as well.

FACT The most-delivered file that day was a different one: a 389-byte OpenSSH RSA public key. It was observed 11 times that day, from different source aliases.

Let me unpack what a public key is. On a Linux server there’s a file called authorized_keys (the list of permitted keys). Write one public key line into it, and whoever holds the matching half gets in without being asked for a password at all. Put simply, it’s hanging a spare key that opens without a password by the front door. And the important part: even if you change the password, that key stays right where it is.

FACT This key file’s hash, a8460f44…, appears in all 17 days from August 16 through September 1. Counting today, that’s 18 consecutive days.

FACT Commands classified that same day as “persistence — planting an SSH key” also number 11. That matches the 11 file observations exactly.

INFERRED So the conclusion for server No. 01 is short. Nothing on 01 that day was something we hadn’t seen before. The files, the addresses, the shape of the sessions — all previously seen.

But There Was One Thing We’d Never Seen

FACT One file was captured on server No. 02. Its size is 733,706 bytes.

INFERRED The number alone doesn’t land. Let me give you something to compare it to. It’s the size of 2,398 of the 306-byte errand runners strung together. About 717 kilobytes, roughly the bulk of one smartphone photo.

FACT And this file’s hash, deacb991…, appears nowhere in the 17 days of records we hold. It is the day’s only new sample.

FACT Server No. 02 captured exactly this one file that day.

INFERRED So which door did this thing come in through? On No. 02, the only passage a file can actually ride in on is ADB. ADB is short for “Android Debug Bridge,” a developer channel for connecting an Android device to a computer to push and pull apps. The other doors have nothing but doorknobs, so they don’t receive files. That’s why we take it as having come in via ADB. However, the raw data does not explicitly link this download to ADB. This is something we stitched together by looking at the structure.

FACT And here is the point of the day. The ADB passage opened 23 times that day. That’s 0.05% of No. 02’s 44,140 total contacts.

FACT That same day, a single VNC port was knocked on 42,905 times. 97.2% of the total. And the number of files captured from that side is 0.

INFERRED Back to the back-gate story. While the doorknob at the front gate turned forty thousand times, the thing that newly entered the school came in through a door that opens twenty-three times a day. Number of knocks and what actually gets in are not proportional.

Values Worth Writing Down

FACT Below are the four file types observed that day. Tap a value to copy it — these exist to go into a blocklist, not to be read. The addresses are deliberately broken (hxxp://, [.]). Copy and paste them as-is and they won’t connect. The bottom line is the day’s only first-time value.

FACT Of the five lines, only one has an address written on it. The rest all read “address not recorded.”

INFERRED For defenders, this is a nuisance. If there’s no address to block, there’s nothing to put on the blocklist. The 389-byte key in particular isn’t stopped even if you cut off all outbound traffic from the server. That’s because it’s something that finishes inside the server, in the moment the door opens.

Are You Using This Password?

FACT There were 547 login attempts that day. Spread evenly across a full day, that’s about once every 2 minutes 38 seconds somebody tried an ID and a password.

FACT Below are the 20 combinations filtered down to only those observed from 3 or more distinct IPs.

FACT These 20 are not all the ID/password combinations observed that day. There are 239 more that didn’t clear the threshold. Those 239 were counted only; their values are not published.

INFERRED Here’s why. A combination that showed up from only one or two sources may be some real person’s account that actually leaked somewhere. Reprinting it here would be doing that person a second harm. So we only count them.

FACT And look again at six lines in the table above. root/xc3511, root/vizxv, root/xmhdipc, root/juantech, root/54321, root/888888. These six match combinations in the credential table embedded in the Mirai botnet source code that was leaked publicly in 2016.

INFERRED Which means a list nearly ten years old arrived unchanged again that day. And a list that doesn’t change is a signal that the list still works. That said, we have no basis for saying the attacks that day were Mirai itself. We hold neither the raw command text nor a sample classification.

Mapped to the International Classification

The techniques attackers use carry numbers that the whole world shares. It’s a list called MITRE ATT&CK. Below, tapping an ID takes you to the original description — attached so you don’t have to take our word for it and can check directly.

• T1078.001Valid Accounts: Default Accounts — 5 successful login sessions, 20 factory-default-family combinations including admin/admin across 15 IPsINFERRED
• T1110.001Brute Force: Password Guessing — 547 login attemptsINFERRED
• T1105Ingress Tool Transfer — "file download" 18 times, the 306-byte script delivered to 6 aliasesINFERRED
• T1059.004Command and Scripting Interpreter: Unix Shell — 887 commands, "download then execute" 18 timesINFERRED
• T1222.002File and Directory Permissions Modification: Linux and Mac — "granting execute permission" 135 times, the day's most frequent intentINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — "planting an SSH key" 11 times + the 389-byte public key 11 timesINFERRED
• T1070Indicator Removal — "erasing traces" 12 timesINFERRED
• T1082System Information Discovery — "recon — system" 60 timesINFERRED
• T1046Network Service Discovery — 01's "recon — network" 1 time, 02's 44,140 contacts across 5 servicesINFERRED
• T1021.005Remote Services: VNC — 42,905 contacts on port 5900. Being low-interaction, no session establishment or successful authentication was observed. It goes as far as contact and negotiation attemptsINFERRED
• T1021.001Remote Services: Remote Desktop Protocol — 808 contacts on port 3389, 124 unique sources. Same limitation as aboveINFERRED

FACT All eleven lines carry the “INFERRED” badge. That’s because what we saw is an intent classification of commands and a count, not a purpose the attacker stated themselves.

FACT And the bottom two lines, VNC and RDP, carry one more caveat. No. 02 is a server with nothing but doorknobs, so the event “successful login” doesn’t exist there at all. Those forty thousand are “knocked,” not “got in.”

The Whole of Yesterday

FACT This is based on sensor 01 (the side a person can actually get into).

INFERRED The strangest line in the table is the second one. Sessions fell to 1/3.9 and commands to 1/15.9, yet the number of places that showed up went up. More people came, and each one did far less. At 2.13 per source, that’s the lowest value of the 18 days we hold.

FACT The “intents” attached to that day’s commands break down like this. An “intent” is a classification of what a typed command was trying to do.

FACT “Granting execute permission” is the act of attaching a marker to a downloaded file saying “this is a program that may be run.” On Linux, a file you’ve merely downloaded won’t run. You have to attach that marker separately.

FACT And “file download” at 18 and “download then execute” at 18 are exactly the same number. Meaning that what was downloaded led to the execution step without exception.

FACT Let me also carry over the numbers from server No. 02 standing beside it. Again, “contact” here means the number of knocks.

FACT The six lines sum to 44,140, matching the total exactly. And look at the top and the bottom side by side. From 42,905 contacts, 0 files; from 23 contacts, 1 file.

FACT There’s one more shape on the VNC side. The top 7 sources by event count that day were 7,242 / 7,163 / 6,673 / 5,107 / 5,060 / 5,040 / 5,035. And the 8th is 170.

INFERRED Between 7th and 8th there’s a 29.6x cliff. And the top 7 combined, 41,320, are 96.3% of the day’s VNC contacts. These seven look like the substance of the VNC flood.

FACT But we stop here. Whether these seven are related to each other is unknowable. Similar numbers alone don’t let us write that they’re the same actor, and we have no means of checking.

FACT Let me also carry over what the protocols told us. Protocol vocabulary means the value the connecting side proposes up front: “I’ll speak this version.”

• The versions proposed on VNC were 003.003 in 41,336 contacts and 003.008 in 1,135. Of the 42,471 contacts where a version was recorded, 97.3% were on the lower side.
• SMB dialect proposals were NT LM 0.12 77, LANMAN1.0 68, LM1.2X002 68, and so on. Contacts proposing SMB 2.??? numbered only 3.
• RDP connection cookies were <ip> most often at 437, then hello 184, eltons 7, empty 5, Domain 2, and HQJrlorlj 1.

INFERRED RFB 3.3 is an old version in which the server decides the authentication method, making it a value a tool broadly hunting for unauthenticated screen-sharing servers might prefer. That said, the basis for this reading is the protocol definition, not this data. Same on the SMB side: the tools knocking on doors that day spoke almost entirely in 1990s dialects.

INFERRED Putting the target IP itself in the RDP cookie field instead of a username (437 contacts, the most common) reads as the trace of an automated tool working through a list, not a person.

The Best Tool We Have Didn’t Reach, of All Days, Today

FACT Incoming SSH connections 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. It’s just about the only material we have when we want to say “these connections were the same tool.”

FACT 41 fingerprint clusters were tallied that day. The top one was acaa53e0a7d7ac7d1255103f37901306 (SSH-2.0-OpenSSH_7.4), at 246 sources that day and 899 cumulatively. That’s 56.3% of the 437 unique sources on No. 01 that day.

INFERRED Looking at the number alone, you want to write “246 sources are one group.” We won’t. This value is the string of the default OpenSSH 7.4 client that simply ships with widely used Linux distributions. It’s normal for people with no connection to each other to have the same value. What can be said goes as far as “246 sources use the same tool,” and “246 sources are one organization” does not hold up with this data.

FACT And there’s one more limitation that day. All five doors that actually opened were Telnet. Telnet has no such thing as a fingerprint at all. SSH exchanges greetings on connect; Telnet has no such step. That’s why the fingerprint field and the client program field are empty for all five sessions.

INFERRED To sum up: all 41 fingerprint clusters are an SSH-side story, and the five places actually breached that day belong to none of them. The best grouping tool we have happened not to reach that day’s intrusions. This isn’t a collection failure; it’s a structural limitation of Telnet as a method.

So What Should You Do

INFERRED Here are the brief’s seven “if this control had been missing” items, ordered by how strongly that day’s data backs each one.

1. Get rid of factory-shipped accounts and common passwords — the five doors that opened that day were all successful logins. And all 20 entries in the table above are either defaults or four-digit numbers. Look at what happened next. 31 commands within an average of 68 seconds. On a real server, within those 68 seconds a file would have come down and had an execute marker attached. There is no time for a person to notice.

2. Turn off Telnet — all five successes that day were Telnet. Telnet has no key-authentication option at all, and passwords travel across it unencrypted. So the thing to do on the Telnet side isn’t “let’s use keys,” it’s “let’s turn that service off.” On the SSH side, block password authentication and permit keys only, and all 547 attempts that day end at the authentication step.

3. Don’t leave remote-access and management ports open straight onto the internet — two machines we never advertised anywhere took 44,140 and 931 hits in a single day. On the VNC port alone, 62 sources knocked 42,905 times, 692 per source. Even with zero vulnerabilities, that much pressure is applied constantly. Exposure itself determines the volume of attempts. Move them behind a VPN or an allowlist and this entire volume of attempts disappears before it ever reaches the authentication step.

4. Keep the Android debug channel (ADB) turned off — this is the point of the day. In contacts it’s 23 out of 44,140, 0.05%. And yet the day’s new sample came from there. Leave an unused developer channel switched on and attached to the internet, and even with few knocks, the actual delivery happens over there.

5. Restrict outbound connections from the server — the stage where an intruder, once inside, fetches the real weapon is entirely outbound connections. That day’s “file download” 18 times and “download then execute” 18 times are exactly that. Had outbound traffic been blocked by default with only the necessary destinations permitted, the login could still have been breached but the 18 deliveries would have failed. This is your second line of defense.

6. Keep logs somewhere outside the server — intent to erase traces was observed 12 times that day. Had the logs lived only inside the server, those 12 would have succeeded, and whoever investigated later would be looking at logs saying “nothing happened.” The reason we can count these 12 is that the logs accumulate separately, outside the honeypot.

7. Don’t rely on “lock out after N failures” alone — that day this item cuts both ways. On No. 01, sessions per source were 2.13. With each source knocking two or three times and leaving, a threshold like “block after 5 failures” would barely have fired that day. That’s the shape of IP-based blocking being neutralized. Conversely, No. 02’s VNC ran 692 per source. Had rate limiting been in place there, most of the 42,905 would have been cut. The same measure is useless at one door and decisive at another.

FACT And a caveat on No. 5. Planting an SSH key requires no outbound connection. Block all outbound traffic and this still isn’t stopped. If you run a server, open up ~/.ssh/authorized_keys once and look. If there’s a line you don’t remember putting there, that’s someone else’s key. Changing your password does not erase it.

It Has Happened Before

INFERRED The Mirai botnet (2016). A case of mass-infecting IoT devices using Telnet and a dictionary of device factory-default accounts. When the source code was published, the credential table inside it was exposed along with it. Six of the 20 combinations we quoted that day (xc3511, vizxv, xmhdipc, juantech, 54321, 888888) match combinations in that table. It means a list nearly ten years old is still circulating unchanged, and that is a signal the list is still effective. That said, we are not attributing that day’s observations to Mirai. We hold neither the raw command text nor a sample classification. We also don’t quote figures like infected device counts or damage amounts. (Basis: the publicly leaked source code, US-CERT/CISA alert TA16-288A.)

We Don’t Stop at Observing

FACT The distribution address captured that day, hxxp://185[.]93[.]89[.]72/wget, and the new sample deacb991… are subject to reporting to C-TAS (the Korea Internet & Security Agency’s cyber threat information analysis and sharing system).

INFERRED Even on a day like this one, when there’s nothing new at all on No. 01, the one new hash from No. 02 is a value worth reporting. That one thing that came in through the back gate was the only new information we had to offer the outside world that day.

FACT One caveat, though. What we can confirm goes as far as the transmission having succeeded. Whether it was actually ingested on the receiving side is something these records cannot tell us.

What We Don’t Know

This is the most important part of this post. There is more we couldn’t write than what’s written above.

• [Core] We don’t know what the five sessions executed. What we have is intent classifications and command counts, and we don’t have the raw command text. The TTY recordings are confirmed only to exist (201 that day, 213 cumulatively); their contents are not in this brief.
• [Core] Treating the 733,706-byte sample as having come via ADB is an inference. It comes from the structural fact that “the only passage a file can ride in on at No. 02 is ADB,” and the raw data does not explicitly link this download to any specific service.
• We also don’t know what this new sample is. File type, classification, and MalwareBazaar tags are not in the brief. “A file we haven’t seen before” and “a malicious file” are two different statements. We can only make the first one.
• The fingerprint and client-program fields for the five sessions are all empty, so we can’t group them by SSH fingerprint. That’s a structural limitation of Telnet, not a collection failure.
• The only basis for viewing the five sessions as the same tool is the match in command counts, files fetched, and time taken. It does not mean the same organization. Unrelated people each running the same widely distributed script would look exactly the same.
• No. 01’s per-port session sum (577 + 349 = 926) is off by 5 from the total of 931 sessions. The cause is unknowable from these records.
• On VNC, 42,471 contacts had a version recorded while the total is 42,905. 434 have no version information. We can’t distinguish whether they dropped before negotiation or the record was simply missing.
• The 389-byte public key was observed 11 times, but only 10 entries are carried in the source alias list. We don’t know where the eleventh source is.
• The 9-byte text sample has a count of 6 but a single source. The two values disagree and we have no basis for judging which is right, so we did not interpret the count in the body.
• On No. 02, we cannot compute whether a single source swept multiple services together. The top-sources list has only total event counts, with no per-service breakdown. So we don’t know whether the top 7 VNC sources knocked on other doors too.
• We can’t know the intersection of the two servers’ unique sources, so we can only speak of a combined unique-source ceiling of at most 737.
• The background statistics we hold — 6,607 CVEs, 390 CISA KEV entries, 98 confirmed ransomware cases, plus the Fortinet, Confluence, Log4j2, NetScaler, and PAN-OS items — are background context pulled from KISA security advisories. They are not connected to that day’s honeypot observations.
• C-TAS reporting is confirmed only as far as success at the transport layer.
• Aliases (ATK-XXXXXX) are merely markers pointing to the same masked source across posts; they are not identities.
• Finally, a honeypot is a server built to open its doors. A successful login does not mean “this password works on real production servers too”; it means “this password is being tried.”

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

• ASN and ISP — we have no such database. We cannot confirm which carrier or which hosting range.
• Geolocation — likewise absent. And IP geolocation is not by itself a basis for attribution. We name no country, company, or individual as that day’s attacker.
• VPN / Tor / cloud status — we have no means of determining it. This is also why we did not interpret the fact that No. 02’s top 7 sources that day were of similar scale.
• VirusTotal — not integrated. Including the 733,706-byte new sample, we cannot state in this post whether that day’s samples are malicious or how they’d be classified.
• User-Agent — neither observation surface is HTTP. No. 01 is SSH and Telnet; No. 02 is SMB, RDP, VNC, MSSQL, LDAP, and ADB. The RDP cookies, SMB dialects, and VNC versions quoted above are not substitutes for a User-Agent but negotiation vocabulary fixed by the protocols.
• CVE linkage — SSH and Telnet attacks generally use credentials rather than referencing a specific vulnerability. No. 02 is the same, being at the protocol negotiation stage. We cannot link a specific vulnerability to any of that day’s observations.

INFERRED To sum up, the day went like this. The doorknobs turned 44,140 times and 931 times. Doors actually opened five times, 5 minutes 40 seconds all told. And what those five carried off was the same thing, on day 17, while the most-delivered key of the day was the same thing, on day 18.

INFERRED Back to the school. However crowded it gets at the front gate, the things that come inside come through the back gate. That day’s one never-before-seen thing came in through a door that opens twenty-three times a day, and nothing came in through the door that was knocked on forty thousand times.

So what that day’s data points to is not “guard the noisiest door.” It’s “start by counting how many doors you never counted.” If you have even one machine attached to the internet, there are just two things to try today: check whether an admin or developer channel you don’t even remember switching on is open, and open up ~/.ssh/authorized_keys once and look. The latter takes a few seconds.

The observation period is the single day of September 2, 2026 (UTC). Source IPs were carried over in the brief’s masked form (59.126.x.x) and not restored. Distribution addresses were written in altered form so they won’t connect (hxxp://, [.]). For credentials, we quoted only the 20 combinations observed from 3 or more distinct IPs, and for the 239 combinations that didn’t clear that threshold we disclosed only the count and did not publish the values — because a combination seen from only one or two sources may be a genuinely leaked account. ASN, nationality, and actor attribution are not speculated on, as we have no means of confirming them.