CyberWire Daily - SCARLETEEL zaps back again. [Research Saturday]

Episode Date: July 15, 2023

Michael Clark from Sysdig joins with Dave to discuss their research on SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto. New research from Sysdig threat researchers found that the group continues to thrive with improved tactics. Most recently, they gained access to AWS Fargate, a more sophisticated environment to breach, thanks to their upgraded attack tools. The research states "In their most recent activities, we saw a similar strategy to what was reported in the previous blog: compromise AWS accounts through exploiting vulnerable compute services, gain persistence, and attempt to make money using cryptominers." Had Sysdig not thwarted SCARLETEEL's attack, they estimated that they would have mined $4,000 per day until they were stopped. The research can be found here: SCARLETEEL 2.0: Fargate,Kubernetes, and Crypto Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWires 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 our rapidly evolving cyberspace. Thanks for joining us. Back in February of 2022, we first encountered this actor, who we call Scarlet Eel, mainly because we are kind of a nautical-themed mascot that's a Kraken, so it seemed appropriate. That's Michael Clark, Director of Threat Research at Sysdig. The research we're discussing today is titled Scarlet Eel 2.0, Fargate, Kubernetes, and Crypto.

One of our customers had a security issue, and it led us down this path of finding this cloud attacker who went from runtime into the cloud and did some very interesting things that we don't see a lot. We see things like crypto miners and other financial motives quite a bit. But this one was quite a bit different because not only did they try to run a crypto miner, but they also stole code from a Lambda. So they downloaded all the Lambda functions and they stole some intellectual property. And we know they stole it because they actually ran it on a different cloud and it had a beacon that phoned home. Oh, interesting. So it wasn't just about crypto. They obviously were looking at what data they're collecting. So that's what kind of put us on the trail of this guy.

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? Yeah, 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 alerts a customer that something's wrong. And this was trying to run crypto miners by spinning up instances.

And then as we traced that back, we found all this other activity. They even tried some lateral movement. So they found credentials to another account, which they tried to get into. So they were definitely more interested in everything about the organization, not just spinning up crypto miners. 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? 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 in some software or an unpatched vulnerability, which was the case in one of these, where they just got in through runtime and then made their way into the cloud. And so they get in, and what sort of things are they up to? Where do they head from there?

Once they get 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 overprivileged. And they were able to assume that role and then basically pivot 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. 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 because they were able to escalate their privileges through a poorly written policy. So the client had made an error in their own policies and that's what allowed them to escalate privileges? 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,

because the people who wrote it thought that was case-insensitive. Yeah, that's a fascinating insight. I mean, not to oversimplify it, but I think it really emphasizes that these configurations can be complicated. You know, it's hard. Yeah, it's very hard, especially for big organizations who have a lot going on. Yeah. So they get in and they escalate their privileges. What do they do next?

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 very aware of Fargate.

They're very aware of cloud formation. In fact, we saw as a part of this, they tried to use cloud formation to escalate their privileges as one of the paths. Were there any indications from their activity what part of the world they were coming from? Not exactly. This attacker uses a stand. 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 VPN or other anonymized service. It's hard to tell.

And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever

with AI tools. It's time to rethink your security. Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps,

not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions.

Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. So are they trying to escalate privileges for multiple users then once they're in? 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 basically selling your IP address to route traffic for an anonymization service. We see that as a payload. So they definitely try to diversify their income as much as possible. They installed a denial of service agent to use DDoS as a service as well. So they definitely are not just counting on cryptocurrency anymore. 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? We believe it's opportunistic still. Since this was a misconfiguration, it was up for a short time. These kind of attackers are constantly scanning. And sadly, if you put something up, it'll only take a very short amount of time, a few minutes probably, to get hit, especially on the runtime side.

Does the crypto mining seem to be sort of the final step here? As you mentioned in your research, that's when things get particularly noisy. Yes,, that's when things get particularly noisy. 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 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. It's interesting to me that, as we say, the crypto mining was the thing that really set off the alarm here. But what could the customer have done along the way here to try to catch them earlier on in the process?

Since it started during runtime, that's where most of my expertise is into, is 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, example is they installed several support scripts, support tools, which we didn't see before either. So they installed Paku, which is a AWS penetration testing tool. And I can never say this name right, Pirates or Pirates. It's a 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. One of the things you highlight here is the possibility for using these resources for DDoS as a service. Yes, and we saw them install a variant of Mirai on the system, on the runtime system, where they got in, versus the ones they spun up for mining.

What happens once the detection has been made, in terms of incident response and 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? Sure. So luckily with cloud, there's a lot of interesting tools. You can take a snapshot of the runtime instance and then kind of treat that as forensic image to whatever standard you like. And then you can analyze that for all of the artifacts

and do a traditional kind of instant 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. So in terms of recommendations here, based on the information you all have gathered, what would you say to folks who are looking to best protect themselves? I would say it's going to be that defense in depth kind of answer that cloud is 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 make sure you have proper monitoring there.

You're never going to be able to stop everything, so you need to have threat detection and response there so you know if something happens. And then on the cloud side, you have to have visibility too. You can't just wait until something happens and go look at CloudTrail. You need to be monitoring CloudTrail or whatever cloud service provider you're on, if they're equivalent, for threats and abnormalities.

How would you rate the sophistication of this threat actor? Where do they stand? I would say somewhere in the middle of someone who just wrote a script and then the nation states, because as we saw with the first attack, 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 the last time they came in.

So they're definitely evolving. They're also doing some more stealth things by renaming their binaries. 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 that answers the 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. our thanks to michael clark from cystic for joining us the research is titled scarlet teal 2.0 fargate kubernetes and crypto we'll have a link in the show notes. And now a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home?

Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Thank you. executives and their families 24-7, 365 with Black Cloak. Learn more at blackcloak.io. 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 Ervin and senior producer Jennifer Iben. Our mixer

is Elliot Peltzman. Our executive editor is Peter Kilpie, and I'm Dave Bittner. Thanks for listening.