SCARLETEEL zaps back again.

Dave Bittner: Hello, everyone, and welcome to the CyberWire's "Research Saturday." I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities. Solving some of the hard problems and protecting ourselves in a rapidly-evolving cyberspace. Thanks for joining us.

Michael Clark: Back in February of 2022, we first encountered this actor who we call SCARLETEEL namely because we are kind of a nautical-themed mascot that's a kraken, that it seemed appropriate.

Dave Bittner: That's Michael Clark, Director of Threat Research at Sysdig. The research we're discussing today is titled, "SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto."

Michael Clark: One of our customers had a security issue and it landed us down this path of finding this cloud attacker who went from runtime into the cloud and it's very interesting things that we don't see a lot. We see things like cryptominers and other financial motives quite a bit. But this one was quite a bit different because not only did they- they did try to run a cryptominer, but they also stole code from a Lambda. So they downloaded all the Lambda functions and they stole some intellectual property. And they- we know they stole it because they actually ran it on a different cloud and it had a beacon that, you know, phoned home.

Dave Bittner: Oh, interesting.

Michael Clark: So it wasn't just about crypto. They obviously like looking at what data they're collecting. That's what kind of put us on the trail of this guy.

Dave Bittner: Well, let's walk through it together here. I mean, let's start from the beginning. How did this first come to your attention? As you mentioned, was it a customer that reached out to you?

Michael Clark: Yeah, they were- they ended up getting some alerts, and as usual with instant response, it's always kind of like the last thing in the chain that it alerts a customer that something's wrong. And this was trying to run cryptominers by spinning up instances. And then as we traced that back, we found all this other activity. They even tried some lateral movement, so to- they found credentials to another account, which they tried to get into. So they're not just- they were definitely more interested in everything about the organization, not just spinning up cryptominers.

Dave Bittner: Interesting. Well, let's walk through it together here. I mean, in your estimation, how would an organization find themselves the target of these actors?

Michael Clark: In this case, in both times, so since we've seen this actor twice, it was through runtime- the runtime side of the house. So whether it was a misconfiguration on some instance and some software or a vulnerabil- an unpatched vulnerability, which was the case in one of these. Where they just got- they got in through runtime and then made their way into the cloud.

Dave Bittner: And so they get in and what sort of things are they up to? Where do they head from there?

Michael Clark: Once they get like runtime access, a shell, they'll try to get the metadata credentials. So if you're on Amazon, that's like the IP address and metadata security credentials. And in one of these cases, the role that was assigned to the EC2 machine was over privilege. And they were able to assume that role and then basically give it back in- pivot into the cloud. And in the new instance that we saw, this was kind of similar, but they actually bypassed a newer version of IMDS, so IMDS v2, which is what Amazon recommends using. They went from a container into that and were able to get the credentials because Amazon recommends a certain setting that still lets containers be vulnerable. And once they got that, they were able to hop into the cloud as a normal cloud account. And then it gets a little weird 'cause they were able to escalate their privileges through a poorly-written policy.

Dave Bittner: So this was the client had made an error in their own policies and that's what allowed them to escalate privileges?

Michael Clark: Exactly. They were able to assign themselves a role that bypassed the resource filter they usually put on these roles. They didn't realize that roles and policies were all case sensitive and just that fact let one character kind of get them past it 'cause the people who wrote it thought that was case insensitive.

Dave Bittner: No, that's a fascinating insight. I mean, I- not to oversimplify it, but I think it really emphasizes that these configurations can be complicated. You know, it's hard.

Michael Clark: Yeah, it's very hard, especially for big organizations who have a lot going on.

Dave Bittner: Yeah. So they get in and they escalate their privileges. What do they do next?

Michael Clark: So the first thing they do is data collection. So they collect as much data as they can and that includes things like credential reports and other data that may get them in other accounts. We saw this one in this most recent event, their scripts actually account for Fargate, which is the Amazon Container as a Service system. So if they ended up on a Fargate account, they would be able to do the exact same thing. So they're definitely aware of these other services. It's not just about EC2 and S3. They're perfectly- they're very aware of Fargate. They're very aware of CloudFormation. In fact, we saw as a part of this, they tried to use CloudFormation to escalate their privileges as one of the paths.

Dave Bittner: Were there any indications from their activity what part of the world they were coming from?

Michael Clark: Not exactly. This attacker uses a stan- we've seen them use the same IP address in Europe, but we suspect it is used by multiple different actors, at this point, and maybe some sort of EPN or other anonymized service. It's hard to tell.

Dave Bittner: So are they trying to escalate privileges for multiple users then once they're in?

Michael Clark: Usually just once and it's to get access to these other things, to look for sensitive information, or to further their financial goals. They try to make money as many different ways as they can. In this case, they did try to spin up a bunch of bare metal instances as a part of their attack, I think 40 C5 metal instances, which gets very expensive very quickly. But like I said, they also try to do things like proxy jacking, which is sharing- basically, selling your IP address to route traffic for anonymization service. We see that as a payload. So they definitely try to diversify their income as much as possible. They installed a denial service agent to use DDoS as a Service, as well. So they definitely are not just counting on cryptocurrency, anymore.

Dave Bittner: Do you have any sense that they were targeting this client in particular because of who they were? Or does it seem as though they're being opportunistic, as you say, just to be able to use the resources to make some money?

Michael Clark: We believe it's opportunistic still, since this was a misconfiguration that was up for a short time. These kind of attackers are constantly scanning. And sadly, you know, if you put something up, it'll only take a very short amount of time, in a few minutes, probably, to get hit, especially on the runtime side.

Dave Bittner: Does the cryptomining seem to be sort of the final step here? As you mentioned in your research, that's when things get particularly noisy.

Michael Clark: Yes, and that's what we believe in the previous attack was, as well. And whether that's just coincidence that they do that after, you know, stealing data, or they just really want to make the money, it's hard to tell. It could be kind of a smokescreen or it just could be part of their standard operating procedure to make some sort of money no matter what account they get into.

Dave Bittner: You know, it's interesting to me that, as we say, the cryptomining was a thing that really set off the alarm here. But what could the customer have done along the way here to try to, you know, to catch them earlier on in the process?

Michael Clark: Since this- it started during runtime. That's where, you know, my- most of my expertise is in, too, is, you know, catching things when they happen on the runtime system. There were a number of indicators that could have been used to trigger a response. One example is they installed several support scripts, support tools, which we didn't see before, either. So they installed Pacu, which is a AWS penetration testing tool, and I can never say this name right, Peirates or Pirates.

Dave Bittner: Right.

Michael Clark: It's Kubernetes version of a penetration testing tool. So they were definitely aware of these environments and looking to leverage them if they end up on a Kubernetes system.

Dave Bittner: One of the things you highlight here is the possibility for using these resources for DDoS as a Service?

Michael Clark: Yes, and yeah, we saw them install a variant mri [assumed spelling] on the system, on the runtime system, where they got in, versus the ones they spun up for mining.

Dave Bittner: What happens once the detection has been made in terms of incident response and, you know, cleaning out the system, making sure that they don't have any more persistence? Can you take us through some of the things that happen there?

Michael Clark: Sure. So luckily with cloud, there's a lot of interesting tools. You can take a snapshot of like the runtime instance and then kind of treat that as a forensic image to whatever standard you like. And then you could- so you could analyze that for all of the artifacts and do a traditional kind of incident response. And then you can move over to CloudTrail and see the other side of the attack, as well, or if you're using a monitoring tool, that might provide both sides, as well.

Dave Bittner: So in terms of recommendations here, I mean, based on the information you all have gathered, what do you- what would you say to folks who are looking to best protect themselves?

Michael Clark: I would say it's, you know, it's going to be that just defense in depth kind of answer, that cloud was very complicated. There's a lot of different layers you have to worry about from runtime, to infrastructure as code, to all the cloud layers. And you kind of have to start at runtime, at least in my opinion, and, you know, make sure you have proper monitoring there. You're never gonna be able to stop everything, so you need to have threat detection and response there so you know if something happens. Then on the cloud side, you have to have visibility, too. You can't just wait until something happens and then go look at CloudTrail. You need to be monitoring CloudTrail and/or whatever cloud service provider you're on, their equivalent, for threats and abnormalities.

Dave Bittner: How would you rate the sophistication of this threat actor? Where do they stand?

Michael Clark: I'd have to say somewhere in the middle of someone who just wrote a script and the nation states. Because as we saw with the first attack, you know, they cared about the data they stole. It's not like it was just a completely automated attack. They investigated what they stole and put it somewhere to run. And then with this attack, they were using all sorts of different methods and new methods since last time they came in. So they're definitely evolving. They're also doing some more stealth things by renaming their binaries. Just- they're just evolving very quickly, it looks like, since it's been, what, six months or so since we last saw them. So hopefully, I answered your question. It's always hard to judge where they stay because, you know, the really bad guys want to look like not-so-smart people, as well.

Dave Bittner: Our thanks to Michael Clark from Sysdig for joining us. The research is titled, "SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto." We'll have a link in the show notes.

Dave Bittner: The CyberWire "Research Saturday" podcast is a production of N2K Networks, proudly produced in Maryland out of the startup studios of DataTribe where they're co-building the next generation of cybersecurity teams and technologies. This episode was produced by Liz Irvin and Senior Producer Jennifer Eiben. Our mixer is Elliott Peltzman. Our executor editor is Peter Kilpe and I'm Dave Bittner. Thanks for listening.