Redis Compromise: Lacework Detection

Dan Hubbard
Chief Product Officer, Lacework

Recently we published a blog on the internals of a Redis compromise with an infection on one of our external-facing honeypots and this is a follow up which demonstrates how the Lacework service would help identify the attack at a variety of stages in the attacker life-cycle. As I outlined in a previous blog about the importance of understanding your risks and threats when it comes to securing your public cloud, we are breaking things down into these categories below.

Stage 1: Identifying the Risk

In this particular case, one of our honeypots was exposed to the Internet with no inbound filtering by port. Our Redis server was listening on the appropriate Redis port. Unfortunately, this happens in the real-world more than one would expect. According to Shodan, there are more than 20,000 internet-facing Redis servers today.

Within Lacework we see this activity occur in a number of ways. First of all when the insecure Security Group is setup, the user is immediately notified of the risk. Below is an example of these alerts from the Lacework UI:

Additionally, the audit and compliance report will identify known risks to your environment:

Stage 2: Identifying Risk, Reconnaissance

One key tool of an attackers trade is the ability to identify open, accessible, vulnerable machines on the Internet for their taking. In stage 1 we identified that you have little to no restriction on your outward facing firewall rules. In stage 2 we identify that outsiders are attempting to connect and identify those servers.

Lacework UI screenshot of external known bad IP’s:

Not only do we identify this at the network layer but we also give you application visibility within your containers on the actual specifics themselves.

Lacework UI screenshot applications and processes running on the target machine and listening ports:

Lastly, in this stage, we also notice that there are brute force attacks happening against the target machine in addition to attempts to exploit Redis.

Lacework UI screenshot of brute-force attempts:

Stage 3: Successful Exploitation

In this stage, we move from identifying, alerting, and demonstrating the risks of identifying and providing context to the threats. The first identified threat was the successful exploitation of the Redis service. We identified this from watching the applications and network behavior directly on the deployed container itself. The first noticed anomaly identified was a new binary was installed by the Redis user.

Lacework UI screenshot on new alert for Redis user:

Stage 4: Running payload and updating code

Typically once exploitation of a service is complete attackers need to connect out to download and run the additional malicious code. You can see this in the next stage in the UI as they then used curl to download additional code.

Lacework UI of payload running and updating:

Stage 5: Identifying the modus operandi and more code

Although, as you will see in an upcoming blog, there is more to this attack as we continue to collect details, in this particular case the attackers motive becomes clear in that they install a Monero miner that is set up to mine and connect to a mining pool.

Lacework UI screenshot, identifying the cryptomining destination domain:

Putting it all together

In events such as these its critical to not just identify the risks as early as possible but, when there is successful exploitation, that the events are tied and correlated together in order to put the pieces together in totality. This helps extremely in triage and mean-time-to-remediate. For this, we use something called “related events” which maps all the related events in a timeline.

Lacework screenshot UI of related events: