How Common Identity Misconfigurations Can Undermine Cloud Security

Welcome to a brand new cloud security podcast, Cloud Security Today. Instead of focusing on the latest news, we’re exploring a different take on cloud security where we dig deeper into its eclectic “how-to” side. On Cloud Security Today, we are going to talk with experts from all over the community so you can do cloud security better. Today’s experts are Nathaniel Quist (Q) and Jay Chen, and they will be talking about Unit 42’s latest cloud threat research. First up Q and J, as we call them, introduce listeners to their professional histories before telling us how they choose their research projects. We then talk to Q and Jay about findings from their latest report on identity and access management. Together, they explain some of the common vulnerabilities that come with identity and access management, like misconfigured roles. Toward the end of the episode, we talk to Q about cryptojacking, as he explains the nuances to mining coins maliciously, the various teams behind the act, and how they use code against each other. 

 Key Points From This Episode:

●      How to become a threat researcher. Q and Jay share a little bit about their background.

●      Watch your roles and look out for wildcards in configurations!

●      APIs don’t always behave as expected – test them!

Tweetables:

“My biggest surprise is that even in a multi-million-dollar enterprise environment with thousands of workloads, thousands of EC2 instances and databases, they still make very fundamental mistakes.” — Jay Chen [0:09:55]

“The cloud has the potential to be so much more granularly controlled than just a normal on-prem environment. From the outside looking in, it's very complex. Complexity can bring some obscurity within the cloud environment.” — Nathaniel Quist [0:17:00]

Links Mentioned in Today’s Episode:

Matt Chiodi on LinkedIn

Matt Chiodi on Twitter

Unit 42 Cloud Threat Report

Nathaniel Quist on LinkedIn

Jay Chen on LinkedIn

IAMFinder tool on GitHub

Secure applications from code to cloud.
Prisma Cloud, the most complete cloud-native application protection platform (CNAPP).

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

[00:00:06] MC: Hey, thank you for joining us today for the inaugural episode of the Cloud Security Today Podcast, sponsored by Prisma Cloud. In this podcast, we won’t necessarily focus on the latest news around cloud security. Rather, we really want to go deep into the house side of all things cloud security.

My name is Matt Chiodi and I'm the Chief Security Officer of Public Cloud here at Palo Alto Networks. Our goal for this podcast is to do these on a monthly basis and pull in experts from all over the community so that you can learn how to do cloud security better.

In today's show, we are going to dig into the latest research from Unit 42, which is Palo Alto Network’s elite team of threat researchers. We're going to dig into their cloud research findings, which came out in the latter part of 2020. We're also going to then dig into newer research on something called Hildegard, which has to do with crypto-jacking.

Today, I invited on the show, Nathaniel Quist, who goes by the very awesome letter Q. I wish I had that capability to do that, go by a letter. Also, Jay Chen. Q, don't you go first and introduce yourself and then Jay, and then we'll jump right into it?

[00:01:23] NQ: All right. Thanks, Matt. I’m very happy to be on this inaugural kickoff podcast. This is awesome. As Matt said, I'm a senior threat researcher with Prisma Cloud, also with Unit 42. My primary focus is looking at the who, why, what behind who's attacking cloud and why they're doing it.

[00:01:40] MC: How about you, Jay?

[00:01:42] JC: In case you haven't noticed, my name can also go by a letter, J.

[00:01:46] MC: I think I'm going to start calling you that now. It'll just be J and J.

[00:01:50] JC: Yes. My research has been around public cloud and microservice technologies, such as container and Docker Kubernetes. In this episode, I hope to share with the community what I have been looking into in the past year.

[00:02:10] MC: Awesome. Awesome. Well, awesome. Let's jump into it. You guys do your cloud threat reports about two times a year. I know, the last one was focused on cloud native identity and access management. I think, many people that's been said, I think, I heard it probably two years ago, that identity is the new perimeter. When I first heard that, I first thought, yeah, that sounds like somebody in marketing wrote that.

I think the more and as I looked at some of the research that you guys carried out, I think that's actually true. We know that identity and access are really intrinsically connected when providing security to cloud platforms. In your report, I know that you guys conducted a red team exercise. I definitely want to hear about that, and I think the audience will probably find that really, really interesting. Let's, let's dig into it.

I know that you did a red team exercise. You are able to discover and leverage IAM misconfigurations to own, essentially, an entire cloud environment. I read that it could have potentially have been a multi-million-dollar breach. Before we talk about that part, I would like to actually learn about two things. One, how do you actually choose your threat research projects? Then the second part of it is then, how do you go about executing those projects? What tools do you use, the infrastructure? What do you need?

I'm imagining, someone's going to hear about the red team exercise. They're going to think, “Wow, that was awesome.” They're going now, “How do I carry that out along my own cloud environment?” Q, I'll start with you. Maybe talk a little bit about how you choose projects and what your setup looks like.

[00:03:48] NQ: Yeah, perfect. There are two aspects. Choosing how we're doing this, every threat report that we do, we focus on a specific topic. This last one, as you said was IAM. The report before was infrastructure is code. We looked at different aspects of that. Then what we do is we do some research, we formulate our analysis, collect a whole bunch of data, do some analysis on it, and then present our findings.

Specifically, within identity and access management, we were actually presented by a client. They said, “Would you want to do a red team exercise in our environment?” Being unit 42, we're not like a red team group. We are more threat intel, threat research, what are the risks that we find within this field? It was interesting. I mean, no one's really done it to a great scale. We wanted to see if we were already focusing on identity anyway, so let's just see what we can find. It brings us to the next phase. Well, how would we actually do a red team exercise? First off, obviously, we need knowledge. I mean, Jay and I have been doing cloud-focused research for quite a while. Jay's been doing a little bit longer than I have when it comes to containers and Kubernetes and Dockers and things of that nature, the exploits within. I'm focused more along the line of the threat actor groups, how our techniques garnered miter attack framework, things of that nature.

What we did is we wanted to figure out well, how do we actually do this attack? Obviously, books, knowledge, gathering intelligence from a lot of different sources. I have a pile of books right down here. It's amazing, of what would it look like. Then we start talking about what is our scope? What is the scope of that attack? We talked with the client that was interested in working with us and figure out, are we going to go from an outside-in, or we're going to have limited access inside? Then what is the ultimate goal?

[00:05:35] MC: What was the ultimate goal for this time around? I know, with this specific report, did the client restrict you and say, “You can't do this.” Obviously, they wouldn't volunteer to run a DDoS against their environment. What did that look like?

[00:05:50] NQ: Again, it was very cool that the client approached us. They were very engaged and willing to go where we wanted to go with it as well. It was open-ended. We started out with no access. We just wanted to do a perimeter recon on it. What can we actually find from a cloud perspective in that environment? Then, how far can we go into it? We did a little recon on it. Jay found a really cool way into the environment with unauthorized access, just being able to peek inside of specific containers. I'm sure we'll get into that here in a second as well.

We scoped it out, say we want to do an external view on it. Then worked with the client again, changed the scope, and said, let's go a little bit of internal access. Not full access. Just specific developer access. Then how far can we go? Could we actually get to the point where we own the entire system? They left the reins open and we just ran with it. Sure enough, we were able to get root access to the whole cloud environment. It was really fast. Only within a couple of days, we were able to do that.

[00:06:52] MC: Do you guys get these requests often, like to pen test environments to Red Team cloud environments? I know you said that that's not what Unit 42 typically does, but just curious.

[00:07:03] NQ: Yeah. I mean, we have been approached a few times. We have said no to a few clients. Just because it isn't our focus. This was a special one-off, I guess, you could say.

[00:07:14] MC: Awesome. Jay, from your perspective, I know that Q mentioned you've been doing this for a while. I'm curious before we actually get into some of the findings from the recent threat report, how have you approached, and maybe not even this specific project, but when you've done some threat research projects in the past, I know that you've got a lot of research on blockchain and things like that that you've done in the past. How do you typically approach your projects? What's your setup look like?

[00:07:40] JC: For me, I usually look at the trend of the industry, like what people are interested in, what people are looking at, what are the top topics, what are the latest technology that people are talking about? Two years ago, in early 2017, in 2016, blockchain Bitcoin was a hot topic. It died down. Apparently now, Bitcoin is it's hot again, but I'm not looking at it anymore. Too bad.

Yeah. At the time, I look at the blockchain. In 2017, when people started to look into  containers when Docker first emerged and followed by Kubernetes, then I look at this new technology. First, I understand how it actually works, how that engineers, how the DevOps actually use these tools, then I started to dig into the security to see what are the attack vectors into this new technology, what kind of mistakes that people tend to make. I'm not a real vulnerability researcher. I don't look into software vulnerability. I don't look at the source code. Typically, I look into how we can make a specific technology more secure and look into what mistakes that people tend to make that make this technology insecure.

[00:09:00] MC: That's an interesting approach. I'm curious, Jay, while you're talking about that. I know that you had found some IAM and misconfigurations in the one client that Q is talking about. Then, you had done some separate research around the issue, just to make sure there was – how widespread was it? Maybe before we jump into that, let's talk about some of the high-level findings from the report. Jay, maybe start with you. When you looked at all this research. I know, it wasn't just one red team exercise. It was actually the broader industry as well. What was most interesting to you in the report? We'll put a link in the show notes to the full report. Jay, from your perspective, what was most interesting?

[00:09:45] JC: For this particular report, the latest report that we published two months ago, focusing on IAM, my biggest surprise is that even in a multi-million-dollar enterprise environment with thousands of workloads, thousands of EC2 instances and databases, they still make very fundamental mistakes. These mistakes that we all have heard about, we all know, but people are still making the same mistake. From the first day that public clouds are available, my biggest surprise is that I know, at least more than 200 engineers are using this cloud environment – the particular cloud environment that we pen test more than 200, or close to 300 engineers are using it every day.

Everybody is focusing just on the specific service that they are using day-to-day. Nobody seems to oversee or look at the entire cloud security comprehensive enough to spot this very simple misconfiguration that allows us to get the entire – to take over their entire cloud completely from an authenticated user to the almost root user privilege.

[00:11:16] MC: We've been beating around the bush. How did you actually get in? What was the vector? What did they do wrong? What should they have done differently? Let's get to the specifics, like what did you actually find?

[00:11:28] JC: We look at multiple cloud environments, multiple AWS accounts specifically. In one of the accounts that we look at, we found a specific IAM role that allows an unauthenticated user access. Using a traditional SSH server as an example, this is like, you have a user inside your SSH server that can be logged in with our password. As long as your normal, the username, like Jay, and you can just type your username, enter, then boom, you're in.

This is the same type of vulnerability or misconfiguration we found in this particular environment. The client has multiple IAM roles that are not restricted. Meaning that they can be used by anyone. As long as you know this role, then you can get in this role and you can start to access the current environment. This is one of the worst misconfigurations you can have. Unfortunately, yeah, we found more than one of these types of misconfigure IAM roles in this customer's environment.

[00:12:37] MC: This wasn't the typical, they had a weak password. It wasn't a username and password and someone's password was God, or whatever, like a three-letter. I mean, Q, from your perspective, is this something that if they would have had multi-factor authentication turned on, would it have helped in this case?

[00:12:53] NQ: Sure. Well, I mean as Jay said, I mean, all you had to know was the username. That's all you had to know. Then you just requested access into that particular environment. If they put in, even just putting in require a password, that would have done something. Then if you add just a second level of multi-factor authentication to FA using your phone, or an uber key, or whatever you want to use, I mean, it just increases the difficulty in accessing that. That's a lot to handle amazing exponentially. You need to have a password. That's something that they just didn't fail to put in.

[00:13:31] MC: I was looking at the report. It says that you're able to do this by exploiting a single misconfigured IAM trust policy. Maybe for people who are not familiar with this is, I think, AWS-specific language. What is a trust policy or a role trust policy? What does that do and what was the actual misconfiguration?

[00:13:52] JC: The concept of IAM role in AWS is similar to other role-based access control.

[00:14:01] MC: It’s a best practice, right?

[00:14:02] JC: Yeah, it’s a best practice that you set up multiple rows and each row can be used by a specific group for specific functions for a job. It’s the same as in AWS. You set up multiple roles. The way that a user can access can use this role is by assuming a role. For each row, in AWS, you need to attach something called trust policy to this role. What this trust policy does is that it restricts the entities that this particular role can trust; essentially define who can use this role, who can access this roles.

You can define hey, this role can be used by another AWS account, or you can define the way that this role can be used by this particular AWS service, such as lambda EC2, or EKS. You can also restrict this role to be only be used by a specific user in your account, like Jay or Q if we are in the same department. For this misconfiguration, we found that a particular role has no restriction at all. Meaning that this role can be used by anyone, even users in other AWS account.

[00:15:22] MC: How did you find this, to start out? Did you go directly after the account? Or did you have to bring up your own AWS account and you went through some long, brute-forcing process? What did that look like?

[00:15:34] JC: We did some reconnaissance. We were able to find out the 12-digit account IDs of these customers. Each AWS account is uniquely identified by a 12-digit account ID. The next thing we needed to do is to find out the existing roles in this AWS account. We did some reconnaissance that we scraped – we actually scraped the Internet for that particular customer. We looked at their GitHub repository to see how they use this account. What are the roles that exist in this particular account?

To emphasize, roles are typically not considered as a secret. I can safely give another person, or another company a role and let them access my cloud infrastructure. A lot of times these role names are public information. We were able to identify a set of roles and we start to test this role and found out that some of them are misconfigured and can be accessed anonymously.

[00:16:40] MC: Q, from your perspective, obviously you played a big part in this research as well and you've done this for the last couple of years under unit 42. What stood out to you specifically around identity and access management? What jumped out for you from some of the statistics that you've got, that you pulled together? What was interesting?

[00:16:58] NQ: I guess, to me, it's interesting in that I think, the cloud has the potential to be, or cloud environments just in general have a potential to be so much more granularly controlled than just a normal on-prem environment. From the outside looking in, it's very complex. Complexity can bring some obscurity within cloud environment. You get this warm feeling that look, it's so complex, that it's obviously very powerful and futuristic and all that fun stuff.

Within that complexity veneer, within all those different granular aspects inside of it, I mean, it breeds the capability that there's just something that you're going to miss. Just one thing that you're going to miss. It's exactly what Jay was just describing right there. I mean, it's very simple. If you look at it directly, if you take it apart and say, “Well, anybody can access this role from anywhere in the world.” It's just, well, that's obviously a security risk. It’s just cloud trust and cloud providers in no fault of their own, are trying to make cloud accessible and easily usable to breed adoption and you have people go to their platform. That's great. There's tricks that are in there, like the Asterix. I absolutely hate Asterix in cloud environments, because it means everything.

[00:18:14] MC: When you say an Asterix, like a wild card, what do you mean you hate to see those in – you mean, like configurations for IAM?

[00:18:22] NQ: Correct. Yeah. The biggest of the trust policy that we found that Jay was just talking about there, was the trust policy itself is which AWS accounts, or environments can access this role? It was an Asterix, which means anybody can access it.

[00:18:39] MC: That's like the equivalent of in a firewall policy, having any-any, right?

[00:18:43] NQ: It really is. I mean, but you can make the trust policies show granular. You can put it down to where I only want this particular person from this particular environment access his role. That's it. I only want this one service from this one environment to access that. You can you can specify specifically that with cloud environments, I mean from a security perspective, if you are going to do the compliance checklist and go down the thing and say, how are all these configured? You want to be able to specify every single role that you want to access that and no more.

I mean, the least privileged principle is what we want to aspire to and have made. Every time you put an asterisk in, it just makes to where anything within whatever that value, than anything else after it is allowable. That brings us into the next finding within this particular role, which was, we just talked about the outside in, that if we were going to go from the inside up, we had limited access to an environment. We just by enumerating the rules, enumerating the permissions that this one role had, we found one specific IAM role that allowed administrative access.

Once we had that, all we had to do is assign that one role to a new instance that we could create, then we had full access to the entire environment. It's all because of there was a little asterisk that said, you can have everything.

[00:20:02] MC: The first, it sounds like, so there was two types of scenarios that you carried out in this red team, actually. There was from the outside-in, so you're posing as somebody who's just any person that has an Internet connection, can do that. Then you said inside-up, so that must mean, did they give you direct remote access into the environment, like username and password? What did that scenario look like?

[00:20:24] NQ: Sure. Yeah. I mean, there is a nuance. Thanks for spelling that out. We had two access. One was no access whatsoever, then everything we found was just recon that we took from GitHub and all that stuff. That's what Jay was just talking about. Then the other aspect is we had limited access to environment. By limited, I mean, we had developer access. Developers traditionally are able to start processes, they're able to change access, networking routes and things like that inside of environment.

What's very important about this is we had developer access to only a very specific, small AWS environment, just an environment – their full infrastructure, just that one little piece that the engineers themselves, the developers were able to use, and test products like, I want to test some new tool, or some new gadget that – we had access to that.

[00:21:13] MC: Okay, that makes sense. That inside up scenario. If I understand what I write correctly, so in both of those cases, both which you guys found from the outside-in and the inside-out, in both of those cases, it was the misuse of a wildcard in the IAM configuration that allowed you to get in. You still had to find it.

Jay, from your perspective, when you're finding these things, are you exploiting some zero-day? Are you writing some new tools for this? I guess, what I'm getting at is if I'm somebody listening to this podcast, I'm starting to think, “Oh, my goodness, is my cloud environment susceptible to this type of attack?” What do you recommend? How does someone go about trying to find these types of misconfigurations in their cloud environments?

[00:22:05] JC: [Inaudible 00:22:06] no. I didn't use any zero-day.

[00:22:10] MC: That would’ve sounded so much cooler if he had said that –

[00:22:12] JC: I don't have any zero-day. Yeah, sorry about that. It's not as exciting, as fancy as hot everybody thought about pen tester. As Q has mentioned, we are not real pen tester. This is not our day-to-day job. I'm sure most of the pen tester will agree that when they go to a client's environment, 80%, 90% of the time, they look for misconfiguration. Most of the times, they just get access to a misconfiguration, instead of using any zero-day, or using any new vulnerabilities. I don't think usual pen tester will have zero days, or can exploit zero days in a [inaudible 00:22:53]. Usually, you don't need to go that far. You just need to find one misconfiguration, and that can start your journey to the – into clients’ environment.

[00:23:05] MC: I've looked at some of the previous reports that you guys had put out. It seems that if I remember one statistic correctly, it was that 65% of I believe, it was all security incidents in the cloud as a result of customer misconfigurations. 65%, so the majority. You guys didn't use any type of zero-day to do this, both inside and out. You just used a misconfiguration that doesn't require any special code to execute. You didn't have to go into the dark web and try to find some great tool to do it. This really puts two questions in my mind. I read, Jay, that after you have found the IAM, these types of these IAM misconfigurations in this one client, that you actually did some separate research to find out just how widespread the issue was in the industry. What did you find? Is this just one client who had a really bad day? Or is this more common?

[00:24:02] JC: Yeah. For the misconfigured IAM roles that I mentioned earlier, so there are different ways that you can identify the existing roles in the customers, in the cloud environment. You can search on Google. You can look at the GitHub page of that customer and find out their roles. Another way is through enumeration. This is a known technique that published, I think, almost two years ago. There's a way that you can enumerate – as an outsider, there's a way that you can enumerate the existing IAM users and roles in a call environment. This is a known technique.

For coming conduct the written exercise, I use this technique. I actually use this technique to enumerate the customer’s color comp and to identify the misconfigured IAM roles. After the written exercise, when I try to understand how widespread this issue is in the while, I tried to look to GitHub, trying to find as many AWS accounts as possible. I tried to look into them trying to see, trying to enumerate, trying to identify the roles in those accounts, and to see how many of the customers have misconfigured IAM roles. The issue that I encountered was that this enumeration process is very slow. AWS restrict how fast you can abuse this particular API to enumerate existing IAM roles, or users.

[00:25:48] MC: I'm curious. As you're doing this, to me, this sounds almost like, what we would have done historically with trying to brute force a password, or something like that. As you said, I would imagine the cloud service providers. They spend billions of dollars on their security, making sure that their platforms are secure, that they do things like API rate limiting. It was AWS in this case. I'm sure, any cloud service provider is not going to let you just go crazy and just enumerate.

What protections do the – in this case, it was AWS. I mean, how did you stay under their rate limiting? How did you go through, because I'm looking at the report right now. I'm just scrolling through it. It looks like, you really leveraged public data from GitHub. I see, you went through almost 283,000 files, nearly a 150,000 source code repositories. It looks you scraped from that about almost 70,000 role names and almost 33,000 potential AWS accounts. You mentioned that it would take a long time. How did you go about carrying this out? Was there a tool that you used? What did that look like?

[00:26:57] JC: There are several ways that I tried to accelerate this research. Enumeration is my last resourt. I start from Google. Just use Google Docking to identify the roles in this particular account. I scraped GitHub. I identified old the repositories of this particular associate, or related to this particular data was account ID. I tried to parse out all the possible drone in. I did everything else, then usually, I can find a list for each account ID hat I found in GitHub, just by looking at the related project, I can find at least five existing IAM roles already. Then the last resort, I had to do is to enumerate. For this purpose, in order to enumerate fast and in large scale, I had to develop another tool called IAM Finder. For this particular tool, I identify a set of AWS APIs that can be abused. They are not vulnerable. I am just using those APIs in a way that were not expected by AWS.

[00:28:06] MC: I want to double click on that, because you're saying, so you found a way that you could use an AWS API in an unexpected way. What does that mean? It sounds like, I want to make sure we pull out that nuance there. What does that actually mean?

[00:28:21] JC: There are two type of security policies in AWS environment. There's resource-based policies, or permission-based policy. My particular finding is in the resource-based policies. Cloud resource-based policy means that for each resource, such as S3s, or where you have an S3 bucket, or you have an EC2 instance, you can attach a policy, security policy to this resource. If you have 10 S3 buckets, you can have 10 different resource policies attached to each of these S3 buckets.

There are APIs that allow you to configure this resource-based policies. Meaning, that you can use this API to upload a policy, usually written in JSON format and attached to a specific resource, such as S3 bucket you create. S3 bucket is just an example. There are I think, identify around 26, different AWS service that all support resource-based policy. All these APIs can be abused the same way. I'm using S3 buckets as an example.

When you upload a policy in JSON format to choose an API, the GitHub API back-end actually tries to verify your policy. One part of the policy is to specify who can access the S3 bucket that this policy attached to, similar to the IAM trust policy that we explained earlier. For this particular part of the policy, you need to specify hey, Q has an account in 1234 and I want to allow him to access this S3 bucket. I need to put out again, never use a asterisk to allow anyone to access the bucket.

A good security practice is always restrict the access to a particular resource to the users, or entity that absolutely need it. One very nice feature of what AWS does is that it helps you verify that the identity, or the principle you put in the policy is valid. I have an AWS account, and I create – 

[00:30:36] MC: Is it responds with true or false? That's what you mean by evaluating it?

[00:30:41] JC: Evaluate means that if I have an AWS account and I want to share one of my S3 bucket to Q, and I specify in my resource policy that, hey, Q in his account 1234 can access my bucket. If I accidentally typed his name wrong, instead of Q, I type J, adapt and J is not a valid user in that account 1234. AWS back-end will give me an error message telling me that, “Hey, this user does not exist.” This is a very nice feature that help the client write a valid policy.

[00:31:24] MC: That's really user friendly for the valid user, but someone who is just trying to go through and enumerate, they can just keep trying things, waiting till they get a correct response.

[00:31:35] JC: Right. I know Q's account number, but I don't know who, what are the users in that account. I can start to try out a word leads to thousands of different names. Eventually, I can find out a set of users exist in that account. That's essentially what I meant abuse, because that is a very user-friendly feature to help a user write a policy, but to use it is not what I expected.

[00:32:02] MC: Yeah. It's also attacker-friendly. The IAM finder tool that you wrote, I know it's open-source that people can go out and get it on GitHub. It's IAMFinder, all one word and they can find it on GitHub. I assume that tool leverages that nice feature that you were just talking about. They can also use [inaudible 00:32:20] survey the security of their own cloud accounts.

[00:32:24] JC: Right, right. One nice thing about that was that although I found plenty sick, or I think, plenty are sick AWS service can be abused the same way. 26 AWS APIs, but I implement, I think, five APIs. Also, in order to scale to get around with the API limit toggled by AWS, I also that – IAMFinder also allow you to put in multiple AWS accounts. Instead of using one AWS account to enumerate, you can use 10 AWS account, which essentially increase your enumeration rate by 10.

[00:32:58] MC: You proved out that these identity misconfigurations, you found this really glaring one in this one specific client that you did a red team exercise for. Then Jay as part of your broader look across the industry, you actually found that there are probably hundreds, or maybe even thousands of other cloud accounts out there that have similar misconfigurations. I saw that in the report, I think it's on page 14, said that you guys found more than a 175,000 EC2 snapshots that you could have accessed hundreds of S3 buckets.

Let me ask this and then we'll jump over to another topic. Maybe each one of you, if you could just give one thing that you would recommend anybody who's listening, do to prevent these types of attacks, or to prevent these types of misconfigurations. Q, I’ll start with you. What’s one recommendation that you would make?

[00:33:52] NQ: Scan your cloud environments.

[00:33:55] MC: Use IAMFinder to scan your own cloud environment before an attacker use it.

[00:34:01] NQ: There's a number of open-source tools. There's a number of tools, like Palo Alto, obviously. We have infrastructures, code scanning, being able to use some cloud native security platform that is able to scan your environment to see if you have misconfigurations in your environment. The cloud environment that we found these in, they’re using cloud data security tools to find stuff. I mean, when it comes to just configurations, I mean, having a tool, or being able to use infrastructure as code scanning, now being able to use some third-party app to look at a cloud environment and look at all these misconfigurations, where potential misconfigurations is a huge step. Making sure that your cloud environment is configured properly. Because I mean, there are thousands. There are hundreds of thousands of potential –avenues of potential misconfiguration. Having some automated tool go through that and look at it all, from an automated perspective, a machine's going to catch things that humans will just miss.

[00:34:57] MC: Especially, probably with cloud-scale, right? I know, at least most customers that I talk to, clients that got usually – don't have a single Cloud account. They usually have hundreds of cloud accounts across 2, 3, 4, 5 different cloud providers. Be difficult. Jay, from your perspective, what's one thing that maybe you would recommend? You're a threat researcher, so you get to sit on the other side of the table, where you get to go out and find all these things. If you were in the position of a defender, someone who's just trying to make sure that their own cloud environment’s in a healthy, secure shape, what's one thing that you would recommend they do?

[00:35:35] JC: Particularly in IAM, I will suggest to audit your IAM users, roles and groups. Periodically, you keep only users who are active and remove all the user who are inactive. Periodic audit, the permissions of each user in rows and follow the principle of least privilege. If this roles only need to access three AWS feature service, don't give it 10. Another easy way to get the wrong with this particular IAM issue that we mentioned is to use federated IAM access, instead of creating a user for every developer, or create a role for every developer, use federated access to minimize your IAM attack vectors.

[00:36:29] MC: I appreciate that. I thought, we would maybe jump into one other topic and then we'll wrap up for today. One of the other things that I read about that I think is – Jay mentioned at the beginning. Anything having to do with cryptocurrency is top of mind. It's in all the major news now. Back, Jay, when you were looking at blockchain a couple years ago, I think it was just – it just wasn't really in the – if I asked my dad, what's Bitcoin five years ago, he would have no idea what it was. Today, I know he's got his own Coinbase account and he's got some Bitcoin. I don't know how many, but maybe more than one. I don't know.

I know that, Q, you've established a reputation in the industry for really closely following crypto-jacking as it applies to the cloud. Just real quick, what is crypto-jacking and what did you find in some of the latest threat research around that?

[00:37:22] NQ: Okay. First off, crypto-jacking is the malicious use of crypto mining. Crypto mining is the process of either finding specific cryptocurrency coins, tokens themselves, or the process of validating those coins are actually proven. If there is a transaction that happens, that you can prove that that was actually a valid transaction, that should go on to the ledger or not. The actual process of finding the actual token itself is the process of what is considered crypto mining.

Then taking crypto-jacking is just, like I just said, just the malicious use of that. Performing those operations on some other infrastructure that you don't own. Using someone else's, essentially, electricity to provide you with profit.

[00:38:05] MC: It always hits the malicious crypto-jackings, the malicious use. We know that the thing about cloud that I would imagine that attackers love is the fact that there's this almost unlimited compute capacity, right? We know with crypto mining, there's proof of work, where you have to actually – you do complex mathematical computations to prove right certain things. Then there's proof of stake, which some other, the different blockchains applications use. In this case here around crypto-jacking, what did you find from a trend perspective. Is this really common? What did you guys see?

[00:38:41] NQ: Yeah. There's a few commonalities. There's a lot of crypto-jacking operations in existence. I've found 13 or 14, just within the last year of different operations. The vast majority of them are really operating – They have the same tactics, techniques and procedures, where they scan for exposed systems of specific types of services. It varies. They get to that system and then they essentially kill all the other miners that are out there. If they're on that system, got pre – if they were compromised before, it kills all those known systems, and then installs their own system and then they start crypto-jacking on top of that.

What's really interesting, and this goes in-line with what we were just talking about with identity and access, and this can tie in to Jay's latest blog that he just reported on as well, was this group called Team TNT.

[00:39:31] MC: I want to know how they come up with their names, because that's pretty awesome.

[00:39:33] NQ: It is. It is a great name. I mean, it's like, yeah, we're team explosive. This is awesome.

[00:39:37] MC: Team explosion. Yeah, I love it. Sorry, go ahead.

[00:39:41] NQ: It's interesting, because Team TNT, actually stole a lot of their code base from another team, another group called Kinsing. What's amazing, if you're looking at across all those different crypto groups that I mean, literally 12 or 13, just within this last year that I found, is that within the same block of code, you'll find the exact same. This actor just copied this block of code and put it in their tool, and then another actor copied that block of code and put it in their tool. There’s just a whole bunch of sharing that's going along. It's funny.

What they're doing that’s really interesting is Kinsing and Team TNT, both follow very, very similar TTPs. One of those tactics are, once they compromise the system, it's actually the very first thing they do after they compromise that system is they scrape that compromised system for its internal data. They are looking for what type of passwords already on that system? Can I grab SSH keys? What type of passwords, or usernames are on that particular system?

What's really important is that they're specifically targeting now AWS configuration files on those particular compromised systems. If you are able to grab the AWS configuration file, you're able to find the configuration and the credentials of users of AWS accounts that can log into that system. If we go back to what we were just talking about with IAM roles, misuse, misconfigurations, whether you have assumed role, or you can pass roles on to other resources that you may have access to. If we have an actor group that is now compromising hundreds of thousands of cloud accounts across lots of lots of different environments and they're grabbing AWS configuration credentials from every single one of the systems, they now have IAM identity and access credentials to those cloud environments.

If they're able to access that cloud environment and they are able to misuse, perhaps a pass role feature, or if they can assume a role now that they know which one it is, and that particular client is vulnerable, then they could have larger access to the cloud environment, not just the compromised host.

[00:41:44] MC: How prevalent is this? I was looking at some of the older research. Looks like, you first started tracking this back in 2018. Is it more common now? What are some stats around crypto-jacking?

[00:41:56] NQ: It's actually very big. During this report that we're just talking about here, is that 23% of all cloud organizations that we can see, 23% of them are experiencing some form of crypto-mining operation, network connectivity. That means that nearly a quarter of every environment is communicating with a known crypto mining platform.

[00:42:17] MC: Is there a valid reason for that? I know a lot of the research, you tend to hone in on Monera, which goes by XMR. That's its three-letter piece. Is there a valid reason that company X would have traffic going to these, or is this all usually malicious?

[00:42:34] NQ: We've been proactive and we've reached out to some clients and then we're saying like, “Hey, we see that you may have some crypto mining operations happening in your cloud environment.” We've actually been told on more than one occasion that that's okay, we're aware of it. We're doing this on our own. It's like, well, if you want to mine, sure. I mean, the price of Monero is going up. It's going up pretty dramatically, matching that Bitcoin marched up to 51,000 yesterday.

Depending on where your electricity is and how much it costs to pay for compute cycle within whatever cloud environment you're using, maybe there's a cost-benefit that you could do that, or you're looking for an investment opportunity. Maybe an organization is doing that. I want to caveat as with a really big caveat is that Monero, specifically Monero is a criminal favorite cryptocurrency.

I mean, if you're going to mine, you might want to pick an easier mine, like Ripple or something else that you don't want to mine with, it's easier to process, or maybe has a better, more highly favored legal history, or usage behind it. Monero is very – criminals love it for a lot of reasons. When we're seeing Monero mining happening in the environment, I just don't know if that's legitimately true or not.

[00:43:49] MC: It's probably very different than if it would be Bitcoin, which seems to be adopted by, I think, it was just last week, Tesla announced that they invested, I think, one and a half billion dollars of their Treasury into Bitcoin. Probably, if you see Bitcoin mining, Ethereum mining, it could be legitimate, but Monero is probably not legitimate.

[00:44:09] NQ: Yeah. I just want to say, if you are mining Bitcoin on the cloud, you're doing it wrong. Just don't do that.

[00:44:13] MC: You're paying probably way too much. I also saw from a Bitcoin perspective, I saw that one of the Russian oil companies announced that they are starting a Bitcoin mining operation in Serbia, or Siberia rather. Anyway, well, I've really enjoyed having you guys today on the podcast, especially being our inaugural podcast. Thank you both for joining today.

Again, our goal with these podcasts is to do them on a monthly basis. If there is a specific cloud security topic that you want to learn more about, please drop us a DM on Twitter. It's @CloudSecToday. @CloudSecToday. That's our handle on Twitter, so you can reach out to us that way as well. Also, a call to action would be to download the free IAMFinder tool, and you can scan your cloud environment and look for common IAM misconfigurations. Again, it can be downloaded directly on GitHub by searching for IAMFinder.

Thank you so much for joining us today. Have a great day.

[END]