Blog

Silent But Deadly: Cloud Security and Cryptomining

The crypto currency frenzy at the end of 2017 is well behind us, and the bubble has burst, but that doesn’t mean that you shouldn’t be paying attention to this anymore. Especially if you run any of your compute infrastructure in a public cloud provider, especially using Amazon’s AWS, there are potential risks that require continuous, automated detection in order to protect your environment and/or data.

Crypto and your cloud infrastructure…you might ask how these two things connected and what does it have to do with your cloud security needs?

Most concerns about securing your infrastructure are focused on your public facing servers and services, and making sure these have the typically recommended layers of security most security teams are familiar with. However, running your servers and services in a public cloud infrastructure has opened up a whole new attack surface in the form of the API.

Attackers are still searching for servers running vulnerable or misconfigured versions of software to exploit and do whatever they can to get access to your data or resources. However attackers have started using the oldest type of vulnerability and one that can’t be patched, people. Attackers are taking advantage of this vulnerability in the form of phishing, malware, and other means to steal your cloud resources and compute resources. This is not done through the complex work of finding a vulnerable server but rather by finding a vulnerable person to perform cryptomining and gain financially that way.

You may wonder if using an IaaS factors in to your security considerations. Well, as we mentioned previously, the security weak spot for almost every organization is its people. We now have to consider the vulnerability introduced into your infrastructure’s APIs and how they, plus your users, create vulnerability issues. The ability to create and interact with resources via remote API calls from anywhere in the world has made securing APIs a critical part of cloud security strategy.

API access is secured via an API key that is unique for each user and the corresponding policies the user has. However, you can’t simply cut off the ability for your users, who in this case are developers, to use these APIs and this is where the attackers step in to take advantage of the vulnerability introduced by your users.

At issue here is the accessibility of the API and the value it contains. As developers are building the code to create, manage, and support your services, this code is simultaneously leveraging the API for your public cloud provider. As a result, it is likely, and very common, that during the development process, keys get hard coded into a file and reference that as a quick and temporary path of least resistance during the development process. This code is usually stored in a Git repository that is private since this is pre-production code. This is where the people vulnerability and attackers come together, especially if you’re using a GitHub for your repositories.

If your developer fails to remember to remove the API key(s) from that code when that repository is made public you have the makings of a very expensive security incident. A simple search on API keys on Github or AWS bill will quickly surface an enormous amount of results of people and stories of how leaving your API key in a public GitHub repo will result in a massive AWS bill very quickly.

How does this relate to cryptocoin mining? Well this is where the attackers come in. Attackers use bots to crawl git repos, mostly GitHub, to look for API keys. Once found, these bots will programmatically test these keys to see what resources can be accessed, checking permissions, and then will check to see where your EC2 and workload resources are deployed; in other words, they’re searching for the region(s) you’re using. An attacker who has a valid API key with the ability to launch an instance, or virtual machine, will do so and then put their cryptomining software to try to gather as much as they can before being caught.

This is where the strategies of these attackers vary, but irrespective of how they approach it, it’s important that you have a security solution that can automatically detect this activity quickly. One thing that they all tend to do, however, is look for and focus on regions. If you company is like most public cloud customers they tend to run only in the regions that are closest to the majority of their customers for performance reasons. This means that only those regions are monitored and console users only spend time looking at services in those regions. Yes, this is why it’s a best practice, and default, to monitor all regions with the API logging. Attackers will take advantage of this to launch the instances they’re planning on using for their cryptomining in a region that you don’t use and never look at.

Knowing that they will likely have a short period of time to use these stolen resources it is common to launch the largest of compute resources for this activity. This is how it is possible to generate a very large bill of tens of thousands of dollars in a very short period of time, sometimes only hours. Of course this is also where we’ve seen attackers’ strategies differ recently.

A new trend has started to emerge since cloud providers are aware of this and will automatically notify a customer when things don’t look quite right regardless if any alarms or alerts are configured. Attackers are starting to revert back to the low and slow method where they maintain their foothold as long as possible. This has become a popular trend for a lot of server and network hacking. From loud and proud to low and slow. Attackers are starting to use smaller, less costly compute and often in actively used regions to hide in plain sight, all in the hope that admins and tooling won’t see the forest through the trees.

Of course this is where a cloud security platform is critical in identifying this activity before is starts getting expensive. This should not only be a concern if you are using public cloud infrastructure for production and public-facing services. Actually it’s quite the opposite. This scenario is far more likely to occur in development and non-production environments. In other words, environments in which developers are making frequent changes, have broad access and permissions, and in all likelihood are almost completely unmonitored.

This is where Lacework and our Cloud Security Platform provides the elements required for continuous, end-to-end security. The idea is that you can’t protect what you can’t see, so Lacework’s automated cloud security platform provides deep visibility into what’s happening in your cloud infrastructure by telling you what your exposures are today and constantly monitoring those from unexpected and insecure deviations. It does this by monitoring resource configurations against well established security best practices, regulations, and compliance frameworks.