Why Containers Are Sweet Targets for Ransomware Attacks

Why Containers Are Sweet Targets for Ransomware Attacks

Ransomware and other attacks are becoming increasingly common, as black hats discover how cloud native and other newer platforms can serve as softish targets. With the recently revealed Docker runtime exploit as an example of what can go terribly wrong, the pressure is obviously on security providers to stay ahead of the game — but finding the right solution for this new world of computer protection can mean the difference between a thriving architecture, or in the worst case, a complete shutdown of an organization’s operations.

What to look for in the way of security solutions for cloud native, as well as serverless and more mature platforms were the main subjects in this episode of The New Stack Makers podcast with Neil Carpenter, a solutions architect for Twistlock, hosted by Alex Williams, founder and editor-in-chief of The New Stack.

The obvious and sometimes overlooked assumption is attackers will seek the easiest targets. Previously, Carpenter described how desktops were especially vulnerable ransomware targets before moving into some server environments, culminating in especially nefarious attacks in the healthcare and education sectors in 2016 and 2017.

“This was a way to monetize these attacks,”  Carpenter said.

Still, ransomware attacks are challenging to orchestrate. Carpenter described how an attacker’s attempt to run malware on a desktop, for example, in order to encrypts all of the documents and data until the victim buys pays a ransom in Bitcoin or another cryptocurrency.

But finding a Kubernetes cluster with an unauthenticated endpoint or an unpatched vulnerability on a Docker server accessible with an Internet connection represents a particularly attractive target.

“[As an attacker], I can drop my crypto miner directly on what you’re running and schedule it to run on your Kubernetes cluster and then I don’t have to deal with helping you figure out how to buy Bitcoin and get it to me. I just run my miner and it runs on your CPU and takes up,” Carpenter said. “I think, for an attacker, it’s elegant, (which is probably not really the word I’m looking for), but it’s simple and a lot simpler than the other approaches that they had to monetize that sort of attack.”

With Twistlock’s Runtime Application Self Protection (RASP) Defender, the idea was to embed security capabilities within applications as opposed to offering external — and more unwieldy and less-effective — protection for Kubernetes and containers running in cloud-native environments, as well as for serverless and other platforms, Carpenter said.

“So, the idea is we’re taking those protections and instead running them on these hosts that you own, since we’re baking them into the application itself and into the code that you are deploying, so that wherever that runs, it gets that same level of protection and visibility,” Carpenter said. “You can automate this into your pipeline as you deploy it and then protect those workloads.”

The idea is to limit the extent to which your developers have to manage to embed this into the code itself, Carpenter said.

“So, instead, this is conceptually a wrapper around the things that they’re deploying instead of having to really change your development processes and change the approach that you’re taking,” Carpenter said. “What we’re doing is giving you the tools to wrap these things with the RASP Defender and then deploy them in random wherever they go.”

In this Edition:

1:09: What is RASP Defender.
6:17: How you use RASP Defender as a wrapper for a Fargate task
10:43: Think about this differently with different cloud services.
12:22: Deploying containers in more distributed environments?
14:25: Some tips.
18:21: How to think about RASP Defender.