Discover Redigo — New Redis Backdoor Malware

Aqua Nautilus discovered new Go based malware that targets Redis servers. The attack was executed against one of our deliberately vulnerable Redis honeypots (CVE-2022-0543). Our investigation revealed new undetected malware written in Golang designed to target Redis servers to allow the attacking server to dominate the compromised machine. Therefore, the malware received the name Redigo. In this blog, we’ll examine how adversaries exploit this Redis vulnerability and use it to run the new malware. Moreover, we’ll review the attack process and recommend methods to protect against future attacks.

What is Redis?

Redis (remote dictionary server) is an open source in-memory database and cache. It was first released in 2009 as a solution for real-time applications that needed a way to deliver data to their clients faster than a relational database could handle. It allows data fetching and delivery in short response time, allowing millions of requests per seconds. Redis assures responsiveness by using a cache to store frequently accessed data in memory.

Redis Vulnerability - CVE-2022-0543

Redis architecture contains two main processes – Redis client and Redis server. The Redis server constitutes the main part in the architecture. It is responsible for storing data in memory and handles management processes. The server also consists of Lua scripting engine which allows users to upload and execute Lua scripts directly on the server. This ability makes the process very efficient to read and write data from scripts. The engine should be sandboxed so that the interaction with the Redis client will be made using Redis APIs while limiting the client abilities to run arbitrary code on the Redis running machine. However, in 2022 a vulnerability was discovered in the Lua scripting engine. In some Debian packages the Lua library provided a dynamic library. When the Redis server loads the Lua library, it loads a package variable. The package is left in the Lua sandbox and used to call any Lua library. That resulted in a Lua sandbox escape that would allow an attacker to execute arbitrary commands.

Figure 1: attack flow of Redigo malware

The Attacking process

Initial access

Adversaries use scanners or botnets to search for the Redis server exposed to the internet on port 6379. After connecting to the Redis server, the adversaries are able to run Redis commands as follow:

1. INFO command – this command allows adversaries to receive information about our Redis server. Among the data they receive, they now know which server’s version is vulnerable to CVE-2022-0543 (As we explained earlier, the honeypot was built with this vulnerability on purpose). This information provides adversaries with the approval they would need to be able to exploit the vulnerability and allow them to start preparing the surface to exploit it.
2. SLAVEOF command – this allows adversaries to create a replica of the attacking server. This action will later help them download the shared object allowing for the exploitation of the vulnerability.
3. REPLCONF command – this command is used in order to configure a connection from the master (the attacking server) to the replica that just was created.
4. PSYNC command – the new replica runs this command and initiates a replication stream from the master. This connection keeps the replica updated and allows the master to send a stream of commands. The attacking server that is defined as the master uses this connection to download the shared library exp_lin.so to the disk of the replica. Furthermore, this connection can use the adversaries as a backdoor, where in case of interrupts during the connection the replica is reconnects and tries to obtain the part of the stream of commands it missed during the disconnection.
5. MODULE LOAD command – this allows for the loading of a module from the dynamic library downloaded at stage 4 at runtime. This library allows for exploitation of the vulnerability and runs arbitrary commands later.
6. SLAVEOF NO ONE command – this turns off the replication and converts the vulnerable Redis server into a master.

Figure 2: captured communication of Redis commands between the vulnerable Redis server and the attacking server

Execution

The library file exp_lin.so that is loaded by the adversaries executes the code which exploits the vulnerability that was deliberately left in our honeypot. This file contains the implementation of the command system.exec which allows the adversaries to execute an arbitrary command and initiate their attack. The first use of the command is activated to receive information about the CPU architecture. The second use of the command is done to download the newly discovered malware from the attacking server - Redigo. After downloading the malware file, the attackers elevate the permissions of the file to execute, and execute it (for malware investigation read below).

Figure 3: captured communication of malicious commands

Defense Evasion

The adversaries are interested in concealing their activity to avoid being detected. They are doing this by using a seemingly legitimate communication of Redis that simulates communication between Redis cluster using port 6379. However, the communication is being used by the adversaries to transfer commands that will allow them to control the vulnerable server.

Discovery

Adversaries strive to get familiar and learn about the system they have attacked, in this case, our Redis server. This information is valuable to them as they progress with their attack. As we described earlier in the initial access, the adversaries were using the Redis command INFO, which returned information and statistics about our server. Our server returned a response with all the specified information including details about the server, memory, and CPU. This data helps adversaries learn about the target resources. Moreover, after exploiting the vulnerability and escaping from the Lua sandbox, they run the lscpu command on the host to receive information about the CPU.

Command and Control

The dropped malware mimics the Redis server communication which allowed the adversaries to hide communications between the targeted host and the C2 server. After downloading the malware, the roles of the hosts change - our vulnerable Redis server turns into a client while the attacking server is now the Redis server. This relationship allows the adversaries to express the C2 connection between one another as the response of the attacking server will be used as commands for future attacks on the vulnerable Redis server. It simulates a legitimate Redis cluster communication over port 6379. This may help it to evade network sensors detectors. After analyzing the actual communication we learned that the malware was used by the adversaries to control the Redis server in a master-slave relationship.

Impact

We limit the attack duration in our honeypots, and, thus, it is hard to say if we’ve seen the full scope of the impact. Based on similar attacks, we can speculate that when attackers add a targeted host to a large botnet it usually means that the compromised server will take part in a Distributed Denial of Service (DDoS) campaign against target applications and affect their business. Another plausible scenario is to run cryptominers on the targeted host. Furthermore, since this is a database, attackers can exploit the host to steal data or secrets and gain further foothold in the environment. In any case, each scenario can make an impact on the resources of the compromised server which is now used as part of a co-opted system to solve resource intensive problems that may impact its availability to the users who daily use its services.

The newly discovered Redigo Malware

Our investigation of this malware examined two angles – network analysis and malware analysis. The Redigo malware was downloaded from the same server that started the attack on our Redis container. Searching for the IP address in the Shodan engine reveled the server had an open port of Redis – 6379.

Figure 4: details of the attacking server in Shodan

Moreover, while the malware is executed, it creates communication back to the attacking server using port 6379. This increased our suspicion that there could be malicious communication between our Redis server and the attacking server, which turned out to be true since the attacking server turned our Redis server into a slave and created a command-and-control relationship between them. As we can see in one of the communication sessions we captured, after the malware was downloaded, we were able to demonstrate how the communication attempted to conceal itself under legitimate Redis commands:

Figure 5: conversation between the vulnerable Redis and the attacking server

The lines that colored in red represent outbound communication generated by our server while the lines colored in blue represent inbound communication generated by the attacking server. In one of the commands, we can see that the vulnerable Redis server tries to authenticate the current connection using the AUTH command. Further, there are PING-PONG commands – the vulnerable Redis sends a PING command and the attacking server returns a PONG. This is useful when testing whether the connection is still alive.

Deeper investigation of the malware revealed that the file was written in go and included some interesting functions that exposed its real intentions:

Figure 6: Redigo malware functions

The functions above demonstrate different implementations of commands that the malware uses to dominate its servers (the attacked Redis servers). We can see that some of the functions are written to the Redis server in particular which may imply that the adversaries desired to build an adjusted attack that would target Redis servers.

Because Redigo is a new Redis backdoor malware it remains undetected in Virus Total by all vendors:

Figure 7: VirusTotal scan of Redigo malware

Tracing Redigo Malware

As can be seen in the screenshot below from our eBPF-based Aqua Lightning Enforcer, the first event alert was a detection of a shared object loading and deleting. Normally, we shouldn’t see these kinds of events in running Redis servers. This is the .so file (exp_lin.so) that was passed via the Redis communications. Next, we see a new executable drop. This is the binary file redis-1.2-SNAPSHOT, which is the Redigo malware.

Figure 8: Detection view in the Aqua Platform Incident Screen

Next, we see a second payload and events of outbound traffic (socket_create and socket_connect).

Figure 9: logs from Tracee

Above you can see the how these events look like when using Aqua Tracee, Aqua’s open source runtime security and forensics tool for Linux.

Tracee captured this malware’s activity (process name: redis-1.2-SNAPSHOT):

1. security_socket_create: the malware creates a socket, which is an endpoint for communication
2. security_socket_connect: the malware initiates a connection on a socket to the adversaries' server (45.41.240.51) using port 6379.

This led us to further investigate the binary and to reach the conclusion that it was designed to disguise command and control communication as legitimate Redis communication.

This novel malware provides a great example showing the full scope of Aqua's new Lightning Enforcer and runtime protection solution. In this case, we observed novel malware dropped during runtime on our server. As can be seen in the Virus Total scan, conventional tools such as anti-virus didn’t mark this tool as malicious. While our Lightning Enforcer based on eBPF technology was able to detect this behavioral anomaly and alert us about malicious activity. Normally, an .so file shouldn’t be loaded in runtime. Additionally, we shouldn’t see files dropped in runtime in container environments.

Protect from Future Threats

We are standing before a new threat, backdoor malware first seen in the wild. These adversaries were using seemingly innocuous communication with the Redis protocol while building a botnet network and then converted our Redis server into a slave to execute the master’s commands. The attack was successful thanks to the vulnerability these adversaries exploited in our server.

To cope with these types of threats, we recommend following these guidelines:

• Unknown threats and zero-days are here to stay. Even if you do everything right you can’t always protect your runtime environments from such attacks. Thus, you need to monitor runtime environments. Runtime monitoring is a fundamental practice to help mitigate issues quickly and minimize disruptions. The monitoring process also applies to the runtime environment where suspicious activity can occur (e.g., download of malicious binary files).
• Harden your environments to prevent running undesired Redis commands such as slaveof.
• Scan your supply chain. You can use open source tools such as Chain-Bench designed to audit your software supply chain stack for security compliance based on a new CIS Software Supply Chain benchmark.
• Empower your developers, DevOps and security teams with tools that scan for vulnerabilities and misconfigurations. Along with Aqua’s tools for organizations, you can find particular open-source tools such as Trivy to scan for such vulnerabilities. The Aqua platform scans container images with tools that rely on a constantly updated stream of threat intelligence - aggregate sources of vulnerability data (CVEs, vendor advisories, and proprietary research) which ensure up-to-date, broad coverage while minimizing false positives.

Indicators of Compromise (IOCs)