Four Boxes Arrived, and the Waybill Had No Sender

You come home and there’s a box sitting by your door. You don’t remember ordering anything.

Usually it sorts itself out fast enough. You just look at the waybill. There’s a store name in the sender field, a phone number, an order number. If it came to the wrong place, you call them and tell them to come get it. If strange packages keep arriving, you can report that store.

But what if you look at the waybill and there’s no sender field at all? Not that the print rubbed off — the field was never on the paper to begin with. Only the recipient is written down.

At that point your options shrink fast. You can’t return it, you don’t know who to complain to, and you can’t tell the front desk “please block anything coming from that store.” All that’s left is the box itself. Beyond weighing it and taking a photo, there’s nothing.

Over the course of a single day, August 28, 2026, four such boxes arrived at our server.

First, let me unpack one unfamiliar term. A honeypot is a decoy server, deliberately built flimsy and put out on the internet. It does no real work. It’s a machine left open so that whatever anyone does after they get in can be recorded in full. Every number below comes from one.

We run two servers, and they’re opposites

FACT The first (Sensor 01) is a high-interaction server. You can actually log in, whoever gets in can type commands, and every one of those commands is recorded. The second (Sensor 02) is a low-interaction server. It takes your greeting at the door and never lets you in.

FACT So on the second server, successful logins, commands, and credentials do not exist in the first place. All that can be counted there is “how many times did someone knock” and “what protocol did they speak in.” And very occasionally, like today, something gets left behind.

The four boxes in this post are all the second server’s story.

A field that had been empty for two days got filled

FACT Samples secured on this server: 0 on August 26, 0 on August 27. On August 28 it was 4.

FACT This isn’t just a number going up. In the August 26 brief we wrote this down — “this channel is the only path where payload contents could be preserved, yet the details are empty. Confirmation needed in the next collection.” We wrote the same sentence again on August 27. On the third day, that field was filled for the first time.

FACT The four sizes are these. 46,525 bytes · 153,208 bytes · 239,388 bytes · 334,816 bytes. Roughly 45KB up to 327KB. Added together, 773,937 bytes.

FACT And all four came from the same single source. One alias: ATK-F4738A.

The waybill has no sender field

FACT For these four, our data holds only two things. The sha256 (file fingerprint) and the size.

Let me unpack fingerprint here. It’s a 64-character value computed over the entire file. Change a single character inside the file and the value changes completely. It’s like the tamper seal on a box — we use it to judge whether two boxes hold the same thing.

FACT And there is no URL field. Not that the value is empty — the field itself does not exist in the data. Where it was downloaded from, what address it had been sitting at, is not in the record.

INFERRED Here’s how we read the absence. If the server ordered and fetched the file, the address it ordered from is preserved. But if the other side just pushed it in, there was no order at all, so no address was ever created. It’s not that the waybill has no sender field — there was never any occasion to write a waybill.

INFERRED What this means in practice is one thing. There is no address to add to a blocklist and no distribution site to report. The field you’d type into the firewall is blank. What’s left is the box’s tamper seal — four sha256 values, nothing more.

FACT The same problem catches us elsewhere today. There are 12 indicators we obtained only by unpacking archives (filenames under 31[.]77[.]227[.]121/bins/), and for those files too, looking at the outside shows no address at all. You have to strip the wrapper to get them. Today’s four boxes are the kind with no wrapper even to strip.

The other server did leave a waybill

The files that came down on the first server the same day are a different character. Let me put the data down first, then explain.

FACT On August 28, samples secured on the first server: 8 distinct files. Two of them have an address attached.

• hxxp://185[.]93[.]89[.]72/wget — where a 306-byte shell script had been sitting
• hxxp://5[.]182[.]210[.]174/ok — where a 1,608-byte bash script had been sitting

FACT The addresses are written deliberately broken (hxxp://, [.]). Copy-pasting them as-is will not connect.

FACT Today’s reportable distribution sites are these two. From the second server’s four boxes, not a single reportable indicator came out.

INFERRED This difference is today’s backbone. On one side the server went out and fetched something, and so “which store it came from” was preserved. On the other side someone carried it over and set it down, and so nothing was preserved. Same day, same organization, two servers, opposite shapes.

Weighing them makes it stranger

FACT The first server’s 8 samples come to 2,783 bytes in total. About the volume of a dozen or so short text messages.

FACT The second server’s samples are 4 files at 773,937 bytes. Roughly 278 times larger.

FACT One more number brings it into focus. The smallest of the four boxes alone (46,525 bytes) is about 16.7 times the first server’s entire eight-file day combined.

FACT And on the first server, ELF executables: 0. ELF is the file format for programs that run directly on Linux. Following August 27, that’s two consecutive days at 0.

INFERRED The kind of ‘program’ antivirus would catch hasn’t come down on one side for two days now, while on the other side four large boxes arrived for the first time in three days. Look at the two observation surfaces separately and they’re “a quiet day” and “a strange day” respectively; put them side by side and you get a picture of the center of gravity shifting.

FACT But we have to stop right here. What these four files are is not in our data. There’s no field for recording type either. Whether they’re executables, archives, or images, we cannot know. We are not going to write “45KB to 327KB, so probably executables.”

Which door did they come through

FACT Contacts the second server received yesterday: 47,815. Spread across a full day, that’s about once every 1.8 seconds. Every couple of blinks, something somewhere spoke to this machine. Distinct sources: 248.

FACT That’s up 55.2% from the day before (30,804), and it also passed August 26’s 42,493. The busiest of the three days.

FACT Here’s which doors those 47,815 piled up in front of.

FACT The bottom row of the table is today’s spot. ADB is the channel developers use to connect an Android device to a computer, look inside it, and push files in. It was built to be used over a cable, but when it’s open toward the internet it doesn’t ask for a password. 87 sessions works out to about once every 16 minutes across the day.

INFERRED On a low-interaction server, ADB is the only channel where a file drop could take place. So that’s how we read the four boxes. The data does not state this explicitly. We’ll come back to this judgment in ‘What We Don’t Know’ at the end.

FACT The three-day trend in ADB session counts is 8/26 86 → 8/27 26 → 8/28 87. But the samples go 0 → 0 → 4. The session count is nearly identical to August 26, yet only the outcome differs.

The one that dropped the boxes wasn’t on the list

FACT The nine sources that knocked most on the second server:

FACT Together these nine account for 45,035 contacts, 94.19% of all contacts.

FACT And ATK-F4738A, the one that dropped the boxes, is not on this list, nor on the list of twelve below it. It’s a source that never made the contact rankings.

FACT Since it isn’t on the list, we don’t know its masked IP or how many times it made contact. “Not in the rankings” is as far as the fact goes, and we can’t say more than that.

INFERRED Put back in delivery terms: the nine households that rang the doorbell 5,000 times each through the night are clearly recorded in the front desk log. The person who dropped off the box is not in the log. It wasn’t a list sorted by dangerous — it was a list sorted by loud.

The day in chronological order

Laid out in time order, it looks like this. From here on, most of it is first server (high-interaction) records. Pay attention to the elapsed time on the third and fourth lines — those are seconds, not minutes.

1. 2026-08-28T00:51:46Z ~ 00:52:54Z (68.2s)
   FACT ATK-D62131(220.133.x.x) telnet login success. 31 commands, 1 download. intents are file download → grant execute permission → download-then-execute, 3 types, with no recon or persistence. Being telnet, no SSH fingerprint exists (fingerprint is an empty string). completeness 16
2. 2026-08-28T05:49:09Z ~ 05:50:10Z (60.8s)
   FACT ATK-4F095E(47.82.x.x) telnet login success. 17 commands, 5 intent types (recon — system · file download · grant execute permission · download-then-execute · persistence — SSH key planting). Yet download_count is 0. completeness 17
3. 2026-08-28T09:20:33Z ~ 09:20:38Z (4.8s)
   FACT ATK-CA5936(130.12.x.x) SSH login success. Only 1 command but 5 intent types attached, and 2 downloads. Client SSH-2.0-Go, fingerprint 16443846…4397. completeness 19, today's highest
4. 2026-08-28T10:43:51Z ~ 10:43:55Z (3.7s)
   FACT The same alias ATK-CA5936 reconnects 83 minutes later. 1 command · 5 intent types · 2 downloads · identical fingerprint — structurally identical to the 09:20 session
5. 2026-08-28T13:38:22Z ~ 13:38:49Z (27.5s)
   FACT ATK-AE28B3(187.52.x.x) SSH login success. 18 commands, 4 intent types — recon — system · persistence — SSH key planting · persistence — cron · indicator removal. Today's only cron session (the daily total is also 1). 1 download. Client SSH-2.0-libssh_0.11.1, fingerprint 03a80b21…e6fb. completeness 18
6. No timestamp (Sensor 02)
   FACT 4 samples secured. Sizes 46,525 · 239,388 · 334,816 · 153,208 bytes, totaling 773,937 bytes. delivered_by is the single source ATK-F4738A for all four. No item on this sensor carries a timestamp, so we cannot say when during the day
7. 2026-08-28T15:05:18Z
   FACT Brief generated. Sensor 01 daily totals are sessions 3,303 · unique sources 202 · login attempts 3,051 · commands 10,940 · TTY recordings 2,836, and Sensor 02 is contacts 47,815 · unique sources 248

FACT What stands out most in the table is the third and fourth lines. Two sessions of 4.8 seconds and 3.7 seconds, and the command count, intent types, download count, and client program fingerprint are identical without a single difference. 83 minutes apart.

INFERRED We read it as the same tool running twice. That’s everything we can say. We cannot say it’s the same person or the same organization.

FACT And the sixth line is today’s protagonist, but the time field is empty. The second server has no time records at all. When the box was set down, we don’t know. Just as the waybill has no sender field, here there’s no delivery-time field.

Meanwhile the first server flipped direction

FACT Commands executed on the first server yesterday: 10,940. August 27 was 2,313. 4.7x in a single day. Spread across a full day, that’s a command coming in about every 8 seconds.

FACT But the number of sources went the other way. Distinct sources came to 202, down 54.3% from August 27’s 442.

FACT Commands per session went from 0.89 on August 27 to 3.31 yesterday.

INFERRED If the day before was “many places sweeping wide,” this was “few places going deep.”

FACT The access channel flipped in a day too. Telnet sessions were 2,081, 63.0% of the total. On August 27 it was 186, 7.1%. Telnet is a very old remote access method. It’s a channel left open so that someone across the internet can type directly into that machine’s command prompt, and passwords flow through it unencrypted, in the clear.

FACT Yet on a day when commands rose 4.7x, only 1,200 commands (11.0%) were classified into intents. On August 27 it was 1,970 of 2,313 (85.2%). The data does not explain why the remaining 9,740 went unclassified. So we did not interpret this day’s ‘recon 995’ as a proportion of total commands.

FACT The breakdown of the classified 1,200:

Two things to unpack here. SSH key planting is the act of writing a line containing someone else’s public key into a Linux server’s authorized_keys (list of permitted keys) file. Put plainly, it’s hanging a key at the front door that lets you in without a password. Change the password and that key still opens the door. cron is the feature for scheduling “do this at such-and-such time” on a server. Once set, it survives reboots.

FACT ‘Persistence — cron’ was exactly 1 yesterday. And that one came from the 13:38 ATK-AE28B3 session. Recon → hang a key → set a schedule → wipe traces ran back to back in one session within 27.5 seconds.

FACT The fingerprint of the client program that session used is 03a80b21…e6fb (SSH-2.0-libssh_0.11.1). It’s not in yesterday’s top-11 fingerprint list, and this version has never appeared in the records from August 16 through 27 either.

INFERRED But let me draw a line here. This is a fingerprint of a build, not of a person. Completely unrelated people using the default client bundled with the same distribution will have the same value. On top of that, telnet — 63% of yesterday’s sessions — has no concept of a fingerprint at all.

FACT And ‘defense evasion’ had no entry at all yesterday.

Which passwords were tried

FACT Login attempts yesterday: 3,051. Spread across a full day, someone tried the doorknob about once every 28 seconds. Divided across 202 sources, that’s an average of 15.1 per source.

FACT Below are the 20 combinations filtered to only those observed from 3 or more distinct IPs. Combinations seen from a single source could be real leaked credentials, so we do not publish their values.

FACT Beyond these 20, there are 862 more combinations that appeared from a single source only. Up 105 from the day before’s 757. We write down only the count, never the values. What we withheld outnumbers what we published by 43 to 1.

INFERRED What to watch in the table is the second row. 345gs5662d34 is a string that looks entirely meaningless, and the username and password are identical. 10 different sources typed it exactly 10 times, once each. We read that as meaning they’re reading straight off a list circulating somewhere, not values a person came up with one at a time.

What got left behind yesterday

Values to write down. Click a value to copy it — these aren’t here to be read, they’re here to go into a blocklist. The addresses are written deliberately broken. Look at the URL field on the bottom four lines — today’s story is there.

FACT The difference between the ten lines above and the four below is visible. The upper part has two url lines mixed in. The lower part has none. For those bottom four, the only field you can write into a blocklist is the sha256.

FACT Worth noting the top line too. The 389-byte public key has been the same hash for 13 days running since August 16. It’s about the size of two or three text messages, and yesterday 12 sources planted it. It means the same key has been getting hung, continuously, for 13 days.

Mapped to the international classification

The techniques attackers used carry numbers the whole world shares. It’s a list called MITRE ATT&CK. Below, click an ID to go to the original description — we attach them so you can check for yourself instead of taking our word.

• T1110.001Brute Force: Password Guessing — Sensor 01 login attempts 3,051 / unique sources 202INFERRED
• T1078.001Valid Accounts: Default Accounts — the 20 quotable combinations including admin/admin (15 sources) are all defaults or simple numeric stringsINFERRED
• T1082System Information Discovery — 'recon — system' 995 timesINFERRED
• T1105Ingress Tool Transfer — Sensor 01 'file download' 21 times + 8 samples. 4 samples also came in on Sensor 02 (the path is not stated in the data)INFERRED
• T1222.002File and Directory Permissions Modification: Linux — 'grant execute permission' 135 timesINFERRED
• T1098.004Account Manipulation: SSH Authorized Keys — 'persistence — SSH key planting' 15 timesINFERRED
• T1053.003Scheduled Task/Job: Cron — 'persistence — cron' 1 time. The only one yesterday, and it matches the intents of the ATK-AE28B3 sessionINFERRED
• T1070Indicator Removal — 'indicator removal' 12 times. Without the raw commands we cannot distinguish whether logs, history, or files were deleted, so we attach no sub-techniqueINFERRED
• T1046Network Service Discovery — on Sensor 02, 248 sources contacted 5 service ports. Mapped from the fact of service contact alone; no scanning tool was identifiedINFERRED
• T1021.005 / T1021.001Remote Services: VNC / RDP — mapped by service type only. Being a low-interaction sensor, actual use of the remote services was not observedINFERRED

INFERRED All ten lines carry the ‘INFERRED’ badge. What we saw is intent classifications of commands and contact counts, not purposes the attackers stated themselves. The bottom two lines in particular are observed only as far as “they spoke to this port.” It does not mean anything was actually breached.

The whole of yesterday

FACT On the first server (Sensor 01, high-interaction):

FACT On the second server (Sensor 02, low-interaction). The unit of a session differs between them, so we do not add the two servers together.

FACT The protocol they spoke in is preserved in the records too. For VNC, of the 45,081 contacts with a version recorded, 45,038 (99.90%) proposed 003.003. 003.008 accounts for 43. The dialects proposed in SMB negotiation were NT LM 0.12 58 · LANMAN1.0 53 · LM1.2X002 53 and so on — all SMB1 family — and the SMB 2.??? proposal that appeared 1 time yesterday and 2 times the day before is entirely absent from this day’s list.

INFERRED They’re selectively proposing only very old protocols. We read that as a picture of them looking for machines left old and neglected, not modern ones. That said, what was observed here goes only as far as the negotiation stage.

FACT On the RDP side, a string the other party fills in themselves (the cookie) is preserved. hello 1,586 · <ip> 445 · (empty) 5 · nmap 4 · kset 2 · ZRIlUYMXZ 1, totaling 2,043; of the 2,114 contacts, 71 were not recorded.

INFERRED The 4 nmap entries are a value that wasn’t on the August 26–27 lists. That said, the cookie is a free-form string the other party fills in at will. It is not evidence they actually used that tool. Whatever is written there is just a self-introduction.

So what should you do

INFERRED Here are the six ‘if this control hadn’t been there’ items the brief laid out, ordered by how strongly yesterday’s data backs each one.

1. Unplug devices you don’t use — the channel yesterday’s four boxes came through accounted for 0.18% of all contacts. They don’t come because you’re a target, they come because you’re open. If an Android set-top box or tablet shoved in a closet is plugged into the internet, that’s an unlocked back door.

2. Don’t leave management ports open straight to the internet — 202 sources knocked on two ports yesterday, and on the adjacent server 50 sources · 45,113 contacts hit VNC and 120 sources · 2,114 contacts hit RDP. They come for no reason other than that it’s open, vulnerability or not.

3. Don’t use default passwords — the 20 combinations in the table above are ones that 3 or more distinct IPs actually tried. If even one of them is live, it opens within the day. Yesterday’s top 5 sessions by completeness succeeded at login without exception. The fastest took 4.8 seconds.

4. Open up your authorized_keys file once and look — 15 key plantings and 1 cron scheduling were observed yesterday. The 389-byte public key being planted has been the same file for 13 days. If there’s a line you don’t remember putting there, that’s someone else’s key. Changing your password does not remove it.

5. Block a source that keeps knocking — but that only blocks half of it FACT On the second server, blocking just the top 9 makes 94% of yesterday’s contacts disappear. There’s little to block. INFERRED But combinations like 345gs5662d34 were tried by 10 sources exactly once each. IP-level blocking does not catch the distributed, one-attempt-per-source form. Both forms arrive together on the same day.

6. Restrict outbound connections from the server — and here today’s limit shows up FACT Yesterday’s 21 file downloads and 21 download-then-executes get cut off here. INFERRED But outbound blocking is “stopping you from placing an order.” It has no effect on a box already set down at your door. The fact that the second server’s four boxes have no URL may mean that even if you block all outbound traffic, that channel stays wide open.

7. Keep logs somewhere off the server — intent to erase traces was observed 12 times (down steadily from 70 on 8/25 and 36 on 8/27). At 0.36% against 3,303 sessions it’s on the low side, so we rated the risk ‘medium.’ Still, if the logs had lived only on the server, some of those would have succeeded.

It’s happened before

INFERRED ADB.Miner (2018). A worm that swept for devices with Android Debug Bridge open and spread mining code. The fact that it spread by pushing files in through a debug channel left open with no authentication procedure connects contextually to the shape of yesterday: the only channel where a physical sample was actually secured was the ADB family, and those 87 sessions were only 0.18% of all contacts. That said, our data has neither file type nor behavior. We are not identifying yesterday’s samples as belonging to this family, and we do not cite infection-scale figures either. (Basis: security vendor public research team report — 360 Netlab, February 2018 — and subsequent public analyses from multiple vendors)

INFERRED Mirai-derived families that spread via the ADB interface (2019). A family that had been spreading with default-credential dictionaries and began also using a separate path: an unauthenticated debug port. It resembles the shape of yesterday, where the first server’s 20 dictionary credentials and the second server’s sample intake were observed simultaneously on the same day across two different servers in one organization. That said, we cannot verify the intersection of the two servers’ sources with our data, so there is no basis for saying it’s the same campaign. (Basis: vendor public threat analysis report — Trend Micro, 2019 — and the MITRE ATT&CK T1105 technique document)

What We Don’t Know

This is the most important part of this post. There is more that could not be written than what’s written above.

• That Sensor 02’s 4 samples came in via ADB is an inference. The data does not state which service these 4 passed through, there is no ADB entry in the service list, and following 8/26 and 8/27, this day too has no separate ADB detail block. It’s a judgment resting on the premise that “on a low-interaction server, ADB is the only channel where a file drop could take place.”
• ADB sessions went 8/26 86 → 8/27 26 → 8/28 87, but samples went 0 · 0 · 4. The session count is nearly identical to 8/26, yet the outcome differs. Whether the attack behavior changed or the collector’s state changed cannot be distinguished from the data. This post’s title hangs on that difference, so it is the most important uncertainty.
• Sensor 02’s 4 samples have no field recording file type. There’s only size — whether they’re executables, archives, or images we cannot know. We did not write “45KB–327KB, so probably executables.”
• ATK-F4738A is not on the top-12 source list, so we know neither its masked IP nor its contact count. “Not in the contact rankings” is as far as the fact goes; how many times this source made contact, we cannot say.
• On Sensor 02, whether a single source swept multiple services cannot be determined. There’s no per-source service list, and the sum of per-service unique IPs (50+120+13+37+9=229) is less than the total of 248 unique IPs, so the numbers hold even with no overlap at all.
• The top 9 sum (45,035) is nearly identical to VNC contacts (45,113), but the data does not link sources to services. We cannot conclude that these were on the VNC side.
• Of Sensor 01’s 10,940 commands, only 1,200 (11.0%) were classified into intents. 8/27 was 85.2%. Whether the remaining 9,740 are commands without intent or classification failures, the data does not explain.
• The 15 ‘persistence — SSH key planting’ events and the 12 downloads of the 389-byte public key (12 aliases) are not linked. We cannot confirm whether all 15 planted this key, and only 10 of the 12 delivery sources are listed.
• The 05:49 ATK-4F095E session has ‘file download’ and ‘download-then-execute’ in its intents, yet the download count is 0. Whether it failed, or succeeded but wasn’t saved, cannot be distinguished.
• The two ATK-CA5936 sessions have 1 command but 5 intent types and 2 downloads. How a single command line got classified into five stages, the data does not explain. The same shape appeared on 8/19 as well, but without the raw commands it cannot be confirmed.
• Those two sessions match on command count, intents, download count, and fingerprint. It appears to be the same tool run twice, but there is no basis for saying it’s the same person or the same organization.
• The reference indicators include one Discord webhook address, but there is no date saying whether it’s from this day’s observations or cumulative. It doesn’t connect to any sample from this day, so we did not use it as a fact in the body. The same problem is noted in the 8/27 records.
• For the same reason, the 12 obtained only by unpacking archives (under 31[.]77[.]227[.]121/bins/) also carry no date, and since Sensor 01 had 0 ELF files this day, we did not connect them to this day’s observations.
• TTY recordings number 2,836 but only 200 were actually retained. Whether that 14x gap is due to retention policy or a difference in counting basis, we don’t know.
• Of Sensor 01’s 202 unique IPs, the 11 client fingerprints cover only 35. The distribution of the remaining 167 is unknown, and telnet — 63% of this day’s sessions — has no fingerprint at all. The total cluster count is 45, but only 11 are carried in the data.
• Among the top 5 by completeness, the 2 telnet ones have empty strings for fingerprint and client. It’s not that the value is missing — the protocol has no such concept. This must not be read as ‘the fingerprint was wiped.’
• The 450 unique sources across both servers combined is an upper bound arrived at because the intersection is unknown. How many touched both servers, we cannot know.

And below are things there was never any means to confirm. We do not infer them.

• ASN · ISP — we have no relevant database. Which provider the distribution sites 185[.]93[.]89[.]72 · 5[.]182[.]210[.]174 sit with, or whether Sensor 02’s top 9 are on the same network, we cannot say.
• Geolocation — same, we don’t have it. And IP geolocation is not a basis for attribution in the first place. We name no country, company, or individual as this day’s attacker.
• VPN · Tor · cloud status — we have no means to determine it. Among the 202 and 248 sources, which are relays and which are origins cannot be distinguished.
• VirusTotal — not integrated. We cannot attach external multi-engine verdicts to yesterday’s 12 secured samples (01’s 8 + 02’s 4). The 4 from 02 in particular don’t even have a file type in the data.
• User-Agent — neither observation surface is HTTP. 01 is SSH · telnet, 02 is SMB · RDP · VNC · MSSQL · LDAP · ADB.
• CVE linkage — neither server showed any trace of referencing a specific vulnerability yesterday. The CVE figures we carry as background statistics do not connect to any session or sample observed yesterday.

INFERRED To sum up, yesterday went like this. Four boxes arrived all at once into a field that had been empty for two days. 773,937 bytes in total, about 278 times the adjacent server’s entire eight-file day. They all came from the same single source, and that one source had no name on the list of who rang the doorbell most.

And the boxes had no waybill. All we can write down is four tamper seals, four lines of sha256. A blocklist and a report form are both things you can only use if you know “where it came from,” and what arrived yesterday has no such field at all.

So today’s work lies not in guarding the door but in reducing the number of doors. Unplugging devices you don’t use, closing ports you don’t use. Once a box with no waybill has arrived, there isn’t much left to do about it.

The observation period is the single day of August 28, 2026 (UTC). Source IPs are carried over in the brief’s masked form (187.52.x.x) and were not restored. Distribution addresses are written altered so they will not connect (hxxp://, [.]). Credentials cited are only the 20 combinations observed from 3 or more distinct IPs; for the 862 combinations that appeared from a single source only, we disclose the count and do not carry the values. ASN, nationality, and actor attribution have no means of confirmation, so we do not infer them.