SSH Bot Profiles Server Hardware Before Deploying Cryptomining Malware

A honeypot operated by a SANS.edu intern has captured a rare glimpse into the “pre-sale” phase of cryptojacking operations, revealing an automated SSH bot that meticulously inventories a compromised machine’s hardware.

Checks its privilege level, and then walks away without deploying any malware, likely to determine first whether the target is even worth mining on.

The session, logged on 27 June 2026 by researcher Adam Cann on a DShield sensor running the Cowrie SSH honeypot, lasted roughly eight seconds.

SSH Bot Profiles Server Hardware

The bot authenticated as root using the password “123123” on its first attempt, ran two commands, and disconnected. No files were downloaded. No payload was executed. To an automated triage system, that pattern might look like noise. Cann argues it’s the opposite.

Rather than the typical download-and-run one-liner seen in most opportunistic SSH compromises, this bot executed a structured reconnaissance routine.

It collected the operating system and kernel version, CPU architecture, core count, and CPU model. It then ran lspci, specifically searching for an NVIDIA graphics card, and pulled system uptime and recent login history via the last command.

Every result was written out as labeled fields, such as UNAME, ARCH, CPUS, CPU_MODEL, and GPU, formatting clearly designed for automated parsing rather than human review.

A second command checked /proc/meminfo to confirm the host had more than 1 GB of RAM, executed through sudo -S to simultaneously test whether the stolen root password would grant privilege escalation without a prompt.

The SSH client identified itself as SSH-2.0-Go, a signature consistent with a custom automation tool rather than a standard terminal client, reinforcing that this was a scripted evaluation process rather than manual attacker activity.

The specific combination of checks is the giveaway. A denial-of-service botnet has no interest in GPU models or core counts. But an operator planning to deploy cryptomining malware absolutely does, since mining profitability depends entirely on available compute power.

By grading hardware before committing a payload, the attacker avoids wasting infrastructure on machines too weak to be profitable.

Cann distinguished this campaign from an unrelated DDoS-recruitment loader observed on the same honeypot earlier in the month by comparing HASSH fingerprints, a technique for identifying SSH clients based on their negotiation behavior.

Despite both campaigns exploiting the same weak-password vulnerability, their distinct fingerprints confirmed that they were operated by separate operators.

The central finding here challenges a common triage assumption: that sessions dropping no malware are low-priority. Cann’s analysis suggests that recon-only sessions often constitute the first half of a two-stage attack, in which the operator returns later with a tailored payload once a target has been qualified.

Security teams and system administrators can defend against this and similar campaigns by taking several concrete steps:

Enforce strong, unique credentials, since the entire chain begins with a guessable root password
Disable root SSH login and require key-based authentication, which also neutralizes the sudo password-reuse tactic
Deploy rate-limiting tools like fail2ban to block repeated login attempts
Restrict SSH exposure to VPNs or allow-listed IP ranges rather than the open internet
Alert on bulk hardware discovery commands, particularly GPU searches and memory threshold checks
Monitor previously “cleared” hosts for delayed follow-up activity, including unexpected CPU/GPU load or mining pool connections

Indicators of Compromise: Source IP 91.92.40.13 (ASN 197170, Netherlands); SSH client SSH-2.0-Go; HASSH 2ec37a7cc8daf20b10e1ad6221061ca5; credentials root/123123.