How a botnet sizes you up — and quietly checks whether you're a honeypot — before it ever drops a payload.
Across a two-week window, our fleet of LLM-backed SSH and Telnet decoys logged tens of thousands of hands-on shell sessions. When we clustered those sessions by their exact command set, one signature stood out: a 52-command reconnaissance playbook that appeared 886 times, run identically across at least five of our Linux decoys, in multiple regions. Same commands, same order, same sentinel strings. No typos, no exploration, no hesitation.
Public abuse feeds log these same hosts hammering SSH with brute-force logins; once one succeeds, this survey runs in the shell it opens. On our decoys the door always opens — so we get to watch what happens next, and what it does is a small masterpiece of automated triage.
It doesn't assume uname lives in one place. It calls it three ways and falls back to reading /proc/version directly. Embedded and IoT systems are stripped down and inconsistent; this playbook is built to work on all of them.
This is the tell. It determines the exact instruction set with a fallback ladder straight out of the botnet-loader playbook:
The lm ("long mode") flag means 64-bit x86; CPU architecture: 8 is ARMv8/aarch64; 7 is ARMv7. Multi-architecture malware carries a dozen compiled binaries — x86_64, ARM, MIPS, PPC, SH4 — and it needs to pick the right one. This is how it decides which binary to drop. In a separate session on the same fleet, we watched the follow-through: a loader that dropped ARM, ARMv5, ARMv7, and MIPS binaries one after another, byte-by-byte. Security researchers have documented this exact fallback pattern as a hallmark of multi-architecture IoT loader reconnaissance.
It counts cores, reads the CPU model, checks /proc/device-tree/model (an embedded-device tell), pulls uptime, and reads login history with last. Then the most interesting line in the whole survey:
It's looking for a GPU. A box with an NVIDIA card is a cryptomining or ML-theft prize, not just another DDoS foot-soldier. CPU-and-GPU resource profiling is well-established botnet behavior — mining is resource-hungry, and operators triage accordingly.
This is the part that should make honeypot operators uncomfortable. The playbook prints a marker, ===SHELL_BEHAVIOR===, and then runs a genuine capability test:
It writes a tiny script, makes it executable, runs it, and checks whether the sentinel xxxxxx actually comes back — repeating the test across every shell it can find and capturing the error mode of each. In plain terms: it is checking whether commands truly execute, or whether something is faking the output.
Everything collapses into one structured, machine-readable line:
Key-value, easy to parse, easy to route. This output feeds a queue that decides — automatically, at scale — which boxes get which binary, which get mined, and which get discarded as honeypots.
Seeing the same playbook 886 times across just a handful of our decoys is a rounding error of a campaign that is surveying the entire internet, continuously.
This is the internet's triage layer, and you can watch it work. The 52-command playbook isn't the attack; it's the census the attack runs first. Industry telemetry backs the scale: 2025's botnet growth was driven less by novel malware than by automation against known weaknesses, with Mirai-descended families (Murdoc, Resbot/LZRD, Mozi, Gafgyt, Hajime) scanning broadly and deploying multi-architecture payloads — and Mirai-class DDoS alone was pegged at $2B+ in global damages for the year.
The honeypot that survives the census is the one that catches the payload. The Phase-4 shell-behavior probe is a filter designed to make traps disqualify themselves — a decoy that only fakes a shell gets fingerprinted and abandoned before the interesting part ever happens.
A timing-based classifier would happily label this session "agentic": no typos, steady sub-second pacing, dozens of distinct commands, methodical branching that looks like reasoning. It isn't. It's identical across hundreds of sessions and many source IPs — the signature of a very good script. The honest test for an autonomous AI attacker is behavior that adapts over time, not one fast, flawless, perfectly repeatable run. That distinction is the difference between a threat-intel headline and a threat-intel finding.
uname, architecture-detection greps, lspci | grep nvidia, script-execution probes — you can act before the payload arrives.The census never stops. The useful question isn't whether you're being surveyed — you are — but whether you can watch it happen.
The playbook ran from 20 source addresses clustered in a handful of /24 ranges — not a single host. Those ranges span a few offshore/anonymized ASNs — AS47890 and AS48090 (Romania / Netherlands “Unmanaged Ltd” / “Techoff” space that OSINT reports frequently tie to “DMCA-ignored” marketing), plus a third offshore ASN (AS197170 / AS210644, per differing OSINT sources). Treat the networks as blockable indicators, but lean on the behavioral signatures: the same toolkit reappears from fresh IPs, while the command pattern stays constant.
Deception Check operates a global fleet of LLM-backed honeypots that study how attackers behave the moment they reach an exposed system — from Linux servers to industrial controllers and medical devices. We turn that behavior into early-warning detection for the operational-technology, healthcare, and enterprise environments that conventional tools struggle to protect. This briefing is for educational purposes and references open, citable sources throughout.
© 2026 Deception Check. Command sequences reproduced from real captured sessions; identifying details withheld.