The capture
There was one session from a single address. Its only real act was fetching and running a shell dropper named syst.sh, 992 bytes long, SHA-256 beginning 5b73969e4df42bd5. The session ended seconds later. The address did not return.
The dropper was served from a short path on the same address. I am not naming that address here; the reason is in the section on the loader tier.
What the dropper does
syst.sh is a POSIX shell loop over fourteen architecture builds: mipsel, mips, armv7l, armv6l, armv5l, armv4l, aarch64, x86_64, i486, powerpc, sh4, m68k, sparc, and arc.
Each filename is the architecture name wrapped in long runs of xnxn padding, so a grep for mips or arm across a filename list finds nothing readable at a glance. For each build the script tries wget, then curl, then busybox wget, writes the response to a mktemp file under /tmp, and skips anything under 512 bytes as an error page. The remaining file is made executable and started in the background. The script sleeps one second. If the process is still alive it exits 0; if not, it deletes the file and tries the next architecture.
for each padded architecture filename:
try wget, then curl, then busybox wget
save the response to a temporary file under /tmp
reject anything under 512 bytes
run it, wait one second, keep a surviving process and exit
otherwise delete it and continue
This is the same spray-every-architecture shape as the RedTail capture, done more cheaply. Instead of uploading six megabytes of binaries, it ships a one-kilobyte script that pulls only what runs.
The one-second liveness test is the interesting part. It is a crude but effective architecture probe. A binary for the wrong CPU dies immediately with an exec format error, so still being alive after one second means the architecture was probably right and the program did not crash on startup.
Correction, 2026-10-23. I first wrote here that "the sensor never fetches an attacker-supplied URL" and that I did no hash lookups. Both were wrong. The decoy retrieved syst.sh itself when the attacker's command ran, which is how the script was captured, and the sensor checked its hash against a public multiscanner automatically at capture; one of 75 engines flagged it. Nothing was uploaded. The ELF payloads the dropper would have fetched were never captured, so there is still nothing to reverse.
Why the volume tiers could not see it
Until 2026-09-20 the blocklist had two tiers, both volume-based. Credential meant repeated login attempts against the decoys. Scanner meant sustained credential-less probing.
This address made one login. It fell below any inclusion floor and never appeared on the list. That was a measurement problem: a single session that delivers a dropper is more dangerous than a thousand failed passwords, and the old tiers had no way to represent the difference.
The loader tier
I shipped a third tier, loader, on 2026-09-20. Any address that delivers a payload inside the window, whether fetched into the session or uploaded to it, is listed on that evidence alone, with no volume floor. Precedence is credential over loader over scanner, so nothing moved between tiers.
Thirteen addresses active inside the current 30-day window had been missed by the volume tiers. The feed grew from 594 to 607 entries.
Why the address is not named here. The handling policy names addresses only for sustained activity, and this was one session on one night.
It is on the blocklist for 30 days after its last activity. That is the point of the loader tier: a time-boxed, automatically expiring public listing for a single-event address, instead of a permanent naming in prose.
The same week showed the contrast. 130.12.180.51, the address named in the RedTail writeup because it has attacked these sensors continuously since January, dropped an ed25519 private key and an ssh_config fragment containing StrictHostKeyChecking no over SFTP. That is persistence staging, not a botnet loader. It was already on the credential tier and stays there.
Correction, 2026-10-23. The paragraph above is wrong twice. The key and the config were not uploaded over SFTP; they were written with echo inside a single command. And they are not persistence staging. They are RedTail's current loader, which uses the key to pull its installer from the botnet's own server. I read the two files without reading the command that wrote them. The full account is in RedTail brings its own key.
What I can and cannot say
| Claim | Confidence |
|---|---|
| What the dropper does: fourteen builds, three fetch tools, size check, one-second liveness test | High. Read directly from the script. |
| The payloads are IoT botnet binaries | Likely, not observed. The architecture list, the fetch behaviour, and the liveness test all fit. They were never captured, so nothing was seen. |
| The address was a one-off | High for this sensor, unknown elsewhere. One session, one night, no return. |
Remaining gaps
The ELF payloads. I do not know what they would have executed, or whether their hashes would tie this to a known family.
The xnxn padding. I do not know whether it is a family marker or one operator's habit. I have not seen it elsewhere and have not looked systematically.
The loader tier is one day old. Its false-positive behaviour is unmeasured. Nothing benign uploads files to a honeypot shell, but that is an expectation, not a measured rate. The bogon and benign-survey-scanner exclusions apply to it like every other tier.