 YouTube, so it'll be interesting to see if we get more people over there. How many of you are brand new to atomic red team? Mostly brand new. Got a couple new. Matthew, not that new, yep, I know that. It's 7 a.m. for me, so that's a little early, so I'm yawning a little. Looks like we're getting a few more attendees. We got a couple more minutes up to 19 and go to webinar or Zoom, whatever Zoom calls it, webcast. I don't see any action over in the Discord atomic red team channel. That's where we're going to be or I'll be on afterwards to answer questions if you get stuck on the labs. And it won't be here on the chat, so you'll want to get on there if you're doing the labs and want to ask questions over there. See some people typing over there. Matthew, can you post the Discord link in the chat just in case some people aren't over on the Discord yet? I'm on it. There's also someone having trouble with the Zoom link from Eventbrite. Okay, we've got a few people. Can we just post the same Zoom link over in the Discord channel that we're using? Since it looks like some people aren't getting connected. Yeah, I'll do that right now. So we'll just hang on a couple more minutes. For those of you who are in the year, what Zoom link did you use? Did you have a different source besides the Eventbrite meeting? Okay, I'm going to go ahead and get started. Hopefully the others can join quickly with the new link posted. Okay, use the open with the app, not the web browser option. Maybe we can post the YouTube link too. So people can fall on there if they're having trouble with the Zoom meeting and they'll be essentially the same thing. There we go. We got the YouTube channel. Yeah, so I post both the Zoom and the both the Zoom and the Discord. Sorry, it's early morning. The Zoom and the YouTube link are posted in the Discord Atomic Red Team channel. And I think we're in 902. This is your host, Carrie Roberts. She's awesome. She knows Atomic Red Team very well and we're all in very good hands. I hope you'll enjoy. I'll hope you keep it interactive post in the chat. It's always fun when you're giving a workshop that you feel that people are there. They are understanding and they are following along. So please be very active and supportive. Thank you and enjoy the workshop. Yeah, let's go ahead and get started. Let's click this. So my name is Carrie Roberts. I have background in web application development and I have kind of a fun and kind of a not fun at the time. It wasn't fun story about getting into information security. When my web application failed a pen test or a security audit miserably for things like SQL injection and cross-site scripting back in 2010. And at that time I had never heard of either of those things. And so I really felt like, oh, I can't believe that my application is completely hackable. I was like, I can't be a developer if I don't know anything about security. So I was like, maybe I'll just quit. That's a typical response after failure is just give up. And maybe I shouldn't be a developer, but then logic set in. And I realized that I could seek out some training on security instead of being scared of it and brace it. So I did that. I spent some time as a pen tester after that experience, which was a lot of fun pen testing for Black Hills. And the last four years I've been at Walmart two of those years was on the red team. Now I'm on the blue team. And I'm one of the atomic red team maintainers and developers. And that's what I'm going to introduce you to today. Atomic red team is in its most simple form, library scripted attacks. So they're the actual command lines, the actual things you type in or the actual things you execute to run specific attacks. So we have the MITRE attack framework, which is a great kind of grid of here's all the things that attackers are doing tactics and techniques they're using. And then atomic red team kind of fills in that last level of detail like, okay, so they're running Mimi cats to dump credentials. How do I actually try that to see if I would detect or block that? And that's where atomic red team comes in with the library of scripted attacks. And it was started by the red canary company. And it's free and open source. There's currently over 165 contributors. And so we the project benefits from this great community of folks who contribute these scripted attacks. Today, I'm going this one hour workshop is really a subjection of a larger class that I teach with my husband Darren about attack emulation. And so you can see atomic red team part one is what we're covering today. But if you're interested in more details on attack emulation and other tools you can use, including vector minor caldera purple sharp. And you can join us for the 16 hour class, but that one is a paid class. The schedule for today is we have one hour of lecture and which I'll just be demoing atomic red team and executing some tests and talking about how you might set up atomic red team for testing in your environment. And then that'll be followed by two hours of lab. So each of you will be giving if you registered will be given an IP address to make a remote desktop connection to. And there's a web page that you're going to go to and put in the email you registered with it will give you the IP address and the credentials to log into that VM, which is in Azure. And then you'll have access to the labs. Even if you don't get access to the VM, there's still also a link in the bottom of these slides to the lab walkthrough. So these are something you can download and take with you that you can run on your own VM. The lab VM that I give you is not special. It's just a Windows VM. It's just a safe place to run a bunch of things without breaking something of your own or a network of your own. But other than that, there's nothing special about it. It's just the vanilla Microsoft Windows installation. And the support for this will be giving for both the lecture today and the labs will be given through the discord channel, which there's a link in the chat here in zoom and also to the discord channel. Oh, yeah, one note about the two hours of lab time. So you have up to two hours to use the lab VM, but that that two hours can be used anytime within the six hours after class. So if you want to take a little break or have something else to do right after class, you can still do that lab time up until four p.m. Eastern today. More details on the labs at the end of class. Okay, so just to get us everyone on the same page with attack emulation, we want to start off with talking about the mitre attack matrix. So we're looking at a snapshot of the matrix here. It's like a table or spreadsheet and across the top there are tactics that attackers use to obtain their purposes. For example, there are certain techniques that they use under the tactic of initial access to get initial access. So that's your fishing and your external exploits. And then they do they'll do certain techniques to gain execution on your computer or the victim's computer. And then, of course, they don't want to lose the access that they got initially. So they'll do things to persist their access so that if the system they got access to gets reboot rebooted or kicked off the network that they when that system starts back up, they will again have access. And of course, there's many things they do to avoid being caught or eradicated by the defense under defense evasion. So those headings across the top are the tactics. And then as you go down one of these columns, like the tactic of credential access, you see many different techniques. So under the technique of gaining access to credentials, attackers may use brute force, they may use input capture, which is like a key logger. And then point keeping track of what person types to gain their access. And for each of these techniques, for example, exploitation for credential access, there is a technique number and that technique number is a number that starts with the letter T and then a four digit number like T 1003. And then depending on whether it's a technique or sub technique, so a child kind of a broken down, more descriptive version, there may be a sub technique number. So in this case, the dot 001 is a sub technique. So at a minimum, a technique number is like T 1003. There may be a sub technique number. And so every one of these cells on this spreadsheet has a technique number. And it may optionally broken be broken down into sub techniques. And that's important because that's how that's how atomic red team ties back completely into MITRE attack is by this technique number. So you'll see that one to one correlation of every scripted cyber attack and atomic red team is all uses that same technique number and ties right back into the MITRE attack matrix. So before we get right into atomic red team, we'll talk a little about the value of emulating attack attacks. So over on the right, I have a simplified chain of some things that have to be in place in order for you to be able to detect or prevent mostly detect malicious behaviors in your environment. So first, we have to capture the events or the telemetry from the endpoint. And then those events have typically are forwarded to a central collection agency. And then from that central central logging system, we apply some alert logic to go through and say, okay, of all these things are happening. Is there anything suspicious or anything we might need to worry about or alert on? And then those alerts get reviewed by an analyst, perhaps. And then if it really looks like it's something bad going on, that needs to get raised to the incident response team to have it dealt with. So that's an example of a few things that have to be in place in order for this whole detection pipeline to be working to be able to know that something bad happened and ultimately deal with it. And there's, I draw that as a chain because to point out that if any one of those links is broken, then the protection that you have set up is also broken. So there's a lot of moving parts and pieces, things that can break. And so one of the values that we can get by continuously emulating attacks is we can validate that that chain is in place. So before we had something like this scripted cyber attacks, we might have written a detection six months or a year ago. And we just assume that that detection is still working, that all those chains in the link are still there. But we really don't know for sure. So when we emulate attacks, we can continuously validate that our detection is in place. Of course, when we're emulating attacks, it makes it convenient to emulate that attack and then work to build the detection. Because if we're trying to write some alert logic, and there's nothing in our system to be hunting for that something bad happened, then we don't really know if we're finding what we're looking for because there's no examples of something to find. Another useful thing for attack emulation is actually tuning your configuration. So think about the Sysmon tool, how it captures different telemetry from our endpoints. Well, it can capture a lot more than we can feasibly store and search through. So we need to be able to tune those to keep what we would say is the important stuff and throw away the other stuff to keep that manageable. But we need to know how to decide, well, what's important? Well, if we're emulating these attacks, we can say, well, if in order for me to know the attack X, Y, or Z happen, I'm going to have to hold on to this piece of information, this telemetry. So then we can tune our security products to keep those pieces of information and perhaps throw away other pieces. And we can also, if we emulate attacks, we could compare different security products and say this product detected X amount and this one did Y and maybe we find that one product we're comparing is just duplicating stuff we have elsewhere and perhaps we can get rid of it. So here's an example of a scripted cyber attack. It's just four command lines. It's using the bits admin built in Windows tool and it's using bits admin as a tool to download things in the background while other things are running on Windows. So here it's setting up a job to download this bits.bat file. And then it uses the set notify command line option to stay after you get done downloading this file, please run notepad.exe. So this is a very benign example, but imagine that notepad is a piece of malware. And so now we have bits admin launching some malware and that's an advantage to an attacker because bits admin is a trusted process. And when it launches things, the parent of that process shows up as SVC host. So it could be, it would get less scrutiny from a blue team because that kind of looks like something that is legitimate. So if we were to emulate this attack in our environment, we could ask ourselves questions like is this happening in our environment? Are people using set notify command line? This in and of itself is not a bad thing. It's a feature built into Windows, but it really isn't very commonly used. So it's likely that you can set up some alert logic in your environment that says let me know if you see this because this is a tactic used by attackers. And if you do find that some admin people in your environment are using this, you could add them to an allow list and say it's okay if certain people in the IT department are doing this, but if I see this on a system over in HR or finance, then I want to know about it because I'll be concerned. And so when if we emulate this attack, we can definitely answer the questions like would this be detected? Would this be blocked? And that's the value of atomic red team and emulating attacks. So we talked about how atomic red team is a library of scripted attacks. There's also something else that we refer to as an execution framework. It's a thing that knows how to read that library because the library is literally like a bunch of command lengths that you could run and some rules about whether to run it in PowerShell or whether it needs admin. But in terms of running it, you can either copy those commands manually and follow the instructions manually or you can do that in an automated way with the execution framework. There's several execution frameworks. There's one provided by read in red canaries repository called invoke atomic red team. It's a PowerShell execution framework. And that's what I'm going to be showing today because it's a simple way to get started. But there's several other execution frameworks or tools that can utilize the atomic red team library of scripted attacks. For example, Caldera imports the atomic red team of library of scripted attacks. And it can be the tool that you use to execute those attacks in an automated fashion. Another example is the prelude operator tool. And then there's commercial tools, many commercial tools, including site that can read that library of scripted attacks and use them. So the biggest value and key takeaway from today is really atomic red team library of scripted attacks. The execution framework we're talking about is an execution framework. It may not be the one that best fits your needs. But that library is what you want to look into and see if it can provide value to you. Okay. So now I'm going to switch out of the presentation here. And we'll just go look through some things manually here. So actually, let me show you the desktop here. So this is I'm presenting from one of our lab VMs. So when you join, when you RDP to your lab VM, it's going to look just like this. You've got Chrome here, which you want to use because I've got all these bookmarks set up for you. So there's a link to your labs and there's shortcuts to other things you'll be using in class. So the labs are here. And you've got a link to the slides. And then there's seven labs that you'll be walking through. And so I'm going to go over here and I'm going to use this art atomic red team to get to the atomic red team GitHub repository. So atomic red team, let me zoom in here a little atomic red team project itself is hosted on GitHub and GitHub is a great place to share code like projects that many people can collaborate on easily because it allows you merge people's work together without overwriting each other's changes. So here's the main repository. There's a lot of stuff in here. So the first time you come here, it's a little overwhelming. Like where do I even get started? But we'll talk you through that over here. We can see there's 168 contributors so far. And that's been growing. I teach this webcast every couple of months. And I'm always updating the number here because it keeps growing. I want to point out that there we do keep this wiki up to date. And so if you click on wiki here, you've got the kind of about atomic red team stuff here. If I click over on the about atomic red team on the right, this actually goes through everything I'll be going through in the webcast today. It talks about how the library of scripted attacks includes tests for Windows, Linux, and Mac. And it shows you the MITRE attack matrix filled in with a red color for each of the techniques that has at least one atomic test written for it. I use the word atomic test as a shortcut for seeing one scripted cyber attack. So I call that an atomic. So you'll hear me call it that. But you can pull up an interactive MITRE attack matrix with the coloring showing how well atomic red team tests cover that space. And then it talks about the GitHub structure, which I'll go over today. And then it has some references to how you could execute these atomic tests, either manually or with an execution framework, which we also talked about today. And of course, there's a great section here on contributing. So if you want to contribute to the project, you can do something as simple as just submit an idea or a feature request or report a bug on the issues page all the way through submitting a pull request with your own additions or new tests. So we go, we go back to atomic red team. Just remember that wiki is there for your future reference. So there's a lot of supporting stuff in here that you don't need to concern yourself with. The really important thing that you want to look out from this repository is this atomic folder. This is where the library of scripted attacks lives. So if we go into this atomic folder with the exception of the indexes, every one of these folders is a MITRE technique number. So we see the T number, and in some cases, sub technique numbers. So you can see that we have scripted cyber attacks under many of the techniques here. So let's take a closer look at one of these. In one of these folders, we have at a minimum, each of these folders has two files, a YAML file and a markdown file. It may also contain a source and or a bin directory, which contains supporting files like payloads for the scripted cyber attacks. But at a minimum, you'll see that YAML and markdown file. So this YAML, which stands for yet another markup language, is a format, a text format, for defining things in a very machine readable way. So we can kind of make sense of this. It's for attack technique T 1016. We see that there's a list of atomic tests. There's one here, and there's some commands to run. But all in all, here's a second test, list windows, firewall, all in all, it's not that fun for humans to look through, although it's excellent for machines to read through. And that's why we also provide this markdown file in the repository. It gets generated automatically from the YAML file, but it's just much nicer to look at. So when you're browsing through the repository here, I recommend you just stick with the markdown file. The markdown file copies in the description right from the MITRE attack website to keep you from having to cross-reference what this technique is all about. And then it lists each of the tests. So here we have eight tests. And if we go to the first test, we see that this is just easier to read. So it says, run this with the command prompt, and here's the commands to run. So it's saying attackers will do things like use ipconfig, netsharp, et cetera, to get information or perform reconnaissance once they gain initial access to a Windows endpoint. And so one way that we could use this library of scripted attack, one is just read through and learn about different ways that attackers are doing things. Another way is we can actually copy this out manually so I could copy this and say, oh, I'm supposed to run this on the command prompt. I could start up the command prompt. And I could paste that in and that I'll just fly by. So now I've run all those commands. So I could go back to my logging and I could look through and say, is there something unique about this sequence of events that isn't common in my environment that I might be able to alert on and say it looks like somebody's doing reconnaissance in our environment. Is it legitimate or potentially an indicator of a compromised system? But running things manually gets harder as the tests become more complicated. Plus if you talk about wanting to run this continually, like maybe you want to run this test every month to confirm that a detection you have set is still working month to month, that gets to be not fun to have to go in here and copy and paste things out. So that's why we talk about an execution framework. Let's look at another test. I'm going to use the search feature up here to look for a test that uses the S delete tool. So here we go 1485. We've got overriding a file with S delete. So to do this, we just need to run the S delete tool against this file. But you see this weird variable notation, which is a hashtag squiggly and then a variable name. So we have this file to delete and that matches up here with our input argument. So we have this table of input arguments or variables that we can define when we run the test. We also have an S delete executable here, S delete. So the default value for S delete is in the temp directory in the S delete folder. So on our system, maybe we have S delete installed at a different location. So when we run this atomic test, we want to run it from maybe the C tools directory instead of the temp directory S delete, which is the default here. And maybe we want to securely delete some sensitive file instead of this test file. And so when atomic tests are written with these variables, it makes it configurable. But at the same time, it also makes it harder to just we can't just right click, copy this out and paste it into PowerShell because of all these variables. These variables also make it nice to do things like we have now this dependency section that's the dependencies say, here are the things you need to have in place that aren't on the system by default in order to run this test. So that S delete tool is a tool from Microsoft, Sys internal, so that doesn't come on Windows by default. So this test has a dependency or prerequisite that says the secure delete tool must be on disk at the specified location, which is S delete AXE right here. Of course, we could change that and run it from say C tools, but it uses that by default. So then we have a couple of commands that we can use. We can use this command to decide if we have that. So it's just checking whether S delete AXE is at that location. And if it isn't, then we can use these commands to get it. So here we're downloading the S delete zip file from Microsoft and then unzipping it and putting it in the temp directory or wherever we specify with our input argument. And this so this is also where the execution frameworks come in handy because we can ask it to check our prerequisites and see if we have them and get them if we don't. So I've already installed atomic red team. It's a PowerShell module for to speed up the presentation today, but the first lab that you do in in lab time and also the document that you get to take home with you is how to install and then import the atomic red team module so that you'll be in the same place I'm starting today. And that that walks you through all the little gotchas that you might have in your environment to get that install. Okay, so let's go back and look at using the PowerShell execution framework. So to do this, we can type in boat atomic test, and then you just pass it a technique number. So that first one we looked at about reconnaissance was T 10 16. So we can do T 10 16. And then there's some options we can use so we can add in a show details brief, which just lists the name of the test under that technique. So I'm going to go back actually to T 10 16 over here so we can compare what we see on the command line to what we see on the web. Okay, so here's all the tests under T 10 16. So if I push enter, it lists the name of the test, which it's got system network configuration discovery list windows firewall rules. And then it skips test number three right here test number three, which is also system network configuration discovery. So let's take a closer look at test number three. Test number three, it says the supportive platforms are Mac OS and Linux. So because we're executing the frame execution framework on Windows, it knows that only Windows tests apply here. So it's leaving out anything like Mac and Linux tests that don't apply to Windows. So that's why you don't see test number three here. But the rest of this you see matches up with the tests we see available online. And so we can choose any of these tests to run. For example, we could specify test number one that we want to run test number one. And we can also do a comma separated list here as well. But we're just going to stick with test number one. But before we run this, we can ask it to show us like instead of the brief details, the full details of this test. So we say show details. And now we have the technique name. So it's a little bit like the markdown, but on the command line, we have the description. We know that we should run this on the command prompt. And here are the commands we we should run. And so these are the same things we copy and paste it manually into here. But instead of doing that, we could just remove the show details and have the execution framework run that for us. And so we see the same output that we had over here when we manually copied and pasted. But we can see that we're getting closer to be being able to have this scripted and running on a regular basis in our environment. Okay, so let's look a little bit harder test. So we talked about um, T 1485, which was secured delete, S delete, it had some input arguments, it had some dependencies. Let's talk about, let's look at those. So we'll show the brief details just to see what tests are available. So there's only one test under T 1485 that applies to Windows. So instead of specifying a test number, if you want to run all the atomic tests under a given technique number, you just don't specify a test number. And it'll run all of them. So in the case of T 1016, that'd be like seven or eight tests, all, you know, back to back. And I'm just seeing if I'm missing any messages, doesn't look like it so far. So invoke atomic tests. So before we run this, let's show the full details and see some handy things that the execution framework does for us here. Okay, so one nice thing it does when it listed on the command line like this is it actually shows the input arguments in red. And so we can see that these are variables that need to be replaced, the file to delete here. And in the S delete executable. And then it also shows the command with input. So it actually takes these default values here and plugs them in. So here for file to delete, we see environment 1485, we see that as the default value here. And for the S delete executable, we see that it switches out this default S delete location. And then it also lists the same thing for the dependencies. So let's say we forgot to check if we have the dependencies and we just go ahead and try to run this, we don't have the S delete tool at that location. So let's see what it does. It says S delete is not recognized as the name of a command function. So S delete isn't on our system. So somebody's asking questions in French. Matthew will have to help me with that. It's actually me. I'm just saying that if you want to ask question in French, I can translate them. Oh, okay. Because I know that because I know there's a few French people in here. So that's why I wanted to say. Cool. Thank you. So let's let's use another feature of the execution framework, which is this dash check prereqs option. So now we run this. And it gives us this little red message that says the prerequisites are not met. The secure delete tool needs to be at this location. And it's not. And it says try installing it with get prereq. So this is a handy way for us to get S delete in the location it's supposed to be without a lot of hassle for us. So we can change this to get prereqs. And it's downloading the zip file, extracting it and putting it at that location in the temp directory. So now we can go back and just run the test. And it says one file deleted, secure delete. So it was successful. And now we could go and work on our detection that detects when files are being securely deleted, which is an attacker technique to hide what they've been up to from the defense. So that makes it easy. We also have an option with the execution framework to specify our own input arguments. So maybe we like we said we want to run S delete from the C tools directory, or maybe we want to delete a different file. So we could use the prompt for input arcs. And then it'll ask us enter value for S delete. And here's where we could say C tools, S delete, for example. And if we want to accept the default value, we just press enter. So we could press enter. So here it's having the same issue. It can't find S delete there. But you get the idea that this lets us set input arguments interactively. Of course, if we're scripting this to run every week, we're not going to have a human there to fill this out. So there's another way to set the input arguments in an automated fashion. If I go back to actually, I forgot to show you guys this, but we talked about how there's this atomic red team repository. But if we back up one level, if we back up one level, we see that besides atomic red team repo, there's also an invoke atomic red team repo. So atomic red team being this library scripted attacks, invoke atomic red team being one option for an execution framework, which is PowerShell execution framework. It works cross platform on Windows, Mac OS and Linux. But to use it on Mac OS and Linux, you have to install PowerShell core, which may or may not be an option for you. If it's not an option, then you'll want to look at some of the other execution frameworks, for example, mitre caldera and prelude operator would be options for you. Okay. So in this invoke atomic red team repo, the execution framework, there's also a great wiki. And over on the side, you see the menu of items, what's in the wiki to help you. And actually, if you compare this to the labs for today, you'll notice that basically the seven labs line up with seven of these bullet items, how to install, import, list atomic tests, check your prerequisites, etc. So I'm coming in to here to show you another option. If we look at executing atomic tests locally, it talks about one other way. Let's search for prompt frame, prompt. It's, it's not in here. Why isn't it prompt? Oh, it's in a different section. Sorry. It's specifying custom input arguments. So here's the wiki that tells you how to use the prompt for input arcs. But you can also do it in a scriptable way. You can define your arguments as a hash table. And so here we were setting a file name to a different value than the default and an ADS file name. And then when you invoke atomic tests, you just pass in instead of prompt for input arcs, you use just dash input arcs and you pass it that hash table. So if we were going to do that over here, we could say my arcs equals, and we could say, what's the name? sdelete underscore exe equals the tools. And we don't have to define all of them, just the ones we want different from default. So now we have your arguments there. Now we could say invoke atomic test and instead of prompt for input arcs, we could just say input arcs, and we could pass it our arguments. And then we still don't have sdelete at that location. But you get the idea that it tries to run it with our custom input arcs instead of the default. So now it becomes very scriptable. There's another feature of the scripted library that I want to show you, and it has to do with cleanup commands. Let's search for that. I forgot to write down the technique number, but yeah, 1546. Wait, screen saver? No, not that one. 1137 as a cleanup command, if you want. Okay. I think this is the one I'm looking for. 1003 number two. So this registry dump of SAM creds and secrets. So this just uses reg to save three registry hives. And actually, this has another thing that I want to show as well. So let's look at, let's see, that's T1003 number two. Okay. I'll show the brief details to remind myself what test I am trying to run. I'm trying to run number one, show the details. So it's just going to run these three commands, but then it has cleanup commands, which is going to delete those files that we created in the temp directory, which is a good idea because those files contain sensitive information. So cleanup commands are there to get rid of temporary files, to get rid of files that may leave sensitive stuff laying around. And also, and kind of most importantly, resetting the system to allow you to run the test again. So if the test itself, maybe it sets a registry key that allows credentials to be stored in memory. And so if you want, or it stops a service. So if you want to run that test over and over again, you need something to restart that service. So then you can subsequently try to stop it again. Or if you've already set the registry key to an insecure value sets it back to secure to leave your system in a better state, but also allow you to run that again. So that's the idea of the cleanup commands. So let's just double check that we don't have any of these same files in our temp directory. Okay, so all we have there is delete. So let's go ahead and run this test. Actually, I think it's going to complain, because we need to be admin. So if we were to check our prerequisites for this test, it would tell us we don't meet the prerequisites because we're supposed to be in an elevated context and we're not. So let's go ahead and switch over to show this example. Run it. It's administrator. Now we can invoke atomic test T 1, 0, 0, 3, 0, 0, 2. And then we could check our prerequisites, just make sure. Whoops, I forgot to say that's the number I'm interested in. This says, okay, for the registry dump of the cred or the SAM creds and secrets, everything's good to go. We can run it. So we can take off the check prerequisites and run it. And it says completed successfully. We can list that temp director again. And now we see the SAM security and system files. So let's look at the cleanup commands. Whoops, I didn't look out of my random. So to run the cleanup commands, which just deletes those three files, you just tack on a cleanup flag. And so that cleans your system back up. Now, I will admit it doesn't, it's not perfect. It doesn't put your system necessarily back exactly to the way it was. But it puts it back in a more desirable state. It doesn't remove prerequisites like that S delete file. The cleanup isn't going to delete the S delete tool because we tend to favor leaving the prerequisites there so you can run the test over and over again. So the idea is you run, get prerequisites once, and then you have all the tools you need on your test system. And then you can just run the test, clean up, run the test, clean up, run the test, clean up, and you don't have to do prerequisites in between. So it isn't going to leave your, it isn't going to put your system exactly back the way it was. But it is going to let you run the test over and over again. So if we now try to list the SAM security and system files from the temp directory, they're not there. So it's cleaned up. Now, I also want to show you one little caveat with this execution framework is that when you call invoke atomic test, it actually starts up a hidden either command prompt or PowerShell window to run everything. And then at the end, it kind of regurgitates the output back to your current screen. But it isn't actually running in the same window that you're looking at. So this can present problems. So when this test, if you run it twice in a row, the second time you run it, you're going to get prompted and say, oh, you know, the SAM file already exists in that location, do you want to override it? But since that prompt is being displayed on a hidden window, you don't realize it in the test just hangs. So to demonstrate this, I'm going to use this time out option with the tool that by default, these tests will time out after two minutes. But I want to make this faster time out so we can demonstrate this problem. So I'm going to run this test. And so it says the operation completed successfully. We can see we have those files in that directory. Now I'm going to run it again. And we're going to see that it hangs. So here it is. It's just thinking, thinking, thinking. And what's really happening is that hidden window where it's trying to dump this file is actually prompting us whether to override these three files that already exist. And so it's hanging. So now that it timed out after 15 seconds, we can see what it was trying to do. It was sitting there prompting us. Do you want to override this file? Yes or no? And we weren't able to answer. And so there is another way to run these tests that's interactive. So if we add in the interactive flag, then we're able to interact with these prompts. So it says, do you want the SAM already exist? You want to override it? Yes, yes, yes. So the reason why this isn't the default setting interactive, it used to be, but the reason why it isn't now is because when you're in interactive mode, there's no way to redirect all of this output from the test into a file. And that tends to be one of the valuable things that people like to do when they execute the test is to direct all this output saying whether it worked or not to a file so they can analyze it maybe with a script and say, okay, we ran these 100 tests. And based on the output, based on the fact that we did see credentials or didn't or that it said error, didn't the test worked? So we don't have that as the default because of that reason. But just so you know that there is that option and sometimes you can get things hung up, waiting for input. Okay. So yeah, so there's a question about can does it flag it as failed or success? So in vocatomic red team and actually a lot of these execution frameworks don't have a great way to tell did it actually work because success is really defined differently by different people. And it's really hard to sometimes tell from the command output. Did it really inject into this process? Did it really start up the service? Did it really show credentials on the screen? And so no, there isn't a good solution in here for run these 100 things and then put a green check mark if it worked and a red if it didn't. We do, however, log everything that you attempted to run. So there is a record that you tried to run this test at this time on this system. And I'll show you that now. Actually, I'll go, I think we're done with this administrative prompt. So, and that's with the execution log, which by default goes to the temp directory. So I'm going to use this import CSV because the log is in CSV format. And yeah, invoke atomic tests, invoke atomic test execution log. Let's take a look at that. If we had Excel on here, we could open it up in there. So here we see that at this time UTC or this time local, we ran T 1016, which has this name and was run on this host by this user. And the test has this GUID. So I didn't talk about the GUID, but if we do this show details on a test, you may have noticed there's a GUID here. So every test has a unique GUID. And you can specify a test, you can specify running a test by a GUID. So you could say test GUID, test GUID. And you could paste this in. But when you're playing around manually like this, that's kind of a pain in the neck to do it like that. But the reason why this GUID is important is because it never changes and it uniquely identifies this test. So if we execute test by test number, that test number is only set by the order that this test shows up in the YAML file. So if we maybe are executing test number five, and then somebody in the community decides to remove test number four, maybe we don't like test number four anymore. So we take test number four out of the YAML, suddenly test number five is now test number four. So these test numbers, they're reliable in like our particular instance here. But if we were to update our atomic red team, what used to be test number five may now be test number four. Or if somebody adds a test before the test we think we're running, then these numbers change. Also the test name, you can also run things by test name. But those tend to change too because somebody in the community might want to make the test name more specific or fix a typo in the test name. So if you want to have a really reliable way to execute the same test, regardless of whether the order of the test changes in the YAML, or if someone slightly tweaks the name of the test, you want to do that with GUID. So like when I am automating, whenever I'm automating running tests on a regular basis, I always use the GUID because that's going to stay the same. So I'm not going to accidentally run PowerShell MemeCats one day and then dumping of SAM system and security the next day, just because I updated my repository. So that's why the importance of the GUID and we also include the GUID here in the execution log. Okay. I think I got that answer. So this execution log now becomes valuable because we can take this execution log and we can marry it up with our telemetry and our alerts and say, okay, we ran these 100 attacks. How many of them did we detect? And we can potentially do that in an automated fashion that compares what we ran this month to what we detected was ran or what we blocked. So I talked about how there isn't a good way within the execution framework to tell if something worked or if something didn't. But we can do that if we use our own telemetry so we can get that answer of did it work or not from our own telemetry. I just realized we are so close to out of time. We have four minutes left. Matthew, do we have to stop it right on the top of the hour? No, we actually have until 12. So we have two more hours. Wow. Well, I'm going to jump ahead and tell folks how to get to their labs in case they have a time commitment. And I don't want them to miss that. But then I'll go back and present the rest of what I ran out of time. So at the end of the slides, it talks about accessing the lab. So there's a website control panel, DC training online. If you go there, you enter the email address you registered with, and then it will display the IP address and the credentials to log into that machine. So you just use RDP and connect to that. And then that's a safe place for you to play around with all the atomic tests once you get connect. Well, actually, it'll display your VM and I'll have a little start button. So the VMs are actually shut down right now. They're deployed in Azure, but shut down for cost savings. But you get to start them up and use them for two hours. So you push the little play button when you're ready to start the labs. And then you'll have two hours to play with that. And you can use those two hours all the way up until 4 p.m. today. And so once you connect to the RDP, like I have here, you start Chrome and you click on the labs link. And then you've got all these links to the seven labs. Even if you don't RDP to the labs, you can still click the link in the slides to get to these documents. You can download them. You can run through the labs, all of these labs on your own Windows VM. Like I said, the Windows VM isn't special. But it is a nice place to play with something without getting in trouble at work because these atomic tests, they are designed to be benign, but there's no guarantees. Plus, they look like malware and they act like malware. And so if you install atomic red team in your work environment, it's going to just installing it is going to set off a bunch of alerts and get a bunch of things blocked. And so you're kind of going to blow things up. So you don't want to just blindly, you don't want to install this on your work system. You don't want to download it over your work network until you have become familiar with it. And you, you know, maybe you get permission from work, you set up a test machine to do it at work. And, and you work through there. Let's see. And then just someone has a question just clarifying not all techniques are on the atomic red team yet. That's, that's correct. If we go and look on the index, let's actually do that. So on the wiki for atomic red team, I mentioned about atomic red team, there's some links here. So if we want to look at how much of the MITRE tech framework is covered by atomic red team for all operating systems, we can open this link here. And everything shown in red has at least one atomic test written for it or one scripted cyber attack. So you can see anywhere there's white has no atomic red team test written for it. But if it's read, there is at least one. So that gives you an idea of coverage. Okay, so I think I've got everybody started where they know how to get access to the labs, they can download the labs to do later today. You have two hours of access to that lab environment. And that brings us to the top they are, it sounds like we have more time. So I'm going to actually go back and finish up the lecture for those of you who still have time to stick around. One thing I didn't show is there is this option to, to instead of passing a technique number, you can say all. So I don't recommend actually like entering this, like this right here, because it would literally run all the tests. And because there's so much going on at once. For one, you can't even make sense of what you just did, because you just ran like 600 tests. And, and it's not useful because you don't even know how to start digging through it. But two, it'll probably leave your system in a bad state by the time all these things interact. And you might have to get a new VM. But one thing you can do is you could do this show details brief or get prerequisites, for example, and get all the prerequisites for the, all the tests at once. But we could do show details brief with the all technique. And then we get a great idea of what's available to us to run on this operating system. So we see quite a few tests there. That's taking forever. Okay, so we're going to back up here. Okay, so we showed you the execution log. You can also specify your own location for execution log. And that's all talked about on the wiki. I also provide you a link here to a little sales spreadsheet. That's just what I call starter atomics. So they're kind of some of my favorite atomics. And, you know, maybe because they're straightforward or because they're less likely to get just prevented right off the bat by your EDR. There are things, yeah, things that EDR doesn't tend to block right away because they're also legitimate things for admins to be doing. But you can write detections in your environment that allow that use but not used by like finance or HR or something. So I give you this starter atomics just because it's a little overwhelming when there's 600 atomic tests to look through. But this is a smaller like 30 tests that if you were going to start playing with something, you could start here. And so my advice for all this is to just start slow, start with some of these starter atomics, get familiar with them, work in a lab environment, you know, with permission and get comfortable with things. And then I'll show you some examples of how you might want to set this up for testing out of work environment. So here this computer we have the G represents like a golden image. So you may take your your base image that you give to a new employee and you could install atomic red team on that. And then this blue arrow means that you execute the atomic tests against the same system you installed the atomic red team. So you install atomic red team and execute tests locally. This is the same thing we're doing in the demonstrations I did and in labs today. And then you may or may not have your AV or EDR turned on. It's probably good to try it both ways, like turn off your blocking controls and just see if this happened to run somehow, like they were able to bypass the blocking controls, would we still be able to know what happened, you know, under the idea that prevention is ideal, but detection is a must. So in this case, we run our atomic tests like this, and then we ship off our telemetry to our production system so that we can test our production alerts and say, okay, everything's in place so that we could actually detect that this happened. So that's one example of how to use atomic testing to validate detections. But one negative of this is that atomic red team is actually not like a super light footprint when you install it. It has to install a PowerShell YAMMA module. It downloads a bunch of malware looking stuff into a directory and see atomic red team by default. So another way to do it is actually by installing atomic red team on some other system that isn't like your golden image, and then execute only the one or two tests that you're interested in running against a remote machine where you have not installed atomic red team. And this is possible with the PowerShell execution framework I showed you today through PowerShell sessions. And so there's a whole wiki page on how you can execute tests remotely. So you install atomic red team locally, but then you execute the tests on the remote machine. And that gives you the option to spot check your network by running certain trusted atomics on even potentially real endpoints. So this is that scenario where you install atomic red team here, and then you have a golden image somewhere where you execute tests over the network, and then those logs go into production. Your production telemetry. I've got some notes here about setting up your own lab if, you know, once you don't have access to the lab that I provide for you, but if we're short on time, so I won't go into those, but there's more details at that link there. And remember, there's a whole page on contributing. There's many ways to contribute, even if you aren't a code writer. You can still contribute issues and feature ideas through the GitHub issues page. Okay. The starter atomics link isn't working. I hear. Okay. There might be some trick to get it to work, but I can post that here in the channel too. Actually, I'll just do that now. If it lets me. Let's see. It doesn't let me copy the link, but I can get that to you. Let's see. Okay. So that wraps it up. There is a great Slack workspace with over 2,800 folks on it that all like to talk about attack emulation topics, not just atomic red team, but it's a great place to go and ask for advice. It's a very supportive community and come in with new questions, and we're happy to help you out. There's a link here to join that Slack workspace. And I'm always over there on that Slack workspace as well. So it's a great way to ask me additional questions. I'm happy to mentor folks who are new to GitHub and doing pull requests. Maybe you've never heard of a pull request. Maybe you think that's a weird name like I do for contributing, but I can help walk you through that. And if you're interested in the 16-hour class, there's a link there. Our next offering for that paid class is in September and October, and we go into more detail on atomic red team and other execution frameworks. Again, we've got the control panel here to get access to your labs. If you DM me on Discord and you're not registered, I'll try to get you access as well if you didn't get a chance to get registered. Has anyone gone to the site and gotten access to their VM yet if you can post on the channel and let me know that's working? And that's it. That's what I got today. Looks like one about eight minutes over. Somebody, yes, the lab environment just got posted over in Discord, but I'll post it here in the chat as well in case you're not in Discord. But as soon as we close this down, Discord will be the place to, the atomic red team channel and Discord will be the place to ask questions because I think this chat will be going away. Any last-minute questions that you want to post here in either Discord or chat, we can answer. Yeah, someone asked if we stopped the VM, will it restart the instance? Yes, so if you're in the middle of something that you didn't want to lose, you would need to save it. So by restart, I mean it just reboots it. So if you install the atomic red team and you ran some things, but then you need to take a break and you stop it, when you come back maybe an hour or two later and start it again, it'll still have atomic red team installed and stuff just if you were in the middle of a Word document and didn't save it, you would lose that. But essentially, it just does a system shutdown. But your changes will persist if you've installed the atomic red team, it'll still be there. Someone says I had some experience with Caldera is one better than the other. So the things I will compare are what we showed PowerShell execution framework. That's kind of a quick and easy way to get started because it's just running tests locally. It's not any advanced C2 framework. So Prelude operator and Caldera, they both execute tests through a C2 connection or a command and control connection. So you run an agent on the system or systems that you want to run tests on and that agent needs to be able to call over the network to your command and control server, which is Caldera or Prelude operator. And that in and of itself can be a beast to get allowed on your network because it's got to communicate over the network. It's got to not get shut down by EDR or blocked by AV. And so, but if you can get that setup, it's pretty powerful because you don't have to install PowerShell core on Linux and Windows. It's cross platform that way. You don't have to install the whole atomic red team on the host you're actually testing. And so it has some benefits that way with the disadvantage of you got to figure out how to get that C2 communication going in the first place and allowed over your network. But other than that, Caldera and Prelude operator are similar. The Prelude folks were actually original authors of Caldera. Caldera had or I mean, Prelude operator is both commercial and community edition. So what we cover in class is the community edition, which is the free version. There's also paid version. So it is a commercial product. So there you might find a little more focus on user experience in that case. But at this point, they're pretty similar. Can I give some command line examples of PS remoting? Yeah, I actually have a great wiki section. If we go to the invoke atomic red team wiki, there's a whole section on execute atomic test remote. And that's the PS remoting stuff. So it talks about prerequisites. It says if you want to have your local and remote computers, both windows, or if you want to run from windows to Linux or Mac, you got to do this, or from Linux or Mac to Windows, you got to do this. And then here's an example of how you would do that. So first you create your session with just new, this is just built in PowerShell function new PowerShell session. So you get your session. And then once you have your session set, all you do is the same thing we were doing in class. I'm trying to find it here. How come it isn't showing that? Okay, I should put an example in there. But essentially, you say invoke atomic test, and then you give it your technique number. And then you just pass it your session variable. And that's the only difference. You can do show details with it, you can do specify test number, you can do get pre rex, and that will get the pre rex on the remote system, because you're passing a session variable. So everything we showed works exactly the same. The only difference to do it on remote is you pass in dashed session and pass it that session you create by a call to new PowerShell session. So that remote execution over PowerShell Remoting is part of the advanced atomic red team section that we do cover in the 16 hour class. What framework would I recommend for Mac OS X? It's hard to say. I mean, if I could install PowerShell, if it's okay for me to install PowerShell Core on Mac OS X, I would do that. Especially if this is a test machine. But if it comes to, I actually have a few trusted atomics that I really want to execute over on Bob's computer over there, to see if in real life on a real computer, on Bob's real computer, if we would really detect something, and I wanted to do that with remote execution, I want to go install PowerShell Core on Bob's computer. I want to do the lightest touch possible. So in that case, I would go with Caldera or Prelude operator. So all you have to do is execute a small executable to get the C2 session going on Bob's machine, and then you can run any of the atomic tests from there. If you want can install PowerShell Core, you can use a framework that was presented today. Yes. What else? Let's see. For the question about Caldera, I will admit that Caldera has been buggy, and we have like 26 labs that we do on Caldera in class, and we had to put in actually quite a bit of effort to get the perfect sequence of lab steps to get through without running into some hiccups. I know that team is working, especially right now, we just met with them to work on the stability issues and some of those kind of GUI issues. So that's the current state with Caldera. There's another question from JJ. Do the atomic commands only usable in a defensive context or offensive context works generally too? So that's an interesting question because I kind of tried to help some folks use this for pen testing and red teaming, and while it does work like the PowerShell execution framework, when you install that, it tends to set off a lot of alerts. So if you're on a pen test and you're trying to be stealthy and not worry about a lot of alerts going off, you're just trying to get right down to it. What will we detect and what we don't? This is a good tool. But when they're stealth involved, I don't recommend using the PowerShell execution framework because it pulls down all the atomics at once and tends to set off a bunch of alarms, and it's not really light touch on the endpoint. On the other hand, if you do something like use the C2 agent, if that ends up not being caught, which as Caldera and Prairie become more popular, I think those agents will start being blocked by defenses more. So I guess the long answer is or short answer is these techniques and these commands are very useful to use in real red team engagements, but the automation pieces of them are published and open and likely to be blocked. I've even seen Defender do things like block something just because it's being downloaded from Red Canary's Atomic Red Team repo. It's not that they went to the work necessarily to figure out it was bad. They're just like, yeah, we we know that we shouldn't be letting things run from the Atomic Red Team repo, so we're just going to block it. So for that reason, when it comes right down, if you're on a stealthy pentest or red team, I think you would want to take the learnings from the scripted library of attacks, but come up with your own way to execute that, that isn't as widely known or published or used where AV and EDR is going to tend to block down. Okay, I think that's the last of the questions and we can wrap it up. I'll be on the Discord channel to answer additional questions throughout the day and also help you if you get trouble getting access to your test VM or if you have a special request to get access to a VM if you didn't get registered. Somebody's asking about accessing the slides. I'm trying to grab the slide link here from the Q&A. All right, Matthew, I think that wraps it up. Awesome. Thank you very much for your time for this introduction and for people, as Gary said, for people who wants to actually complete the end zone part, which is I think the most important, not an important and interesting part of our workshop. She'll be hanging out in the Discord. So thank you for joining and have a great day, guys, and good night, guys, folks, everyone. Thank you very much. Bye. Bye.