Before It Mines You, It Checks Whether You're Worth More: An SSH Botnet That Triages Hosts for Telegram Sessions and SIM-Box Fraud

Most SSH botnets land, drop a cryptominer, and move on. This one stops to ask a more interesting question first: is this host worth more than its CPU?

Observation window: 2026-06-11 (single 11-hour wave)

Signal: 16 unique source IPs, one identical nine-command triage script, every node reaching post-authentication

Core finding: the script enumerates Telegram Desktop session data, GSM/SMS-gateway hardware, and SIM-management config — not just mining real estate

Defensive value: 16 IOC IPs, a high-signal command fingerprint, and detection logic for host-value triage behavior

Anatomy of the wave

Over roughly eleven hours, sixteen distinct source IPs each ran the exact same nine-command sequence after authenticating — one node per host, spread across the window, every one reaching a post-authentication shell. None dropped a payload during the wave. None mined. Each ran the script, read the answers, and disconnected.

The script is short, and every command in it is a question:

/ip cloud print
ifconfig
uname -a
cat /proc/cpuinfo
ps | grep '[Mm]iner'
ps -ef | grep '[Mm]iner'
ls -la ~/.local/share/TelegramDesktop/tdata /home/*/.local/share/TelegramDesktop/tdata \
       /dev/ttyGSM* /dev/ttyUSB-mod* /var/spool/sms/* /var/log/smsd.log /etc/smsd.conf* \
       /usr/bin/qmuxd /var/qmux_connect_socket /etc/config/simman /dev/modem* /var/config/sms/*
locate D877F783D5D3EF8C
echo Hi | cat -n

Read top to bottom, this is not reconnaissance for a mining drop. It is a host-value triage routine: the operator is grading what kind of asset it just compromised, so it can decide how to monetize it. Three distinct answers are being collected.

Answer 1 — “Are you a MikroTik router?”

The script opens with /ip cloud print. That is not a Linux command. It is a MikroTik RouterOS command that prints the public IP address the router learned from MikroTik’s cloud service.

A normal shell returns “command not found.” A RouterOS device returns its public address. The botnet does not know in advance whether the credential it just used opened a Linux server or a MikroTik router, so it asks both questions in one script — the RouterOS command first, then ifconfig and uname -a for the Unix case. Compromised MikroTik routers are valuable in their own right: they make excellent proxies, traffic redirectors, and DNS-manipulation points, and there is a long history of botnets (VPNFilter, Mēris, and others) that specifically harvest them.

Answer 2 — “Do you hold a Telegram session I can steal?”

The center of the script is the long ls -la against ~/.local/share/TelegramDesktop/tdata and /home/*/.local/share/TelegramDesktop/tdata, immediately followed by:

locate D877F783D5D3EF8C

tdata is the Telegram Desktop local data directory. It holds the session keys that authenticate the desktop client to Telegram’s servers. An attacker who copies a victim’s tdata folder can, in many configurations, resume that Telegram session on their own machine — reading messages, impersonating the user, and harvesting whatever the account is connected to. No password, no 2FA prompt: the session is already authenticated.

D877F783D5D3EF8C is the filename Telegram Desktop uses for the encryption-map key file inside tdata. Searching the whole filesystem for that exact string is a fast, reliable way to find a Telegram installation even if the user moved it out of the default path. The presence of this one locate call is a high-confidence indicator that the operator is specifically hunting Telegram session material — it is too specific to be incidental.

Telegram session theft monetizes in several ways: account takeover, access to private channels, and — because Telegram accounts are frequently tied to phone numbers and used as a second factor or as a control channel for other fraud — as a pivot into a victim’s wider digital identity.

Answer 3 — “Are you SMS-fraud or SIM-box hardware?”

The same ls -la line is doing double duty. Alongside the Telegram path, it enumerates a very specific hardware-and-config set:

This is not a server. The host the operator is hoping to find here is an SMS gateway or a SIM box — a machine wired to one or many cellular modems, used to send and receive SMS at scale. Those devices are the backbone of SMS-fraud economies: bulk smishing, OTP/2FA delivery for fake accounts, and interception of inbound one-time passwords. Finding one of these is, for this operator, a far bigger prize than a CPU to mine on. It is direct access to a telephony-fraud asset.

The ps | grep '[Mm]iner' pair earlier in the script is the mundane fallback: if the host turns out to be just a server, check whether a competitor’s miner is already running before treating it as mining real estate.

Why this is triage, not an attack

Every command in the wave is a read. Nothing is written, nothing is downloaded, nothing is executed beyond enumeration. The closing echo Hi | cat -n is an output-sanity check — the operator confirming its command channel returns clean, numbered output before recording results.

The behavioral shape is deliberate: score the host, log the result, move on. Hosts that answer “I have a Telegram session” or “I am an SMS gateway” get routed to a different, higher-value monetization path than the generic “deploy a miner” flow. A wave that touches sixteen hosts in eleven hours and writes nothing is building a filtered inventory, not running an intrusion. The drop comes later, and only for the hosts worth dropping on.

Attribution and scope — an honest note

A conservative reading is warranted. The components of this script are individually well known: /ip cloud print router-probing, Telegram tdata theft, and GSM/SMS-gateway hunting have all appeared separately in prior botnet activity. The notable element is the assembly — a single, stable, replicated triage script that grades each host across all three monetization axes at once — and the scale and completeness of this particular wave: sixteen coordinated nodes, each reaching a post-authentication shell, running a byte-identical routine including the rarely-seen SIM-box markers (/etc/config/simman, /var/config/sms).

There is no basis to attribute this to a named actor. The source nodes are geographically diverse and consistent with a botnet of compromised hosts replaying an operator’s script rather than a single origin. The behavior is consistent with an operator monetizing compromised access through telephony fraud and messaging-account theft — a meaningfully different threat model from the commodity cryptomining that dominates SSH-botnet traffic.

This behavior has recurred for several weeks; this write-up is the first full-wave characterization, prompted by a wave in which every node executed the complete triage script. For a related pattern — a credential-validation botnet that reads rather than exploits — see Residential Broadband Botnet Uses AsyncSSH to Validate Credentials Across Four Regions .

Defensive value

Detection — the command fingerprint is the rule. Any of the following in a post-authentication shell, especially in combination, is high-signal:

• /ip cloud print issued against a non-RouterOS host (a RouterOS command on a Linux box is an attacker probing blind).
• A filesystem search for the literal string D877F783D5D3EF8C, or any access to */TelegramDesktop/tdata by a non-interactive session.
• Enumeration of /dev/ttyGSM*, /etc/smsd.conf, qmuxd, or /etc/config/simman by an SSH session — almost no legitimate automation touches these.
• The closing echo Hi | cat -n channel-sanity probe.

Hardening. If you operate genuine SMS-gateway or SIM-management infrastructure, treat those hosts as crown jewels: no internet-facing SSH, key-only auth, and alerting on any shell that reads smsd.conf or the SIM-manager config. If you run Telegram Desktop on a server-class host, understand that tdata is bearer-token-equivalent material and protect it accordingly.

IOCs. Sixteen source IPs from the 2026-06-11 wave are listed below. They are most consistent with compromised third-party hosts recruited into the botnet; treat them as scanning-fleet indicators, not as origin attribution.

14.55.31.113      45.15.227.120     58.226.230.112    64.226.126.224
65.49.139.223     83.243.158.41     95.167.214.5      109.63.146.109
109.63.164.67     112.167.99.220    125.132.34.65     144.2.91.96
178.175.167.68    185.162.141.34    213.67.210.12     213.230.110.57

Command-fingerprint markers: /ip cloud print, locate D877F783D5D3EF8C, ~/.local/share/TelegramDesktop/tdata, /etc/config/simman, /var/spool/sms, qmuxd, echo Hi | cat -n.

OHIIHO — threat research. Published for defensive value. Observation windows describe the activity window, not the limits of any campaign.