The SANS ISC diary on an SSH bot performing hardware reconnaissance before deploying a miner highlights an important point: not every malicious login immediately drops malware, but that does not make it harmless.

The observed session involved an automated SSH bot logging in as root using the weak password `123123`. Instead of immediately downloading malware, the bot collected system information, checked hardware capacity, looked for an NVIDIA GPU, tested memory size, checked uptime, reviewed recent logins, and tested whether it could elevate through sudo.

That behavior is significant. A simple botnet infection usually logs in, downloads a payload, runs it, and moves on. This bot was more selective. It first measured the target. It wanted to know whether the machine had enough CPU, memory, GPU capability, and privilege level to justify deploying a cryptominer later.

This is a useful reminder for defenders: reconnaissance is part of the attack, not background noise. A session that “only ran a few commands” may still be the first stage of compromise. Attackers often inspect the environment before deciding what payload to deploy, whether the host is worth monetizing, or whether to hand the target to another tool.

Cryptomining attacks depend on economics. Attackers want compute power. CPU cores, RAM, GPU presence, uptime, and root privileges all help determine whether the target is profitable. If the system is too small or unstable, the attacker may skip it. If it looks valuable, the attacker may return later with a miner.

The NVIDIA GPU check is especially telling. GPU resources are valuable for mining and other compute-heavy abuse. A bot that checks for graphics hardware is not randomly curious. It is estimating how much money it can squeeze from someone else’s electricity bill, because apparently even malware now has a business model spreadsheet.

For organizations, the biggest lesson is that weak SSH credentials remain a major entry point. The entire session began because the bot could log in as root using a predictable password. No zero-day was required. No advanced exploit was needed. Just a weak password and an exposed SSH service. Humanity has built cloud infrastructure, AI agents, and quantum research, yet `root/123123` still gets invited to the party. Grim little achievement.

Internet-facing SSH should be treated as high risk. Servers should not allow root login over SSH. Password-based SSH access should be disabled wherever possible, and key-based authentication should be used instead. Administrative access should be restricted through VPN, bastion hosts, zero-trust access, or known management IP ranges.

Rate limiting and brute-force protection are also important. Tools such as fail2ban or equivalent controls can block repeated login attempts. However, rate limiting alone is not enough if a password is weak enough to succeed on the first try. Strong unique credentials and disabled root login remain essential.

Organizations should also monitor successful logins, not only failed attempts. Many teams focus on brute-force failures but miss the moment an attacker actually gets in. A successful login from an unusual IP address, followed by hardware discovery commands, should be treated as suspicious.

The commands matter. Defenders should watch for activity such as `uname`, `lscpu`, `nproc`, `cat /proc/cpuinfo`, `cat /proc/meminfo`, `lspci`, checks for NVIDIA hardware, `uptime`, `last`, `whoami`, `id`, and sudo tests immediately after login. These commands are normal for administrators, but unusual when executed automatically by unknown external sources right after SSH authentication.

This is where context is everything. A system administrator checking CPU details during maintenance is normal. A new SSH session from an unfamiliar IP, using a weak account, running a rapid hardware survey, then disconnecting in seconds is not normal. Security monitoring should distinguish between those two patterns instead of treating both as harmless command-line noise.

Client fingerprinting also matters. The diary notes that the bot identified itself as a Go-based SSH client and used a distinct HASSH fingerprint. HASSH can help defenders connect related SSH activity even when attackers change source IP addresses. That is useful because bot operators often rotate infrastructure, proxies, and infected hosts. Fingerprints can reveal continuity behind the rotation.

Security teams operating honeypots or monitoring exposed SSH services should track source IPs, usernames, passwords attempted, SSH client banners, HASSH fingerprints, command sequences, session duration, and whether the session drops malware or performs reconnaissance only. Recon-only sessions can become early-warning indicators.

Organizations should also monitor for follow-up activity. If a host passes the attacker’s “hardware grading” stage, a later session may deliver a miner. Defenders should watch for sudden CPU or GPU usage spikes, unknown processes, suspicious cron jobs, strange systemd services, outbound connections to mining pools, unfamiliar binaries in temporary directories, and processes trying to hide their names.

Cloud environments are especially exposed to this type of abuse. A compromised cloud VM with enough CPU or GPU capacity can generate direct financial loss through compute charges. Attackers do not pay the bill, which is usually their favorite pricing model.

GPU instances deserve special protection. Cloud GPU systems used for AI, rendering, research, simulation, or development can be expensive. If exposed with weak SSH credentials, they become attractive targets for mining and resource theft. A miner running on a GPU instance can burn money quickly while pretending to be “just high utilization.” Delightful, if your hobby is invoice trauma.

Organizations should enforce cloud guardrails. Security groups should restrict SSH exposure, root login should be disabled, instance metadata access should be controlled, admin keys should be rotated, and alerts should trigger on unusual CPU/GPU utilization, outbound mining traffic, and unauthorized SSH access.

Endpoint and server monitoring should include process behavior, not just malware hashes. Miners may be packed, renamed, downloaded from changing URLs, or compiled for different architectures. But their behavior often gives them away: high sustained CPU or GPU usage, connection to mining pools, creation of persistence, attempts to kill competing miners, and use of temporary directories.

The diary also shows why “no payload dropped” should not be a comfort. Attackers may separate reconnaissance from payload delivery to reduce noise, avoid wasting payloads, improve targeting, or evade simple detection. A quiet first session may be the scouting phase before a more damaging second stage.

Incident response should treat unauthorized SSH access as compromise, even if no malware is visible. The system should be isolated, logs preserved, credentials rotated, SSH keys reviewed, sudoers checked, persistence locations inspected, and running processes examined. If the attacker logged in as root, the safest path may be rebuild from a known-good image.

Organizations should also check whether the same weak credentials exist elsewhere. Bots that find one working password often try it across other systems. A single exposed weak root password may indicate broader password hygiene failure.

For administrators, the practical controls are straightforward: disable root SSH login, disable password authentication where possible, use SSH keys, enforce MFA through a controlled access layer, restrict source IPs, patch systems, remove unused accounts, rotate old credentials, and monitor successful logins.

For SOC teams, detection should include reconnaissance patterns. Alert on rapid hardware inventory commands, privilege checks, GPU discovery, memory checks, and recent-login inspection following external SSH access. These behaviors can indicate cryptomining triage before payload delivery.

For leadership, the business lesson is simple. Resource hijacking is not just a technical nuisance. It can increase cloud bills, degrade performance, damage availability, expose credentials, create persistence, and indicate broader access-control weakness.

The key lesson is that attackers are becoming selective. They do not always infect every system immediately. Sometimes they grade the asset first, decide whether it is profitable, and return later.

A recon-only SSH session should be treated as an early warning. If an unauthorized actor can log in, the damage has already started, even if the malware has not arrived yet.

Organizations should close exposed SSH access, eliminate weak passwords, disable root login, monitor successful authentication, investigate hardware-discovery behavior, and hunt for follow-up mining activity.

The attacker in this case did not drop a miner because it first wanted to know whether the machine was worth mining. Defenders should be at least as curious about unauthorized reconnaissance as the attacker was about the hardware.

[This is a Guest Diary by Adam Cann, an ISC intern as part of the SANS.edu BACS program]

Source: Reconnaissance First: An SSH Bot That Sizes Up Your Hardware Before Deploying a Miner [Guest Diary], (Thu, Jul 30th) via SANS Internet Storm Center — published 30 Jul 2026.