255 Sources That Only Touched the Lock Four Times Each, and the Spare Key That Came Back After 46 Days

Picture a school hallway. Lockers with combination locks line the walls. During break, hundreds of people walk past them. Most open only their own locker.

But every so often someone quietly tries the lock on someone else’s locker. They spin the dial once or twice, and when it doesn’t open, they just move on. That person didn’t pick your locker. They’re only sweeping for a locker whose combination was left at the factory setting.

One person gripping one locker and spinning it a hundred times stands out. But yesterday was the opposite. A great many sources came and touched the lock just a few times each. The same day, at the other end of the hallway, someone drilled an extra keyhole inside a locker that had opened. It was the same handiwork we saw 46 days ago.

There are two lockers in our hallway

FACT We operate a honeypot. A honeypot is a decoy server deliberately left loosely open. We keep it to watch who comes and what they do. What follows is not actual damage but an observation record.

FACT There are two servers. In locker terms, it goes like this.

• The first locker (sensor 01) is set to an easy combination. If the combination matches, it really does open. We even record what was done inside.
• The second locker (sensor 02) never opens. It has several compartments, and each compartment has a different type of lock. We only write down who touched which compartment’s lock and how many times.

FACT On a computer, this ‘compartment’ is called a port. It’s a door number inside a single computer. Port 3389 is the Windows Remote Desktop (RDP) compartment. Remote Desktop is the feature that puts a distant computer’s screen on your own screen to use directly. Half of today’s story came out of this compartment.

255 sources touched the lock and left

FACT Over the course of yesterday, 255 sources touched the Remote Desktop compartment on the second locker. Contacts totaled 1,058. Divide the day into seconds and that’s roughly once every 82 seconds.

FACT 255 is a number we have never seen since we began keeping records. There are 25 briefs with Remote Desktop records, from August 26 to October 8. Across them the source count ran from a low of 102 (9/3) to a high of 164 (8/31). Yesterday brought 91 more sources than the previous maximum. That’s 1.55 times.

FACT And yet the contact count of 1,058 was unremarkable. Across the 25 briefs the range is 567 to 42,578. Yesterday sits toward the low end.

Dividing the two numbers here reveals the shape of the day. Compare the ‘per source’ column up and down.

FACT The source count is the highest on record, while the per-source count is the lowest on record. Each source touched the lock about four times on average and left. Compared with October 8, the previous brief, sources more than doubled. The per-source count fell to below two-thirds.

INFERRED This was not a day when one person stuck to one locker. It’s closer to a day when many people swept straight down the hallway once. This kind of thing is called a ‘broad, shallow scan’. That said, whether the 255 sources were one tool distributed across many locations, or several unrelated scanners that happened to overlap on the same day, is something our records cannot distinguish.

FACT One thing to note. The second locker does not open. So we cannot know whether these 255 sources actually tried the combination. What gets recorded goes only as far as “a hand touched the lock.”

The name tags they held out while touching the lock

FACT When connecting to Remote Desktop, you can attach a short name tag called a cookie. In locker terms, it’s a note you stick on while touching the lock saying “this is who I am.” Here are the name tags attached yesterday.

FACT Name tags totaled 842, and 216 contacts had none. The 790 '<ip>' entries are 74.7% of all contacts. Seven and a half out of every ten. On October 8 this share was 55.8%.

FACT nmap and zgrab match the names of widely known scanning tools. But a name tag is whatever text the sender chooses to write in. They can also write someone else’s name on it. So we do not group contacts into a particular tool or person based on the name tag alone.

Same locker, opposite compartments

FACT We look at the second locker’s other compartments too. We’ve calculated ‘per source’ and put it in. Read the Remote Desktop row and the VNC row side by side.

FACT It’s the same locker, yet the shape is completely different per compartment. 81 sources came to the VNC compartment and hung on it more than 600 times each. 50,922 contacts in a day is roughly once every 1.7 seconds. More than three times as many sources came to the Remote Desktop compartment and touched the lock only four times each. Of the overall 52,971 contacts, VNC accounts for 96.1%.

FACT The share of the version string 003.008 presented when connecting to VNC was 98.7%. It rose again, following 63.2% on October 1, 94.1% on October 4, and 98.0% on October 8.

FACT The top ten sources account for 4,006–6,146 contacts each, and 50,005 combined. Among them, ATK-F81B56, ATK-943F0E, and ATK-A9F1B3 are aliases that were also on the October 8 top list. Names beginning with ATK- are the aliases we assign to each source. Two aliases are masked as 201.79.x.x (ATK-F81B56 and ATK-08F736). Since the aliases differ, they are in fact different addresses.

INFERRED The total for the ten sources is close to VNC’s 50,922. So it’s possible these were the ones hanging on the VNC compartment. However, the records do not show which contact was aimed at which compartment.

FACT On the SMB compartment, 215 connection-method proposals came in. Excluding 3 ‘Samba’ entries, they were all SMB1-family names. SMB1 is a very old form of Windows file sharing.

INFERRED These look like requests searching for servers that still accept the outdated SMB1.

FACT The ADB compartment had 504 contacts. The file left on this locker is 1 kind, 46,525 bytes (0d3c687f…). It was sent by a single source, ATK-371699, an alias we’re seeing for the first time. But the file hash is a value already present in the 8/28, 8/30, 9/20, and 10/4 briefs. A hash is a unique number computed from the file’s entire contents. Change a single character and you get a completely different value.

On the locker that opens — the spare keyhole made within one minute

Now to the other end of the hallway, the first locker, which actually opens.

FACT At 2:39 p.m. Korea time, ATK-FB5E45 (222.71.x.x) logged in successfully over SSH. SSH is a channel for entering a distant computer and typing commands. It wraps what passes back and forth in encryption. The stay lasted 59.81 seconds. During that time 18 commands were typed and 2 files were received. That’s about 3.3 seconds per command.

FACT Four behaviors were classified during this one minute.

• Recon — system. Looking around to see what kind of machine the computer they entered is.
• Persistence — SSH key planting. SSH has a way of getting in with a key file instead of a password. The server only accepts keys written in authorized_keys (the list of permitted keys). Writing your own key in there is ‘key planting’. In locker terms, it’s drilling one more keyhole next to the combination lock and walking off with that key. Even if the owner changes the combination, the key still opens it.
• Persistence — cron. cron is a scheduled job feature. Like an alarm, it makes the computer do a set task by itself at set times. In locker terms, they’ve put a timer device inside.
• Trace removal. Erasing your own line from the locker’s usage log.

FACT ‘Persistence’ means arranging to be able to keep coming back in even after you’ve gotten in once. This single session contained two kinds of persistence together with trace removal. Across all of yesterday, only exactly 1 item was classified with ‘cron’ intent.

INFERRED Since this session had cron, that 1 item is this session.

INFERRED There is something to be careful about here. The four behaviors are a list, not a sequence. It’s tempting to write “they looked around → drilled a keyhole → inserted a timer → erased the log.” But what we can say goes only as far as “all four were observed within one minute.” We also don’t know which key was planted, or what time the timer was set for and to do what. Input records (TTY) remain, but their contents are not in the brief.

The same handiwork was there 46 days ago too

FACT A program connecting over SSH reveals its own configuration combination when connecting. We use that to build a connection fingerprint and group identical tools together. In locker terms, it’s the model name of the tool that drilled the keyhole. This session’s fingerprint is f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6).

FACT 46 days ago, on August 26, there was also a session that came in with this fingerprint. That was ATK-E17FA9. 18 commands, 2 downloads, and even the four behaviors were the same. Only the stay differed, at about 46 seconds. Two days later, on August 28, ATK-AE28B3 also had 18 commands and the same four behaviors. However, the fingerprint (03a80b21…, libssh_0.11.1) and the download count (1) differed. On all three days, that day’s cron intent was just 1 item.

INFERRED So this session is not a ‘first-time intrusion’. It’s the third appearance of this combination in the archive. It’s right to see it as a rarely returning repetition. The source address differed each time. But the tool model was the same.

INFERRED That does not mean it’s the same person. Anyone can buy the same model of tool. The same goes for this fingerprint. Unrelated people using the same default program will have the same value. We say only ‘the same tool’ and do not write ‘the same organization’.

FACT This tool was not alone yesterday. Yesterday’s SSH fingerprint groups numbered 48, and f555226d… was the largest group among them. This fingerprint appeared from 41 IPs. Put four numbers side by side and it looks like this.

• Times the 389-byte public key (a8460f44…) was downloaded: 41 (from 40 sources). 389 bytes is about the size of two or three text messages.
• IPs where fingerprint f555226d… appeared: 41
• IPs that tried the ID/password 345gs5662d34/345gs5662d34: 37
• Behaviors classified as ‘SSH key planting’: 43

FACT The four numbers moved together at the same order of magnitude. It’s a shape similar to the September 20 brief (41·41·40·43).

Other locker doors that opened the same day

FACT Yesterday we noted 5 successful-login sessions on the first locker. But matching aliases, fingerprints, and file hashes against the 35 briefs accumulated since August 16, there is not a single new combination. Among the 6 kinds of files left on the two servers, there is no first-seen hash either.

FACT

• ATK-ADE2BE (45.43.x.x) came in over Telnet. Telnet is an old channel that does the same thing as SSH, except it does not wrap the contents in encryption. 60.66 seconds, 17 commands, 5 behaviors, 0 downloads. The figures are identical to a session from the same alias recorded in the August 23 brief.
• ATK-CA5936 (130.12.x.x) stayed 3.95 seconds over SSH. 1 command, 5 behaviors, 2 downloads. It’s an alias that has appeared repeatedly since August 19.
• ATK-A51A59 (111.246.x.x) typed 31 commands over 88.95 seconds via Telnet. The behaviors include ‘download’, yet the actual download record is 0.
• ATK-8FB338 (171.114.x.x) typed 61 commands in 19.08 seconds over Telnet. That’s more than three lines a second. 20 downloads, and the behavior was a single ‘trace removal’. At a record density (completeness) of 69, it was yesterday’s highest.

INFERRED The noisiest was ATK-8FB338. But all it took away was a one-character file and a script we’d already seen. So we put the center of today’s story on ATK-FB5E45, which quietly stayed one minute. It left behind the greatest variety of devices.

Laid out in chronological order

Here is yesterday’s record in chronological order. Times are in Coordinated Universal Time (UTC); for Korea time, add nine hours. The top four lines are the Remote Desktop compartment’s day; the lower ones are scenes from the locker that opens. Notice that the start and end of the ATK-FB5E45 line fall within one minute.

1. 2026-10-11 (full day) · 02
   FACT RDP(3389) contacts 1,058, unique sources 255. An average of 4.15 per source
2. Archive comparison · 02
   FACT Across the archive's 25 briefs, unique RDP sources ran between 102 (9/3) and 164 (8/31). Today's 255 is 1.55 times the previous maximum. Contacts per source are also lower than the previous minimum of 5.02 (9/27). The previous brief, 10/8, was 795 contacts from 119 sources (6.68 per source)
3. Full day · 02
   FACT The 790 RDP cookies reading '<ip>' are 74.7% of RDP contacts (10/8 brief 444/795 = 55.8%). Beyond that there are hello 33, eltons 7, rdpaudit 5, nmap 4, zgrab 3. Cookies total 842, and 216 contacts have no cookie recorded
4. Full day · 02
   INFERRED The shape is one where only the source count rose sharply while contacts per source fell to an archive low. It looks like a broad, shallow scan in which many sources swept by a few times each rather than one source knocking persistently. Whether it is the same tool or several unrelated scanners cannot be distinguished from the JSON
5. 05:39:25Z ~ 05:40:24Z (KST 14:39)
   FACT ATK-FB5E45 (222.71.x.x) logged in successfully over SSH. Over 59.81 seconds there were 18 commands and 2 downloads. The intents are four: Recon — system · Persistence — SSH key planting · Persistence — cron · Trace removal. Fingerprint f555226df1963d1d3c09daf865abdc9a (SSH-2.0-libssh_0.9.6), completeness 21. A TTY record exists, but its contents are not in the brief
6. Full day · 01
   INFERRED 'Persistence — cron' in command_intents is 1 item for the entire day. Since cron is in ATK-FB5E45's intents, that 1 item is this session
7. Archive comparison · 01
   FACT On 8/26, ATK-E17FA9 also had the same fingerprint f555226d…, 18 commands, 2 downloads, and the same 4 intents (about 46 seconds). On 8/28, ATK-AE28B3 had the same 18 commands and 4 intents, but a different fingerprint (03a80b21…, libssh_0.11.1) and download count (1). On all three days, that day's cron intent was just 1 item
8. Common to the 4 intents
   INFERRED The intents array is a set of intents, not an execution order. So we cannot write that it happened in the order 'recon → key → cron → removal'
9. 05:51:19Z ~ 05:52:19Z (KST 14:51)
   FACT ATK-ADE2BE (45.43.x.x) logged in successfully over Telnet. 60.66 seconds, 17 commands, 5 intents, download_count 0, completeness 17. The figures match a session from the same alias recorded in the 8/23 brief
10. 06:14:01Z ~ 06:14:05Z (KST 15:14)
    FACT ATK-CA5936 (130.12.x.x) logged in successfully over SSH. 3.95 seconds, 1 command, 5 intents, 2 downloads. Fingerprint 16443846…4397 (SSH-2.0-Go) appeared from 4 IPs today and is the only value in today's fingerprint list with delivered_samples=true. It is an alias that has appeared repeatedly since the 8/19 brief
11. 08:12:40Z ~ 08:14:09Z (KST 17:12)
    FACT ATK-A51A59 (111.246.x.x) logged in successfully over Telnet. Over 88.95 seconds there were 31 commands, and the intents are three: download and execute · granting execute permission · file download, with download_count 0
12. 14:53:04Z ~ 14:53:23Z (KST 23:53)
    FACT ATK-8FB338 (171.114.x.x) logged in successfully over Telnet. Over 19.08 seconds there were 61 commands and 20 downloads, and the intent is a single trace removal. At completeness 69 it is today's highest. This alias is in the delivered_by of a 1-byte file (01ba4719…) and a 202-byte shell script (0c99433c…, a hash that was in the 8/23 archive)
13. Full day · 01
    FACT 389-byte public key (a8460f44…) 41 times from 40 delivery sources, fingerprint f555226d… from 41 IPs, credentials 345gs5662d34/345gs5662d34 from 37 IPs, 'SSH key planting' intent 43 items. The four values moved together at the same order of magnitude. It is a shape similar to the 9/20 brief (41·41·40·43)

FACT As you saw, there is no line with a timestamp on the Remote Desktop side. Because it’s a locker that doesn’t open, no scene of ‘when someone came in’ is created. Conversely, the first locker’s five successful logins all ended within 1 minute 30 seconds. The shortest was under 4 seconds.

All of yesterday

Widening the view, we look at the first locker’s entire day. The ‘For comparison’ column on the right makes the numbers tangible.

FACT Commands classified as behaviors number 2,580. Of those, ‘Recon — system’ is 1,763 (68.3%). That means seven out of ten times they came in and only looked around. The rest are granting execute permission 689, trace removal 44, SSH key planting 43, download and execute 20, file download 20, and cron 1. Out of 2,580, cron was a single item, and that was the one-minute session we looked at today.

FACT Input records (TTY) remain for 1,931 items. Unique sources across the two servers combined number at most 673. Because we cannot know which sources came to both servers, we write only ‘at most’. We do not add session counts, because the two servers count in different units.

Are you using this combination

FACT Of the ID/password combinations tried on the first locker yesterday, 6 kinds are reproduced verbatim in this post. The criterion is one thing. We write down only combinations tried identically from three or more different IPs. If many sources are carrying around the same combination, it’s likely a factory default belonging to no one. Look at the numbers in the third column.

FACT admin/admin was tried 118 times in total by all 37 sources. That’s 3.2 per source. 345gs5662d34/345gs5662d34 was 38 tries from 37 sources. Almost exactly once per source.

INFERRED The fourth row is not a password. A sentence requesting a web page (GET / HTTP/1.1) went into the ID field. A scanner looking for web servers sent a web request to the Telnet door. That sentence appears to have been written straight into the ID and password fields. The password field originally contained an address, but we omitted it because it could be our own server’s address.

FACT Combinations that fell short of this criterion are only counted. Yesterday there were 1,861 kinds. Since they could be leaked from someone’s real account, we do not write the values. That works out to about 310 unwritten combinations for every one we put in the table. The recent trend is October 1 at 1,608 kinds → October 4 at 3,026 → October 6 at 2,213 → October 8 at 3,212 → yesterday at 1,861.

FACT We do not know which combinations the five successful sessions used to get in yesterday. The information linking a connection to a password is not in the records.

Values that came out yesterday — to write down

We reproduce these as-is so you can use them in defense. Values like these are called IOCs (indicators of compromise). They’re markers meaning “be suspicious if you see this value.” Click a value to copy it. Look at ‘delivered by’ in the description column.

FACT Yesterday’s IOC is this one line. A one-character, effectively empty file. And yet the deliverers include today’s protagonist, ATK-FB5E45. It’s not a newly appearing value but a repeatedly appearing one. For the 5 kinds of files left on the first locker yesterday, the download address (URL) was empty in every case. So whether there was a new distribution site to report yesterday is not confirmed by these records. A distribution site is a place that serves the file for download.

Mapping the attackers’ techniques to the international classification table

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

• T1078Valid Accounts — 5 successful logins. Which credentials they came in with is not in the JSONINFERRED
• T1082System Information Discovery — intents 'Recon — system'INFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — intents 'Persistence — SSH key planting'INFERRED
• T1053.003Scheduled Task/Job: Cron — intents 'Persistence — cron'INFERRED
• T1070Indicator Removal — intents 'Trace removal'. Without the original commands we do not pin down the sub-technique (history deletion, log deletion, etc.)INFERRED
• T1046Network Service Discovery — the broad, shallow contact from 255 sources on 02 RDP, RDP cookies nmap and zgrabINFERRED

FACT All six lines are [INFERRED]. What we hold goes only as far as behavior classifications and counts; we don’t have the original commands. The lines to watch are the middle two, T1098.004 and T1053.003. The spare keyhole and the timer device are these numbers. Both are techniques for ‘getting in again next time’. At the bottom, T1046 points to the shape of the 255 sources that swept the Remote Desktop compartment.

There has been a shape like this before

FACT Outlaw botnet (2018–2019). A group that brute-forced passwords into Linux servers to get in, then changed authorized_keys and registered cron to keep coming and going. A botnet is a group of many infected computers controlled all at once. (Source type: security vendor threat report · Trend Micro blog)

INFERRED The combination of ‘key planting + scheduled job’ is the same. But our records have no mining program, no executable, and no original commands. So we do not judge this to be the Outlaw family. It is only a comparison that the technique resembles it, not grounds for determining who did it.

So what should you do

Returning to the locker story, the things to do come down to three. Don’t put your locker out in the hallway. Don’t leave the combination at the factory setting. And if it has ever been opened, don’t just change the combination — search the inside. We go through the six items the brief listed, in order.

FACT 1. A management port was left open directly to the internet · high likelihood The Remote Desktop compartment was touched 1,058 times by 255 sources in a day. The first locker received 2,321 SSH sessions and 326 Telnet sessions, with 5 successful logins among them.

INFERRED If a computer in operation had port 3389 open to the internet, 255 sources would have checked that door in a day. Since the second locker does not open, what happens after that cannot be spoken of from these records. What is confirmed goes only as far as “the fact that it’s open becomes known to hundreds of sources within a day.”

FACT 2. Default accounts and easy passwords are left as-is · high likelihood admin/admin came 118 times from 37 sources; root/1234 and root/123456 came from 3 sources each.

INFERRED Equipment using these combinations could be guessed within a day. Once it opens, key planting and a scheduled job come in within one minute, as with ATK-FB5E45. After that, it can keep opening with the spare key even if you change the combination. However, we don’t know which combinations the five that succeeded yesterday used to get in.

FACT 3. Password login is allowed and key-based login isn’t used · high likelihood 2,068 login attempts, 1,861 kinds of combinations whose values we didn’t write. There were also 2 successful SSH logins.

INFERRED A server that opens with a password alone has to face all 1,861 unwritten kinds on top of the 6 made public. If real employee accounts are mixed into a leaked list, it becomes a login that matches on the first try rather than a brute force. Whether the successful sessions actually came in with a password is not in the records.

FACT 4. There is no failure-count limit (fail2ban, etc.) · medium likelihood The 345gs5662d34 combination was 1.03 per source across 37 sources, admin/admin was 3.2 per source, and Remote Desktop was 4.15 per source.

INFERRED fail2ban is a tool that blocks a source after it gets the password wrong a few times. But yesterday’s attempts did not come in a burst from one source. They were spread thinly across many sources. A rule like “block after 5 failures from one source” would not have fired for most of the sources. That’s why it’s ‘medium’ rather than ‘high’. A quiet block log doesn’t mean nobody came. You have to count failures accumulated on a single account regardless of source to see this kind of distributed attempt.

FACT 5. The server doesn’t block outbound connections · medium likelihood 20 ‘file download’ and 20 ‘download and execute’ were classified. The behaviors of ATK-ADE2BE, ATK-CA5936, and ATK-A51A59 included ‘file download’.

INFERRED The intent to fetch files from outside was visible. But the 5 kinds of files left yesterday all had empty addresses, and there was no executable. Because it isn’t confirmed whether an outside connection actually succeeded, it’s ‘medium’. If outbound connections were blocked, the flow breaks at this stage.

FACT 6. Records aren’t collected off-box (no log collection, no EDR) · high likelihood ‘Trace removal’ for the full day is 44 items. The single ATK-FB5E45 session had key planting, cron, and trace removal together. For ATK-8FB338, the behavior throughout all 61 commands was a single ‘trace removal’.

INFERRED EDR is a monitoring program that records and alerts on suspicious activity inside a computer. If the usage log exists only inside the locker, it’s over the moment it’s erased. You can’t retrace when, and by whose hand, the spare keyhole and the timer appeared. Then it doesn’t end with changing the password. You have to open both authorized_keys and crontab (the scheduled job list) and decide whether to reinstall. The reason we can say “this is the same as 46 days ago” is also that we accumulate records separately, off-box.

We also made a 60-second video about the same day. The video focused on the single matter of the 255 sources at the Remote Desktop door. This post unfolds how those 255 sources differed from the other compartments, and what was left inside the locker that opened the same day.

What We Don’t Know

This is where this blog differs from others. We know few things, and just as few things we don’t.

About the 255 sources on the Remote Desktop compartment

• [CANNOT CONFIRM] We don’t know whether the 255 sources were one tool distributed across many locations, or several unrelated scanners overlapping. The second locker has no information for grouping sources, such as an SSH fingerprint.
• [CANNOT CONFIRM] On the second locker, the number of sources that touched multiple compartments together cannot be counted. The per-source records contain no distinction of which compartment. Writing 0 would read as ‘there were none’, so we leave it blank.
• [CANNOT CONFIRM] We don’t know where the 216 contacts without a name tag came from. We also don’t know why the '<ip>' name tag’s share rose to 74.7%.

About the one-minute session

• [CANNOT CONFIRM] We don’t know which key ATK-FB5E45 planted, or what time it set the scheduled job for and to do what. Behavior classification is merely a grouping of ‘what they tried to do’. The original commands and the contents of the input records are absent.
• [DATA INCONSISTENCY] Fingerprint f555226d… is marked as ‘has never delivered a file’. Yet ATK-FB5E45, a session with this fingerprint, is on the list of sources that delivered the 1-byte file. Whether empty files are excluded from the tally, the records do not explain.
• [DATA INCONSISTENCY] The 1-byte file is 20 times in a day, but adding up the download counts of the two aliases that delivered it gives 22 (ATK-8FB338 20 + ATK-FB5E45 2). Whether the remaining 1 of ATK-FB5E45’s 2 downloads is the 389-byte public key cannot be confirmed. Of the 40 sources that delivered the public key, only 10 have their names disclosed.
• [CANNOT CONFIRM] The ‘all-time IP count’ of 656 for fingerprint f555226d… must not be read as a cumulative number. That this value does not only increase was already confirmed in the 9/5, 9/8, and 9/10 briefs.

About other records from the same day

• [CANNOT CONFIRM] ATK-ADE2BE and ATK-A51A59 have downloads in their behaviors, yet actual downloads are 0. We cannot distinguish whether they tried and failed, or received files that weren’t saved.
• [CANNOT CONFIRM] We don’t know whether the 399-byte OpenSSH private key (43728fbf…) left by ATK-CA5936 was brought in by the attacker or created during the session. It’s an unresolved question since August 19.
• [CANNOT CONFIRM] We don’t know which session or file the 1 repeatedly appearing Discord webhook (an address that sends messages automatically) connects to. Because it contains a token, we do not include the original.
• [CANNOT CONFIRM] The 5 kinds of files left yesterday all have empty addresses. Whether there was a new distribution site to report to C-TAS cannot be known from these records. C-TAS is the threat information sharing system of the Korea Internet & Security Agency (KISA). For reports, only successful transmission is confirmed; whether KISA’s side ingested them must be checked separately.

About the nature of the numbers

• [CANNOT CONFIRM] Among the 1,861 kinds whose values we didn’t write, we don’t know how many are actually leaked accounts. ‘Could have been leaked’ is a publication criterion, not a determination.
• [NEEDS PRE-PUBLICATION CHECK] The GET / HTTP/1.1 row in the password table originally contained an address verbatim. We omitted it because it could be our own server’s address. The sanitization process appears to have failed to mask an address inside the ID and password fields, so this needs checking.
• [BACKGROUND] The vulnerability statistics (7,679 CVEs · 413 KEV entries with confirmed exploitation · 101 with confirmed ransomware use, topped by FortiOS, Confluence, Log4j2, NetScaler, and PAN-OS) are background information based on KISA notices. They do not connect directly to yesterday’s Remote Desktop and SSH observations.
• [EXCLUDED] The 12 indicators that only appear after decompression (31[.]77[.]227[.]121/bins/) are values repeated since August 16, so we did not use them as new material for yesterday.

What we don’t judge at all

• Carrier/organization (ASN·ISP): We have no relevant database. We do not infer.
• Geographic location: Unknown for the same reason. IP geolocation is not grounds for determining who did it in the first place. This post does not name any country, company, or individual as an attacker.
• VPN/Tor/cloud status: We have no means of determining this.
• VirusTotal: Not integrated. For file classification we use MalwareBazaar tags.
• Client program string (User-Agent): Neither server is a web (HTTP) server. The first is SSH and Telnet; the second is SMB, RDP, VNC, MSSQL, LDAP, and ADB.
• Vulnerability number (CVE) linkage: SSH and Telnet attacks mostly do not reference a specific vulnerability. The same applies to the second server, since it’s at the stage of matching connection rules.

Two things happened in the hallway yesterday. 255 sources passed in front of the Remote Desktop compartment on the locker that doesn’t open. That’s the largest number since we began keeping records. And yet they all touched the lock about four times and left. On the opposite side, on the locker that opens, one source stayed for a minute. During that time it drilled a spare keyhole, inserted a timer, and tried to erase the logbook. It was the same model of tool we saw 46 days ago.

The two scenes say one thing. The side touching the lock does not ask who the locker’s owner is. It only looks for whether there’s a locker whose combination wasn’t changed. And once it opens, it arranges things so that it keeps opening even if you change the combination, and leaves. So there are two things to do. Compartments you don’t use, like Remote Desktop, should be taken out of the hallway. And if it has ever been opened, don’t just change the combination — open it up and check the inside for an unfamiliar keyhole and a timer.

The observation day is October 11, 2026 (one day on a UTC basis), and this post was compiled the next day. Source IPs are reproduced exactly as masked in the brief (222.71.x.x, 45.43.x.x, 130.12.x.x, 111.246.x.x, 171.114.x.x, 201.79.x.x) and were not restored. Addresses are kept defanged (hxxp://, [.]) so they aren’t visited by accident. For credentials, we quoted verbatim only the 6 combinations repeatedly observed from 3 or more different IPs. For the remaining 1,861 kinds we state only the count and did not write the values. Items for which we have no means of measurement — carrier, nationality, VPN status — are left as “we don’t know” rather than inferred.