HeadCrab

What it is

HeadCrab goes after Redis database servers left open to the internet, on virtual machines and in containers. It loads itself into Redis as an add-on, mines cryptocurrency and gives the attacker a backdoor. It runs from memory rather than from files on disk, takes over Redis's own commands, hides the output of its loading, and can load kernel modules (add-ons that run inside the core of the operating system) straight from memory. That's why a server with HeadCrab can't be trusted to check itself.

How it gets in

Through Redis servers reachable from the internet with no password, or with settings left too open.

Close the door: Do not expose Redis to the internet or to untrusted clients. Enable protected mode, restrict listening addresses with the bind setting, and disable the replication feature (slaveof/replicaof) if it is not used.

How to tell if you have it

Signs published for this threat. One sign alone proves little: names get reused, and newer versions change them. Look for several together.

These commands only look. They change nothing.

Look for the known file locations

sudo ls -la /dev/shm/rupd /etc/ice9j /etc/init.d/ice9j 2>/dev/null

List running programs that live in a temporary folder (real software almost never does)

sudo ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E '/(tmp|var/tmp|dev/shm)/'

Check the known startup entries, wherever they are installed

systemctl list-unit-files --no-pager 2>/dev/null | grep -F -e 'ice9j'; sudo ls -la /etc/init.d/ice9j 2>/dev/null

How sure these signs are: HeadCrab runs from memory and hides inside Redis, so a check run on the infected server can miss it, and finding nothing does not prove the server is clean. The 2024 version dropped the extra Redis commands the 2023 version added and hijacks normal ones instead, so checks for the older commands miss it. /dev/shm/rupd is deleted right after use, so not finding it proves nothing. The add-on's name has never been published: any Redis add-on you didn't install, shown by MODULE LIST or a loadmodule line in the Redis settings, is the sign. Its startup entry ice9j poses as an SSH service, so check what it actually runs. No SHA-256 fingerprints have been published. These signs come from 2023 and 2024 reports.

How to deal with it

Removing it in place isn't safe. Here is what to do instead, in order:

1. Don't try to clean it in place. Removing the loadmodule line and restarting Redis isn't enough: researchers report the attacker keeps other powers afterwards, including loading kernel modules.
2. Cut the server off from the internet, but keep a way to log in, such as your hosting provider's web console. Save evidence: the Redis settings file and its loadmodule lines, the Redis data folder, /etc/ice9j, /etc/init.d/ice9j, your systemd services, and a copy of memory if you can. From a trusted computer, run MODULE LIST against the server and note any add-on you didn't install.
3. Copy off your data. Don't copy programs, Redis add-ons, systemd services or startup scripts; any of those could bring it back.
4. Reinstall from a fresh image, install all updates including Redis, then restore only the data you copied and checked.
5. From a clean computer, change every password, SSH key and token that was on the server, and cancel the old ones.
6. Before you reconnect, keep Redis off the internet and away from untrusted computers: turn on protected mode, use the bind setting so it listens only on trusted addresses, and turn off replication (replicaof or slaveof) if you don't use it.

What Minaki Scan does about it

Related threats

Sources

This page is written by MinakiLabs in our own words. The facts above come from this published research; credit and thanks to its authors.

• SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops, NIST (2013-07)
• HeadCrab 2.0: Evolving Threat in Redis Malware Landscape, Aqua Security (2024-01-29)
• HeadCrab: A Novel State-of-the-Art Redis Malware, Aqua Security (2023-02-01)