Home > Blog > The Redis Rush

The Redis Rush

The Redis Rush

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!

 

 

Share this with your network
FacebookTwitterLinkedInShare