 Hello everyone thanks a lot for coming today. I hope you are having a great time at the conference. I couldn't make it to the end of the day so what you're going to see next is a version of this talk that I recorded a couple of weeks ago just for you. That said, I am hanging in the chat right now so I'm looking forward to the questions and the discussions that we're going to have together. Let's get started. Today we're going to talk about Stratus Retim which is an open source tool that we released here at DataDog a couple of months ago. We're going to see why we built it, how you can use it, and some background on more advanced usage as well. My name is Christophe Taffani de Roper. I work as a cloud security researcher and advocate at DataDog. Feel free to send me any message, email if you want to discuss this, if you want to challenge some of the things that I say today. And yes, today we'll start by introducing a few things around detection engineering, purple teaming, then we'll move to some of the pain points of purple teaming in the cloud which led us to build Stratus Retim. So we'll see how we built it, what it looks like. We'll continue with a small demo and finally we'll discuss a few more advanced use cases. I want to stop for a bit on how as an industry we work on detecting malicious activity. A few years ago, we used to use mostly indicators of compromise, things like hashes, IP addresses, binary names, things like that. Because the idea is that it's pretty easy to share those across organizations and that if you share that with partners organization, it's easy for them to prevent some attacks because an attacker that is going to reuse the same infrastructure, the same binaries, is going to get caught more easily. And as time goes by, we noticed that hashes, IP addresses, domain names are pretty easy for attackers to change. If you think about binary hashes, it's very simple to change. A single byte changes and the whole hash is not the same. For IP addresses, it's the same, domain names, etc. And this figure here you see is called the pyramid of pain. And basically, as you move up this pyramid, things become much harder to change for an attacker. And if you think about the tools or the way that they work, maybe how they persist, how they exploit data, this is something that they're typically not going to change easily. And for defenders, it's a bit around the opposite. If you think about a hash or an IP address, it's pretty simple to detect. If you think about tools and behaviors, it gets harder. But generally, as an industry, we've been moving towards detecting not only hashes, IP addresses, domain names, and this kind of indicators of compromise, but also more behavioral things. And so there are a few models that exist to model how attackers work, what behaviors they have. The most famous is, of course, Mitre attack, which has also a version for cloud and for containers. There's also the Kubernetes threat metrics from Microsoft that basically is focused on Kubernetes and containerized environments. Now, on purple teaming, for sure, it's a buzzword. So I just want to stop to demystify it a little bit. A lot of organizations used to have a blue team and a red team that wouldn't really work together. And the way it would work is that the red team would simulate some attacker behavior and the blue team is left to detect it and to prevent it. And purple teaming is really about making these two teams collaborate, exchange information, empower each other. And that's what I want to use as a definition. And I want to also underline that purple teaming is supposed to be a mentality, a way of working and not a team by itself. So for this presentation, I want to define it as empowering defenders to understand, reproduce, and detect common attacker tactics. And you will see that also sometimes abbreviated as TTP. Now, the way that this usually works, let's say I want to detect a specific kind of attack. I'm going to first try to reproduce it to see how it works. I'm going to see what kind of logs do I have, what kind of alerts can I leverage anything that I have to detect that. So I'm going to craft this detection. And I'm going to iterate on this feedback loop to make my detection better. And the main issue that we see is that reproducing the attacks is pretty hard in the context of cloud environments. If we take an example, let's say that we want to detect when VPC flow logs are removed. VPC flow logs is a construct in AWS where you can have some net flow data on your network traffic. So it's pretty interesting for an attacker to try to remove that so that they can cover the tracks. So if we want to reproduce that, first thing we do, we create a VPC in AWS. Then we go ahead, we enable VPC flow logs. And this gives us a state where we are ready to reproduce the attack. First step, we will reproduce it. We can just delete VPC flow logs. That's the theory, right? But if we go to the AWS console and we do it, it looks like this. We create a VPC, we give it a name, an IP range. Then we go to flow logs, we create a flow log configuration. Then we are asked for a few things. Where do we want to send the logs? The destination log group name, but we don't have any. The IAM role to use, we don't have any. So we go to the documentation. We see that we need to use an IAM role that has a specific policy so that the VPC flow log service can write to our logging things. Okay, then we see that we need to attach a trust policy to the role that allows the VPC flow logs configuration to assume it. And at this point, we are not really doing what we wanted anymore. And in the end, what we notice is that we spend a lot of times setting up the right cloud infrastructure, configuring things, and actually very little time testing our threat detection. So that's an issue because it means it's hard to iterate on this cycle. It's hard to reproduce the attack techniques. It's hard to make sure that you can clean up everything you need. So that's really around these two challenges that we build strategy threat team. The first one being how do we handle complex testing prerequisites in AWS and Kubernetes? And second one is, as an industry, we have to be very honest that the cloud and containers are still a pretty new topic. So we don't have a lot of good data on incidents in the wild. So for defenders, it's hard to say what to prioritize. And this brings us to strategy threat team. And I like to say that strategy threat team is something that allows you to help with purple teaming in the cloud. Strategy threat team, first, it has a very nice logo. It's an open source project that I like to pitch as atomic threat team for the cloud. Atomic threat team is a project by Red Canary, which is focused on endpoints. And it allows you to reproduce some common attack techniques very easily. And we try to be the same for the cloud. It's written in Go, so it's a single binary that you can download through homebrew or directly from GitHub and run without installing anything else. It's packaged with a few cloud attack that comes with the binary. And currently it supports AWS and Kubernetes. The first question that we had when building it was, what kind of attack techniques do we want to package? And the philosophy what we ended up is two things. First, we want all the attack techniques to be as code. And as you'll see in a bit, they are defined as Go code and Terraform code. Then we want to be very opinionated and intentional about the attack techniques that we have. What we want is we want them to be actionable for defenders. So as a defender, you should be able to go to the strategy threat team documentation and to understand things to better understand what it does and how the attack techniques in the cloud work. And second thing, we want them to be threat informed. Essentially, we don't want attack techniques that are super new, that no one uses, and that no one should care about. So we try to prioritize a lot attack that have been seen in the wild, that are used by pentesters, by retimmers, by offensive tools. So again, strategy threat team is really around these two things. First, a catalog of cloud attack techniques. And in some sense, it's similar to Mitre attack, except that we are not scared about going very deep and being very specific to a single cloud provider like AWS, whereas Mitre attack is more trying to get the common ground and not trying to be too specific to a single service. And second thing is to have an easy way to reproduce the attack techniques in a live environment. So typically it's going to work like this. You're going to take strategy threat team, point it at your AWS account or to an existing community cluster, and you're going to use it to reproduce some attack techniques. Currently, strategy threat team has 23 AWS attacks and six Kubernetes one. You can see the full list on the website, strategy threat team dot cloud. It has the user guide, the reference of all the attack techniques. On the left, you will see they are sorted by platform. So you have some for AWS. And if you scroll down, you will see them for Kubernetes. Now, let's stop for a minute and have a look at a specific attack technique, see what it looks like, and how it's implemented. This one is going to be about stopping a cloud trail trail. Cloud trail is a way in AWS that you can log all the API calls that are made to AWS. And it's super important for defenders. So it's interesting for an attacker to stop it so that your defenders are basically blind. First thing you will see if you go to the documentation of an attack technique is the name, the platform. When you will see the mapping to my attack, you will see a description about what it does, how it works. And finally, you will see some detection leads. And the idea here is not to give a precise rule. It's more to say which log sources you have at your disposal to try to detect that. First thing you will see then is the Terraform code. And this Terraform code is completely hidden. So as an end user, you will never see it. But it's how it's implemented. So this Terraform code is going to handle the prerequisite infrastructure that you need to be able to reproduce the attack. Typically here, the attack is around stopping a trail. So first, you need a trail. And you need an S3 bucket to which the logs are going to be sent. You need to have the right role, the right permissions, so that this works smoothly. And the goal of that is to encapsulate all this complexity so that you can just say, go ahead, prepare this infrastructure for me. And I want to be ready to reproduce the attack. Again, this is totally transparent. So Stratus Stratim doesn't mess with your Terraform version. It doesn't require you to install Terraform beforehand. And it uses a Terraform wrapper that is written by HashiCorp, which basically downloads its own Terraform binary and takes care of everything you need. Then we have the attack as code that is written in Go, so in an imperative way using the AWS or Kubernetes SDK. And this is really what the attack is about. So now that I have my trail ready, I know that to reproduce the attack, I need to stop it. And in terms of lifecycle, an attack technique is going to live through three life cycles. First is going to be called. This is the initial state where you didn't start to work with it. Then it's going to be warm. And warm is the state where your prerequisite infrastructure is ready. So here to warm up this attack technique, my Terraform is going to create an S3 bucket and a cloud trail trail. Then once we are ready, we can go ahead and detonate it. And detonate is about reproducing, executing, simulating this attack. And this is just stopping the cloud trail trail. There are a few tools that can be quite similar to Stratus Stratim. So I just want to comment on it. And there is a page that explained this into more detail. So Atomic Red Team is more focused on endpoints. Leonidas by F-Secure is a great tool. It's a bit more complex to set up and also has more features. Pakoo is more of a penetration test framework. Gardity Tester is a big bash script basically that you can use to test Gardity, but it's specific to Gardity. And Cloud Goat is more of a set of vulnerable scenarios that you can deploy yourself. Now it's time for the demo. Let's start with the GitHub repository. On the repository, you will have the source code, the instructions to install it. So typically you can install it through Homebrew. You can download one of the pre-built binaries that are available for Linux, Mac and Windows. Or you can also use the Docker image that is listed here. There's also a website, Stratus Stratim.cloud. And if you go there, you will see that you have a user guide. You have frequently asked questions around the permissions that you need, how it works with its state, how can you package your own attack technique, and some questions around the design choices. Then there is the comparison with other tools that is a bit more detailed than what we did in the slides, a guide on how to contribute. And in the user guide, you will find some installation instructions, some examples, some workflow on how to use it with AWS, which is just quite simple as we'll see in a bit, and some references around the commands as well as a troubleshooting guide and some more information on how to use it programmatically. And we'll see that in a bit. Now the interesting part is around the attack techniques reference. So if you go there, you will see first the listing of all the attack techniques that we have for AWS for communities. You have some more background on the philosophy of what we expect from all these attack techniques. So we want them to be granular, we want them to emulate actual attacker activity, and we want them to be self-sufficient, meaning that we should be able to reuse any of these attack techniques without making any assumptions around the state of your AWS account or Kubernetes cluster. If you click on one of the supported platforms, AWS or Kubernetes, you will have the listing that is organized around my through attack tactics. So we have credential access, defensive vision, discovery, execution, exfiltration, persistence, privilege, escalation, and if we select one of the attack techniques, let's say we want to have the one that exfiltrates an Amazon machine image. We'll have the platform, the Mitre attack mapping, the description, the command line that we can just copy paste in our terminal, and some leads on how to detect it. Now, if we go to our terminal, we'll see that I have stratus version 170 installed. First thing I can do is to do a stratus list to see the attack techniques that I have packaged in my binary. If I want, I can be a bit more specific. I can do stratus list for a specific platform. This will give me only the attack techniques for AWS and also for a specific Mitre attack technique. Let's say I want to see the attack techniques I have for AWS for persistence. Now, if we do stratus status, we will see the status of each of your attack techniques. So here I can see they are all called because I didn't start to work with any of these. What I'm going to do now is I'm going to select two attack techniques. So this one, exfiltration of an AMI, and I'm going to warm it up. Now, what's going to happen is that stratus team is going to instrument Terraform under the hood. It's going to do a Terraform apply of my prerequisites. And here the prerequisites are going to be just an Amazon machine image that I need to be able to reproduce the attack. All right. Now it's telling me my AMI is ready. I'm going to warm up another attack technique, this one, which is going to be around backdooring an S3 bucket policy. Okay. So during the warm-up, it's going to create an S3 bucket. And during the detonation, it's going to backdoor the bucket policy. I see that it has created my S3 bucket. And if I do a stratus, stratus, I will see that these two attack techniques are now warm. So it considers that they are ready to be used. They are ready to be designated. If I go to my AWS console and I look at my list of Amazon machine images, I will see that now I have an AMI created by stratus red team. Similarly for my S3 bucket, if I go there and I search for them, I will see I have one bucket created by stratus red team. Now we'll go ahead and we do, instead of a warm-up, we're going to do the detonation. We'll do stratus detonate. And it's going to tell me, okay, I have backdoored your bucket policy. Similarly for the other one, we're going to detonate this one. And it's going to exfiltrate my AMI by sharing it with an external account. So again, if now I do a stratus stratus, I will see that my two attack techniques are detonated. And if I go back to my AWS console, if I go to my Amazon machine image and I look at the permissions, so I need to refresh it first, I will see that it has been shared with an external AWS account ID, which is the simulation of my attack technique. I go to my S3 bucket and I look at the bucket policy. I see that it has been backdoored to allow the access from an external AWS account as well. I know to clean up all this infrastructure, I just need to do stratus detonate of these two things. Sorry, stratus clean of this guy and this guy. And now I see that the attack techniques are called. So I am confident that I don't have any infrastructure left in my AWS account. And that's it. So what we have done is we have reproduced two attack techniques very easily. We use the warm-up, then the detonate command. But if we just do stratus detonate, it's going to warm it up and then detonate it. And in the end, we just do a clean up and it will be the same. It's going to remove all the infrastructure and make sure everything is clean up. Now that we have a good idea of how to use stratus strat team, I want to touch a bit on some more advanced use cases that you can do with stratus strat team. First one is going to be around continuous detection testing. So if we look at the typical logs pipeline for IWS, it's going to look like that. You have a cloud trail trail that is running, logging to an S3 bucket. You have something that is going to forward your logs to a logs management solution to a CM. The logs are going to be parsed. Your detection roles are going to run on these parsed logs and you're going to get some alerts. The issue with that is that it's pretty sure that at some point something is going to break. Maybe your trail is not going to log in anymore. Maybe the permissions on the S3 bucket are going to be messed up, et cetera, et cetera. So how can we test that? And the idea is to consider all of this as a black box to poke from one end using stratus strat team. And from the other side, try to use the API of your CM, of your logs management solution to confirm that an alert is created. And we can do that using the programmatic interface of stratus strat team. Basically, you can use stratus strat team as a go library. So if you do go get github.com data doc stratus strat team, you can use it from your code. And there is some automatically generated good documentation as well. So it looks like that. Basically, you are going to say get the instance of stratus, get the attack technique that is called AWS something. Then you can say, at the end of my code, I want to make sure it's going to be cleaned up automatically. You warm it up. Finally, you can detonate it. It's basically the same as we did in the demo, except that we can do it programmatically as well. And once we have that, we can basically poke from one end. So detonate the attack technique programmatically. Stratus strat team is going to inject a unique identifier in the user agent. And then we can go ahead and look in our CM if we have an alert for what we expect that corresponds to the logs with the same unique identifier. So typically in cloud rail, you're going to be able to see the user agent. And this allows it to correlate the specific run of stratus strat team with the alert that we get. And once we confirm the alert is there, we are happy because we know that we triggered an attack, a real one, and that we have alert that we expect. It's going to look like that typically. So you detonate the attack technique. You query the security alerts of your CM, of your logs management solution. And once you have it, so typically it's going to take a few seconds for Kubernetes. It's going to take more around five to 10 minutes for cloud trail. You're going to see the alerts. You can mark it as read. You can archive it. You can close it. And at this point, you're happy because you confirm that this is working end to end. What's nice with it is that you can run inside a continuous integration. You can run that on a nightly basis. And you can have some kind of dashboard where you say, today I tested these attack techniques. They worked. They didn't work. You can have some alerts based on that. So I think it's a nice way to make sure that your most important attack techniques are being detected as you expect and to be alerted when it's not the case. To conclude, around what's next. So first thing is that we want to add some additional attack techniques for AWS, for Kubernetes. We want to add support for Azure and possibly for GCP. And finally, we are super eager to hear about the community in terms of what attack techniques we should add. So typically things that you can see in the wild or things that you see used by red teams, by pentesters, by tooling. So the best way to contribute is to open an issue on the repository and to propose the attack technique. And then we will work on implementing that. So thanks a lot. I'm super happy that you showed up today. I'm hanging out in the chat to answer any questions, to discuss anything. So feel free to ask questions and go ahead and visit the website, the repository and feel free to send me a message if you want to discuss anything. Thanks a lot and have a great day.