CSO Perspectives (Pro) 11.28.22
Ep 92 | 11.28.22

MITRE ATT&CK In the Cloud.


Rick Howard: Back in August of 2022, I stumbled across three infographics from a commercial MDR vendor called Expel. MDR stands for Managed Detection and Response. And that category of security services is really the latest development in SaaS delivered SOC services, Security Operation Center services. The thing that distinguishes an MDR service from the traditional Managed Security Service Provider, or MSSP, is the use of APIs or Application Programming Interfaces. In the past, MSSPs would either receive logs directly sent from your security stack or the SOC analyst would log in directly to your security stack tools to monitor and collect telemetry. MDRs in contrast use API calls to collect that telemetry more, efficiently.

Rick Howard: If you think this sounds just like XDR, Extended Detection and Response, and EDR Endpoint Detection and Response, you would be right. But with MDR, you outsource the XDR EDR task to a contracted SOC like Expel. Anyway, what caught my eye was their published one-pagers mapping the API calls within AWS, Amazon Web Services, and Google GCP, Google Cloud Platform, that cyber adversaries typically use when they are traversing the intrusion kill chain to the MITRE ATT&CK framework. They are brilliant. In one easy to read diagram, all of the information that a SOC analyst might want to track is right there. I had to talk to these guys to see what they were trying to do. 

Rick Howard: And then I remembered that Greg Notch, the Expel CISO, is a regular visitor here at the CyberWire Hash Table and, by the way, a very old friend of mine. I asked him to hook me up with somebody at Expel to walk me through the diagrams. So hold on to your butts. 


Samuel L. Jackson: (As Arnold) Hold on to your butts. 

Rick Howard: This Rick the Toolman episode is about tracking cyber adversary API calls in AWS and GCP across the intrusion kill chain using the MITRE ATT&CK framework. 

Rick Howard: My name is Rick Howard. And I'm broadcasting from the CyberWire's Secret Sanctum Sanctorum Studios, located underwater somewhere along the Patapsco River near Baltimore Harbor, Md., in the good ol' USA. And you're listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. If you've been listening to this show for any length of time, you know that I'm a huge advocate of intrusion kill chain prevention as a first principle security strategy, so much so that you probably wish that I would just shut up about it. Well, just so you know, I'm not the only one. 

Etay Maor: Hi. This is Etay Maor. 

Rick Howard: Etay Maor is the senior director for security strategy at Cato Networks, one of the first SaaS vendors, by the way. And Etay is one of our newest guests to the CyberWire Hash Table. Here's what he has to say about the goodness of the MITRE ATT&CK framework and how the tool is just as useful in cloud environments. 

Etay Maor: Well, we had a lot of success with it. In fact, we actually used MITRE to tag a lot of the different activities that we see on networks to understand what it is that adversaries are doing or trying to do on enterprises networks. MITRE ATT&CK has a lot of applications. With that, you can understand, for example, different trends or different types of attacks that our attackers are using most. If you know that a certain threat actor is targeting you, you can actually look at what are the different tactics and techniques used by that threat actor and prepare for that. It can be used also for gap analysis. 

Etay Maor: So you can actually use MITRE to map out the different defenses that you have and then layer on top of the different attacks that you're experiencing or the different attacks that threat actors are planning to use based on your threat intelligence and see if you have any gaps - certain techniques that the attackers are using for which you don't have defenses for. Of course, you don't have to leave it just as a gap, but you can also use it then, using tools like Caldera and Atomic Red Team. And also, MITRE are now offering their own micro tests, I believe they call it, so you can actually test these things out. 

Etay Maor: Now, while MITRE does have a lot of information about nation-state actors, it is also applicable, usable for modeling and understanding non-nation-state attacks. We are seeing different types of attackers and threat actors using these techniques, things like targeting specifically the cloud, so using, for example, legitimate cloud services as command and control servers or bots. So it can definitely be used for non-nation-state attacks. And also keep in mind that nation-state attacks are not necessarily targeting critical infrastructure, but you have a nation-state threat actors or different APT groups that have financial motivation as well. And they're also included in the MITRE framework. 

Etay Maor: So to summarize, yes, I think MITRE is a great common language now used both for describing different types of attacks, but also for tagging them and then being able to enrich your data and creating almost stories and visuals that help you understand what are the threats that you're facing and how they're working on your network. It can be used for statistical analysis, can be used for gaps understanding and testing. And it is definitely applicable in the cloud. And we're going to see a lot more of it. 

Rick Howard: Kyle Pellett is the senior detection and response analyst at Expel. When I called Greg Notch, the Expel CISO, Kyle is the guy that he introduced me to. And Kyle has one of the most interesting career paths that got him in the cybersecurity. He started out as a commercial underwater diver. So I had to ask him about that. 

Rick Howard: So you've been with Expel coming up on three years by the time this interview airs. And a quick glance at your LinkedIn profile suggests that you're one of those, shall I call it, career changers - OK? - meaning you were doing one thing professionally and then decided to go into a completely different direction, cybersecurity. And I've talked to a lot of those folks over the years, but your past profession might be one of the most interesting ones and at least unique ones that I've come across in my entire career. You were a commercial underwater diver, of all things. Talk to me about that path. What got you into diving in the first place, and what caused you to come over to the dark side with the rest of us cybersecurity people? 

Kyle Pellett: Yeah, for sure. So it is a unique path. It's a small community of commercial divers right there. It's a little bit more like surface-supplied air, wearing the hard helmet instead of, like, goggles and a breathing apparatus. But, yeah, it's - that path started. I was actually driving over the Tacoma Narrows Bridge where I live in Washington. And I looked over, and I saw people jumping in the water, constructing this bridge, which I thought was the coolest thing. And while I was doing that, I was hearing on the radio, you know, do you want to go explore the world and, you know, all this adventure and excitement? And I just stopped what I was doing, and I called up the school and went and got certified to do that. 

Rick Howard: How old were you when all that happened? 

Kyle Pellett: I was - I think I was 18 at the time. 

Rick Howard: Yeah. 

Kyle Pellett: I was just - it was just, like, a spur of the moment thing. I was kind of on track to do a degree program, right? I wanted to, like, sell websites, right? This is right around 2008. So I'm like, yeah, that's a great industry. But then I opted for the - go use the, I guess, youthful years to go explore and do something somewhat dangerous. 

Rick Howard: Go do adventure first before you had to get into the seat and, you know, look at a computer screen all the time, I guess, right? 

Kyle Pellett: Yeah, something like that. I gave it all up, and now I'm back, right? So... 


Rick Howard: You said you traveled all over the world. What are some of the most interesting places you've been? 

Kyle Pellett: We had all sorts of different jobs. I was mostly, like, an inland diver. I mostly stayed local. So the company I worked for - they did, like, the Costa Concordia, helped on that salvage. They had some Saudi Aramco, like, oil stuff. But I was mostly, like, an inland, like, non-potable water. That was kind of, like, my specialty, if you could call it that. So I was in, like, power plants and water you wouldn't want to drink, so to speak. 

Rick Howard: Yeah - well, all very interesting. Welcome to the cybersecurity world, though. We're glad to have you, right? And like I said, you've been working at Expel for almost three years. And so tell us what Expel does for its customers. 

Kyle Pellett: Yeah, so Expel is a MDR service. Our customers are looking for a security team to work with the tech that they have. So it's really important for us to provide a strong aptitude in whatever avenues of security products they have, right? So we'll monitor their alerts. We'll investigate with them. Sometimes we try not to just throw things over the fence and say, hey; we saw something weird. You know, go deal with it. We want to be there to really provide more than that. We want to get answers and remediation and hopefully resilience so it doesn't happen again. 

Rick Howard: And with that kind of service, what's your job there? 

Kyle Pellett: So I started as, like, a frontline SOC analyst. So I'm reviewing alerts. I'm making calls. You know, I'm getting paid to make decisions, ask investigative questions. And I got promoted up to, like, our senior level, so we - a little less on the frontlines. Like, I still help the team out, get people up to speed doing what we need to do. But I also get the luxury of, like, stepping away from that frontline and tracking red teams and real critical incidents. 

Rick Howard: So today we're talking about the MITRE ATT&CK framework. And the reason I asked you to come on the show is that you guys published a series of white papers this past summer about adversary playbooks in the cloud. And what I mean by that is that you mapped cyber adversary activity about the intrusion kill chain, but specifically, you captured what these groups did - their tactics, techniques, and procedures - as they traversed big cloud environments like Google Cloud Platform, GCP and Amazon Web Services, AWS. So what was the goal there? What were you all trying to do when you published those papers? And what was the difference between what was in that that we couldn't get from the MITRE wiki with similar information? 

Kyle Pellett: Yeah. So I think the goal, for starters, is we want to equip defenders like us. When we get dropped off in a forest of logs - right? - we're looking for these breadcrumbs to just understand, like, how far an attacker may have gotten, right? Assuming that it's an incident - right? - something bad happened, we wanted to call out, like, ETITs - like a guiding map, so to speak, of, like, how to navigate and maybe what to look for. What it isn't is something where you can just look for these things and you're considered secure. People are going to be in investigation. Maybe they're stuck, and they're like, I don't know what they did after this. And maybe a glimpse of this would say, like, oh, this is maybe where they were going to exfiltrate data or maybe how they laterally moved. It's really highlighting the API keys, which is the closest thing we can get to attacker behavior on that, like, API level. 

Rick Howard: Well, the reason this caught my eye is I just don't see this anywhere, and that's the reason I reached out to you guys. I have this debate with folks that come on the show - is that trying to prevent adversaries traverse the kill chain is no different in concept from traditional way they do it through the firewall, down to the network, onto the endpoint. Compared to how they do it on the cloud, they just do it a little bit differently. But the concept is the same. And when I saw that the bulk of the things that were in the white papers - all your API calls that bad guys have to use to traverse the kill chain, I thought that was brilliant - totally obvious in hindsight. But I'd never seen it before. So my hat's off to you guys. What got you on to that whole thing? 

Kyle Pellett: Yeah, I think the - like, so we - I'll be honest. When I started here, AWS was new to us - right? - or at least to me, mostly to me. And we're like, it sure would be nice if we could help new people really spin up because, like, we're familiar with - you know, oh, they had a new domain admin, and then they ran Mimikatz, right? Like, that's easy. We can point to that and say, this is the thing that's bad... 

Rick Howard: Yeah, yeah. 

Kyle Pellett: ...In the cloud. 

Rick Howard: We know about those things. Yeah, right. 

Kyle Pellett: Yeah, exactly. You're familiar with, like, what bad looks like. In the cloud, it's kind of - it's a little more abstracted because now you're in, you know, cloud land, GCP or AWS. And they have their own words for things that mean very important security principles. So if you're just not familiar with the API calls and running an investigation down, you kind of have to start from scratch. And that's where the AWS Mind Map came from originally. And it did a really good job to level set. Like, OK, we've seen enough bad to notice a trend, and this is what it looks like. This is how they're laterally moving. This is how they're getting initial access. And typically, like, this is what we can say about it. Like, we're confident enough that we've seen enough incidents in the cloud that we can talk about it. 

Rick Howard: Well, I know what you mean about the overlap. I did a deep dive last year on this show about all the security services that all these cloud platforms offer. And they all sound eerily the same, but they're all just a little bit different, right? And so it's not a one-to-one mapping. You know, an Amazon service that has a similar sounding name to what Google does is probably not doing it the same way. So it's very confusing to figure out what you should be doing and how they should be operating across the board. So I totally get that idea. 

Rick Howard: After the break, we're going to hear from Steve Winterfeld, the Akamai Advisory CISO, about the MITRE ATT&CK framework's special section on cloud tactics, techniques and procedures. We're also going to do a little, small diversion about one of my favorite graphic designers, Edward Tufte. And we'll finish up with my interview with Kyle to talk about using the Expel infographics in the SOC and attributing adversary campaigns in the cloud. Come right back. 

Rick Howard: MITRE released version 12 of the ATT&CK framework at the end of October 2022. In this version, they have introduced the idea of adversary campaigns, something we've been talking about here at "CSO Perspectives" for about two years. It decouples the adversary group name from their various attack sequences, making them two different entities. In other words, don't associate Panda Bear, a group name, with all of their attack campaigns through history. Instead, name campaigns as a grouping of intrusion activity conducted over a specific period of time that may or may not be linked to a specific threat actor or may be linked to one or more threat actors. The campaign across the intrusion kill chain is the important thing, not the adversary group name. 

Rick Howard: That was Steve Winterfeld, the Akamai Advisory CISO, my best friend by the way, and a regular here at the CyberWire's Hash Table. "CSO Perspective" fans have started calling him the Al Borland sidekick to these Rick the Tool Man episodes. He and I were talking about using the MITRE ATT&CK framework to track adversary campaigns in the cloud. And he pointed out that the framework has these subsets of TTPs called matrices that track adversary techniques for specific situations, like cloud environments. But there is also matrices for preattack, operating systems - like Windows, macOS and Linux - networks, containers, mobile devices and industrial control systems. Here's Steve. 

Steve Winterfeld: So, Rick, one of the things I'd love to talk about is the MITRE ATT&CK framework. You know, it is such a great tool. It can be used in so many different ways. At the very top level, it follows a attack methodology similar to the cyber kill chain. I think that had seven steps. So MITRE breaks it out into 11 different categories of types of attacks. There's a framework for industrial control systems, another one for insider threat that just came out. They've mapped it to different APT actors, but they've also - you know, there are so many different attacks for every different environment. There's a MITRE ATT&CK framework specifically for the cloud matrix. So when you go there, you'll see those ATT&CK methodologies that work aimed at the cloud. And again, you can use it to map and measure maturity with your red team. You can use it for training within your SOC and making sure people understand those different ATT&CK techniques - just a phenomenal resource. 

Rick Howard: Looking at the two Expel infographics on typical adversary API use in GPS and AWS reminded me of one of my favorite information design authors, Edward Tufte. He was my introduction to information design. Back in the day, he published four books on the subject, and they are just gorgeous to look at and cover both good and bad information design examples throughout history, like the horrendous charge that NASA engineers used to try to convince leadership not to launch the Challenger space shuttle in less-than-optimal weather conditions. The answer was buried in the slide deck with multiple bullet indentations and shrouded in acronyms. The NASA leadership team didn't know what they were looking at. Or like that fantastic diagram from Frenchman Charles Joseph Minard that visualized Napoleon's 1812 marks to Moscow - on one piece of paper, Minard captured Napoleon's route, the descending temperatures as the army marched into Russia, the size of his forces through the period and how the force dwindled after the battle and after each winter river crossing. And while I'm no expert by any means, a few of Tufte's lessons have stayed with me over the years. And the Expel infographics seem to follow his good design rules, I'm just saying. So I asked Kyle if these infographics were a tool that he and his team use in the SOC on a regular basis, or do they represent just a straightforward way to organize the information? 

Kyle Pellett: I'm pretty familiar with this one particularly. So for me, it's - it would be fun to print it out and point to it and be like, oh, I'm right here today on this incident, but (inaudible). Yeah. 

Rick Howard: Here's my map (laughter). 

Kyle Pellett: When I - like, I guess when I was first getting started with, like, understanding cloud intrusion and, like, what is - what am I looking for? I just had that up in a tab, and I'm like, I need to make sure that I'm not seeing these API calls - right? - 'cause we'll use robots to do some enrichment when we do get, like, say, a GuardDuty alert or some vendor alert. And it kind of drops off in the middle of nowhere, and it's up to you to be like, OK, so if this is bad, that assumes we're, you know, five stages into this kill chain. So they must have got in somehow. Maybe they created it like a service account. They spun up some resources because what - maybe what the alert we're looking at is, like, a coin miner or something, right? So we're - we got to figure out how they got there. And that's - that was really the backtracking aspect that - it was useful for me to, like, say, OK, if we're assuming this is bad - and it probably is - we should be able to prove these other steps along the way. 

Rick Howard: Well, and all the things that you guys got to be collecting for telemetry for cloud access, there must be gazillions of API calls. The fact that you guys are centering in on these handful, all right, and say, you know, these are the ones that we should be looking out for at least as a starting point, I think that's very valuable. It would be for any SOC analyst, I believe. Is that how you talk to your customers about this? 

Kyle Pellett: You know, we try to make it as easy as we can. And sometimes easy as we can is paging up, paging down through thousands of logs in Excel and being like, OK, this looks like normal for this environment. But elsewhere, maybe in other environments this is not normal. So there's a lot of, like, baselining we have to do. Whenever we get into a new customer's environment, we really need to understand what's normal for them. Maybe they use a lot of cloud functions, right? Maybe they're spinning up S3 buckets publicly all the time, you know? There's just all these things that aren't always bad. But for us to kind of acclimate to that environment, we do need to come up with the top talkers for when it is bad. We'll use, like, color coding. Like, OK, this is, like, a red API whenever we see it, but it's not always bad. 

Rick Howard: It's something that we should make sure it's not bad, right? That's what you're saying. 

Kyle Pellett: Yeah, exactly. Like, it should raise some eyebrows - this, you know, service account access key getting created by some Tor IP. That's interesting. That's probably not good. And if it isn't good, we're going to get to the bottom of it. Like, one example I can give is - we have a customer that spins up resources in AWS to do interviews, right? And before we talked to the customer and understood what they were using this particular resource group for, it just looked like straight compromise - right? - like, web application, pen testing, style. It must have been for, like, a technical aptitude interview. But yeah, we're seeing all sorts of weirdness come out of this, and it... 

Rick Howard: And just being able to have that at your fingertips to be able to say this looks like something that shouldn't be here versus this looks normal - that's one step ahead, right? That's where this is going. 

Kyle Pellett: Yeah. And it gets a little subjective. Like, how do you make a behavioral detection that's going to hit all the customers all the time? 

Rick Howard: Yeah. 

Kyle Pellett: And that's really what it comes down to. Like - and we need to filter out noise. So maybe we start to get familiar with what certain job roles would even be in AWS, changing permissions or setting up policy bindings. If you don't have a history of doing something in the cloud and we don't have any further visibility - right? - maybe we don't have cloud access logs at that time for whatever reason, or maybe we're not equipped to have the greatest visibility at that time. That'll really quickly illuminate, like, hey, we need to have better visibility of what's going on surrounding this activity. 

Rick Howard: One of the things I didn't see in either of the white papers for Google or AWS is any kind of attribution of advisory group campaigns. So regular listeners of my show know that I'm a big fan of this kind of attribution and not necessarily attribution of who is behind the attacks - like Russia or China or North Korea - but more attribution of a regular campaign that they use. Like, for example, if you go to the MITRE ATT&CK wiki, Hafnium is an attack campaign, and they're suspected of being state-sponsored cyberespionage out of China, but that's not what's important. To me, in my mind, the important part are the 21 tactics, techniques and procedures that they use in the entire attack sequence. 

Rick Howard: Or, if you go over to the Tidal platform - Tidal is a company trying to operationalize the data in the MITRE ATT&CK wiki - they have information about APT28 or Fancy Bear. Those guys have 89 TTPs in the attack sequence. In my mind, I don't want to target one TTP in a collection of the thousands, you know, listed on either the MITRE wiki or the Tidal platform, with no relation to the attack sequence. I want to stop the entire sequence because I know that it takes time for adversaries to build these things. And they may change out one or two TTPs because they either don't work anymore or they find something that works a little bit better, but they rarely change out the entire sequence at once. So that was a huge, long explanation to ask that question. Do you guys attribute cloud adversary campaigns? 'Cause I find that to be very interesting. 

Kyle Pellett: One time, we had a - like, TeamTNT is a pretty prolific, like, crypto mining group, right? But it's more than that, right? 'Cause it's like once you see all the scripts that are executing, it does - it'll scrape access keys for cloud, right? So that's, like, a whole nother avenue that we need to then branch and be like, OK, if they got access to this, we need to go and check all these other things, right? Like, we really hope that these mind maps are helpful for defenders, right? And whenever something catastrophic happens - right? - I'm thinking, like, a Log4j situation or, like, anything big for us. And when it starts happening in the cloud, we expect there to be a lot more demand for, like, please explain - why is this happening? The question I would pose is, like, is there a better format to do this? And, if there is, we're all ears. But here's what we got so far, so we're just going to keep rolling this strategy out there. 

Rick Howard: For me, the MITRE ATT&CK Cloud Matrix is a simple spreadsheet of generic TTPs across the intrusion kill chain. And don't get me wrong. I love it. But the Expel, GCP and AWS versions are exponential advances in information design that are specific to those cloud environments. And on one page, chose the MITRE ATT&CK TTPs, the specific cloud services those TTPs leverage, the identity and access management services associated with those cloud services and all the API calls. Brilliant. 


Tim Allen: (As Tim Taylor) Oh, yeah (laughter). 

Rick Howard: The one piece that is not shown is an overlay of known adversary campaigns. 


Tim Allen: (As Tim Taylor) Oh, no. 

Rick Howard: That's the intelligence the SOC needs - a diagram similar to the Expel diagrams that show how Panda Bear executes one of its campaigns through these cloud environments. But that's not a criticism. It's more of a suggestion for the next version. I highly recommend that you all take a look at these current versions. I think you will find them immensely useful. 


Tim Allen: (As Tim Taylor) Oh, yeah (laughter). 

Rick Howard: And that's a wrap. 

Rick Howard: I'd like to thank Kyle Pellett and Greg Notch, both working in Expel, for helping me put this together, and Etay Maor from Cato and Steve Winterfeld from Akamai - the Al Borland to my "Rick the Toolman" - for providing some clarity to this topic. 

Rick Howard: Next week, we'll be addressing our most requested topic here at "CSO Perspectives" - how do newbies become CISOs? You don't want to miss that. 

Rick Howard: And as always, if you agree or disagree with anything I have said, hit me up on LinkedIn or Twitter, and we can continue the conversation there. Or if you prefer email, drop a line to csop@thecyberwire.com. That's csop@thecyberwire.com. And if you have any questions you would like us to answer here at "CSO Perspectives," send a note to the same email address, and we will try to address them in the show. 

Rick Howard: The CyberWire's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design and original score. And I'm Rick Howard. Thanks for listening.