TI-2026-097C — One Binary Per CPU: The Cross-Architecture Build Matrix

Classification: HIGH · Forensic threat intelligence · Dropped-sample corpus · Series: Reading the Drop

The first two letters ranked the drop corpus honestly and tore down its worst single specimen. This one looks sideways, at a pattern that runs across many of the real payloads at once: the operators do not ship a binary. They ship a matrix — the same miner cross-compiled for every CPU a victim device might run, from a processor designed in 1979 to one that barely exists in the field yet. It is the assembly line behind the infection, and reading it reveals two things: how total the coverage has become, and a quiet blind spot at its leading edge — the honeypot's own classifier under-rates precisely the newest architectures, so the very ranking the first letter prescribed looks past the frontier builds.

1. The Matrix, Three Times Over

Filter the corpus to the real, classified payloads and a shape repeats. A single family arrives not as one file but as a set, one per instruction-set architecture, fronted by a small loader that detects the CPU and pulls the matching build. Three separate operations in the corpus do exactly this:

Collapse the duplicates and the corpus covers nine distinct architectures: m68k, armv5, armv6, arm7, arm8/aarch64, i386/i686, x86_64, riscv, loongarch64. That range is the point. m68k is the Motorola 68000 — a CPU from 1979, still alive inside industrial controllers and ancient embedded gear. loongarch64 is a 2020s Chinese architecture only now appearing in the field. riscv is the open-standard newcomer. The same drop directory on 41.216.189.236 holds a build for a forty-six-year-old processor and one for a CPU most defenders have never seen in a sample — side by side, xnxnxnxnxnxnxnxnm68kxnxn next to xnxnxnxnxnxnxnxnloongarch64xnxn.

Whatever the compromised thing is — a router, a NAS, a set-top box, an IP camera, a point-of-sale terminal, a hobbyist board — there is a binary waiting for its CPU.

2. It Is Maintained, Not Frozen

A multi-arch kit could be a one-time build that an operator drops forever. RedTail's is not. The corpus caught two RedTail campaigns, on 2026-07-09 and 2026-07-19, and the per-architecture binaries carry different hashes across them:

Ten days apart, the whole matrix was recompiled. Whether the change was a config update, an evasion tweak, or a pool rotation, the operational fact is the same: this is a maintained toolchain with a build pipeline behind it, not a static payload someone found and reuses. Someone runs make across a rack of cross-compilers on a cadence. The 07-19 campaign also added riscv to the set — the matrix is not just refreshed, it is being extended.

3. The Blind Spot at the Frontier

Here is where this letter feeds back into the first. TI-2026-097A's whole thesis was: do not rank the drop corpus by count — rank it by content and severity. That is correct, and this letter finds its limit.

The honeypot's auto-classifier handled the common RedTail builds well — redtail.arm7, arm8, i686, x86_64 were each scored severity 20–25 and tagged T1496 (resource hijacking). But redtail.riscv was scored severity 0 — recognised as family RedTail, yet assigned no tactic and no technique, landing at the very bottom of a severity-ranked list. And the whisper ARM ELFs on 31.170.22.205 were labelled "Windows API dropper" — an ARM Linux binary tagged as Windows malware.

The pattern is legible: the classifier degrades on the newest and rarest architectures. It has seen ten thousand ARM and x86 miners and scores them confidently; it has seen almost no RISC-V, so it shrugs. Which means the strategy of building for the frontier has an incidental second payoff beyond reaching new devices — it partially evades classification. A RISC-V miner and an x86 miner from the same campaign, the same operator, the same make, land at opposite ends of the severity ranking the defender was told to trust.

This does not overturn 097A — severity is still a far better sort than count. But it names the residual: severity-ranking under-weights exactly the forward-looking builds, because novelty and low-classification-confidence coincide at the architectural edge. The honest sort is severity plus a flag for "family-known but arch-unrecognised," so the frontier builds float up instead of sinking.

4. Clearing the Field, Surgically

The matrix is the delivery; clean.sh is what the campaign does on arrival, and it is a small masterclass in turf warfare. Where the #biret worm of the previous letter evicts rivals with a blunt killall list and a single /etc/hosts blackhole, RedTail's clean.sh is precise. It defines a helper that edits competitors out of persistence rather than just killing their processes:

clean_file() {
  chattr -ia "$1"
  grep -vE 'wget|curl|/dev/tcp|/tmp|\.sh|nc|bash -i|sh -i|base64 -d' "$1" >/tmp/clean_file
  mv /tmp/clean_file "$1"
}

It chattr -ia to strip the immutable bit competitors set to protect themselves, then runs that filter across every crontab (/var/spool/cron/crontabs/*, /etc/crontab, /etc/cron.hourly|daily|weekly|monthly|d), anacrontab, and the shell rc files (~/.bashrc, ~/.bash_profile, ~/.profile) — deleting any line that fetches or executes a payload while leaving the file otherwise intact. It then systemctl stop/disables the named service c3pool_miner (a specific rival Monero-pool miner), zero-truncates rival binaries hiding under decoy names (systemtd — a typosquat of systemd — plus /bin/-bash and /usr/bin/.sh), and wipes /tmp, /var/tmp, and /dev/shm of everything but its own working directory.

The difference from a blunt killall matters forensically: clean.sh removes persistence as well as processes, so a competitor cannot simply respawn from its own cron entry after RedTail lands. The host is not just cleared; it is de-persisted in the attacker's favour.

5. The Counter-Narrative

Steelman. "Multi-architecture IoT malware is not news — Mirai shipped a dozen builds in 2016. You've counted some architectures and found a classifier bug. Where is the intelligence?"

The framing earns its length on two points a "not news" dismissal skips:

• The frontier is the finding, not the multi-arch fact. That IoT miners cross-compile is old; that these operators now ship RISC-V and LoongArch64 builds, in 2026, and rebuild them across campaigns, is a current datapoint about where the targeting is heading. Watching m68k and loongarch64 share a drop directory is watching the coverage envelope stretch at both ends simultaneously.
• The classifier blind spot is actionable, not a curiosity. It directly qualifies this program's own prior advice. TI-2026-097A told defenders to rank by severity; this letter shows that ranking sinks the RISC-V build of a known family to zero. A defender who applies 097A naively will systematically deprioritise the newest payloads. Naming that failure mode — and the fix (flag family-known-but-arch-unrecognised) — is the intelligence.

What is not claimed: that the three operations share an operator (they are distinct families and hosts; only the strategy is shared); that RISC-V/LoongArch infections are yet common (they are forward positioning, and the letter says so); that the classifier is broken (it is strong on common architectures — it degrades specifically at the frontier); or that clean.sh is unique to RedTail (surgical cleaners are a genre — this is a clear specimen of it).

Confidence: HIGH that the corpus contains three multi-architecture delivery operations spanning nine CPUs, that RedTail's matrix was rebuilt between campaigns, and that clean.sh performs surgical competitor de-persistence (all in the retained data); MEDIUM that RISC-V/LoongArch inclusion is deliberate forward positioning and that the classifier's frontier weakness confers meaningful evasion.

6. Defence Response

• Rank by severity, but flag arch-unrecognised builds. Apply TI-2026-097A's severity sort with one addition: any sample whose family is known but whose architecture the classifier could not score should be floated, not sunk. redtail.riscv at severity 0 is a known miner, not a benign file.
• Do not trust the OS label on exotic ELFs. An ARM Linux binary tagged "Windows API dropper" is a classifier failure, not a platform fact. Verify the ELF header/architecture before believing a platform attribution on rare-arch samples.
• Remediate persistence across the whole cron/rc surface. Because campaigns like RedTail edit competitors — and themselves persist — out of crontab, anacrontab, cron.d, and the shell rc files, hunting a running miner is not enough. Audit every cron and rc location and watch for the immutable bit (chattr) being toggled.
• Block the drop hosts and loaders. Hosts 41.216.189.236 and 31.170.22.205; the /bins/xnxn…<arch>xnxn and redtail.<arch> / whisper.<arch> URL patterns; the run.sh/setup.sh/clean.sh/dl600 loader names; and the c3pool_miner service name as a compromise indicator.

7. A Note on Method

Built through honeypot_downloads for the per-URL, per-hash, per-classification delivery records that expose the architecture matrix and the cross-campaign rebuild, and honeypot_sample_analysis for the retained bytes of clean.sh. The architecture list, the differing hashes across campaigns, and the severity anomalies (RISC-V at 0, ARM-as-Windows) are read directly from the classifier output. No SQL touched the investigation, and no sample executed — Cowrie captured the drops; it did not run them.

8. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence