CyberWire Daily - Unleashing the crypto gold rush. [Research Saturday]

Episode Date: June 24, 2023

Ian Ahl from Permiso's PØ Labs joins Dave to discuss their research on "Unmasking GUI-Vil: Financially Motivated Cloud Threat Actor." First observing the group in 2021, they discovered GUI-vil is a financially motivated threat group primarily focused on unauthorized cryptocurrency mining activities. The research states "the group has been observed exploiting Amazon Web Services (AWS) EC2 instances to facilitate their illicit crypto mining operations." This group is dangerous because unlike many groups focused on crypto mining, GUI-Vil apply a personal touch when establishing a foothold in an environment. The research can be found here: Unmasking GUI-Vil: Financially Motivated Cloud Threat Actor 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. The first case that I got when I moved over to Permisso was with this threat actor. And it was a very interesting threat actor in the sense that it didn't look anything like what we typically see. Not a lot of automation, a lot of GUI tools, and a lot of mistakes along the way that were kind of funny that stood out. That's Ian Aul, Senior Vice President of Permisso's PZERO Labs.

The research we're discussing today is titled Unmasking Gooeyville, Financially Motivated Cloud Threat Actor. But effectively still able to be super effective at doing their main mission, which was crypto mining in this environment. So thousands of dollars of resources from the client used for very small gains on the crypto mining side, about $7 a day in one instance. But they were able to spin up so much infrastructure that it was very impactful to our client. Well, before we dig in too deep,

just selfishly, I want to tip my hat to you and your colleagues for actually including pronunciation guidance in your research here. So often, as everybody who's listening to this, who's into cybersecurity knows, there'll be some interesting, fun, unique name for something, and nobody has any idea how to pronounce it. And I find that often I am one of the people whose job it is to pronounce it. So thank you for taking the guesswork out of that. Just, again, selfishly, I appreciate it. And for you and for everyone else who's listening, please do more of that. Yeah, that's great.

You know, naming's actually been kind of a controversial subject lately for groups. And I figured I'd try to make everybody mad by doing the boring Mandiant-style name as well as a funny pun with it. Yeah, yeah. Well, let's dig into the research here. Can you walk us through what exactly is going on with this attacker? Sure, absolutely. So a pretty common method for initial access with cloud threat actors is just finding keys publicly accessible. And that's what this threat actor will do most commonly. They do have some exploits that they'll do against vulnerable GitLab instances as well. But

generally, even in those situations, the goal is find an access key that they can then use. Access keys, again, in general, are just so prevalent publicly. Everybody knows GitHub and the like. Occasionally, we'll have keys linked to GitHub or other code repositories. But there's other places that people don't really even think about, like Android applications.

When you're packaging up your Android application, oftentimes organizations bake their keys right in. And threat actors with just basic knowledge of strings and a regex can grab those keys real easily and leverage those. And that's what's happening here initially. They get a key. Now they're going to see what they can do with it. And for this redactor,

the reconnaissance is mostly done, again, with GUI tools, hence the GUIVL name. So they'll throw it into a utility they call S3 Browser. It's a particular version as well, which is kind of interesting. It's a version from January of 2021 that they've never updated. So it's S3 browser 9.5.5. It's a pretty common

utility that some admins will use for uploading and modifying files in S3. But what they use it for instead is, well, sure, they're going to look at S3 and see what's available in there. But it has some basic tooling for modifying and interacting with IAM, the identity management solution for AWS. Yeah, so they'll take IAM portion of that. And for us on the detection side, because that's what I care about most is like, how do we detect these in the future? what I care about most is how do we detect these in the future. S3 browser usage for downloading files, uploading files,

common that organizations around the world will do that. S3 browser usage for interacting with IAM, very rarely do we see anybody that's doing that that's not doing it for malicious purposes. So it always ends up being this group there. So once they're in, what are they after? Ultimately, they want to be able to deploy EC2 instances to do their crypto mining on. So they're going to do everything they can to lead up to that. So if the credential that they first have doesn't have the permissions to do EC2 instances, to run an EC2 instance, they're going to escalate their privileges.

They're going to look for methodologies to make sure that they can stay in the environment while doing this as well. Oftentimes, at least in cloud, identities are just grossly overprivileged. So they don't have to do a lot of privilege escalations in general, but occasionally they do. And in one of the instances,

they had a read-only credential, and that read-only credential had access to S3 buckets. They searched through those S3 buckets, looking through flat files, found a Terraform TF state file, which is a juicy target for a lot of threat actors because it often contains credentials and other information about the environment. And they grab that. So now they have administrative privileges. Once they have administrative privileges in the environment, they want to make sure that if somebody else discovers this key that they discovered or a defender finds out that they have access to this compromised credential, that they have another way back in. So they'll create other users, create other access keys, or in certain situations where they want to be low and slow

and go below the radar a bit more, they look for existing identities that don't have login profiles set, meaning that they can't log into the AWS management console. Maybe they only have access keys associated with them. And what they'll do is they'll create a login profile for that existing identity, essentially taking over whatever permissions that that identity has. And the reason they go about that is a lot of organizations, while detection in the cloud is really low bar, in my opinion, what a lot of organizations do pretty well is monitoring new IAM users that are created,

new access keys that are created. But not many organizations are watching for when an existing user's password is reset or a login profile is created for them when they didn't have one previous. So it's a way for them to fly under the radar there. Are most people looking for any type of privilege escalation? Like you're saying, if I've assigned someone your read-only access and that gets flipped to where they can suddenly write, am I likely to get an alert about that? Not in any native solutions in the cloud.

A good mature organization is probably monitoring that a little bit better. But generally, no, it just doesn't happen. They're not monitoring for big changes. And in addition to that, like I mentioned before, they don't even really need to go that route often because everything's so overprivileged. When we look across all of our clients that we've ever had, we see that roughly 4% of the assigned permissions that an identity has are ever used. To give you an example of how grossly overprivileged. And that's to include your CSPNs,

your security vendors in your cloud are also overprivileged grossly. Wow. So they are in your cloud are also overprivileged grossly. Wow. So they are in your environment here, and they're set on doing some crypto mining. What sort of infrastructure do they set up for themselves to do that? Yeah, so that's the beauty of the cloud, right? So now that they're in the AWS Management Console,

they have the ability to spin out EC2 instances. They're just going to go region by region, switching and deploying as many as your resource constraints allow. And they're going to be spinning up big EC2 instances too. So from a size-wise, these are all in the large to extra large range. But to put that in perspective,

these are machines that cost roughly $5 to $50 a day versus maybe smaller machines that are not even a dollar a day. So they're spinning up big EC2 instances to do their crypto mining. And occasionally, again, they'll reach resource limitations that a client will have set on a region. And then they'll just switch over to US West, and then they'll switch over to AP South, and so on. Keep going. They don't even really do a whole lot of profiling first to see which regions have what resources available. They just kind of go and deploy as much as they can. And once they hit a limitation, that's when they stop. 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 would it be fair to say that once they're in and up and running,

that they're not trying to be particularly stealthy? Yeah, I would say they don't have to be. Attackers will work only as hard as they have to. And again, just a real low bar on detection in general in cloud environments. There's so much activity, so much log data, and just not a lot of folks have gone down the path of really building up a big detection response program in the cloud. They don't have to take a whole lot of steps because oftentimes they're not noticed until somebody gets a big bill.

Right. A big bill indeed it could be. Oh, super big. Yes. We've had clients where hundreds of thousands of dollars are out the door before they notice. In terms of how long they're able to stay in an environment, do you have any sense for what a typical occupation is for them before somebody catches on and boots them out? Yes. So I guess this might be a little bit of a bias

because we monitor for them pretty heavily in our clients. So as soon as they are in, we notice them because they have a very specific set of TTPs that we monitor for. So we're able to get them out of there pretty quickly. But there are situations where we'll plug into a client

and do our 90-day back scan and start seeing evidence that, oh, they've been here already. They've been here a while. So yeah, in some environments, we're talking months. And in others, we're catching them as they're deploying their stuff and trying to eradicate them from the environment before they can do too much damage, which is actually another interesting thing about these guys is they don't give up.

A lot of threat actors, like from back in my Mandiant days, anytime we'd run into FIN5, as soon as they saw a Mandiant agent touch the box, they're gone. They'll come back eight months later once Mandiant's done with their investigation and try again. Whereas these guys, they're fighting every step along the way. They're not just fighting, but also monitoring what you're doing. So they'll look at CloudTrail logs themselves to see, oh, what steps is this organization doing to try to stop me, to try to get me out of this environment, and how can we get around those? Do you have any sense for who's behind this, what part of the world they're coming from? Yeah, all the traffic sources out of Indonesia,

it's hard to say, obviously, like in a world where VPNs are everywhere. They could be anywhere in the world. But I would put my bets on Indonesia, especially given that over the last two years, we see them only from these very two specific ASNs. The timeframes that they do their work in is kind of after hours for Indonesian working hours, which leads me to think it's, hey, somebody gets done with their job at work and him

and his friends or them and their friends then start doing their after hours, more lucrative financially job there. And do you have any sense for what kind of numbers we're talking about here in terms of a take? Yeah, that's an interesting one. I don't have specific numbers here. Here's what I will say. From my perspective, Permiso, where I work now, we're a relatively small company, recent startup. If we're coming across these folks a half a dozen times over the course of a year, that gives you a good indication of how prevalent they may be everywhere. Monitoring some of their wallets, it looks like they've done well, but it's hard to say how well without having a bit more data points. Yeah. So what are your recommendations then for

folks looking to protect themselves against this? How should they come out that? Yeah. So a few things. Obviously, monitoring for compromised credentials is a place where I would focus a whole lot of efforts because this is where everybody's getting their initial access, not just Goebel, but Team TNT, all the various threat actors out there that are commoditizing the cloud space, they're all getting in via compromised credentials. So knowing what different access looks like, knowing what different activity looks like, and understanding what signals are associated with trying to gain access, maintain access, escalate privileges, those things are really important to

monitor in your cloud environments. So I guess that would be kind of number one there. And then in addition to that, implementing least privilege is really, actually relatively easy to do in the cloud. You have all the data to be able to make those decisions. It's just kind of hard to manage for all your individual identities.

So I definitely recommend every client I ever look at in their environment, grossly overprivileged on every identity, every credential that leads to situations like this, where somebody can get in and grab an account that maybe isn't meant to do EC2 things, but has that permissions anyways, and be able to spin that up. So implementing least privilege, super important. When we start measuring maturity in the cloud, we measure human access to machine access. And you'll notice as you start seeing more mature organizations that infrastructure as a code is really prevalent. No human change ever occurs.

In fact, in some of our more mature environments that we monitor, there's never a console login, right? Very, except for break glass situations, it doesn't really occur. So keep traveling on that maturity curve, get yourself to a point where you're not doing a whole lot of human manual change

in your environment, and it's all done through infrastructure as code. To what degree do you think that these folks are sophisticated in their targeting or are they perhaps opportunists? Definitely opportunists. They're just whatever keys they can find, they're going to give it a go. They're going to try. So definitely opportunistic there.

As far as sophistication in general goes, that's something I kind of battle with with these guys. Oftentimes, you associate GUI tools with people who maybe are less skilled. I think it used to have a somewhat derogatory term of like GUI jockeys back in the day, right? Right, right. But at the same time, they're doing things that are very smart as well. When they get into an environment, they're tailoring their attack to that environment. So if they're going to create a new user, they're going to look at what your existing users are named. In one situation, they had an IT audit, an external audit. So they saw that, hey, they're just adding this suffix of underscore audit at the end of all these accounts. We're going to make our own. We'll call it sec underscore audit.

So they're doing some smart things as well. But I guess the other side of that too, because they're using S3 browser as their tool set, they oftentimes are moving a little too fast for their own good and leave defaults in. So one of the first times I realized we were definitely looking at the same group again was when I saw them try to create a policy, but they left the template of your bucket name here in the resource section of that policy. And we'd seen that in a previous instance of them as well. And they're just moving too fast sometimes for their own good. I'm curious, from a personal point of view, for you as a researcher, how does a group like this rank? Is this the type of organization that it's fun to chase down? Interesting. Yeah. So I would say as far as cloud attacks go, this is a funner one. Any investigation is always fun on my side. Not always great for the client when you have to

deal with it. But there's so much... The most prevalent attacks that we see in cloud right now are more crypto mining, but in an automated fashion. And also SES, simple email service for sending mass mail or mass text messages abuse. And those are so automated to the point where you know exactly what API calls are going to come in what order and what timing. And it kind of gets monotonous from a personal stance where I don't want to deal with those types of cases anymore. It's like back in the old Mandian days where I don't really want to do another ransomware case. Can I have one of the more fun ones this time? Yeah. So Gleevel, on the other hand, it's always a little bit different. And they're always

adaptable. And they're also fighting back when we're trying to eradicate them from the environment as well. So again, while not great for clients, fun for a researcher, for an incident response person. Our thanks to Ian Aul from Permissos P0 Labs. The research is titled Unmasking Gooeyville, financially motivated cloud threat actor. 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. Because when executives are compromised at home, your company is at risk. In fact, over one third of new members discover they've already been breached. Protect your executives and their families 24-7, 365 with Black Cloak. Learn more at blackcloak.io. The Cyber Wire 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 Thank you.