SSH Honeypot Analysis: Bot Profiles System Hardware Before Deploying a Cryptominer

In a Guest Diary published on the SANS Internet Storm Center by Adam Cann (an ISC intern with the SANS.edu BACS program), researchers detail an automated SSH-targeting bot observed performing hardware and system reconnaissance on a compromised or honeypot host before deploying a cryptocurrency miner.

What Happened

According to the diary, the bot connects over SSH and, rather than immediately dropping a payload, first runs a series of commands to profile the target's hardware — reportedly checking details such as CPU specifications and system resources — before proceeding to deploy a miner. The full technical specifics of the recon commands and miner payload are described in the original write-up.

Why It Matters

SSH remains one of the most commonly targeted services on internet-facing Linux systems, and cryptomining campaigns continue to be a persistent, high-volume threat against exposed or weakly-credentialed hosts. The reconnaissance-before-deployment behavior noted here suggests operators are optimizing miner configuration or targeting based on available compute — a low-sophistication but pragmatic step that can make campaigns more efficient and potentially harder to distinguish from benign administrative activity in the early stages of an intrusion. Any organization with internet-facing SSH, weak or reused credentials, or default configurations should consider themselves potentially in scope.

What Defenders Should Watch For

• Monitor SSH authentication logs for brute-force or credential-stuffing patterns against exposed hosts.
• Look for anomalous post-login command sequences that gather system/hardware information (e.g., CPU info, memory, disk) shortly after a new or unusual SSH session, which may precede payload deployment.
• Watch for unexpected spikes in CPU utilization or new unrecognized processes consuming sustained compute resources.
• Review outbound network connections for contact with unfamiliar mining pools or C2 infrastructure.
• Harden SSH exposure generally: enforce key-based authentication, disable password auth where feasible, rate-limit or fail2ban repeated login attempts, and restrict SSH access via network controls where possible.

This is based on a single guest diary and reflects one researcher's honeypot/incident observations rather than a fully attributed or widely corroborated campaign; details on scale, targeting, and specific IOCs should be confirmed against the original source. For the full technical account, see the SANS ISC Guest Diary.