The Redis Rush

Chris Hall
Cloud Security Researcher, Lacework Labs

Redis has been heavily targeted for years and recent activity shows it is more popular than ever with attackers. There are several reasons for this: zero security for the base image, easily discoverable, and easily exploited. This makes Redis the ultimate low-hanging-fruit when targeting cloud infrastructure. This blog provides trending on Redis targeting in the wild and includes indicators and tools that you can use for your own threat intelligence purposes.

The ease with which Redis can be exploited means that a successful attack often depends on how quickly vulnerable hosts can be scanned and identified. To that end, there are numerous attackers rushing to be the first to take over your newly spawned Redis container. While a honeypot would demonstrate this, we found Shodan to be a more useful tool especially for identifying attackers. 

If a Redis server is open to the internet, then scanners such as Shodan can connect and send an ‘info’ command which returns the server’s full configuration data. This data includes records of connected clients which can allow us to derive indicators on attackers. For example,  attacker hosts can be identified by searching for the Redis ‘master_host’ value in the info output. 

In many cases, these master hosts are actually “rogue servers” meaning they were configured by an attacker. (Examples of this tactic can be found on Github) Establishing a rogue server can enable a shell and/or the ability to run a payload on the Redis host. In most cases this payload consists of a cryptomining installer. Figure 1 shows this data as it’s presented in the Shodan interface.

Figure 1. Rogue servers, clients & commands

Redis scanners are also observable in the connected clients portion of Redis information. By inspecting the cmd parameter in the client connection record (in Figure 1), we can see if the host simply just connected to the server port (6379) or attempted to run commands with the Redis cli. For example, also in Figure 1, IP address 119.45.34.13 was observed issuing a ‘flushall’ command. The flushall command deletes all the keys for the existing databases so this suggests the attacker attempted to drop their own SSH key onto the Redis server. By filtering on these commands, the legitimate scanners can be distinguished from the likely attackers.

Using the Shodan API, we first identified all reported hosts. Currently, there are over 30K however many do not contain any Redis configuration data. To filter those ones out you can run the following:

Shodan query	description
port:”6379″ “Connected Clients”	finds Redis with Client Connections
master_host port:”6379″	finds Redis replication data and lists master host

Table 1. Redis Queries

Our Redis collection tool shows the IP, the number of unique Redis servers the host connected to, as well as the issued commands. In total 43005 IPs were extracted from Redis client connection data in Shodan. The IPs seen connecting to the most servers were either not observed issuing any commands or they only sent an ‘info’ command to return the configuration. Filtering these mass scanners out leaves 33K hosts seen issuing one or more Redis commands. Another good filter is the number of unique Redis servers. If the host sent commands to three or more servers then there is higher probability the IP is engaged in offensive operations.

Redis scanner	Targeted servers	lastseen	ports	commands	asn	country
193.106.30.23	1316	9/26/2020 0:00	(high ports)	none	50297:Infium, UAB	Ukraine
193.118.53.218	1010	9/26/2020 0:00	(high ports)	info	21859:ZNET	Germany
202.107.226.5	1004	9/26/2020 0:00	(high ports)	info	4134:Chinanet	China
192.35.169.48	976	9/26/2020 0:00	(high ports)	none	237:MERIT-AS-14	United States
202.96.99.83	940	9/26/2020 0:00	(high ports)	info	4134:Chinanet	China
183.129.159.243	824	9/26/2020 0:00	(high ports)	info	4134:Chinanet	China
202.107.226.3	811	9/26/2020 0:00	(high ports)	info	4134:Chinanet	China
183.129.159.245	799	9/26/2020 0:00	(high ports)	info	4134:Chinanet	China
45.148.122.152	781	9/26/2020 0:00	(high ports)	info config slaveof get	64425:SKB Enterprise B.V.	Netherlands
202.107.207.226	766	9/26/2020 0:00	(high ports)	info	4134:Chinanet	China

Table 2:. Redis client data and commands

The following shows the most frequently observed Redis commands. The client command was by far the most common. There are several tasks related to this command and it is unclear what actions were being performed. The command can be used to list and kill connections so it may have been leveraged to identify and terminate connections from competing attackers which is a common tactic in cryptojacking campaigns. 

Figure 2. Commands from Client connections

Mapping client IPs to ASN data and host country revealed the leading sources for Redis scanning. At the top of the list is ASN 4134 Chinanet aka No.31 Jin-rong Street. This ASN also accounts for a large portion of general scanning, botnet activity, and targeted attacks. In total, a quarter of all client connections originated from China. If you only count the high confidence hits (3 or more connections) then that increases to 60%.

Figure 3. Source ASNs

More interesting outputs from Shodan include rogue Redis servers which can be gleaned from the master host data. While there are tens of thousands of Redis scanners out there, the lion’s share of vulnerable instances appears to have been exploited by a small few. Among the 1254 compromised Redis instances reported via Shodan, only 11 rogue servers were identified. And between those there only appears to be 2-3 sets of activity including hosts attributed to prolific cryptojackers known as Kinsing. In a previous blog, we reported on a Kinsing rogue server with a master port of 8886. This port is still in use and there have been at least 331 Redis instances in communication with 7 Kinsing rouge servers over the past 30 days.

rogue server	Redis instances	lastseen	ports	asn	cc
45.148.122.152	691	9/26/2020 0:00	random high ports	64425:SKB Enterprise B.V.	Netherlands
165.227.102.206	122	9/26/2020 0:00	random high ports	14061:DIGITALOCEAN-ASN	United States
195.123.246.63	105	9/13/2020 0:00	[8886]	204957:ITL-Bulgaria Ltd.	Czechia
45.148.122.184	102	9/26/2020 0:00	random high ports	64425:SKB Enterprise B.V.	Netherlands
195.123.228.32	66	9/1/2020 0:00	[8886]	59729:ITL LLC	Bulgaria
5.34.183.14	45	9/23/2020 0:00	[8886]	15626:ITL LLC	Ukraine
45.10.88.124	42	9/26/2020 0:00	[8886]	48693:Rices Privately owned enterprise	Ukraine
93.189.42.250	31	9/22/2020 0:00	[8886]	41853:Limited Liability Company NTCOM	Russia
45.153.231.22	26	9/21/2020 0:00	[8886]	44094:Webhost LLC	Russia
5.34.183.145	20	9/23/2020 0:00	[8886]	15626:ITL LLC	Ukraine
144.217.207.15	4	9/16/2020 0:00	[1323]	16276:OVH SAS	Canada

Table 3: Rogue server data

Two other rouge servers within the same subnet (45.148.122.0/24, 64425:SKB Enterprise B.V.) have been linked to 794 Redis compromises. Unlike Kinsing, these are using random high ports. Multiple hosts within the 45.148.122.0/24 subnet have also been linked to scanning and Mirai activity and the IP 45.148.122.152 was also observed as top scanner in Table 1.  The third possible set of activity is also leveraging high ports for their rouge server: 165.227.102.206 (14061:DIGITALOCEAN-ASN). This host also appears to be cryptojacking related as its been observed hosting a known cryptomining payload dubbed “kpsmoused.” Figure 5 illustrates these rouge servers. 

Figure 4. Rogue Servers

So long as Redis remains easy to exploit, then we can expect the same level of targeting to continue. This is especially true when deploying Redis via Docker containers. Since version 3.2.0, Redis enters ‘protected mode’ upon installation. Protected mode only allows connections from loop-back interfaces to prevent exposure to the internet. 

Unfortunately, protected mode is disabled by default in the Redis Docker image. Although there is a warning about this in Redis’ Docker documentation, it is clearly not sufficient to prevent unauthorized access. This makes it more important than ever to lock down your Redis instances!

Indicators sourced for this blog are available here. We recommend you periodically run the Redis collection script to generate a recent list. If you found this blog useful then please share and follow us on Twitter!