A living field guide drawn from a large, multi-window observational sample of 21,223 distinct source IPs / 1.37 million sessions across three 2026 windows (April, July, and August) on the live Deception Check decoy fleet. Deduplicated by source IP and classified by behaviour. Reference Examples name known families for context; they are not attributions of these observations. This is an observational sample over time, not a full census; the guide grows as new decoy types and behaviours produce verified data.
Modbus Read Device Identification and Report Server ID queries, plus S7comm SZL identity reads
Purdue-model segmentation, protocol-aware allowlists, read-only register replicas
PLC/RTU device maps, register layouts, the reconnaissance a control-process attack needs first
whoami → uname -a → cat /etc/passwd → explore; with typos and irregular pacing
Honeypot deception, EDR behavioural detection, session recording
Targeted intelligence, custom tooling, unpredictable movement
Novel, non-replayed sequence + high unique-command diversity + clean structure
Honeypot deception, and the fact that its own novelty makes it stand out
Well-structured attack paths; attribution to AI is not established
Full IPv4 sweep from a published, attributed network range
Blocklists and rate limiters neutralize them instantly
Internet-wide scan datasets, research papers
Hardware recon → deploy XMRig → crontab persistence → kill competing miners
Process monitoring, CPU alerts, egress filtering on stratum ports
Monero (XMR), pool statistics revealing the operator wallet
Many attempts confined to a narrow, repeated credential set
Rotating credentials, MFA, lockout on repeated failure
A narrow credential set being repeatedly tested for reuse
chattr -ia .ssh → mkdir .ssh → append authorized_keys → chmod; seconds, self-contained
Immutable authorized_keys, key-based auth, file-integrity monitoring
Persistent backdoor access, lateral movement
Bursts of distinct exploit and secret-file paths, then .env / .git harvesting
WAFs with virtual patching, up-to-date dependencies
Exposed secrets from .env / .git, RCE shells, cloud keys
High cross-sensor fan-out, minimal per-host engagement, scanner user-agents
Being correctly identified and set aside from the adversarial count
Internet-wide inventory datasets
Opening sequence replayed byte-for-byte across many distinct source IPs
Static, brittle playbook; trivially fingerprinted once catalogued
Evidence of widely reused automation or shared tooling
enable → system → shell → sh → busybox echo \xNN tag → wget C2 → chmod +x for every architecture
Firmware updates, changed default passwords, network segmentation
DDoS-for-hire capacity, proxy networks, additional drones
Connect or single probe, no authentication, no command, no HTTP body
Literally everything. A closed port stops them.
Nothing. Not even a completed interaction.
Five-plus attempts spanning many distinct passwords in a single burst
Account lockouts, fail2ban, key-only SSH auth
Valid credential pairs for lateral movement
One to four auth attempts, no post-auth shell, no follow-up
Any non-default credential; connection rate limits
A yes/no on whether the easy credential works
Signals we track that do not (yet) carry their own archetype card, either because they describe abuse of the fleet rather than an attacker type, or because the number behind them is not yet reconciled. The Bestiary is a living document. Cards in the guide above are published once a real, reconciled number stands behind them; archetypes still waiting on that number are listed at the foot of this page.
On the OT decoys, 194 source IPs probed SNMP without ever touching an industrial control protocol. SNMP is common on printers, switches and UPS units and is frequently used for amplification/reflection abuse rather than targeted OT reconnaissance, so it is deliberately excluded from the ICS/OT Prober count. Of 1,639 IPs that touched any protocol marker on the OT sensor, only 367 reached genuine industrial protocols. Treating a SNMP probe as "wants your turbines" could lead to an over-count in this area, so it lives as a metric instead.
Roughly 6,600 login attempts used fixed random strings such as 345gs5662d34 (username = password), a known technique to detect honeypots by checking whether a host accepts obviously invalid credentials. Attackers are actively fingerprinting for decoys on our fleet, which is why persona fidelity matters. The username claude has also begun appearing in credential lists.
106 disclosed research scanners (Censys, Shodan, Shadowserver and peers) and 720 behaviourally-identified commercial/research scanners are classified as scanners and set aside from the adversarial population; real traffic, correctly labelled, so the threat picture is not inflated by internet-wide measurement.
The decoy was not inside the April, July, and August sampling windows that produced the counts on this page, so it has no verified number of its own. We would rather leave it blank than borrow a figure from another surface.
A full sampling window measured on its own sensor.
We hold candidate sessions, but not yet the corroboration needed to separate this cleanly from the SSH Key Injector and botnet families it overlaps with. Publishing it now would double count behaviour already attributed elsewhere.
Corroborated classification against a named tooling or C2 family.
No staging or execution of a ransomware payload has been confirmed on the decoys in the sampled windows. The behaviour is in the classifier; the observation is not yet there.
An observed staging or execution sequence we can attribute.
Watched for across every surface in the fleet. Nothing in the sampled windows meets the bar for confirmed wiper behaviour.
A confirmed destructive sequence rather than an isolated destructive command.
Every industrial protocol interaction we have classified so far is read only. Across three engines we recorded no completed writes, controls, or restarts, so the ICS / OT Prober card covers what we can actually evidence.
A confirmed write to a control register, coil, or setpoint.