A new SSH bot has been caught quietly logging into Linux systems, profiling their CPU, GPU, and memory, and then walking away without dropping any visible payload.

The behavior looks harmless at first glance, yet everything about it points to carefully staged cryptomining activity waiting for the right hardware target.

Instead of rushing to install malware, this bot takes time to weigh whether a compromised host is powerful enough to be worth mining on.

The activity came to light when a DShield honeypot recorded an automated login that behaved very differently from the usual noisy password-guessing and one-line loader scripts.

In a single session, the bot logged in as root, ran just two commands, profiled the host, tested for privilege escalation, and disconnected within seconds.

Analysts from the Internet Storm Center noted that this “recon only” session delivered no miner at all, which made the reconnaissance itself the most interesting part of the attack.

According to the report, the SSH bot connected from a single IP address, authenticated using a weak root password, and identified itself using a Go-based SSH client instead of a standard terminal.

Internet Storm Center said in a report shared with Cyber Security News (CSN) that the entire interaction lasted around eight seconds, leaving behind no binary, no persistence hook, and no obvious second stage for defenders to dissect.

This pattern fits into a wider trend where attackers move beyond “infect anything they can reach” and instead tune their campaigns to maximize return on compute resources.

Similar behavior has been seen in other campaigns that hijack Linux servers and cloud workloads for Monero mining, often after gaining access through weak SSH credentials or misconfigured services.

Readers looking to explore related threats can review how attackers reuse weak SSH credentials to mine Monero.

SSH Bot Profiles Linux CPU, GPU and RAM

Once the bot lands on a host, it does not immediately download a miner; instead, it runs a hardware survey to gauge the machine’s capabilities.

The script collects the operating system and kernel version, CPU architecture, number of cores, and detailed CPU model information, then labels each value with tags such as UNAME, ARCH, CPUS, CPU_MODEL, GPU, and LAST.

That structured output is exactly what an automated controller would consume later to filter out low-powered devices and focus on the most profitable targets.

The bot also runs lspci to search for a discrete graphics card, explicitly checking for an NVIDIA GPU that could accelerate mining workloads.

In addition, it measures system uptime and pulls recent login history, giving the operator a sense of how stable and actively used the host is before committing to a heavier payload.

Readers interested in broader Linux cryptomining behavior can compare this tactic with campaigns that weaponize PAM to hide miners, where attackers go straight from access to stealthy mining.

The second command focuses on memory and privilege. The bot reads /proc/meminfo, checks whether total RAM exceeds roughly 1 GB, and pipes that test through sudo using the same password it just used for root, effectively probing whether it can elevate without prompting.

Counting CPU cores, inspecting the CPU model, hunting for NVIDIA GPUs, and enforcing a minimum RAM threshold is classic cryptomining triage rather than denial of service preparation or casual snooping.

Internet Storm Center analysts emphasize that no payload in the first session does not mean no attack is coming.

Instead, the recon-first model lets operators grade a host now and return later with a tailored miner or hand off the target to another tool if the hardware passes their thresholds.

A similar pattern appears in other campaigns where attackers hijack Linux environments worldwide for crypto mining, again after brute forcing SSH or exploiting exposed services.

The recon session, condensed (Source - Internet Storm Center) — The recon session, condensed (Source – Internet Storm Center)

The original report shows a condensed view of the recon session, from login through hardware inventory and privilege test to clean exit.

The recon-first model (Source - Internet Storm Center) — The recon-first model (Source – Internet Storm Center)

The recon-first model in which the attacker evaluates potential victims, decides whether a miner is worth deploying, and only then proceeds with a second-stage payload.

Why recon-only SSH sessions matter

The honeypot operator notes that another, separate SSH campaign targeted the same sensor earlier in the month, using a loader chain that downloaded an ELF binary and joined a denial of service botnet.

That campaign rotated through different IP addresses and command and control servers, but its HASSH fingerprint remained constant, making it easy to group those sessions together.

In contrast, the mining-oriented recon bot presented with a different client and HASSH, indicating a distinct actor and reinforcing how client fingerprints help defenders separate overlapping campaigns.

This distinction highlights a key defensive lesson: sessions that never drop files can still represent the first half of a serious compromise.

Treating discovery-only logins as harmless background noise means missing the scouting pass that may precede a much louder follow-up carrying miners or other payloads.

For a broader perspective on automated SSH attacks, readers can examine how a self propagating SSH worm forms botnets, again showing how fast weak credentials can be abused.

The report recommends several basic steps to blunt this kind of activity, starting with strong, unique passwords to block trivial root logins.

Disabling direct root SSH access and preferring key-based authentication removes the exact route this bot used and frustrates its attempt to reuse passwords in sudo.

Rate limiting SSH logins, restricting exposure through VPNs or known IP ranges, and alerting on bulk hardware discovery all increase the chances that such recon sessions will be spotted and investigated instead of ignored.

Monitoring for follow-up activity is equally important. If a host passes the bot’s grading test, a later session may quietly deploy a miner, drive sustained CPU or GPU usage, and connect out to mining pools using otherwise legitimate network protocols.

Combining SSH client fingerprints, behavioral patterns, and anomaly detection around resource use gives defenders a better chance to connect the dots between a silent recon pass today and an active cryptomining operation tomorrow.

Indicators of Compromise (IoCs):-

Type	Indicator	Description
IP address	91.92.40.13	Source IP observed logging into the honeypot and running hardware reconnaissance commands.
SSH client	SSH-2.0-Go	Go-based SSH client string used by the bot during the recon session.
HASSH	2ec37a7cc8daf20b10e1ad6221061ca5	SSH client fingerprint associated with the recon-first cryptomining bot.
Credentials	root / 123123	Weak root password combination used to gain access to the target system.
Behavior pattern	Hardware survey and sudo test	Bulk hardware survey, /proc/meminfo RAM check above 1 GB, and sudo -S privilege test behavior.

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Building Resilience Against Phishing & Malware and Analyze it in a safe environment – Power your SOC with ANY.RUN

The post SSH Bot Profiles Linux CPU, GPU and RAM Before Deploying Cryptocurrency Miner appeared first on Cyber Security News.