How a Redis Server Got Hijacked and What You Can Do to Prevent It

Hijack Incident

A Redis service across development, testing, and production servers suddenly stopped, severely impacting development and online environments, prompting a deep dive into security investigation.

Investigation Steps

Checked Redis services on all servers (dev:251, test:204, prod:164,165); many were not running.

Verified Redis processes using ps -ef | grep redis and confirmed connectivity with Redis Desktop Manager.

Attempted to restart Redis with ./redis-server & after killing the existing process ( kill -9 PID), but the service failed to start.

Discovered a malicious process consuming high CPU via top, suspected to be injected via cron or startup scripts.

Examined crontab entries, removed suspicious tasks, and deleted malicious files such as /var/spool/cron/root, /var/spool/cron/crontabs/root, ~/.ssh/authorized_keys, and temporary files in /tmp.

Downloaded and analyzed pm.sh from the attacker’s site to understand the payload, confirming a mining operation.

Deleted all identified malicious files and Redis dump files ( /tmp/dump.rdb, /usr/local/redis/bin/dump.rdb, /var/spool/cron/dump.rdb), then successfully restarted all Redis services.

Redis Protection Recommendations

Do not use the default port 6379.

Configure a Redis username and password.

Bind Redis to specific IP addresses in redis.conf.

Keep Redis servers off the public internet.

Enable firewall rules (e.g., iptables) to restrict access.

Run Redis inside containers (Docker, etc.) for easier recovery and isolation.

References

CentOS7 installation Redis hijacked by AnXqV mining program.

Alibaba Cloud server mining intrusion solution.

Google infrastructure security design overview (translation and guide).

Dockerized Codis and Pika as Redis alternatives.

Conclusion

Security is paramount; thorough investigation and prioritizing a stable development environment are essential to mitigate and prevent similar incidents.