3,026 Numbers We Didn't Write Down — Everything Else Was Something We'd Seen Before

Picture a school hallway lined with lockers, each with a combination lock. Every break, someone walks past and spins the dial on someone else’s lock. Most of them try 0000 or 1234. Those are the numbers anyone thinks of first.

But every so often, someone tries a strange number. Not 0000, not 1234 — something oddly specific. What if it is somebody in this class’s actual locker combination? You wouldn’t want to post that number on the hallway bulletin board.

Today’s story is about what we posted on that board and what we did not. Yesterday, the numbers we did not post came to 3,026.

Our lockers are bait, deliberately left on easy combinations

FACT We run a honeypot. A honeypot is a decoy server left deliberately exposed so we can watch who comes and what they do. Think of it as an empty locker left on an easy combination with a CCTV camera pointed at it. What follows is not an account of actual damage — it is an observation record.

FACT There are two lockers. The first (sensor 01) actually opens when the combination is correct. It even records the commands typed by whoever opened it. The second (sensor 02) never opens. It only writes down who came and how they spun the dial.

The whole of yesterday

First, how busy it was in front of the first locker. Look at the “once every N seconds” figures in the right-hand column.

FACT SSH and telnet are both ways of getting into a distant computer and typing commands. SSH wraps what passes back and forth in encryption. Telnet is an older method that does not. Small devices like routers and cameras sometimes still leave the telnet door open.

FACT Of the 11,394 commands, 3,516 carry a classification for “what was this trying to do.” That is about 30.9% — roughly three in ten.

FACT Reconnaissance dominates. The very first thing done after opening the locker was looking around inside. All five remaining rows added together come to less than a tenth of reconnaissance.

The numbers we posted on the board, and the ones we didn’t

FACT Of the ID/password combinations tried yesterday, 20 are reproduced verbatim in this post. Our rule is a single one: we only write down combinations tried identically from three or more different IPs. Combinations that fall short of that bar get counted, not quoted. Yesterday that count was 3,026 types.

FACT 3,026 is the highest value across the 32 briefs we have accumulated. The previous maximum was 2,527 types on September 7. That is about 1.2 times higher. For every one number we posted on the board, there were roughly 150 we did not.

INFERRED A combination that showed up from only one or two sources may be someone’s real account, leaked from somewhere. It is like the oddly specific number that exactly one person in the hallway tried. So we do not write the values down. The 20 below, by contrast, are numbers many sources bring with them. They belong to no one — they are factory defaults. Look at the number in the first row.

FACT “(blank)” means an attempt to get in with no password at all. It is like pulling on the door without touching the dial. Those attempts came from 4 sources too.

FACT Why the figure rose to 3,026 types yesterday, we do not know. The data does not distinguish whether the other side’s number lists changed or our own counting method changed.

Thirty-three visitors, once each — and the same key

FACT 345gs5662d34 / 345gs5662d34 in the first row of the table was tried exactly 33 times from 33 different IPs. Once per source.

FACT On the same day, a 389-byte SSH public key file was also left 33 times from 33 different sources. 389 bytes is 389 English characters — about one short note. Here is what planting an SSH public key means: you quietly add your own key to the locker’s “open for this key too” list. After that, even if the dial combination changes, that key still opens it. On a server this list file is called authorized_keys (the list of permitted keys). This public key has been appearing continuously since the August 16 brief.

FACT The number 33 turns up in one more place. A program connecting over SSH presents its own configuration combination when it connects. The value derived from that is called a fingerprint. Fingerprint f555226d… (SSH-2.0-libssh_0.9.6) was seen from 33 IPs yesterday. libssh is a bundle of parts used to build SSH client programs. Behavior classified as “planting an SSH key” occurred 34 times.

INFERRED 33 sources for the password combination, 33 for the key, 33 for the fingerprint. It looks like the same tool running “log in once from each source, then add the same key to the list.” But whether the 33 sources behind the three figures are the same 33, we cannot confirm. The data contains nothing that links them per source.

FACT This fingerprint group now totals 693 sources cumulatively, the largest of 52 groups. That said, the “cumulative” value has decreased before, so it should not be read as an exact increment. And an identical fingerprint only means the same tool — not the same person or organization. Unrelated people running the same libssh version produce the same value.

INFERRED What matters here is a rule like “lock out after five failures.” If each source only spun the dial once, that rule would never have fired. By contrast, root/xc3511 was tried 87 times from 3 sources — 29 times per source. That kind gets caught by lockout rules nicely.

Footage that overlaps a recording from 42 days ago

Now the five sessions that actually opened a locker. All five were telnet, and all five logged in successfully.

FACT The one that did the most was ATK-F2B80A (121.161.x.x). Names beginning with ATK- are aliases we assign per source. This session typed 48 commands over about 32.5 seconds. That is about 1.5 commands per second — a speed that is hard for a person typing by hand. It left 12 files inside the locker.

FACT But this alias also appears in the August 23 brief. Set the two days side by side and you get this.

FACT 42 days passed. The only thing that changed was the start time. The durations differ by 0.1 seconds. Overlay the two CCTV clips and they very nearly superimpose.

FACT Of the 12 files put in the locker, 11 are one-byte empty files. The size of exactly one character. That empty file appeared 22 times in all yesterday, and has recurred since August 17. The remaining one is a 202-byte shell script. A shell script is a note with several command lines gathered into one file. 202 bytes is 202 English characters — a couple of lines of a text message. This note has now appeared for the fourth time, following August 21, August 23, and September 6.

INFERRED The same alias does not mean the same person came back. An alias is just a device for seeing whether a source persists. The same automated program running again from the same address fits the data better. Automated programs do not care what day it is. Put them in front of the same locker and they do the same things in the same order.

FACT There is one more near-replica. ATK-2CB5A2 (58.72.x.x) typed 20 commands over about 17.7 seconds and left 11 files. Log density was 40. The August 29 brief has the same alias recorded with 20 commands, 11 files, about 18 seconds, and 40. That is 36 days apart.

FACT ATK-50E6EA (45.238.x.x) is the session with the most behavior classifications attached yesterday. Reconnaissance, file download, granting execute permission, execute after download, and planting an SSH key — five of them. It had 17 commands and left 0 files. This shape (17 commands, 5 classifications, 0 files, density 17) matches what was recorded six times under different aliases between August 18 and 23.

FACT ATK-7FD4FE (112.46.x.x) typed 20 commands in 5.0 seconds and left two 9-byte text files. 9 bytes is the length of one English word. These two files also appeared as a pair on August 21, 23, 28, and September 1. Under different aliases then.

FACT ATK-677233 (117.216.x.x) typed 31 commands over about 86.2 seconds. Download behavior was classified, but 0 files remained.

Laid out in time order

Lay yesterday out in time order and it looks like this. Times are Korean time, with Coordinated Universal Time (UTC) in parentheses. In the “archive comparison” rows, line the August 23 numbers up against the October 4 numbers.

1. 10:01:38 ~ 10:03:04 KST (01:01:38Z ~ 01:03:04Z)
   FACT ATK-677233(117.216.x.x) telnet login succeeded. about 86.2 s · 31 commands · 3 behavior classifications ('file download' · 'granting execute permission' · 'execute after download') · 0 downloads · log density 13
2. 10:01:38 ~ 10:03:04 KST (01:01:38Z ~ 01:03:04Z)
   INFERRED download behavior was classified, yet 0 files were stored. Whether the download failed or only the classifier reacted cannot be distinguished
3. 11:15:40 ~ 11:15:57 KST (02:15:40Z ~ 02:15:57Z)
   FACT ATK-2CB5A2(58.72.x.x) telnet login succeeded. about 17.7 s · 20 commands · 11 downloads · no behavior classification · log density 40. one-byte empty file (01ba4719…). On 8/29 the same alias was recorded with 20 commands · 11 files · 18 s · 40. 36 days apart
4. 17:08:21 ~ 17:08:26 KST (08:08:21Z ~ 08:08:26Z)
   FACT ATK-7FD4FE(112.46.x.x) telnet login succeeded. about 5.0 s · 20 commands · 2 downloads · behavior classifications 'granting execute permission' · 'file download'. two 9-byte ASCII texts (a9b1c85a… · 1193dde1…). Also appeared as a pair on 8/21 · 8/23 · 8/28 · 9/1, under different aliases then
5. 17:12:07 ~ 17:13:09 KST (08:12:07Z ~ 08:13:09Z)
   FACT ATK-50E6EA(45.238.x.x) telnet login succeeded. about 62.4 s · 17 commands · 5 behavior classifications (most of the day) · 0 downloads · log density 17. Matches the shape recorded six times under different aliases from 8/18 to 8/23
6. 17:12:07 ~ 17:13:09 KST (08:12:07Z ~ 08:13:09Z)
   INFERRED behavior classifications carry no ordering information. We cannot write that it happened in the order reconnaissance → download → execute permission → persistence. We can only say the five were 'observed'
7. 21:35:51 ~ 21:36:23 KST (12:35:51Z ~ 12:36:23Z)
   FACT ATK-F2B80A(121.161.x.x) telnet login succeeded. about 32.5 s · 48 commands (most of the day) · 12 downloads (most of the day) · log density 43 (highest of the day) · no behavior classification. 11 one-byte empty files (01ba4719…) + 1 202-byte POSIX shell script (0c99433c…)
8. Archive comparison (8/23 → 10/4)
   FACT On 8/23, ATK-F2B80A(121.161.x.x) ran 02:13:52Z~02:14:24Z · about 32.6 s · 48 commands · 12 downloads · density 43 · 0 classifications. The hashes match too: 11 × 01ba4719… + 1 × 0c99433c…. Only the start time changed; the duration differs by 0.1 s. 0c99433c… is the fourth occurrence, following 8/21(ATK-792ADF) · 8/23(ATK-F2B80A) · 9/6(ATK-60E535)
9. Archive comparison (8/23 → 10/4)
   INFERRED An alias is only a device for seeing whether a source persists. It does not mean the same person came back. The same automation script running again from the same address fits the data better
10. Entire observation window
    FACT A 389-byte OpenSSH RSA public key (a8460f44…) appeared 33 times from 33 different sources. Recurring since 8/16. The 345gs5662d34 / 345gs5662d34 combination appeared 33 times from 33 IPs. SSH fingerprint f555226d…(SSH-2.0-libssh_0.9.6) from 33 IPs. 'Planting an SSH key' 34 times
11. Entire observation window
    INFERRED 33 overlaps across three values. It looks like the same tool running 'one login per source → plant the same key'. Whether the 33 sources behind the three values are the same ones cannot be confirmed
12. Entire observation window (sensor 02)
    FACT 4 sample types on 02 (46,525 · 153,208 · 239,388 · 334,816 bytes, 773,937 bytes total) arrived 3 times each from ATK-D71792 · ATK-EE2628. All four hashes were first recorded on 8/28 (then ATK-F4738A), all 4 types again on 8/30, and one of them on 9/20. Over 37 days the files stayed the same; only the sending alias changed
13. Entire observation window (sensor 02)
    FACT 32,043 VNC (5900) contacts. RFB version 003.008 30,099 times · 003.003 1,887 times. Of the 31,986 with a recorded version, 003.008 is 94.1%. The share that first passed half (63.2%) on 10/1 has grown further

FACT All five timestamped sessions were shapes already in the ledger. Not one session was seen for the first time yesterday. The shortest was 5 seconds, the longest 86. Far too short for a person puzzling over a lock.

In front of the locker that never opens

FACT The second locker (sensor 02) does not open. So there are no successful logins, no commands, and no passwords. All that remains is who came to which window and how many times.

FACT VNC is 95.4% of the total. 32,043 in a day is about once every 2.7 seconds. Each source came 390.8 times on average. The three most frequent sources (ATK-F81B56 6,484 · ATK-943F0E 6,481 · ATK-A9F1B3 6,468) account for about 57.9% of this server’s entire record. Fewer than 20 contacts separate the three.

FACT On this server too, 4 file types were left 3 times each. The four together come to 773,937 bytes, about 774 kilobytes. Smaller than one smartphone photo. All four files were first recorded on August 28. Over 37 days not a single byte changed, and only the sending alias differed.

INFERRED Most of the connections to the SMB window presented the entire dialect list of a very old generation (SMB1) at once. The RDP name tags also included zgrab twice. zgrab is the name of a survey tool that sweeps the whole internet. Shapes like these are common from scanners sweeping the entire internet rather than from attacks aimed at a specific target.

The values from yesterday — for your records

For use in defense, here are the hashes verbatim. A hash is a unique number computed over a file’s entire contents. Change one character and the value is completely different. Click a value to copy it. Yesterday no file had an address (URL) recorded with it. Look at the dates in the description column.

FACT All nine lines were values already in the ledger. If you have been maintaining your blocklist steadily, there is nothing new to add from yesterday. That is itself yesterday’s result.

Mapping the attackers’ methods to the international classification table

MITRE ATT&CK is an international list that assigns a number to each attack method. Mapping yesterday’s observed behavior onto those numbers gives this. Click an ID to go to the original description.

• T1110.001Brute Force: Password Guessing — 5,020 login attempts, combinations centered on defaultsINFERRED
• T1078.001Valid Accounts: Default Accounts — 5 successful telnet logins with default-account-type combinationsINFERRED
• T1082System Information Discovery — 'reconnaissance — system' 3,250 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 67 times, 'execute after download' 49 timesINFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'granting execute permission' 81 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — planting an SSH key' 34 times, 389-byte public key 33 timesINFERRED
• T1070Indicator Removal — 'deleting traces' 35 times (the specific technique cannot be pinned down without the original commands)INFERRED
• T1046Network Service Discovery — VNC · RDP · SMB · LDAP · MSSQL contacts on sensor 02 (a probing stage, not intrusion)INFERRED

FACT All eight lines are [INFERRED]. What we hold is the behavior classification results and the counts, and that is all. We do not have the original commands. So attaching a number is always interpretation. In particular, T1098.004 is the swapping of the key list we looked at earlier.

There has been a shape like this before

FACT Mirai botnet (2016). An incident in which IoT devices were infected by guessing default telnet accounts. IoT devices are small internet-connected devices like routers and CCTV cameras. root/xc3511 and root/juantech in yesterday’s table are combinations included in the default credential list of the Mirai source code published in 2016. (Source type: government agency alert US-CERT TA16-288A, 2016 · publicly released source code)

INFERRED The resemblance extends only as far as the method of guessing default telnet accounts. We make no determination that yesterday’s observations are of the Mirai family. Sample classification tags are absent from yesterday’s material. We say only this much: numbers that were going around the hallway ten years ago are still going around.

So what should you do

Back to the locker story, and the to-do list is simple. Don’t use a number everyone knows, look at your key list, and don’t leave your locker out in the hallway.

FACT 1. You are still using default accounts and easy passwords · high likelihood All five sessions we looked at yesterday logged in successfully. admin/admin came in 102 times from 12 sources, root/admin 93 times, root/xc3511 87 times, root/juantech 70 times, root/(blank) 70 times, support/support 54 times.

INFERRED If you were using one of these numbers, it would have opened with no particular skill involved. Once opened, the first thing done is looking around inside (reconnaissance, 3,250 times). After that, files can be fetched from outside and run, and the device can be used as part of a botnet. That said, the files actually left yesterday were only the 1-byte files, the 9-byte files, the 202-byte script, and the public key. There were no executable programs.

FACT 2. You use password login only and no key-based method · high likelihood There were 5,020 login attempts and 3,559 SSH sessions. The same public key was planted 33 times from 33 sources.

INFERRED If password login had been turned off, those 5,020 dial spins would have been pointless from the start. Conversely, once it opens and a key goes onto the list, changing the dial combination still leaves that key able to open it. Even after switching to key-based login, open authorized_keys (the list of permitted keys) and check that there is no key you don’t recognize.

FACT 3. You have management windows opened directly to the internet · high likelihood In one day, 216 sources knocked on the SSH/telnet side and 311 on the Windows remote management side. That is 752 RDP contacts (114 sources) and 32,043 VNC contacts (82 sources).

INFERRED If the management windows had sat behind a VPN or access control, these contacts could not have laid a finger on the lock. It is like putting the locker inside a locked classroom rather than out in the hallway.

INFERRED 4. You have no repeat-attempt blocking (fail2ban or similar) · medium likelihood fail2ban is a tool that “locks things for a while after so many failures.” The kind where one source spins the dial 29 times, like root/xc3511, gets stopped by this. But when 33 sources each spin once, like 345gs5662d34, it does not catch them. Both kinds are mixed together, hence “medium.” This is why account-level lockout and disabling password login need to be used together.

INFERRED 5. You do not block outbound connections · medium likelihood There were 67 ‘file download’, 49 ‘execute after download’, and 81 ‘granting execute permission’. If a server can reach outward freely, “fetch → grant permission → execute” follows straight through. That said, the files actually left on the first server yesterday included no executable programs. Hence “medium” rather than “high.”

INFERRED 6. You do not collect logs off the machine · medium likelihood There were 35 instances of ‘deleting traces’. Because we are a honeypot, recordings of all five sessions remained. If an ordinary server keeps its logs only on itself, an intruder can erase them. The reason we recognized yesterday’s session as identical to one from 42 days ago was precisely that the record from 42 days ago was kept separately.

FACT Recurring indicators (12 instances of the 31[.]77[.]227[.]121/bins/ path, visible only after decompression, and 1 Discord webhook) are subject to C-TAS reporting. C-TAS is the Korea Internet & Security Agency’s (KISA) cyber threat information sharing system. What has been confirmed goes only as far as successful transmission. Whether it was actually loaded on KISA’s side has to be verified separately.

We also made the story of that 42-day return visit into a 60-second video on the same day. The video focuses on the single 0.1-second difference. This post spreads out the numbers next to it.

What We Don’t Know

This is the point where this blog differs from others. We claim as little as we know.

About the sessions that were identical

• [Cannot confirm] Whether ATK-F2B80A typed the same 48 commands as on August 23, we do not know. We do not have the original commands. We can say only that the counts, the file hashes, and the duration match.
• [Cannot confirm] ATK-F2B80A and ATK-2CB5A2 typed 48 and 20 commands and left 12 and 11 files, yet their behavior classifications are empty. The August 29 brief noted the same gap. We do not know what yesterday’s most command-heavy session actually did.
• [Cannot confirm] ATK-677233 was classified with ‘file download’ and ‘execute after download’, and ATK-50E6EA with ‘file download’. Yet both left 0 files. Whether the download failed, whether storage failed, or whether only the classification fired cannot be distinguished.
• [Cannot confirm] We do not know the contents of the two 9-byte text files (a9b1c85a… · 1193dde1…) or the 202-byte shell script (0c99433c…). So we made no judgment about their purpose.
• [Inferred] The per-session connection port is not in the data. Telnet = 2223 and SSH = 2222 were matched up because the port counts and the protocol counts are exactly equal (1,768 · 3,559).

About the numbers we didn’t post, and the 33 sources

• [Cannot confirm] We do not know why the combinations we withheld reached their highest figure at 3,026 types. The data does not distinguish whether the attack side’s number lists changed or our counting method changed.
• [Cannot confirm] We do not know how many of the 3,026 types are accounts that were actually leaked. “It may have been leaked” is only our reason for not publishing — it is not a confirmation of a leak.
• [Cannot confirm] We do not know whether the 345gs5662d34 combination (33 sources), the public key a8460f44… (33 sources), and the fingerprint f555226d… (33 sources) are the same 33 sources. There is nothing linking them per source. Of the sources that sent the public key, only 10 of the 33 are included as samples.

About the second locker

• [Inferred] That the 4 sample types on 02 arrived over the Android channel (ADB) is an inference. It rests on the definition that ADB is the only channel on this server where incoming content is retained. The file types and the number of ADB sources are not in the data.
• [Cannot confirm] The 4 sample types on 02 have the same hashes as on August 28 but different sending aliases (8/28 ATK-F4738A → yesterday ATK-D71792 · ATK-EE2628). Whether the same tool ran from a different place, or whether this file is widely distributed, cannot be distinguished.
• [Cannot confirm] We do not know the cause of VNC version 003.008 growing from 63.2% on October 1 to 94.1% yesterday. Whether the other side’s tooling changed or our honeypot configuration changed cannot be distinguished. We also do not know which sources produced it.
• [Cannot confirm] The list of frequent sources contains alias pairs whose masked leading octets are identical (ATK-F81B56 · ATK-08F736 at 201.79.x.x, and ATK-48B384 · ATK-2A62E4 at 168.144.x.x). The aliases differ, so they are different sources. Determining whether they are in the same range would require unmasking, so we do not determine it.

What we deliberately left out or did not connect

• [Excluded] For the one Discord webhook address, the data does not say which sensor or which session it came from. It was also recorded as a recurring indicator in the September 15 brief. The address contains a token, so we did not include the value.
• [Cannot confirm] For the C-TAS report, only successful transmission was confirmed. Whether KISA loaded it has to be verified separately.
• [Excluded] Background statistics (412 CISA KEV entries among the 7,662 CVEs in KISA notices, 101 confirmed ransomware cases) do not connect directly to yesterday’s honeypot attacks. We did not write them as though they did.

What we make no judgment about at all

• Carrier/organization (ASN · ISP) — we have no relevant database. We do not infer it.
• Geographic location — unknown for the same reason. IP geolocation is not grounds for identifying who did something in the first place. This post names no country, company, or individual as an attacker.
• VPN · Tor · cloud status — we have no means of determining it.
• VirusTotal — not integrated. Sample classification uses MalwareBazaar tags, and yesterday’s material has no tags.
• Client program strings (User-Agent) — neither server is web (HTTP). The first is SSH/telnet, the second SMB · RDP · VNC · MSSQL · LDAP · ADB. Web attacks are covered by a separate source.
• Vulnerability number (CVE) linkage — SSH and telnet attacks mostly do not reference a specific vulnerability. The second server is at the stage of matching connection rules, so the same applies.

The hallway was as busy as ever yesterday. About once every 17 seconds, someone spun a dial. It opened five times, and all five times it was a set of hand movements we had seen before. There was even footage that overlaps a recording from 42 days ago. All nine kinds of items left inside the lockers were things we had seen before too.

What was new was the count of numbers we did not post on the board. 3,026 of them. What those numbers are is not in this post. It will not be in future ones either. But one thing is clear. If your number is among the 20 posted on the board, today is the day to change it.

The observation date is October 4, 2026 (a single UTC day), and this post was compiled the following day. Source IPs are carried over in the masked form used in the brief (121.161.x.x, 58.72.x.x, 112.46.x.x, 45.238.x.x, 117.216.x.x, 201.79.x.x, 168.144.x.x) and were not restored. Addresses were kept defanged ([.]) so they are not reached by accident, and the webhook address containing a token was not included. For credentials, only the 20 combinations repeatedly observed from 3 or more different IPs were quoted verbatim; for the remaining 3,026 types we state only the count and do not write the values. Items for which we have no means of measurement — carrier, nationality, VPN status and the like — were left as “we don’t know” rather than inferred.