The Silence

Twenty-three thousand open doors, and what came through none of them

TI-2026-103F · Series: The Loud Hour · Letter F of 15 Operates under the rules of evidence in Letter O — The Instrument. Per R9, volume is not capability; this letter is the letter where that rule is cashed.

1. What this letter is for

Every letter so far has ended at the same wall. Ten machines hold 72% of every successful login this sensor has granted and have issued no commands. A hundred and five machines run a 762-attempt job and issue exactly one. Twenty-two of twenty-five burst events downloaded nothing at all.

An obvious objection follows, and it is the right objection: perhaps nothing happens here. Perhaps this is a quiet sensor on a quiet address, and the "silence" of the beacons is simply the silence of an internet that has found nothing worth taking.

This letter tests that objection and finds it false.

The corpus contains 507 distinct commands, 76 confirmed malware samples, cryptocurrency miners masquerading as system daemons, IRC botnet loaders at maximum severity, multi-architecture droppers targeting MIPS, m68k, ARM and x86-64, and 113 separate machines that installed a persistent SSH backdoor key. It also contains a payload, run 751 times, whose explicit purpose is to determine whether it is talking to a honeypot.

Real intrusion happens here constantly. The silence is not the sensor's. It belongs specifically to the actors this series has been following — and that makes it a finding about them rather than about the address they are knocking on.

2. What actually comes through the door

[DOCUMENTED] The corpus holds 507 distinct commands. The ten most executed:

[DOCUMENTED] The 942-count entries share an identical first-seen timestamp of 2026-06-29T01:26:22 and differ only by path prefix — uname, /bin/uname, /usr/bin/uname, busybox uname, /proc/version, /etc/os-release. These are fragments of a single fallback chain recorded as separate commands because the shell emulator logs each alternative in a || sequence. Counting them as distinct commands would quadruple-count one behaviour.

[DOCUMENTED] echo BMOK — 278 executions from exactly one address, between 2026-05-16 and 2026-05-28, and never again. A single machine's marker string.

3. Real persistence: one hundred and thirteen backdoors

[DOCUMENTED] The most consequential command in the corpus is executed 123 times by 113 distinct addresses:

cd ~ && rm -rf .ssh && mkdir .ssh &&
echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8db…mdrfckr"
  >> .ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

Preceded, in the same sessions, by:

cd ~; chattr -ia .ssh; lockr -ia .ssh

[DOCUMENTED] The dropped key is recorded as sample a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2, classified SSH-key backdoor, 123 drops from 113 addresses, first seen 2026-03-31T13:49:31Z and last 2026-07-29T23:43:10Z — active the day before the record closes.

[DOCUMENTED] The same 112–113 addresses also ran crontab -l (122 executions), whoami, w, top, and four separate /proc/cpuinfo interrogations.

[INFERRED — confidence HIGH] This is the complete intrusion sequence: strip immutable attributes from .ssh so it can be modified, destroy any existing authorized_keys, install the operator's public key, lock the directory's permissions, then enumerate the host and its scheduled jobs. The mdrfckr comment string is a long-documented marker in Mirai-lineage tooling. One hundred and thirteen machines did this. None of them is a beacon, and none is a member of the TechTies fleet.

[DOCUMENTED] The malware corpus holds 76 confirmed real samples. The most-deployed:

[DOCUMENTED] The 8 MiB XMRig binaries were dropped under the filename sshd — a miner masquerading as the daemon it arrived through. The IRC botnet dropper was fetched from URLs that are random eight-character strings (GdorMnnc, Tmwl3bcg, VePzeOc3, z1CdQRcR), and carries nine ATT&CK techniques including T1098.004 (SSH authorized_keys manipulation), T1489 (service stop) and T1562.001 (disable defences).

[DOCUMENTED] Recent droppers target deliberately obscure architectures: http://31.56.209.153/nz/nz.mips, nz.i686, nz.x86_64; http://41.216.189.236/bins/xnxnxnxnxnxnxnxnm68kxnxn and its aarch64 sibling; http://31.170.22.205/bins/whisper.armv5. One — family Aterna, from http://31.56.209.153/bins.sh — was first seen 2026-07-30T00:15:54Z, seven hours before the record closes.

The drop corpus is treated in depth in the previously published Reading the Drop series (TI-2026-097A/B) and is not re-analysed here. What matters for this letter is only that it exists, it is substantial, and the actors this series follows contribute nothing to it.

4. A payload that checks whether it is being watched

[DOCUMENTED] One command was executed 751 times by 27 addresses, first seen 2026-07-05T18:11:25Z. It is roughly 2,600 characters long. Its structure:

Layered fingerprinting with fallbacks. uname -s -v -n -m attempted via uname, then /bin/uname, then /usr/bin/uname, then busybox uname, then by reading /proc/version, then by grepping ID= from /etc/os-release. Architecture resolved the same way, with a final fallback that infers x86_64 from the lm flag in /proc/cpuinfo, aarch64 from CPU architecture: 8, and armv7l from CPU architecture: 7.

Capability profiling. /proc/uptime, nproc, CPU model via lscpu then /proc/cpuinfo then /proc/device-tree/model, and:

gpu_info=$( lspci | grep -i vga ; lspci | grep -i nvidia ;
            busybox lspci | grep -i vga ; busybox lspci | grep -i nvidia )

Session history. last, capturing prior logins.

And an emulation test. Under a ===SHELL_BEHAVIOR=== banner, three probes:

path_err=     ( ./xxxxxx 2>&1 || true )     — error text for a nonexistent relative path
cmd_err=      ( xxxxxx   2>&1 || true )     — error text for a nonexistent command
execute_err=  write a script, chmod +x it, run it, check it echoes back, delete it

[INFERRED — confidence HIGH] The third probe is the decisive one. A real shell writes a file, marks it executable, runs it, and returns the string. Emulated shells characteristically fail at one of those four steps or return a subtly wrong error string, and the first two probes exist to capture exactly which wording the target produces. This is honeypot and sandbox detection, and it is deliberate enough to try bash, /bin/bash, /usr/bin/bash and busybox sh in turn before giving up.

[INFERRED — confidence MEDIUM-HIGH] The GPU query alongside CPU model, core count and uptime is target valuation, not reconnaissance for lateral movement. lspci | grep -i nvidia on a freshly compromised SSH host is a question about compute worth — mining throughput or accelerator availability. Combined with the XMRig deployments in §3, the most economical reading is target selection for compute theft.

[DOCUMENTED] This payload appeared on 2026-07-05, four months into the record. It is the newest tooling in the corpus and it is the only tooling that tries to determine what it is talking to.

It was upgraded mid-record, and it never stopped

[DOCUMENTED] The payload has a datable predecessor. The fallback-chain fragments in §2 — /bin/uname …, busybox uname …, ( [ -f /proc/version ], [ -f /etc/os-release ], head -1 /proc/version | cut -d -f1, all at 942 executions from 29 addresses — carry an identical first-seen of 2026-06-29T01:26:22Z, six days before the full payload.

[DOCUMENTED] All of them, and the full payload, share a last-seen within one second of each other: 2026-07-30T07:17:00.68–07:17:00.70Z — the same execution, in the final hours of the record.

[INFERRED — confidence HIGH] A simpler fingerprinting command arrived on 2026-06-29. On 2026-07-05 it was extended with the GPU query, the last capture, and the ===SHELL_BEHAVIOR=== emulation test. The two are one lineage, upgraded in place, and the upgrade added exactly the anti-analysis component.

[DOCUMENTED] The 2026-06-29 arrival is not a visibility artefact. Command capture was more permissive before that date, not less — the sensor authenticated 100% of connections through 2026-05-20 and 46% through late June, against 7.2% afterwards (Letter O, D8). A command that first appears when the door starts closing genuinely started then.

And now the question this letter's earlier draft deferred.

[DOCUMENTED] The payload ran 751 times across 25 days, from 2026-07-05T18:11:25Z to 2026-07-30T07:17:00Z — roughly 30 executions per day, 28 per address, continuing to the last hours of the corpus.

[DOCUMENTED] Its emulation test was answered, 751 times, by an emulated shell.

[INFERRED — confidence HIGH] They never stopped. Twenty-seven machines ran a honeypot detection routine for twenty-five consecutive days against a target that fails it, and kept running it. Either the result is collected but never acted upon, or it is never read at all.

This matters more than the detection routine's sophistication. Building a shell-emulation probe requires understanding how honeypots differ from hosts; continuing to run it for three and a half weeks against a host that answers wrongly requires that nobody is looking at the output. The tooling is more careful than the operation. Letter K takes what that implies about how these campaigns are actually run — and it is the strongest single piece of evidence in the series against the reading that any of this is targeted at anything.

5. D11 — degenerate hashes inflate every download count

Status: RESOLVED. Rule issued. Affects any download-volume statement.

[DOCUMENTED] The download record holds 111 entries. Ranked by volume, three of the top six are not files:

[DOCUMENTED] Verified by direct computation: these are sha256("\n"), sha256("") and sha256("test") — three of the most recognisable constants in computing. Together they account for 90 recorded "downloads" from up to 76 distinct addresses, all classified with severity: 0 and no family.

[INFERRED — confidence HIGH] These are artefacts of command output or shell probing being captured and hashed as though a file had been retrieved. The execute_err probe in §4 writes and deletes a small script; the fallback chains in §2 emit empty output. Either produces exactly this.

Rule R14. Download counts are quoted only after excluding degenerate-content hashes, and malware presence is ranked by classification severity and file type, never by drop count. A raw download total for this corpus overstates malware activity by including the empty string.

[DOCUMENTED] Applying R14: of 111 download entries, 76 are confirmed real samples. The single highest-volume entry, at 123 drops, is a key rather than an executable, and carries severity: 0 despite being the most operationally significant artefact in the corpus — a reminder that severity scoring measures file danger, not consequence.

[DOCUMENTED, requires confirmation] The 76 addresses associated with the newline artefact and the 76 addresses that executed uname -s -v -n -r -m are the same count. Whether they are the same set — which would mean the fleet's uname execution generates a phantom download record — is not established here. The reference fleet node's own download total is independently zero, so the fleet's abstention (§6) is unaffected either way; but the coincidence is recorded rather than assumed, and closing it requires a per-sample address list the download endpoint does not return.

6. The abstention, quantified

Against everything above, set the actors this series has followed.

[DOCUMENTED] The beacon class has authenticated successfully 22,783 times and never issued a command. The fleet has authenticated roughly 1,700 times and issued uname -s -v -n -r -m, only ever that. Neither has downloaded anything.

[DOCUMENTED] Meanwhile 113 machines — a population larger than the beacon class by an order of magnitude, and individually far less persistent — walked in, defeated the immutable flag on .ssh, installed a durable backdoor key, read the crontab, and left. The whole sequence takes under four seconds.

The two behaviours are mutually exclusive in this record. No address that installs the mdrfckr key beacons. No beacon installs a key. No fleet node does either.

[INFERRED — confidence HIGH] This is not a capability gradient, it is a division of labour. The mdrfckr cohort's job is to take hosts. The fleet's job is to enumerate them. The beacons' job is to confirm one fact repeatedly. Three populations, three jobs, no overlap — and only one of the three does anything a defender would recognise as an attack.

The uncomfortable corollary

[DOCUMENTED] The population that does real damage is the one with the weakest signature by every measure this series has examined. The mdrfckr cohort is 113 addresses each appearing briefly, with low per-address volume — exactly the profile that Letter E showed sits at the 1.0 attempts-per-address end of the distribution, indistinguishable from commodity noise.

[DOCUMENTED] The populations with the strongest signatures — 4,574 attempts from one address, 762-connection jobs in exact multiples, four-month metronomic cadence — are the two that have never taken anything.

[INFERRED — confidence HIGH] Any detection strategy that ranks by volume, persistence or anomaly magnitude will surface the harmless populations first and the damaging one last or never. This inverts the usual assumption and it is Letter N's central problem.

7. What the silence bounds

Any explanation of the beacon and fleet populations must now satisfy a harder constraint than before, because the environment they operate in demonstrably rewards action.

[DOCUMENTED] The sensor grants shell access on admin/admin to anyone who asks. 113 machines used that access to install persistence. XMRig deploys successfully here. The fingerprinting cohort's own probes would have told it the host has CPU cores worth using.

The beacons had, 22,783 times, everything required to do any of that. They did none of it.

[INFERRED — confidence HIGH] Three readings survive, and this letter does not choose between them:

1. The record is the product. The operator sells or maintains a list of reachable credential-and-host pairs. Acting on access would risk the access and produce nothing the list needs. Supported by the fleet's uname-only behaviour, which populates exactly one database field.
2. The consumer is gone. A process still runs whose downstream component no longer exists — verifying a fact nobody reads. Supported by the beacons continuing to transmit into network space blocked at the edge since June, without ever detecting the irrelevance.
3. Access is being held, not used. The credential is confirmed against a future need. Supported by nothing in the record except its own logic, and weakened by four months of inaction.

[DOCUMENTED] What the silence rules out is the reading that these are attacks whose payload this sensor failed to capture. Command and download capture demonstrably works: it recorded 507 commands, 76 samples, and a 2,600-character payload in full. The absence is real, not instrumental.

8. What this letter could not establish

• Whether the newline artefact's 76 addresses are the fleet's 76 (§5). Requires a per-sample address list the endpoint does not provide. Nothing here depends on it.
• Who operates the mdrfckr cohort. 113 addresses sharing one public key is a strong shared artefact — considerably stronger than a HASSH — and it has not been pursued. It is the largest unexamined cluster in the corpus and it belongs in Letter J.
• What the fingerprinting cohort did with its answer. §4 establishes that they kept running the probe for 25 days regardless, so the output is not acted upon. Whether it is stored, transmitted, or discarded is not established — and neither is whether a different, unseen cohort received the result and stayed away as a consequence. An absence of follow-up visits from other addresses cannot be measured from inside the sensor.
• Whether the beacons ever attempted a command that was refused. The record shows commands executed. A command attempted and rejected before execution may not appear, so "zero commands" is strictly "zero commands recorded as executed".
• Whether any of the 76 samples was ever executed to effect. This is a honeypot; nothing ran. The samples are what was offered, and offering is not impact.

The third point is the cheapest open question in the series and the most likely to change a conclusion. A payload that tests for a honeypot, gets the answer, and keeps running anyway would say something quite specific about how little the operator cares — and that is a measurable thing, not a speculative one.

Next: Letter G — Paper Companies. A Panamanian corporation with a documented past, a Seychelles address shared with strangers, and four autonomous systems that have changed their names.