Blank Space: Filling the Gaps in Atomic and Behavioral Cloud-Specific IoCs

Hello Bides. Uh it is my pleasure to introduce Morav and Gilly and they're going to be speaking about uh blank space filling in the gaps in automatic and behavioral cloudspecific IoC's. Take it away. Thank you. Legion, Andrew Ghost, Java Ghost, Greenbot. These are all high-profile malware campaigns targeting cloud environments. And another thing they all had in common was they all had unique and detectable cloud indicators of compromise. They all reused behaviors and unique names. And all of them could have been caught much faster and more accurately if we had a strong cloud IOC's database. Hi, I am Gillette Kosinsky, a malware researcher at Whiz. And I'm Mav. I'm a threat researcher at Whiz. You might know us from our previous works,

the blogs and reports you see there on the right. Or maybe you know us from explaining cloud security while playing with puppies. And today we're here to talk about cloud IOC's. But first, as Taylor Swift says, if you fail to plan, you plan to fail. So this is our plan for today. We'll start with explaining what are IoC's. I'm sure most of you know, but we'll still have to do a little baseline knowledge. We'll follow up with the cloud threat landscape and the unique challenges it poses and finish the more introy part by looking at traditional atomic IoC's. We'll then continue to the cloud IOC's part, the exciting part. Uh first with atomic and then behavioral

and then wrap up with a case study demonstrating all that we have been saying and the summary of course. And if any of these words don't mean not don't make sense yet, that's fine. We'll just head right into it. So what are indicators of compromise? The dry definition would be forensic artifacts indicating past or ongoing security breaches. What this actually means is that these are the footprints left by attackers in their compromised environments. And we can use those footprints for investigation, for detection, for incident response. Now when it comes to attacks targeting the public the public cloud for example environments in AWS or Azure we see different attacks that leave different footprints. So really the cloud has

unique resources and in those resources you can find unique evidence to attacks and that's really what we're going to talk about today. Yeah. So what makes the cloud threat landscape different from traditional on-prem environments? Well, first the cloud itself is a target. Cloud service providers can have vulnerabilities. Kubernetes can have vulnerabilities. And another thing is that cloud environments have new techniques after infection. For example, IM privilege escalation or SSM facilitated remote desktop connections allowing attackers to execute code on remote machines. Now all techniques can also have new impact in cloud environments. For example, SRF can be used to access instance metadata service and then capture credentials from EC2 instances. Now, let's talk about traditional atomic indicators. They are

the three you all know and love, IPs, domains, and hashes. Every fresh report you will ever read will have those same free indicators. The problem is the problem is that modern attackers know about these indicators and they know how to avoid them. For example, IPs can be mitigated by using u VPNs or tour or using other cloud providers as jump boxes. H malware hashes can be avoided by just not deploying traditional malware and domains can be avoided by uh switching domains very quickly. We can see more again and again that modern attackers, modern cloud cloud attackers are just not caught using those traditional IoC's. This is an example of a report by CISA on Andrew Ghost. one of the

attackers we mentioned at the beginning of the presentation. And you can see that they mention domains, they me mention hashes, but the entire report fails to mention any cloud related IoC. No words on the cloud activities that Andrew Ghost performed in their target environments. So what are cloudspecific atomic IoC's? Just like traditional IoC's, they are unique forensic artifacts that help detect cloud threats, but this time they are related to specific cloud resources like container images or cloud subscription metadata metadata. We'll now go over what we believe are the most important cloud IOC's and how we could have used them to catch a ver various different attackers. Right? So the first type of like very cloudy IOC's would be VM and container

image metadata. Now with attacks by known uh attackers to target the cloud such as team TNT or Silent Bob, we have seen them use malicious docker images in order to deploy new containers in their compromised environments. um this kind of activity can leave uh can can have some sort of uh naming schemes or uh repetitive naming that we can use to identify it in a given environment. Now um in addition to that it is very important to monitor for rarely used images in your production environments to track those little things even if they're not known. Another campaign uh demonstrating this sort of malicious activity would be the der kryptojack cryptojacking campaign um that used this malicious

container this malicious docker image um called no hapu/pause that contained the pause crypto miner as you can see it was pulled over uh 10,000 times so you can see the impact of this or the scope of it another cloudy IOC um would be cloud subscription metadata see cloud subscriptions such as AWS account for example can also be exploited or hijacked for malicious purposes. We have seen the threat actor danger uh using these specific AWS accounts to assume roles in its victims environments. Now here it's very important to have some sort of a good baseline on a normal baseline of what are the good subscriptions. The other side of that coin would be to track known bad subscriptions in order

to identify this malicious activity. In order to track uh good uh subscriptions, you can use these this repository by forward clouds uh the known AWS accounts repository and in a similar manner for the cloud subscriptions infrastructures code can also be exploited for malicious activity for example for leaking credentials or privilege escalation. And we see this crazy statistic. It's crazy for me, but I will explain a little bit why it's really crazy. By uh Shel Raban, she posted this. 0.5% of public terraform modules contain anomalous and risky blocks. 0.5% doesn't sound like a lot, but there's a lot of public terraform modules. So, this is actually quite crazy and very uh risky. And um similarly to subscriptions, in order to

detect this malicious activity, you also have to have a baseline of trusted IA providers and untrusted IC providers. U block deploy deployments of unauthorized IA. And as with any OC release, scan for malicious uh terraform and cloud for modules. This is an example for a campaign that we identified targeting cloud AWS users with a malicious cloud formation stack set. Um, so this does happen. IA sounds a bit like a less common uh IOC and it is, but it still happens and it's still cool to see as a hunter, not so much as a defender probably. Another another very common uh indicator of compromise that we see are cloud users metadata. Now attackers like to create new accounts in their uh

target environments. So they'll be able to stay stay even after the original compromise has been remediated. Uh attackers like Fbot like to create a usernamed id exploit. Andrew ghost uses usernames like scatsi and admins the default. Now the interesting thing about those usernames are as you can see in this code snippet by the scripts that Fbot used h they are usually hardcoded with hard-coded usernames and passwords which means that every single environment that Fbots targeted had this exact same username which meant it could have been used as a very very strong signal for their activities and just like new users uh actors also like to use SSH keys as a means of gaining persistence to target environments. Now, from what

we can see, attackers like to reuse those SSH keys. Maybe it's easier for them to keep track of which key is which victim if everyone has the same key. And we can abuse that laziness to track different incidents and trackers across uh victims. Now, keeping an inventory of SSH keys is a bit more difficult than just managed usernames. Managed keys can be tracked with CSP provided logs and CSP provided inventories. But SSH keys that only exist on compute require some kind of disc scanning or runtime agent. But having a full inventory of the SSH keys in your environment will allow you to compare those to keys from threat intel feeds and you you'll be able to

track the attackers's activity in your network. Now in general almost everything in the cloud can be named and attackers really like to uh have repetitive and patterns patterned name. H for example the group bling library or shiny hunters always created an AWS S3 bucket named contact shiny corp something in every target environment. Now monitoring for these naming schemes in newly created resources can really help uh mitigate and stop these kinds of attacks early and you have to cross-check these different named patterns with name patterns reported in threat intelligence feeds. Now I would also like to give an honorable mention to IPs which we sort of trash talked before but are still cool IoC's. We just have to look at them

a bit differently. Um, so why are they slightly less relevant when it comes to attacks targeting cloud environments? As we mentioned before, attackers often use anonymization techniques such as tour or VPNs and they all also use different IPs when it comes to C2 purposes than they would for API calls. And in most threat intel feeds, you can see um IPs that are used for C2 purposes. So those are not as relevant for us. However, this whole VPN usage thing uh does come into play. So, you have to monitor that a lot more than you would in maybe on-prem environments and also you have to look for IPs uh correlations through the attack stages. That way, IPs that may

not look suspicious based on threat intel feeds um can actually come up as the ones um acting out the malicious behavior. Now we move on to behavioral indicators. Now we talked about atomic indicators. Those are static data points such as um I mean hashes and domains which you know from before but it can be also the user ids and stuff that we mentioned. And here when it comes to behavioral IoC's we want to look at the abnormal activity patterns based on actions and their context. Um that may sound to some of you like TTPs but let me um say what we think is different between these and if you disagree we can talk about it after.

Um so we see TTPs as what an attacker does and we look at behavioral IoC's as how the attacker does it in a given environment. Um we have seen other names being used to this because it's really not something that is uh known in the community quite yet. So um some researchers call it signals or um maybe they just call it TTPs but we think there is a difference here. Um now based on that understanding we uh came up with these came up they're in the wild but um these four types of behavioral indicators. Um the first would be plain actions such as an API call to create user. Um the second would be actions with a specific

parameter. For example, this is the andro ghost example from before. Um create user with the user scxxati. Another examp which either the timing or the order of them indicates script usage. And the last would be contextualized actions. For example, if there's an action performed by a tour IP in an environment in which tour IPs are not expected, that should always raise a red flag. From those types, uh we derived two categories. So the first would be actions or series of actions that are specific to a known actor or tool. In this example, we love Andro. I mean, we don't love them. Their attackers are bad. We don't glorify them, but they're a very good example for uh targeting the

cloud. So, they have this series of API calls that they repeat in most of their attacks, which is just, you know, textbook for what we're talking about. Um, and then we have actions that are indicating of generic attack patterns. For this example, we use post initial access reconnaissance. So if you see multiple successive calls to get color identity and list attach user policies with the B3 user agent um you know this is kind of uh an indicator to this uh attack pattern but it's not specific to a tool or an attacker. Now let's zoom out for a little bit. This is very methodolog methodological. Um when we look at uh malicious behavior in the cloud, we

often see it building is like layers with each layer building up on the one before it. Now let's just try and see what I'm talking about here. Um we see the base layer as these individual events such as an API call to get caller identity. But when you look at several of these events happening in sequence, in specific order, in specific timing, you might get an action like mapping out a user's permissions. Um, or to paraphrase Gracie Abrams, what if I took your API call as more than just a call as writings on the wall? Um, I had to say I thought this quote just really fits this. Um and if you look at several

actions again in a sequence or in a sort of uh similar timing, you can get a technique such as privilege escalation. Um which I think is very cool because once we can look at these layers and understand the connection between them, we can see a a full attack path and we can connect the dots between individual events in order to create better detection rules and betterly be better defenders and better hunters. Okay, so next we're going to present a case study we like to call Bak. They are a threat group a threat group that we discovered using the methods we discussed earlier. Just a quick overview, they are a low sophistication threat actor that targeted exposed cloud

credentials. They operated mainly from Indonesia, sometimes using VPN, sometimes not. H they they used systematic scanning of exposed secrets without any specific targeting of a region or industry. and they reuse the same SSH key across multiple incidents which really help uh helped make attribution easy for us. So let's start at the beginning. We start with our proprietary uh cloud honeypot where we leak credentials in public sources and then monitor how attackers acquire those credentials and how they use them. We analyze the API call sequences and the attacker IP's metadata that are actually using those credentials. We then try to pivot from our honeypot environments to real cloud environments. We identify malicious IPs that we found attacking our honeypot. We

then search real cloud environments for those same IPs and IPI calls in a very short time frame. And then we try to uh understand whatever the credentials on the in those leak real cloud environments are actually leaked or stolen in some way and what a actors are using them. This is an example of how we group actions together. For example, uh the first line is a group of IPs from Vietnam calling AI related API calls like invoke model and get cost and usage and so forth. Now the interesting thing about this technique that is it that it allows us to discover new unknown groups by using known actors. What we believe is that leaked keys will

most likely reach more than one malicious actor. Whether it's because the keys are leaked on a public GitHub repo or they are sold on the darknet, more than one actor will likely use some kind of uh compromised credentials. That means that we can use the presence of a known actor that we know how to detect as a signal or as a lead to catch new and unknown groups. With this technique, we were able to find Bapak, the threat actor that we are going to present. Even though they never targeted our honeypot environment, other actors targeted our honeypot environment and then we used that data to catch BPA. Now, let's see some of the uh IoC's

we extracted from Bapak's activities. So, as we mentioned before, they used SSH keys. They always called import key pair on target environments with a very small set of key names, APEC, AES, and DFG. And they always use the exact same public key material which is unique cryptographic fing fingerprint which means we can be 100% sure it is the exact same attacker in all instances. They also like to call create cluster with the name bapak which is why we named that attacker Bak uh to spin up cryptomining machines. Now behavioral IoC's are a bit more loose and less less strongly defined but we were able to find some very unique actions that BPAC performed. For example

in every environment the first thing they did was what we call a reconnaissance action. They called get color identity describe subnets describe instances in that exact order in a very short time frame. This allowed them to get a lay of the land and see how the network the cloud environment works in that specific target. And another thing we also we saw in every environment was their persistence technique which is calling import key pair with the very specific key we saw before and then calling calling create cluster with that key as uh the access key. Now harking back to the um threat to the model that Morav mentioned, we take those singular events into actions and techniques and

then create detections around those techniques and we were able to find BPAC's activities in a lot of real cloud environments. So I think this story is actually very cool and it made us think that there are some things that we as a community kind of lack. See most cloud IOC's um definitely behavioral and I will get to that but even atomic are not really present in any reports or threat intel feeds. Now there's a lot of researchers um that are looking into attacks target in the cloud. So they definitely see these IoC's um but they don't really share them a lot. I mean some do and shout out to permisso for very good reports and blogs um but

mostly they are left out of these blogs and reports. So defenders are essentially flying blind even though the data exists. These attacks are happening. We see these patterns and we we see these atomic IoC's and yet we are not really sharing them in a centralized place that we all know such as like you know virus total when it comes to malware and stuff like that. Um, and when it comes to behavioral IoC's, it's obviously worse because it's not really traditional and not really relating to the attacks targeting on-prem environment. So, people really don't know what to do with these patterns and maybe if they see a pattern, they treat it as individual events, which wouldn't

really help when it comes to um detection as we spoke about before. Um now on our side of what we think should happen um we believe that it's important to monitor attackers behavior and not just individual events. You have to look at logs as um a sequence of things that are happening and try to find those patterns. That's where the behavioral IOC's live. Um and it's also important as we mentioned before to have normal baselines both for behaviors and for individual uh resources in your environment. That way, of course, any abnormal behavior will immediately jump out. And the most important thing really that I uh would want anyone to take from this talk is collaboration and sharing of um

everything that you see in attacks targeting your uh environments or your honeypotss etc. You have to share into things that we can all um somehow uh digest either machine readable feeds or not. Um but that's what would help us move forward and be better defenders when it comes to attacks targeting the cloud. Right? So what did did we learn today? Um we started with what are IoC's and what are the traditional ones that we all know and then we looked into cloud IOC's. Um, and why uh these IoC's matter is because there's a lot of attacks targeting modern cloud environments that just don't have those traditional IoC's. You'll just see a blog with no IoC's on it because there's

no IPs, there's no hashes. So, there's nothing really to detect. But that's not entirely true. we're just missing out on this very crucial data which would be either atomic IoC's for uh known repeated attacks from known actors or the behavioral IoC's that reveal these attack patterns instead of just the isolated events. So the main challenge here is that clouds are just overlooked in threat reports. you you know they exist but people are just not reporting them in machine readable ways like they do IPs and hashes and domains currently and security team needs those uh machine readable formats in order in order to build the tools that integrate those IoC's into their security solutions and unless we start reporting on those IoC's

no one will develop those tools and I think Bak really demonstrated that if we had some centralized database anyone could have done the research that we did anyone could have looked for environ ments seen those IOC's and catch the attacker in their environments quickly and and very accurately right so what is our part in all of this or as Taylor would say this is me trying um we've compiled all the IoC's from research that we um observed and used in this talk and our own research into a public repository on GitHub and we're constantly um updating it with older IoC's that we missed or new things coming out there's not a lot in it right

now as you can understand from this whole talk but we really invite you to uh contribute to it and help us make this a thing. Yeah, I personally approve or reject PRS open to that uh public repo. So please submit whatever you can and um I would love to approve any anyone here anyone's uh automatically approved. Yeah, if you if you've been to this talk just mention it and I'll approve it immediately. Right. So, thank you so much for listening. If you're interested in our other works, you should check out our um whiz.ioblogs tags research. That's all our blogs and reports. You can go to our threat site, frets.wiz.io, where we talk about recent threats from news. We have

the repository we just mentioned. That's the whiz research IC's. And we have our blog on cloud IOC's on our whis blog as we mentioned before. Yes. And thank you to my emotional support billionaire Taylor Swift for walking us through this journey. And thank you all for listening. Thank you to our speakers for a wonderful talk. Um we have quite a few questions in Slido right now. Uh I'll read from the top. Uh you can upvote questions in Slido if you have any you like that cover something you're interested in. Uh our first question uh are there any well-maintained libraries of cloud IOC's? Yeah. So as we mentioned there are not uh currently we are trying

to build one in our public whis research IOC's um repo but it is missing a lot of data so any contribution to it will be very very appreciated one moment slido is rebelling great

uh next question uh this is kind of specific but have you come across a threat actor using that call one Yahoo email addresses for accounts. That is quite specific. That is very specific and I'm I'm afraid I haven't uh run into that specific red actor. But do tell us more. It sounds like an interesting story. Is anyone here who submitted that question that would like to Sure. Would you like to elaborate? Well, I mean, maybe catch up after this, but uh I work at Back Blaze and we've encountered this group person a few times and they keep acting like they aren't the same person while using that coal one email address every time. Yeah. So interesting.

Couldn't make this stuff up. Um, next question. Uh, is there value in more generalized cloud IOC or other taxonomy integration to ensure it fits into the the mental framing? Can you repeat that please? I haven't got it. Uh, yeah. Uh, is there value to a more generalized cloud IOC or other taxonomy integrations that could ensure a better fitting mental model? There were some words there that I don't know. I'm sorry. I think if I understand correctly like to integrate cloud IOC's into existing uh models like sticks or stuff like that that is my interpretation. Yeah. Yeah. Um I I'm I mean sure extend expanding sticks to also include clouds will allow it to be integrated easier into existing uh

security solutions that know how to work with that data and I think we as a community we should be able to define exactly what those IOC's the most important ones are and add them to the format. Um next question. What are your thoughts on balancing sharing within the security community and keeping information close to slow the arms race? So, I think that um there's definitely a balance here and especially when it comes to very active actors that maybe um if we reveal things about their victims, this can be uh risky. However, I think that right now in the state of like a desert of cloud IOC's, um I think the pros outweigh the cons. And

obviously you we should all use our uh own uh I don't know perception of a specific situation but um I definitely would like to see more sharing of this knowledge even if it's a little more on the risky side of things maybe we got uh one question that just came in uh go Tottenham I have no cont right now uh how are behavioral IOC is meant to be consumed. Right? This is a good question and it's uh difficult for us as well. That's not something you can really use machine readable feeds that we know right now. Um so we can only uh use these kind of blogs and reports really to put these things out there. Um Gilly do you want

to add something? I think just like we mentioned with traditional IO with atomic IOC's uh when the data is out there and we have reports and a standard of of posting those things tools will come out tools that know how to use that data but first we need the data to run on like you can't expect someone to develop a very complicated tool that knows how to extract logs and then try to match IoC's if you have no behavior IOC's existing out there that does make it tricky um I think that's it for a Q&A we do have another minute if anyone in the audience has a question they'd like to get out. Otherwise, I can go right

into announcements. No. Well, thank you again to our speakers for the fantastic presentation and wonderful Q&A from everyone here.