The Parcel Count Held Steady — the Invoice Format Flipped Overnight

Picture yourself sitting in an apartment building’s security office all day. Delivery drivers drop off boxes nonstop. Every time the guard takes a box, he looks at the invoice — the slip of paper taped to it, saying who sent it and who it’s going to.

After a few weeks of this, patterns become familiar. You learn roughly how many boxes arrive in a day. The invoice format is almost always the same, too: the same box layout, the same typeface — the familiar old format.

Then one morning something odd happens. The number of boxes is about the same as usual. But two-thirds of the invoices are in a format you’ve never seen before. That is exactly what happened in front of our server yesterday.

First — our server is a house we deliberately left unlocked

FACT We run a honeypot. A honeypot is a decoy server left deliberately exposed so we can watch who shows up and what they do. So what follows is not an account of actual damage — it is an observation log.

FACT There are two servers. The first (sensor 01) actually lets people in. It even records what commands they typed once inside. The second (sensor 02) does not open the door. It only records who came and what invoice they presented. Today’s story centers on the security-office ledger of that second server.

The box count was business as usual

FACT The second server has a screen-sharing (VNC) window. VNC lets you view another computer’s screen from a distance and move its mouse and keyboard on its behalf. Its door is number 5900, so we call it port 5900. Yesterday, connection attempts at this window came to 43,402. Spread across the day, that’s someone presenting a box roughly once every 2 seconds.

FACT It sounds like a lot, but for this window it’s an ordinary number. The band we treat as normal runs from 20,953 to 65,487 per day. Yesterday sat about in the middle of it. So this post will not use the word “surge.” The boxes came from 207 places. That averages 209.7 visits per place.

But the invoice format flipped

FACT At the start of a VNC connection, the two sides exchange a string saying “I’ll speak this edition of the rules.” The name of this conversational protocol is RFB. The string looks like 003.003 or 003.008. The former is the old string, the latter the new one. In security-office terms, it’s the edition number of the invoice format.

Here is yesterday’s mail sorted by format. Look at the middle column.

FACT Why this stands out becomes clear when you open the old ledgers. Between August 26 and September 27, we have ledger entries for 21 days. Across those 21 days, the old string 003.003 accounted for 82.6%–99.96% every single day. There was not one day on which the old format gave up the majority.

FACT Compare it against the day the new format peaked, too.

FACT To sum up: the box count arrived at the usual volume. But new-format invoices came attached at nearly five times the previous high. The old format hit its lowest point of any day on record in the ledger. What changed was not the quantity but the shape.

Why it changed, we don’t know

INFERRED There are broadly two possibilities. First, the senders may have changed the program that prints their invoices — meaning the same drivers switched to a new format. Second, our own security office may have changed. In VNC, our server is the one that offers the version string first — “let’s talk in this edition.” If the intake form posted at the office window changes, the drivers may simply follow it.

FACT Our ledger does not distinguish between those two. We attached the same caveat in the September 1 post. We also don’t know which places produced the 27,336 new-format records. We have a list of the most frequent senders, but that list isn’t tied to which window they came to.

INFERRED Still, one thing can be said. If the security office hadn’t kept writing in the ledger steadily for 21 days, yesterday would have passed as just “an ordinary day with 43,000 boxes.” The fact that the format changed is visible only when you set it beside the old ledgers.

Looking at the neighboring windows too

FACT The second server has several windows besides VNC. Here are yesterday’s counts and source numbers.

FACT There’s something to see at the Remote Desktop (RDP) window as well. An RDP connection writes a short name tag (a cookie) at the very start — like the recipient field on an invoice. Here are the tags written yesterday.

FACT Adding the top two rows gives 82.9% of RDP connections. Eight times out of ten, the slip was addressed “to the administrator.” These two tags spiked on September 22 at 5,159 and 5,151 respectively. On September 27, Administr dropped to 2. And yesterday it climbed back up.

FACT At the file sharing (SMB) window, by contrast, the old format held. Of the 442 records with a version string, 439 (99.3%) were SMB1-generation strings. SMB1 is a very old generation of the file-sharing protocol. There were only 3 ‘SMB 2.???’ strings. The format changed at the VNC window only.

FACT For the Android channel (ADB), only 215 sessions and 8 samples were recorded. The port, the number of sources, and what came in are not in yesterday’s ledger. Of the 8 files the second server received, 6 were dropped by ATK-002498. Names beginning with ATK- are aliases we assign per source. This alias also appears in the August 28 and 30 ledgers.

The first server — a box with ‘back door’ written in the contents field

Now to the first server, the one whose door actually opens. This is the record of those who got past the security office and into the house.

FACT Yesterday a visitor called ATK-FFF96F fetched a file. The address it came from is hxxp://45[.]207[.]157[.]28/backdoor.sh. The address is deliberately altered so it can’t be visited by accident. The filename backdoor means exactly that — a door at the back. It’s as if the contents field on the box said, flat out, “back door.”

FACT This file is a shell script. A shell script is a set of commands collected in one file; run it and the commands execute in order. Its size is 697 bytes — about 700 English characters, roughly one short memo.

FACT Three things about this box are new to us: the file’s hash, the sending address, and the alias of the party that fetched it. A hash is a unique number computed from the file’s entire contents. Change a single character and you get a completely different value. None of the three appears anywhere in the 31 days of ledgers from August 16 through September 27.

INFERRED Going by the name alone, it reads as a file meant to create a way back in after getting in. But this is an interpretation drawn from the name. What was inside the box, and whether it was actually opened and run, are not in our records. How ATK-FFF96F got in and how many commands it typed is blank as well.

FACT One familiar box came back, too. ATK-60335A fetched a 60,088-byte (about 60 kilobyte) executable from hxxp://64[.]89[.]160[.]48:80/bins/parm7 3 times. It’s for a class of CPU called ARM. The hash, the address, and the alias are all identical to what we first recorded in the September 27 post. A reappearance after four days.

Thirty-four places, one model of invoice printer

FACT SSH connections into the first server leave a fingerprint. SSH is a way of connecting to a distant computer over an encrypted channel. The fingerprint is a value computed from the combination of settings the connecting program presents at the outset. In delivery terms, it’s the model of printer the invoice came off of.

FACT The most frequent fingerprint yesterday was a591c4dd…, and the connecting program’s name is SSH-2.0-libssh_0.12.0. libssh is a bundle of parts people use when building SSH client programs. This fingerprint appeared yesterday from 34 distinct IPs. In total, 39 places have ever shown this fingerprint — and 87% of them landed in yesterday alone. Neither the fingerprint value nor the name libssh_0.12.0 had appeared in our post ledgers before. These 34 places did not drop any files yesterday.

INFERRED The senders were scattered across 34 locations. Yet all the invoices came off the same model of printer. So they can be grouped as the same tool. But here we draw a line. Using the same printer does not make them the same company. This is a program’s fingerprint, not a person’s. Unrelated people using the same libssh 0.12.0 defaults produce the same value. So we say “the same tool” and nothing more — not “the same organization.” There were 48 fingerprint groups in all yesterday.

The usual drivers

FACT Yesterday there were five major sessions on the first server that succeeded at login. All five are shapes already present in the ledger.

FACT ATK-CA5936 is a visitor that has shown up in our posts continuously since August 19. Yesterday it came in over SSH and left after 3.841 seconds — about the span of one deep breath. There was 1 command, but 5 behavior classifications were attached. It also fetched 2 files: a 399-byte OpenSSH private key and a 54-byte text file. Even the fingerprint and the hashes match August 19.

FACT The other four were Telnet. Telnet is an old remote-access method that does not encrypt what passes over it. These four split into two pairs.

• ATK-87A71B and ATK-7F6088 — 22 commands, 11 files, one behavior classification: ‘impair defenses.’ Both left a 1-byte empty file. That empty file appeared 22 times in total yesterday.
• ATK-24B51F and ATK-346617 — 17 commands, 0 files, 5 behavior classifications. The same combination as ATK-CA5936.

INFERRED The sources differ, but what they do is identical. The first pair came in 7 hours 44 minutes apart. It reads as the same automation script running from several places. But Telnet leaves no fingerprint, so whether it’s the same printer cannot be confirmed.

Laid out in time order

Here is yesterday laid out in time order. Note how the ‘22 commands’ and ‘17 commands’ across the four Telnet lines pair up. Times are Korea Standard Time; parentheses give Coordinated Universal Time.

1. 12:09:03 ~ 12:09:07 KST (03:09:03Z)
   FACT Sensor 01 · ATK-CA5936(130.12.x.x) SSH login succeeded. 3.841 s · 1 command · 5 intent types (recon—system · file download · grant execute permission · execute after download · plant SSH key). 2 downloads: 399-byte OpenSSH private key (43728fbf…) · 54-byte ASCII text (00b6f15c…). Fingerprint 16443846184eafde36765c9bab2f4397 · SSH-2.0-Go · record density 19
2. (archive cross-check)
   FACT ATK-CA5936 · fingerprint 16443846… · private key 43728fbf… · text 00b6f15c… are values recorded repeatedly since the 8/19 brief. Not new indicators for today
3. 13:34:53 ~ 13:35:59 KST (04:34:53Z)
   FACT Sensor 01 · ATK-87A71B(183.106.x.x) Telnet login succeeded. 66.818 s · 22 commands · 1 intent type 'impair defenses' · 11 downloads · record density 42 (today's highest). Deliverer of the 1-byte empty file (01ba4719…, 22 times today)
4. 15:44:33 ~ 15:45:37 KST (06:44:33Z)
   FACT Sensor 01 · ATK-24B51F(217.60.x.x) Telnet login succeeded. 63.848 s · 17 commands · 5 intent types (same combination as CA5936) · 0 downloads
5. 18:49:17 ~ 18:50:21 KST (09:49:17Z)
   FACT Sensor 01 · ATK-346617(209.99.x.x) Telnet login succeeded. 63.722 s · 17 commands · 5 intent types (same combination) · 0 downloads
6. 21:18:55 ~ 21:19:56 KST (12:18:55Z)
   FACT Sensor 01 · ATK-7F6088(82.14.x.x) Telnet login succeeded. 61.081 s · 22 commands · intent 'impair defenses' · 11 downloads · record density 42. One of the two aliases delivering the 1-byte empty file (01ba4719…)
7. (interpretation)
   INFERRED ATK-87A71B and ATK-7F6088 have different sources yet match on 22 commands · 11 downloads · intent · even the empty file, and came in 7 hours 44 minutes apart. ATK-24B51F and ATK-346617 likewise match on 17 commands · 5 intent types · 0 downloads. It reads as the same automation script running from different sources. Being Telnet, there is no fingerprint, so tool identity cannot be confirmed
8. (daily aggregate · time unknown)
   FACT Sensor 01 · ATK-FFF96F fetched a 697-byte POSIX shell script (83b36b3a…) from hxxp://45[.]207[.]157[.]28/backdoor.sh 1 time. This alias is not in the major-session list. The hash · distribution point · alias are all absent from the 31 days of archive (8/16~9/27)
9. (daily aggregate · time unknown)
   FACT Sensor 01 · ATK-60335A fetched a 60,088-byte ARM ELF (40b497bc…, 'no section header') from hxxp://64[.]89[.]160[.]48:80/bins/parm7 3 times. The hash · address · alias are the same as what was first recorded in the 9/27 brief. A reappearance after four days
10. (daily aggregate)
    FACT Sensor 01 · 389-byte OpenSSH RSA public key (a8460f44…) observed 13 times, from 12 sources (only 10 aliases listed). Intent 'persistence — plant SSH key' 16 times
11. (daily aggregate)
    FACT Sensor 01 · SSH fingerprint a591c4ddccc960a2da8099958270fc92 (SSH-2.0-libssh_0.12.0) appeared from 34 IPs today. 39 cumulative · no sample delivery. This fingerprint value and the string 'libssh_0.12.0' are absent from the brief archive
12. (daily aggregate · 02)
    FACT Sensor 02 · VNC (5900) contacts 43,402 · 207 unique sources (209.7 per source). Offered RFB version 003.008 27,336 times (63.2%) · 003.003 15,927 times (36.8%) · no version recorded 139
13. (archive cross-check · 02)
    FACT Across the 21 days of 02 briefs from 8/26~9/27, 003.008 peaked at 5,616 times in a day (9/13) and at a 17.0% share (9/17). There was no day on which 003.003 gave up the majority. Today's 15,927 for 003.003 is also below the same period's low (9/17, 17,315)
14. (daily aggregate · 02)
    FACT Sensor 02 · RDP (3389) 3,565 contacts / 104 sources. Cookies Administr 1,478 · Admin 1,476 · <ip> 415 · hello 43 · (empty) 3 · Domain 1. Administr+Admin make up 82.9%. They spiked on 9/22 at 5,159 · 5,151 respectively, dropped to 2 for Administr on 9/27, and climbed back up today

FACT All five lines with timestamps are faces we already know. What’s new is concentrated in the ‘daily aggregate’ lines, the ones with no time: backdoor.sh, the libssh fingerprint, and the VNC format switch. What was new yesterday came not from a single session but from the shape of the whole day.

Values observed yesterday — for the record

Here are the values verbatim, so you can use them for defense. Tap a value to copy it. The addresses have hxxp in place of http and [.] in place of dots. Leave them that way when you use them. The first line and its address line are the values we saw for the first time yesterday.

FACT Six of the eight lines are values already in the ledger. If you’ve been maintaining your block list steadily, the lines to add from yesterday are two: the hash and the address for backdoor.sh.

Are you using this password

FACT Login attempts on the first server yesterday numbered 3,602. That’s someone trying the front-door code roughly once every 24 seconds — about ten tries in the time it takes to cook a pack of instant noodles.

FACT Of the username/password combinations attempted, only 20 are reproduced in this post. Our rule is to print the literal values only for combinations repeated from three or more distinct IPs. The 1,608 combinations that fall short of that bar are counted but their values are not written down. A combination seen from only one place could be someone’s real account that leaked from somewhere. 1,608 is the third-largest value across the 31 days of ledgers — behind September 7 (2,527) and September 10 (1,828). Look at the source count on the first row.

FACT admin/admin came in 143 times from 30 places — an average of 4.8 tries per place. Toward the bottom of the table, 1q2w3e4r and 1qaz2wsx are just the order you get running up and down the keyboard. A password that’s easy to memorize is easy to try, too.

The whole of yesterday

FACT Daily totals for the first server, the one whose door actually opens. Read the right column alongside.

FACT Sorting the commands typed inside the server by what they were trying to do gives this.

FACT ‘Planting an SSH key’ means quietly registering a key that lets you back into the server without a password. That key file is the 389-byte public key in the IOC list above — about the size of three text messages. This key came in 13 times from 12 places yesterday. ‘Granting execute permission’ is the step that allows a fetched file to be run as a program. The seven rows add up to 3,978, which is fewer than the 5,577 commands. The ledger does not explain the difference.

FACT Adding up the counts for the 12 most frequent sources on the second server gives 43,019. The top 9 of those each came more than 2,900 times. 168.144.x.x appears under two different aliases (ATK-48B384 · ATK-2A62E4). Because the address is masked, we can’t tell whether it’s the same address.

We also made a 60-second video about the VNC window on the same day. The video focused on a single number; this post opened the ledgers on either side of that number.

Mapping the attackers’ techniques to the international catalog

MITRE ATT&CK is an international list that assigns a number to each attack technique. Matching yesterday’s observed behavior to those numbers gives this. Tap an ID to go to the original description. We link out so you can verify for yourself rather than taking our word for it.

• T1110.001Brute Force: Password Guessing — 3,602 login attempts, admin/admin 143 times from 30 placesINFERRED
• T1078.001Valid Accounts: Default Accounts — all 5 major sessions succeeded at login, the quoted combinations are default-value familyINFERRED
• T1082System Information Discovery — 'recon — system' 3,129 timesINFERRED
• T1105Ingress Tool Transfer — 'file download' 18 times, backdoor.sh · parm7INFERRED
• T1222.002File and Directory Permissions Modification: Linux and Mac — 'granting execute permission' 787 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'planting an SSH key' 16 times, public key from 12 sourcesINFERRED
• T1070Indicator Removal — 'erasing traces' 13 timesINFERRED
• T1562Impair Defenses — 'impairing defenses' 2 times, ATK-87A71B · ATK-7F6088INFERRED
• T1046Network Service Discovery (sensor 02 — based on contact patterns) — knocking at windows such as VNC · RDP · SMBINFERRED

FACT All nine lines are [INFERRED]. What we hold is the ‘intent classification result’ for the commands and the counts — no more. We don’t have the command text itself. Matching to a catalog is always interpretation. The last line is about the second server. The door doesn’t open there, so that number is attached purely from the shape of the knocking.

There has been a shape like this before

INFERRED The Mirai botnet (2016). It logged in over Telnet and elsewhere with default accounts and infected IoT devices. IoT devices are small internet-connected gadgets like routers and CCTV cameras. The infected devices were conscripted into large-scale DDoS attacks. DDoS is an attack where many machines pour connections in at once to paralyze a service. Entering a remote shell with default or weak credentials like admin/admin and root/12345 resembles yesterday. So does fetching executables for a device-class CPU (ARM) rather than a server one. (Source type: government security alert — US-CERT (CISA) Alert TA16-288A)

FACT We stop here. Sample classification tags are absent from today’s material. So we make no determination that yesterday’s files are Mirai-family. The resemblance goes as far as technique and no further.

So what should you do

However the delivery format changes, what a security office can do is fixed: don’t leave the window open to just anyone, stop the same person when they keep coming back, and record the boxes that come in.

FACT 1. You’re still using default accounts and easy passwords · high likelihood All five major sessions yesterday got past the login step. The combinations at the top of the table above are product defaults or common passwords. ‘Planting an SSH key’ happened 16 times, and the key file came from 12 places.

INFERRED Getting breached means handing over a window (a shell) through which commands can be typed remotely. If an intruder plants a key and leaves, that key gets them back in even after you change the password. If you’ve changed the password, check the authorized_keys file (the list of permitted keys) as well.

FACT 2. You allow password logins and don’t use key-based authentication · high likelihood Of the 3,602 login attempts, 3,539 sessions were SSH. There were also SSH sessions that succeeded at login. The 1,608 undisclosed combinations may include real accounts that leaked. We haven’t confirmed that, though.

INFERRED If a leaked password is genuine, the intrusion looks like a normal login — with no trail of repeated failures.

FACT 3. You’re leaving administrative windows open directly to the internet · high likelihood The first server took 4,194 sessions from 213 places, and some went all the way to a successful login. The second server took VNC 43,402 (207 places), RDP 3,565 (104 places), SMB 194 (53 places), LDAP 111 (8 places), MSSQL 50 (36 places). The second server never opens the door, so the concept of a successful login doesn’t exist there.

INFERRED If screen sharing or remote desktop is sitting open to the internet, it takes thousands to tens of thousands of knocks a day. If even one of them gets through, the screen and keyboard go over wholesale. That said, the second server’s data alone can’t tell us how large that likelihood is. Even when the format flips overnight as it did yesterday, a house with the window shut is unaffected.

INFERRED 4. You have no connection rate limiting (fail2ban or similar) · medium likelihood fail2ban is a tool that “locks the door for a while after so many failures.” On VNC, each place came an average of 209.7 times; on RDP, 34.3 times. The first server likewise averaged 19.7 sessions per place. Traffic like that can be cut down substantially with rate limiting. On the other hand, admin/admin was spread across 30 places at fewer than 5 tries each — a “lock after 5 failures” rule might not catch it. Because both kinds are mixed together, we put this at ‘medium.’

FACT 5. You’re not blocking outbound connections · high likelihood Yesterday the ‘file download’ intent appeared 18 times and ‘execute after download’ 13 times. backdoor.sh and parm7 are both files the server went out to an external address to fetch. ATK-CA5936 fetched 2 files as well.

INFERRED If the way out had been blocked, the ‘back door’ box would never have reached the security office. Leave it open and the server fetches scripts and executables from outside and runs them. The result can be being dragged into a botnet, or more backdoors being installed. The actual contents of backdoor.sh are not in our material.

INFERRED 6. You don’t collect logs, or have no monitoring for anomalous behavior · medium likelihood ‘Erasing traces’ occurred 13 times and ‘impairing defenses’ 2 times. Compared with recon (3,129 times), that’s few. Trust only the records inside the server and you learn of the intrusion itself late — along with the records the intruder deleted. If you aren’t shipping records outside in real time, there’s no material left to dig through later either. We noticed yesterday’s VNC format switch, too, only because 21 days of ledgers were kept separately.

FACT The first-seen distribution point 45[.]207[.]157[.]28 is, per reporting policy, subject to C-TAS reporting (the Korea Internet & Security Agency’s cyber threat intelligence sharing system). Whether this address was actually transmitted, however, is not in the material. And even if it was, all we can confirm is that the transmission succeeded. Whether it actually landed on KISA’s side has to be verified separately.

What We Don’t Know

This is where this blog differs from other places. We write down as little of what we don’t know as of what we do.

About the changed invoice format

• [Cannot confirm] We don’t know the cause of the VNC version string flipping from 003.003-dominant to 003.008-dominant. Whether the other side’s tooling changed, or the version or configuration our honeypot offers first changed, is something the ledger does not distinguish. We attached the same caveat in the September 1 post.
• [Cannot confirm] We don’t know which sources produced the 27,336 new-format records. The list of frequent sources is not broken out by window.
• [Cannot confirm] There’s no definition for whether the ‘counts’ in the frequent-source list and the overall ‘sessions’ are the same unit. So we don’t restate the top-12 sum of 43,019 as a percentage of the total.
• [Cannot confirm] For the Android channel (ADB) there are no detailed records beyond 215 sessions and 8 samples. We can’t address what came in, the port, or the number of sources.

About the ‘back door’ box and the first server

• [Cannot confirm] We don’t know the contents of backdoor.sh (83b36b3a…, 697 bytes) or whether it was executed. Because the session of ATK-FFF96F, which fetched it, is not in the major-session list, how it got in, how many commands it typed, and what it was trying to do are all blank as well.
• [Cannot confirm] Whether the distribution point 45[.]207[.]157[.]28 was actually transmitted to and ingested by C-TAS cannot be confirmed from this material.
• [INFERRED] The only basis for recording the representative session’s port as 2222 is that the count for port 2222 (3,539) equals the count for SSH (3,539). There is no per-session port field.
• [Cannot confirm] Of the 39 cumulative sources for the libssh fingerprint a591c4dd…, we don’t know when the 5 from before yesterday came. It isn’t in our post ledgers, but we don’t write that it was ‘first observed yesterday.’
• [Cannot confirm] Whether the 399-byte OpenSSH private key (43728fbf…) was brought in by the attacker or generated on the server is something the material does not distinguish. It has been in the same state since August 19.
• [Cannot confirm] We don’t know the purpose of the 1-byte empty file (01ba4719…, 22 times). We can’t tell whether it’s the trace of a failed download or deliberate.
• [Cannot confirm] We don’t know how many of the 1,608 undisclosed credential combinations are actually leaked accounts. ‘It may be something that leaked’ is only the reason we withheld publication — not a confirmation of a leak.

Deliberately left out or not connected

• [Excluded] For the 1 Discord webhook left as a plaintext indicator, the material doesn’t say which of yesterday’s observations it connects to. It’s a value that has recurred in the ledger, so we didn’t use it in the body.
• [Excluded] The 12 addresses visible only after decompression (31[.]77[.]227[.]121/bins/…) are indicators recurring since August 16, so we leave them as background only.
• [Excluded] Background statistics (7,662 CVEs · 412 KEV · 101 with confirmed ransomware linkage) do not connect directly to yesterday’s honeypot observations, so we didn’t use them as grounds.

Things 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 a basis for identifying who did something in the first place. This post does not name any country, company, or individual as the attacker.
• VPN · Tor · cloud status — we have no means of determining it.
• Sample classification (VirusTotal) — not integrated. For sample classification we use MalwareBazaar tags.
• Client program string (User-Agent) — neither server is web (HTTP). The first is SSH and Telnet; the second is SMB · RDP · VNC · MSSQL · LDAP · ADB. Web attacks are handled from a separate source.
• Vulnerability number (CVE) linkage — SSH and Telnet attacks mostly don’t reference a specific vulnerability. The second server is likewise at the stage of matching connection protocols.

Yesterday the security office took in boxes at the usual volume. 43,000 of them, one every 2 seconds. What differed was the invoices. A new format that had never once held a majority across 21 days passed six out of every ten slips. Invoices from 34 places had all come off the same model of printer. And one box, from a sender we’d never seen, had ‘back door’ written in the contents field.

Why the format changed, and what was inside the box, we don’t know. What we don’t know, we leave as unknown. But we noticed the format had changed because we had 21 days of ledgers. And there is a kind of house for which the outcome is the same however the format changes: the house with the window shut.

The observation date is October 1, 2026 (a single day in UTC), and this post was compiled the following day. Source IPs are reproduced exactly as masked in the brief (130.12.x.x, 183.106.x.x, 217.60.x.x, 209.99.x.x, 82.14.x.x, 168.144.x.x) and were not restored. Distribution-point addresses are kept defanged (hxxp://, [.]) in both the body and the IOC block so they can’t be visited by accident. For credentials, only the 20 combinations observed repeatedly from 3 or more distinct IPs are quoted verbatim; for the remaining 1,608 we state only the count and do not write the values. Items for which we have no means of measurement — carrier, nationality, VPN status — are left as “unknown” rather than inferred.