The set
| SHA-256 (first 16) | Bytes | Architecture |
|---|---|---|
59c29436755b0778 | 1,880,264 | ELF 64-bit x86-64, statically linked |
048e374baac36d8c | 1,748,196 | ELF 32-bit Intel 80386 |
dbb7ebb960dc0d5a | 1,560,860 | ELF 64-bit ARM aarch64 |
3625d06889695359 | 1,299,516 | ELF 32-bit ARM EABI5 |
What it is
One dropper, sprayed across every architecture it knows, hoping one runs. This is the standard IoT botnet shape and it tells you something about the economics: enumerating the target costs a round trip and some cleverness, while shipping four binaries costs about six megabytes. Six megabytes is cheaper.
All four are statically linked — no libc dependency, because embedded userland is unpredictable. All four are UPX-packed (UPX 5.02), which is compression plus a mild anti-analysis speed bump, not real protection. /proc/self/exe appears in the strings, the usual self-relocation dance a packed dropper does on startup.
Not Go. Zero go1.* or golang hits across the set. That matters because it separates this cleanly from the May capture, which is Go throughout. Different toolchain, different operator, different goal.
How it arrived, and how the family got named
As with the May sample, there was never a fetch URL, because these were not downloaded. They were uploaded over SFTP in a single burst:
method SFTP upload x24 events, 2026-01-11 23:25:33-34
filenames redtail.arm7 redtail.arm8
redtail.i686 redtail.x86_64
The attacker's own filenames name the family: RedTail — a cryptomining botnet that drops an XMRig-derived miner.
That is attribution from the operator's naming convention, not from my analysis. Treat it as strong but not forensic. Someone who wanted to poison this inference could simply name their files something else, and I would have written down whatever they chose.
It is worth being blunt about the order of events here. My string analysis found nothing conclusive — the Mirai and Gafgyt markers a naive triage looks for are absent, which is exactly what UPX packing predicts. I could not name the family from the binaries. The log correlation named it in one line. The lesson I took is that the delivery record is often better evidence than the payload, and I had been treating it as the boring half of the job.
On the source address
The uploads came from 130.12.180.51, which has recorded 864 attacks against these sensors from 2026-01-11 through 2026-08-06 and is still active. It is banned at the sensor and it is on the published blocklist.
I am naming it here, and I redacted the equivalent address in the ransomware writeup, because the handling policy distinguishes sustained activity from a short incident. Eight months of continuous attack against infrastructure I own is a pattern I can stand behind. Six days of activity that stopped a quarter of a year ago is not, and whoever holds that other address today is probably not whoever held it then.
What I can and cannot say
| Claim | Confidence |
|---|---|
| Four architectures, one delivery, UPX-packed, statically linked, non-Go | High. All directly observed. |
| The family is RedTail | Strong, not forensic. It comes from the operator's filenames, not from the binaries. |
| Confirmed cryptomining behaviour | Not established. RedTail is a known miner family, but I did not unpack these binaries and did not observe mining. The family label carries that expectation; my evidence does not. |
A note on reading this sensor's numbers
This set landed under an earlier sensor configuration, one where authentication acceptance ran around 4.7% against a lazy-sysadmin password list. The configuration has since been retuned toward IoT defaults, which changes both how many sessions get far enough to deliver a payload and what kind of payload arrives.
If you are comparing capture volumes or malware types across that boundary, the discontinuity is the reconfiguration landing, not a change in the threat landscape. I am flagging it because I would otherwise be tempted to read my own graph as a finding.
Remaining gaps
Not unpacked. UPX is trivially reversible and doing so would expose the real strings and probably settle attribution properly. That is still static analysis and safe, but it belongs off the sensor, on a copy, and it has not happened yet.
No hash lookups. These hashes were not checked against any external service. Deliberate hold under the handling policy, same reasoning as the other capture.