Unleashing the crypto gold rush.

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.

Ian Ahl: You know, the first case that I got when I moved over to Permiso was with this threat actor. And it was a very interesting threat actor in the sense that he 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.

Dave Bittner: That's Ian Ahl, senior vice president of Permiso's PØ Labs. The research we're discussing today is titled, "Unmasking GUI-Vil: Financially Motivated Cloud Threat Actor."

Ian Ahl: But effectively, still able to be super-effective at doing their main mission, which was cryptomining in this environment. So, you know, thousands of dollars of resources from the client used for, you know, very small gains on the cryptomining side, you know, about $7 a day in one instance. But they're able to spin up so much infrastructure that it was very impactful to our client.

Dave Bittner: Hm. 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 is- 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.

Ian Ahl: Yeah, that's great. You know, with- naming has actually been kind of a controversial subject lately for groups and I figured, you know, I'd try to make everybody mad by doing the boring Mandiant-style name, as well as a funny pun with it.

Dave Bittner: Yeah. Well, let's dig in to the research here. Can you walk us through what exactly is going on with this attacker?

Ian Ahl: 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 like GitHub and the like. You know, they occasionally will have, you know, 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 threat actor, the reconnaissance is mostly done, again, with GUI tools, hence the GUI-Vil 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 like January of 2021 that they've never updated, so it's a 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 it's, for us, on the detection side, 'cause that's what I care about most is like how do we detect these in the future. S3 Browser usage for, you know, 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 --

Dave Bittner: Oh, interesting.

Ian Ahl: -- it always ends up being this group there.

Dave Bittner: So once they're in, what are they after?

Ian Ahl: Ultimately, they want to be able to deploy EC2 instances to do their cryptomining 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 the 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 over-privileged. So they don't have to do a lot of privilege escalations, in general, but occasionally, they do. 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 for flat files. Found a terraform tfstate 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, you know, 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, you know, 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 in to the AWS management console. Maybe they only have AFS [assumed spelling] 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 that you go about that is a lot of organizations, while like 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 a 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.

Dave Bittner: Are most people looking for any type of privileged escalation? Like you're saying, if I've assigned someone, you know, read-only access and that gets flipped to where they can suddenly write, am I likely to get an alert about that?

Ian Ahl: 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, like they don't even really need to like go that route often because everything's so over-privileged. When we look across all of our clients that we've ever had, we see that, you know, roughly 4% of the assigned permissions that an identity has are ever used to, you know, give you an example of how grossly over-privileged. And that's to include, you know, your CSPNs. Your security vendors in your cloud are also over-privileged grossly.

Dave Bittner: Wow. So they're in your environment here and they're set on doing some cryptomining. What sort of infrastructure do they set up for themselves to do that?

Ian Ahl: 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 into perspective, these are machines that cost, you know, roughly, you know, five to $50 a day verse maybe smaller machines that are, you know, not even a dollar a day. So they're spinning up big EC2 instances to do their cryptomining. 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.

Dave Bittner: 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?

Ian Ahl: Yeah, I would say they don't have to be. You know, attackers will work only as hard as they have to and in, again, just a really 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, you know, take a whole lot of steps because oftentimes they're not noticed until somebody gets a big bill.

Dave Bittner: Right, and a big bill, indeed, it could be.

Ian Ahl: Oh, super-big, yes. We've had clients where, you know, hundreds of thousands of dollars are out the door before they notice.

Dave Bittner: In terms of how long they're able to stay in an environment, do you have any sense for, you know, what a typical occupation is for them before somebody catches on and boots them out?

Ian Ahl: Yeah, so I guess this might be a little bit of a bias because we monitor for them pretty heavily in our client. 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, you know, 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. In others, we're catching them as they're deploying their stuff and trying to, you know, 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, any time 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 the Mandiant's done with their investigation and then try again. Whereas, you know, these guys, they're fighting every step along the way. They're not just, you know, fighting, but also like monitoring what you're doing. So they'll look at cloud trail 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?"

Dave Bittner: Do you have any sense for who's behind this, what part of the world they're coming from?

Ian Ahl: Yeah, all the traffic source is out of Indonesia. It's hard to say, obviously, like in a world where, you know, VPNs are everywhere. They could be anywhere in the world, but I would put my bets on Indonesia, especially given that, you know, 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 afterhours for Indonesian, you know, working hours. Which leads me to think it's somebody gets done with their job at work and him and his friends or them and their friends then start doing their afterhours more lucrative financially job there.

Dave Bittner: And do you have any sense for what kind of numbers we're talking about here in terms of a take?

Ian Ahl: Yeah, that's an interesting one. I don't have specific numbers. Here's what I will say, you know, from my perspective. Permiso, where I work now, we're a relatively small company, a recent startup. If we're coming across these folks a half a dozen times over the course of the 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.

Dave Bittner: Yeah. So what are your recommendations then for folks looking to protect themselves against this? How should they come at that?

Ian Ahl: Yeah, so a few things. Obviously, monitoring for compromised credentials is a place where I would focus a whole lot of efforts 'cause this is where everybody's getting their initial access, not just GUI-Vil, but TeamTNT, all the various threat actors out there that are, you know, commoditizing the cloud space. You know, 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 kinda number one there. And then in addition to that, you know, implementing least privilege is really 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 over-privileged on every identity, every credential. That leads to situations way this where, you know, somebody can get in and grab account that maybe isn't meant to do EC2 things. But has that permissions, anyways, and be able to, you know, spin that out. So implementing least privilege, super-important. When we start measuring kind of maturity in the cloud, we measure kind of human access to machine access. And you'll notice as you start seeing more mature organizations that infrastructure as a code is really prevalent. Change- no human change ever occurs. In fact, in some of our more mature environments that we monitor, there's never a console login, right? That 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.

Dave Bittner: To what degree do you think that these folks are sophisticated in their targeting or are they perhaps opportunists?

Ian Ahl: Definitely opportunists, that they're just whatever keys they can find, they're gonna give it a go. They're gonna try. So definitely opportunistic there. As far as sophistication in general goes, it's something I kind of battle with with these guys. Oftentimes, we associate GUI tools with people who maybe are less skilled. I think we used to have a somewhat derogatory term of like GUI jockeys back in the day, right?

Dave Bittner: Right, right.

Ian Ahl: Things like that. But at that same time, they're doing things that are very smart, as well. Like 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 like 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 counts. We're going to make our own and 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 toolset, 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're 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, you know, here in the resource section of that policy and we'd seen that in a previous instance of them, as well. And, you know, they're just moving too fast sometimes for their own good.

Dave Bittner: I'm curious, you know, from a personal point of view, for you as a researcher, how does a group like this rank? Is this a type of organization that it's fun to chase down?

Ian Ahl: Interesting, yeah, so I would say as far as cloud attacks go, this is funner one. Any investigation is always fun on my side, not always great for, you know, 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 cryptomining but in an automated fashion. And also SES, simple e-mail 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, in what timing. And it kinda gets monotonous from a personal stance where I don't want to deal with those types of cases, anymore. It's like kinda back in the old Mandiant 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 GUI-Vil, 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 instant response person.

Dave Bittner: Our thanks to Ian Ahl from Permiso's PØ Labs. The research is titled, "Unmasking GUI-Vil: Financially Motivated Cloud Threat Actor." 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 executive editor is Peter Kilpe and I'm Dave Bittner. Thanks for listening.