WEBVTT 00:09.610 --> 00:14.170 And welcome back, everybody, to DEF CON 28 Safe Mode, Blue Team Village. 00:14.530 --> 00:17.530 We're going to start our next set of speakers. 00:17.550 --> 00:19.710 We've got a great topic coming up today. 00:19.990 --> 00:26.070 The title of this talk is Building BlueSpawn, an open-source active defense and EDR software. 00:26.310 --> 00:28.690 Jake Smith and Jack McDowell will be presenting. 00:28.930 --> 00:40.010 As always, please direct all questions to the Tech Talks Track 1 channel, or you can connect to their Discord server as well and send messages to them directly. 00:40.090 --> 00:42.370 I'll have that in there in one second. 00:42.630 --> 00:46.110 And on that note, over to you, Jake and Jack. 00:46.430 --> 00:47.290 All right. 00:47.290 --> 00:48.290 Thank you. 00:48.510 --> 00:50.090 So how's everyone doing today? 00:50.110 --> 00:53.770 Just a few quick notes before we get into the presentation. 00:53.850 --> 01:00.350 We definitely want to take a moment to say thank you to all the volunteers and organizers of the Blue Team Village. 01:00.430 --> 01:07.570 Putting this event on in a normal year is a lot of work, and I can only imagine what they've done to make this happen. 01:07.570 --> 01:09.290 So a huge thank you to them. 01:09.790 --> 01:16.890 So today, Jack and I are going to be talking about an open-source project we've been developing for about a year now. 01:16.890 --> 01:23.970 It's called BlueSpawn, and you'll notice the emphasis on active defense here, so we'll get into more about that later. 01:24.430 --> 01:27.090 But first, a little bit of background about the two of us. 01:27.090 --> 01:29.550 We went to the University of Virginia. 01:29.630 --> 01:39.950 Both of us got our start in InfoSec doing really all kinds of cyber competitions, CTFs, and whatnot, and that's been a fantastic way to kind of get into security. 01:40.430 --> 01:49.130 And these competitions we'll talk about more are some of the reasons why we created BlueSpawn and all. 01:49.450 --> 01:53.310 So an important caveat, too, before we get into the presentation. 01:53.310 --> 01:58.430 When we say we this afternoon, we're referring to all six of us on the slide. 01:58.430 --> 02:09.230 It turns out that developing a large open-source project with already like 20,000 lines of C++ is a huge, huge undertaking. 02:09.310 --> 02:14.550 So it's really a team effort that we've been doing to create this. 02:15.810 --> 02:28.470 So, and also before we get into talking about BlueSpawn specifically, we're going to do a brief overview of some of the available tools out there and kind of where they shine, where they have some shortfalls, and more. 02:28.770 --> 02:37.790 And really, this is just all the tools that we're going to mention do a fantastic job, which is part of the reason why we want to talk about them as well. 02:38.110 --> 02:43.450 So first, we'll start with your Endpoint Detection and Response, or EDR, tools. 02:43.510 --> 02:49.050 That's your CrowdStrikes, your Carbon Black, your Defender ATP, Sentinel-1, and all. 02:49.610 --> 02:55.030 They obviously used to, like 10, 15 years ago, AVs were pretty simple. 02:55.030 --> 03:02.170 They look for bad hashes and whatnot, and now kind of that's, they've increased, and they've gotten really, really good. 03:02.170 --> 03:12.530 So these commercial tools, and they're a bit expensive in some ways, but they really raise the bar for finding the low-hanging fruit, especially in some, even some of the more advanced malware. 03:12.690 --> 03:22.730 They're obviously not all created equal, but one of the things we noticed when we started developing BlueSpawn is that these defensive security solutions are pretty opaque overall. 03:22.910 --> 03:38.730 There's obviously a lot of offensive tools out there, but it's really hard to get your hands on and kind of understand how these modern AV and EDRs work, which leads us into a bit about some of the free tools that are out there. 03:39.130 --> 03:45.490 There's not a whole lot of great ones, but definitely Sysinternals is probably one of the best. 03:45.490 --> 03:56.410 If you haven't used the Sysmon, if you haven't used much just beyond like Sysmon to improve your logging, highly recommend taking a look at like Autoruns and Process Explorer and Procmon. 03:56.850 --> 04:00.930 Just, they do a great job of finding malware on the system. 04:01.030 --> 04:07.670 They're more geared though toward the system analysis side, so they don't really, they're not going to say like, hey, this is malware. 04:07.670 --> 04:19.610 They might show like a different color if this is like encoded or something, but they're not going to point out and like say this is MITRE attack technique 1547, right, for example. 04:20.610 --> 04:22.210 Next is Process Hacker. 04:22.210 --> 04:24.670 Process Hacker is another really great tool. 04:24.690 --> 04:30.610 There's not much automation or security focus, but it's really good at just analyzing. 04:30.610 --> 04:37.530 It's like Task Manager on steroids, really, and you can even look at like a specific region in memory. 04:37.850 --> 04:47.410 So like if you know that one process was injected, for example, then you could go and analyze each bit of the memory yourself. 04:47.910 --> 04:56.050 And then on the like purely defensive side, we've definitely found PE-Civ to be one of the best free and open source tools out there by far. 04:56.110 --> 04:57.870 The idea is pretty simple behind the tool. 04:57.870 --> 05:08.050 It's basically look at all the processes running on the system, and then it can find hooks, process hollowing, process injection, shellcode, all that kind of good stuff. 05:08.210 --> 05:13.230 The only downside, if it's really a downside, is that it's limited to scanning processes. 05:13.230 --> 05:19.030 So it's not going to find like other malware, say, like that's hiding in the registry on a system. 05:20.250 --> 05:29.930 And finally, in this kind of available tool section is like the collections of YARA rules, Sigma rules, Sysmon configs out there. 05:30.090 --> 05:36.450 Even just a few years ago, there just wasn't really a whole lot out there, especially on the defensive side in way of signatures. 05:36.830 --> 05:46.050 But these projects are doing a really good job of starting to share threat intel a bit more widely and can help you find threats just on a particular system. 05:46.570 --> 05:57.250 The only thing, I guess, the caveat is like with hardening scripts, for example, a lot of the stuff you'll find out there is very, I guess, more script-like and not fully fleshed out. 05:57.510 --> 06:02.910 So that's one thing to be aware of, like they'll set conflicting values or miss critical settings and whatnot. 06:03.870 --> 06:12.070 But so that, I mean, that's kind of the reasons why we got into building BlueSpawn, which we'll talk about here more shortly. 06:12.870 --> 06:20.270 And one of the key things we want to emphasize this afternoon is that is the ideas and principles on which we built this tool. 06:20.270 --> 06:24.950 You're probably not going to go into work Monday and deploy BlueSpawn in production. 06:25.110 --> 06:31.910 And I guess you could, but that's maybe not something you want to do quite yet because the project's not quite that far along. 06:31.990 --> 06:43.330 But that said, you can use the information in today's talk to conduct your own security research and begin kind of improving your own defenses too and looking at how these kinds of solutions work. 06:44.070 --> 06:49.550 So with all things, all great ideas, I guess, start in Slack and whatnot. 06:49.550 --> 07:07.610 So this was, I went into our archives, this was last year, like we started with this really simple idea, like what if we could like scan one particular thing, like look at GS registry run keys, like as a way to detect threats and whatnot on a system and like an open source tool. 07:07.610 --> 07:09.450 And we didn't find a whole lot out there. 07:09.630 --> 07:15.590 So that kind of led us to creating BlueSpawn. 07:15.770 --> 07:23.510 And as I said, we were students or we are students, so we compete in a lot of these different cyber defense competitions and whatnot. 07:23.930 --> 07:28.990 Honestly, frankly, I tell some people that I just do go to school for competitions and all. 07:30.010 --> 07:42.550 But basically, these cyber defense competitions are, basically, you get a network and you're asked to secure it against active attackers, who unfortunately for the students are industry red teams. 07:42.550 --> 07:45.390 So you can imagine how that kind of thing goes. 07:45.490 --> 07:48.030 And the red team pretty much always wins. 07:48.030 --> 07:52.830 So in these competitions, though, we can't really, we can't use commercial tools and we can't bring in scripts. 07:52.830 --> 07:54.750 So we have to rely on open source tools. 07:54.750 --> 07:59.450 That's kind of another reason why we focus so heavily on the open source aspect. 08:00.010 --> 08:08.690 And so we built BlueSpawn on one really particular focus is that we want to be able to stop threats as quickly as possible. 08:08.690 --> 08:20.510 So I think that you should be able to run this tool and find as many, if not the majority or more of all the threat, all of the malware that's running on your system as quickly as possible. 08:21.170 --> 08:26.990 And so that is where the idea of active defense comes in. 08:27.570 --> 08:29.670 And then the next is coverage. 08:29.670 --> 08:33.070 So when doing these cyber defense competitions, it's time limited. 08:33.070 --> 08:35.290 You're stressed and whatnot. 08:35.290 --> 08:39.350 So you don't have the luxury of, say, being able to look at everything very closely. 08:39.350 --> 08:45.850 And you can't pull up a process explorer and look at every individual process to hunt for process injection. 08:46.350 --> 09:00.570 So our idea is that if you can get 60, 70, 80% of the way there on finding the most common threats, and you know what your tool is going to be looking for, you can spend more time on those other areas as well. 09:01.170 --> 09:02.830 And finally, open source software. 09:02.830 --> 09:04.670 So this is a call to everyone out there. 09:05.190 --> 09:11.550 There's a lot of stuff on the offensive side, but there's just not really as much on the defensive side. 09:11.550 --> 09:16.350 So definitely building more open source blue team software, I think, is really important. 09:16.350 --> 09:26.790 And it's a great way for people to learn about how these kinds of things work and how you might detect, say, one particular technique in the attack matrix. 09:27.670 --> 09:42.610 So as time went on, from that simple idea that we posted a while ago in Slack, we started moving BlueSpawn towards what you might term as calling EDRs type solution today. 09:42.830 --> 09:46.570 So that's where it's doing continuously monitoring. 09:46.710 --> 09:54.590 And we're asking questions like, what if we could just deploy BlueSpawn across the whole network like you might deploy like Falcon? 09:54.590 --> 10:00.470 This is kind of the ideas that we're heading towards as we spend more and more time developing this. 10:00.470 --> 10:02.050 And then also proactive defense. 10:02.050 --> 10:08.630 So it's not enough that you can detect malware and respond to it, right? 10:08.630 --> 10:16.070 We also, one of the core focuses is the idea of being able to prevent these malicious activities in the first place. 10:16.910 --> 10:21.630 So we've talked a lot about active defense so far, but what do we really mean by it? 10:21.630 --> 10:26.750 And how does BlueSpawn approach the idea of finding anomalous or malicious behavior? 10:26.910 --> 10:29.090 And that's kind of what I'll get into in this section. 10:29.870 --> 10:38.550 So typical antivirus or EDR products are meant to kind of run in the background behind everything, only raising alerts and acting when there's something definitely bad going on. 10:38.550 --> 10:40.730 For their use cases, this is a very good thing. 10:40.730 --> 10:44.710 People don't want alerts about everything that may or may not be malicious. 10:45.090 --> 10:50.250 But when you've been compromised, or even when you think you've been compromised, that might not be enough. 10:50.250 --> 10:53.790 This is where our concept of active defense comes into play. 10:53.810 --> 10:59.750 Rather than sit in the background, only rarely making noise, BlueSpawn is meant to be a tool that's actively used. 10:59.750 --> 11:06.370 The goal is to find absolutely everything that could be malicious, not just the things it knows for sure are malicious. 11:06.630 --> 11:08.790 In such an approach, there are drawbacks. 11:08.790 --> 11:12.790 In catching all the things, we're sure to catch some things that aren't actually bad. 11:12.790 --> 11:16.770 But for an active defense situation, that's a trade -off we want to make. 11:17.210 --> 11:19.830 So how does BlueSpawn go about approaching this? 11:20.090 --> 11:28.810 Originally, this worked by just performing a scan of the system at a point in time to identify all the threats that were currently on there. 11:28.830 --> 11:36.770 And this hunting involved the typical registry scans, file scans, or process scans that an AV or EDR product would use. 11:36.770 --> 11:45.510 But again, BlueSpawn tried to be more in-depth, taking more time to look at things, with more of a focus on finding anything that's not normal. 11:45.590 --> 11:51.350 And I think what makes BlueSpawn different is we also factor event logs into our hunts. 11:51.350 --> 11:59.590 So correlating what Windows events have occurred with what is currently on the system to identify any sort of malicious behavior there. 11:59.590 --> 12:05.830 And we're trying to basically use that to bridge the gap between incident response and what EDR products do. 12:05.830 --> 12:11.950 And as we move towards continuous monitoring, we extended these hunts to be able to run as needed. 12:11.950 --> 12:14.890 And I'll talk more about how we did that shortly. 12:16.310 --> 12:22.790 So as I mentioned on the previous slide, BlueSpawn is built pretty heavily around the idea of what we call hunts. 12:22.790 --> 12:36.350 For each MITRE attack technique we support, which is basically a way attackers do things if you're not familiar, we've created a hunt, which basically is a search for any sort of evidence of malicious activity using technique. 12:36.350 --> 12:44.690 We'll get into more detail about how specifically these hunts work in a bit, but for now, just know that they're really the starting point for everything BlueSpawn does. 12:45.050 --> 12:49.470 Monitoring, as I mentioned a while back, is really just an extension of the hunts we've already written. 12:49.490 --> 12:55.970 Each hunt creates triggers for when it should be rerun, and when those triggers occur, it gets run again. 12:56.350 --> 13:02.850 Now, MITRE recently released sub-techniques, which break down each technique attackers may use into subcategories. 13:02.850 --> 13:08.470 And BlueSpawn has just moved to handle that by making each hunt responsible for all of the sub-techniques that fall under it. 13:10.530 --> 13:15.210 So these hunts are really great for finding the starting points in malicious behavior. 13:15.210 --> 13:21.690 We can find registry keys that run files around startup libraries that aren't meant to be included at all, all sorts of fun stuff. 13:21.690 --> 13:29.590 But malware tends to have a number of different components that it uses, or even if it doesn't, it exists in multiple different forms in multiple different places. 13:29.690 --> 13:38.590 Maybe there's a registry key that points to a file, and then that file is loaded into a process, and then that process is changing other registry keys, and those keys point to files. 13:38.690 --> 13:40.830 And those files, well, you get the idea. 13:41.430 --> 13:47.930 To address this, BlueSpawn searches each piece of evidence it finds in order to see if it can catch anything related to it. 13:47.950 --> 13:51.850 The result from this is a network of evidence of malicious activity. 13:51.910 --> 13:55.750 In the next section, I'll go into a bit more detail about how this actually gets built. 13:56.950 --> 14:05.050 Now that I've given a higher-level overview of our methodology, I'm going to take a deeper dive into the different things BlueSpawn can do with a focus on how it does them. 14:05.070 --> 14:11.570 And this section is going to get a little bit technical, but I'll finish it with a more broad overview if you don't catch anything. 14:12.590 --> 14:16.530 So before I get into any of the features, I want to preface with a disclaimer. 14:16.550 --> 14:18.450 BlueSpawn is still in alpha development. 14:18.470 --> 14:24.710 So far, we've been mostly focusing on infrastructure, that is, building out the core of the features I'm getting into. 14:24.710 --> 14:29.010 Everything I'm presenting is currently implemented, but it's not entirely without its bugs. 14:29.130 --> 14:33.210 And the biggest example of what I'm talking about is our scanning subsystem. 14:33.210 --> 14:40.930 I'm going to say things like, this is where BlueSpawn scans X, but the actual scans performed are new and not necessarily heavily tested. 14:41.130 --> 14:48.350 At this point, I'd say a lot of the features described here are better talked about as a framework than a fully fleshed-out product. 14:48.750 --> 14:51.290 And none of this is to say BlueSpawn isn't effective. 14:51.290 --> 14:59.310 We've spent a long time building our hunts and expanding our coverage, and it's proven to be pretty good at its job, as Jake will showcase in his case studies section. 15:00.290 --> 15:03.050 And now that's out of the way, onto the features. 15:03.150 --> 15:07.930 BlueSpawn has five major components, each of which we'll discuss in detail in this section. 15:07.930 --> 15:25.890 There's Mitigate, which applies security settings, Hunt, which runs the hunts I was talking about earlier, Scan, which determines how bad detections really are and finds associations, Monitor, which hunts over time, and React, which handles responses to what HuntMode and ScanMode have identified. 15:27.050 --> 15:37.090 So Mitigate mode sits somewhat apart from the rest of BlueSpawn without really any integrations to the other modes, so I'll just talk about that first to get out of the way. 15:37.550 --> 15:46.910 Mitigations applied by BlueSpawn are all mapped to either a Security Technical Implementation Guide, or STIG, released by DISA, or the Miner Attack Mitigations Framework. 15:46.910 --> 15:58.950 When running Mitigate mode, BlueSpawn can either audit the current state of the system, which just says this is what it's currently set up as, or it can go ahead and apply the mitigations it finds aren't properly configured, with user confirmation, of course. 15:59.350 --> 16:06.610 Now, as of now, our mitigation framework is very quite simple, but we think it has a lot of potential as BlueSpawn continues to grow. 16:06.610 --> 16:14.570 We see it eventually being configurable through some sort of configuration file, so mitigations can be more uniformly and quickly applied across a network. 16:14.570 --> 16:20.670 We also see it mitigating services and software installed on a system, rather than just the base operating system. 16:20.790 --> 16:29.370 And finally, our biggest envisioned change is for Mitigation mode to serve as really an aid in performing a system audit. 16:29.370 --> 16:39.890 So this would perform some of the same tasks as enumeration tools, such as Seatbelt or JAWS, with a focus on finding and fixing things actually being vulnerable to being exploited. 16:41.230 --> 16:50.110 Now, before I get into the weeds of how everything works, I'm going to throw some definitions at you for how I refer to the ideas and concepts BlueSpawn uses. 16:50.150 --> 16:54.190 So I'm going to be using the word detection a lot, and it's just that, detection. 16:54.370 --> 17:00.630 It could be something good, it could be something bad, it's just something BlueSpawn identified as taking a closer look at. 17:00.710 --> 17:04.110 It could be like a file, a registry key, a process, or something else entirely. 17:05.030 --> 17:08.810 Next, there's an association, which is also just what it sounds like. 17:08.810 --> 17:18.050 It's a connection between two different detections, and in BlueSpawn, we represent associations as having a weight, representing how closely they are associated. 17:19.010 --> 17:25.530 Next thing is certainty, and this is the metric we use for determining the likelihood that a detection is actually bad. 17:25.610 --> 17:27.370 There are three components to it. 17:27.370 --> 17:31.130 The two of them get combined, so in practice, there are really only two. 17:31.190 --> 17:33.570 The first is what I call intrinsic certainty. 17:33.570 --> 17:36.530 This is the certainty that comes from the detection itself. 17:36.530 --> 17:44.750 This would be what we're talking about if a service was called Mimikatz, or if a file matched a Yara rule from Reterpreter, or something like that. 17:45.380 --> 17:47.830 The next is contextual certainty. 17:47.830 --> 17:51.210 This comes from the context surrounding the detection. 17:51.210 --> 17:58.030 In a lot of ways, this is very much like the intrinsic certainty, and in fact, BlueSpawn doesn't actually differentiate between the two. 17:58.030 --> 17:59.290 They're really combined. 17:59.370 --> 18:09.570 And what I mean by context is things like a file in System32 that's not assigned by Microsoft, and that's probably bad just because they usually are. 18:09.570 --> 18:16.690 Or any value listed under an app in a DLL is probably bad just because they aren't really used legitimately anymore. 18:17.470 --> 18:24.670 The last type of certainty I'm going to talk about is associative certainty, and this is the certainty that comes from the associations of detection. 18:24.930 --> 18:28.170 Say we've got a file and we found it loaded into a process. 18:28.290 --> 18:37.970 If the process is behaving maliciously and the file appears malicious, the file should be treated with a higher certainty than if all we had was a malicious-looking file. 18:39.810 --> 18:44.750 Now that I've got those definitions out of the way, I can move on to how BlueSpawn actually works. 18:45.010 --> 18:50.510 The core of all detection management, and really the core of BlueSpawn itself, is our detection register. 18:50.510 --> 18:52.910 This tracks everything that BlueSpawn's found. 18:52.930 --> 18:59.610 Whenever a hunt or a scan or whatever finds anything that might be bad, it sends it to the detection register. 18:59.650 --> 19:03.890 The register will record the detection and send back a reference to it. 19:03.890 --> 19:12.650 Now, this reference may or may not be the detection that was recorded, and I'll explain why next slide when I explain how the registration process actually works. 19:12.750 --> 19:15.730 The detection register has three storage mechanisms. 19:16.890 --> 19:24.810 So whenever a detection gets registered, it gets queued for a scan and we track all queued detection in one set and all scanned detections in another. 19:24.810 --> 19:28.050 That way we can just make sure we're not redoing the same work. 19:28.050 --> 19:31.730 We also keep a record of all detections regardless of whether or not they've been scanned. 19:32.590 --> 19:35.190 So now for how registration actually works. 19:35.390 --> 19:43.150 The first thing the register actually does when a new detection is being added is it checks if the detection already exists. 19:43.150 --> 19:45.370 If it does, they get merged together. 19:45.370 --> 19:52.410 And generally the only thing that changes when this happens is their contextual certainties and their contexts get merged. 19:52.410 --> 19:59.450 If this merge causes their overall certainty to exceed a certain threshold, it then gets logged and its reactions get triggered. 19:59.450 --> 20:05.770 If the detection being registered was merged with the pre-existing one, the reference that returned is actually to the pre-existing one. 20:05.770 --> 20:09.650 That way it's just keeping track of the detection that we care about. 20:09.650 --> 20:11.450 Otherwise it's to the new detection. 20:11.550 --> 20:18.030 After all this is handled, if the detection register needs to queue scans for the detection, it will. 20:18.030 --> 20:27.090 This constitutes calculating the intrinsic certainty, identifying associated detections, and then if the certainty is high enough after that, logging it and handling reactions. 20:27.310 --> 20:32.890 The associated detections then get registered and the scans for those get queued and so on. 20:34.110 --> 20:38.870 So here I've got a diagram for how the detection register lays things out. 20:38.870 --> 20:43.930 It looks kind of complicated, but I'll try to explain it so it's maybe not quite as bad as it looks. 20:44.450 --> 20:47.730 So the register itself has three main storage mechanisms. 20:47.730 --> 20:53.630 There's the queue of things that haven't been scanned yet, things that have been scanned, and then everything overall. 20:53.690 --> 21:00.630 And you can see that all these storage mechanisms really just store references to detections that are stored elsewhere. 21:01.010 --> 21:08.230 I've also broken down one detection, in this case ID2, to show what kind of information detection actually holds. 21:08.270 --> 21:12.970 So it first has its ID, which is just an ID, a unique identifier to refer to it. 21:12.970 --> 21:20.110 It has a context, which is the information surrounding how it was made and how it was found and when that happened and all that. 21:20.110 --> 21:27.470 So that'd be what time the detection occurred, what hunt found it, and when the first evidence of the detection was found. 21:27.830 --> 21:33.650 There's also the data, and this stores information about what actually did it find. 21:33.690 --> 21:41.150 So in this case, I've just decided for the purpose of an example, this detection is going to refer to a run key and its value name. 21:41.150 --> 21:46.130 Its name persists and it's pointing to this file called bad.exe. 21:46.630 --> 21:51.370 The next thing I have is the scan information, which stores information about how it was scanned. 21:51.370 --> 21:57.910 That has the certainty, which combines the intrinsic and the contextual certainties, and then the associative certainty. 21:58.210 --> 22:05.530 The last part of this is the associations, which identifies which detections are associated with this one. 22:05.530 --> 22:11.730 In this case, detection ID1, which I'm using to refer to as bad.exe, is associated with it. 22:12.770 --> 22:15.770 There's also a remediator, and I'll get to that a bit later. 22:16.590 --> 22:22.950 So in the methodology section, I mentioned how hunts represent the starting point for pretty much all the threat hunting that BlueSpawn does. 22:22.950 --> 22:26.170 Each one covers one minor attack technique. 22:26.330 --> 22:31.570 Each hunt, we then break down into sub-techniques, which can be run independently of each other. 22:31.650 --> 22:44.930 Within each sub-technique, that gets broken down then into sub-sections, and one sub-section generally checks just one specific attack surface, whether it's a folder, a file, an event ID, or a registry key, or something else. 22:44.930 --> 22:48.130 The idea is to keep it as simple and small as possible. 22:48.350 --> 22:57.110 This design allows for much more targeted hunts if we know what we're specifically we're looking for, and I'll get into why that matters when I talk about how monitoring works. 22:57.650 --> 23:02.170 Most of the things we check get a quick scan, which just performs the most elementary scans. 23:02.170 --> 23:06.710 It's a very quick test to determine whether or not something deserves more detailed scans. 23:06.810 --> 23:13.790 If it does, we create a detection for it and register it with the detection register and kick off the whole scanning thing I just finished talking about. 23:13.950 --> 23:18.950 Then the scans I discussed get run on it and make a determination, find other related things, and so on. 23:20.690 --> 23:23.010 Here's an example of what a hunt looks like. 23:23.170 --> 23:25.930 In this case, this is a T1547. 23:25.930 --> 23:29.990 The hunt itself really just runs all sub-techniques underneath it, you can see here. 23:32.250 --> 23:37.050 And then here's the sub-technique number four, which I picked out because it was pretty simple. 23:37.770 --> 23:45.890 The first part of it just compares the winlogon values for the shell and username against known goods. 23:45.890 --> 23:56.490 If they don't match, we create detection with a moderate contextual certainty, because anything that doesn't match, chances are it's bad, even though the file itself might not be bad. 23:56.830 --> 24:01.590 The next sub-section refers to the winlogon notify values. 24:01.590 --> 24:06.850 Any of these that we find get a detection created for it, just because they aren't used very commonly. 24:06.890 --> 24:12.590 And we create that with a weak contextual certainty, because again, if you find one, chances are it's not great. 24:12.590 --> 24:17.470 Now you'll notice during each of these, I specify cursory when I initialize a sub-section. 24:17.510 --> 24:23.410 That comes from... when you run bluespawn, you specify how closely it should be looking for things. 24:23.410 --> 24:25.710 There's cursory, which is a very quick check. 24:25.710 --> 24:28.870 There's intensive, which is a very slow but careful check. 24:28.870 --> 24:31.370 And there's normal, which is somewhere in between. 24:31.450 --> 24:39.770 By specifying cursory here, we indicate that bluespawn should run these sub-sections whenever the intensity is greater or equal to the cursory. 24:41.590 --> 24:48.230 So when we originally had our first working version of bluespawn, it was just a few hunts we'd written and not too much else. 24:48.490 --> 24:52.590 Since then, everything we've done really has been taking what we had and proving it. 24:52.590 --> 25:00.910 When it came time to start monitoring systems in real time, rather than just performing a single scan, we realized we could reuse the hunts we had already written to do this. 25:00.910 --> 25:09.710 Each hunt we created already defines a number... sorry, each hunt we created defines a number of events that indicate something pertinent to the hunt has changed. 25:09.810 --> 25:14.630 For example, we might make an event watching a folder for new files or old files being edited. 25:14.730 --> 25:19.230 When the event gets triggered, hunts that care about that folder get rerun. 25:19.230 --> 25:24.690 Of course, there's some obvious inefficiencies in this, which is a big reason why we divided hunts into sub-sections. 25:24.930 --> 25:30.210 Now, when hunts create events, they specify which sub-section should get run for each event. 25:30.830 --> 25:36.050 Now, I'll admit monitoring is unfortunately one of the areas that hasn't received as much attention as others. 25:36.050 --> 25:46.490 It's certainly functional and it's effective at watching for things that hunts can catch, but so far we don't have that much that acts based off of behavior alone that we observe while monitoring. 25:46.510 --> 25:49.310 In the coming months, this is going to be one of our big focuses. 25:49.430 --> 25:56.310 Adding things like event tracing for Windows or API monitoring should position bluespawn to be able to catch much more. 25:57.790 --> 26:05.550 So, here's an example of how monitoring sets up its... or hunt sets up all of its monitoring triggers. 26:05.610 --> 26:11.350 So, if you noticed my example hunt two slides back, each of these sub-techniques gets a scope passed into it. 26:11.350 --> 26:23.350 Well, under the hood, what's happening is the sub-section macros I have actually check the scope against that sub-section ID to determine whether or not that sub-section should be run. 26:23.350 --> 26:28.530 So, whenever I create an event here, I specify which sub-sections are pertinent to it. 26:29.310 --> 26:40.630 And yeah, so here we have registry events, file and file events, but we also have event log events to watch for Windows events being created. 26:41.970 --> 26:46.450 So, the last component I'm going to talk about here is the reaction framework. 26:46.450 --> 26:52.030 As the name would imply, this is responsible for taking care of that BlueSpawn has determined are bad. 26:52.150 --> 27:04.150 Since BlueSpawn is designed around finding as much as possible and is bound to have some false positives, most things here require some sort of level of user confirmation before taking action. 27:04.150 --> 27:11.070 Now, obviously, when I delete a file, it's no longer an active threat, but there's still a reason for BlueSpawn to track it. 27:11.070 --> 27:19.530 To handle this error detection, each detection... sorry, to handle this error situation, each detection has a flag where we mark it as stale or not. 27:19.590 --> 27:28.210 Whenever detection... sorry, whenever reaction mitigates the detection, we mark it as stale, so that way other reactions don't go and try to mitigate it their way. 27:28.410 --> 27:34.290 Currently, we have five reactions available, but there is somewhat of a less defined six, and I'll get into that. 27:34.690 --> 27:42.910 BlueSpawn can delete files, quarantine files, delete registry entries, and that can be values or keys, suspend processes, or carve out memory. 27:42.910 --> 27:44.850 I'll talk about that in the next slide. 27:45.290 --> 27:48.670 The less defined reaction I just mentioned is for special cases. 27:48.710 --> 27:53.270 Remember back to the WinLogon hunt where it was comparing some values against known goods? 27:53.310 --> 27:56.970 It wouldn't be very good to just delete these values if they were malicious. 27:56.970 --> 27:58.730 They need to be properly restored. 27:58.790 --> 28:02.970 And to handle things like that, when a detection is created, it can be given a custom remediator. 28:03.010 --> 28:07.350 This remediator gets precedence over all other reactions if it's present. 28:08.050 --> 28:14.110 Now, as we continue to develop BlueSpawn, we of course intend to continue adding reactions and improving the ones we do have. 28:14.110 --> 28:18.650 Future reactions might include things like de-registering service or blocking certain commands. 28:20.410 --> 28:24.750 So I promised that I'd get into what I meant by memory carving, so here we are. 28:24.910 --> 28:34.430 The idea behind memory carving is that sometimes libraries or shellcode get shoved into processes, and these processes still serve a valid purpose and need to remain active. 28:34.490 --> 28:43.170 In cases like these where a restart isn't a good solution, we came up with a way to mitigate the effect of whatever malicious library or shellcode is living inside a process. 28:43.170 --> 28:46.890 It's not perfect, and it can cause problems, but it's better than nothing. 28:47.690 --> 28:50.330 This reaction works in five steps. 28:50.330 --> 28:55.910 First, we suspend the process so that nothing we're doing causes problems with the way the process works. 28:56.430 --> 29:04.930 First, what we do is we enumerate the threads in the process, searching for any thread whose stack overlaps the memory section in question. 29:04.930 --> 29:11.710 And that basically is an indicator that the thread is acting based off what that malicious memory section wants it to do. 29:11.930 --> 29:14.810 If or when we find this, we kill any thread that does that. 29:14.890 --> 29:21.850 Since malware generally doesn't like to share a thread with something benign, it shouldn't kill anything important to the process. 29:21.970 --> 29:27.730 Of course, if you got things like APC injection going on, there's not too much we can do about that right now. 29:28.170 --> 29:32.410 After that, we scan all memory pointers to the memory segment in question. 29:32.410 --> 29:35.650 If or when we find them, we check the address in question. 29:35.650 --> 29:38.810 If it's data, we patch it with zero, so it can't read anything important there. 29:38.810 --> 29:45.670 If it's code, we patch it with return instructions, so if it ever tries to call there or jump there, it gets immediately bounced right back. 29:46.610 --> 29:56.250 Then we go through and patch the entry point and all functions that are exported with return instructions, so anything trying to run any function inside the memory gets messed up. 29:56.430 --> 30:06.050 This can cause problems if we end up patching any function that requires the callee to clean up the stack, but without extensive work to figure out how much of the stack needs to be cleaned up, there's not too much we can do. 30:06.250 --> 30:09.710 Once we're done with all that, we resume the process and let things continue. 30:09.930 --> 30:17.330 We have tested this with a couple different pieces of malware, including CobaltStrike, Beacons, and Returpreter, and it seems to work without causing too many problems. 30:17.350 --> 30:26.750 Unless processes are storing function pointers in an abnormal manner, it should be very difficult to get anything in this memory segment working again after what we do occurs. 30:27.410 --> 30:30.890 Now, we are working on a few features to improve the stability of this. 30:30.890 --> 30:43.930 This includes things like forcibly walking threads back instead of just killing them, or finding out how much the stack needs to be cleaned up when patching returns, or properly unloading libraries as seen in Process Hacker rather than just breaking them. 30:46.360 --> 30:51.540 Now, BlueSpawn would have been nearly impossible to build from the ground up without any libraries or integration. 30:51.680 --> 31:00.400 As has been a major theme in our presentation, the MITRE ATT&CK framework has been invaluable in providing guidance around what sort of things we should go for. 31:00.460 --> 31:05.940 YARA and YARA rules written by the community have provided immense value in being able to scan files and make determinations. 31:06.260 --> 31:12.440 The stakes around which we built our mitigations make it very clear what we should prioritize and give us a framework to convey our coverage. 31:12.900 --> 31:22.660 Finally, PESib is a great open source tool we use to scan any process for any sort of fileless execution or any form of execution that's not properly mapped to a file. 31:23.600 --> 31:30.240 In summary, BlueSpawn's abilities can be broken into three categories, prevention, protection, and response. 31:30.240 --> 31:35.380 Under prevention, we have mitigate mode, which integrates STIGs and MITRE's ATT&CK framework. 31:35.380 --> 31:46.720 Under detection, we've got monitor mode, which watches for changes to rerun hunts, hunt mode, which is built around the MITRE ATT&CK framework, and then checks for these threats. 31:47.100 --> 31:51.800 Scan mode then analyzes what was found in hunt mode to find associations and make determinations. 31:51.800 --> 31:58.120 Finally, under response, we have our reactions, which aim to mitigate or remove a threat, and then logging to report what was found. 31:59.540 --> 32:10.640 All right, so that was a lot, but we wanted to really give you a deep insight into kind of how some of these AV and EDR type programs, and obviously BlueSpawn in particular, work. 32:10.860 --> 32:16.880 And so now we're going to move into talking about just like seeing the tool in action, right? 32:16.880 --> 32:27.820 So we're going to walk through a case study with some kind of specific point in time screenshots of BlueSpawn catching malware, and then also we're going to have a video of kind of the tool in action. 32:28.260 --> 32:39.700 And I mentioned cyber defense competitions have been a really important learning tool at the beginning, so first I want to emphasize that again. 32:40.140 --> 32:44.960 The largest is by CCDC, and it's held in about 10 regions across the U.S. 32:44.960 --> 32:52.080 with qualifiers, regionals, and nationals, and about 230 universities compete each year actually. 32:52.120 --> 33:01.540 So that's one way if you're looking to volunteer to help in the community, highly recommend looking into a competition like that or others. 33:01.720 --> 33:06.200 So these competitions are basically what's known as an inherit and defend competition. 33:06.200 --> 33:11.000 The student teams work in a group of eight, and they're basically work as a fictional company. 33:11.000 --> 33:15.780 So like they have a whole set of networks they have to defend, and typically that's on-prem. 33:15.780 --> 33:21.380 There's cloud aspects, and that's usually done in like ESXi or AWS. 33:21.780 --> 33:26.660 So here you can see an example of a network map from actually last year. 33:26.660 --> 33:35.980 So you have some on-prem workstations, there's like a on-prem cloud if you will, and like ESXi, and then there's even like an AWS component. 33:35.980 --> 33:47.100 And you'll see the stuff in there ranges from Windows Server 2008, so like really old stuff, to Windows Server 2019, and every flavor of Linux distro really. 33:47.340 --> 33:51.780 So that's they kind of emulate a modern corporate environment the best they can. 33:51.780 --> 33:55.940 And there's of course stuff like Exchange, and web apps, and databases, and all. 33:56.080 --> 33:58.220 And so basically there's two goals in these competitions. 33:58.220 --> 34:08.100 You have to keep your services online, and then just like you would in a real company, and then you have to stop the right team from really just totally destroying everything. 34:08.760 --> 34:12.600 And really frankly that ends up in situations like this. 34:12.600 --> 34:28.840 So on the left hand side you see this is from the national competition this year, and it's where a picture of the red team's Cobalt strike instance, where you can see they just have pwned dozens of machines against this poor team. 34:28.920 --> 34:39.260 And they also do things like defacing the websites, and RMRFing boxes, or overriding MBRs when they get too much access. 34:39.260 --> 34:48.380 But really what that means is that in all reality is that these are a great testing ground for defensive tools, right? 34:48.380 --> 34:53.580 So the red team spends all year writing malware for these competitions, and are probably watching right now. 34:53.580 --> 34:54.960 So hi red team! 34:56.340 --> 35:07.800 But so their tool set is everything from like Metasploit and Cobalt strike, what's pretty commonly used, to really custom malware that's just written for the purposes of CCDC. 35:08.200 --> 35:13.720 So with that kind of backstop in mind, we're going to look at some example screenshots of BlueSpawn. 35:13.720 --> 35:16.940 So here we just have the system. 35:16.940 --> 35:19.480 There's two Cobalt strike beacons running. 35:19.620 --> 35:26.680 One is just an HTTP beacon, and then the other is an SMB beacon living in explorer.exe. 35:26.780 --> 35:29.760 And so this is how BlueSpawn goes about finding it. 35:29.800 --> 35:43.500 It's looking at, when Jack talked about process injection earlier, and the carved memory reaction, you can see BlueSpawn's finding the malware in both explorer.exe, and then also in the PowerShell that's running. 35:43.500 --> 35:51.200 And then it starts prompting the user like, hey we found this malicious activity, and all they did, all the user did was just run BlueSpawn. 35:51.360 --> 36:00.140 And then it's offering to kill the threads, and once it kills it, then we reach a situation like this, where those beacons basically just stop calling back in. 36:00.140 --> 36:04.280 So that's an example of how BlueSpawn is responding to the threat. 36:04.920 --> 36:07.380 And here's another classic threat. 36:07.380 --> 36:17.720 It's not used obviously as much now, but the sticky keys backdoor is where the registry key is configured with command prompt as a debugger. 36:17.720 --> 36:31.880 So BlueSpawn's able to look for that, and that's T1546 sub technique 8, if you're following along on the MITRE ATT&CK matrix, so it knows to look for that, and then it goes and finds it, and it lets you remove that option. 36:31.880 --> 36:38.780 Next, this was probably one of the coolest examples we saw at a cyber defense competition that BlueSpawn caught earlier this year. 36:39.380 --> 36:48.920 Windows has these things called authentication packages and notification packages, and these exist in like the LSA subsystem, which is used for authentication and all. 36:49.160 --> 37:00.260 So BlueSpawn is able to map and is like, hey we found a registry key, it understands that in the hunt, that this hunt refers to things on disk. 37:00.500 --> 37:04.020 So then it goes and correlates that with the file associated with it. 37:04.020 --> 37:10.040 So we have two detections, one for the file and one for the registry key that contains the badness. 37:10.760 --> 37:13.920 Next, here is a good old run key. 37:15.020 --> 37:28.520 So there's a malicious BBS script that's configured to run in the registry, and again BlueSpawn is able to correlate the two and be able to connect that to generate detections and find both pieces of malware. 37:28.780 --> 37:30.240 Here's a web shell. 37:30.240 --> 37:34.740 This is a great, I like to use this for showing how the context works. 37:34.740 --> 37:55.780 So BlueSpawn uses a combination of regexes and YARA rules, and it's scanning all the stuff on the system in the web accessible directories, in say like IIS for PHP files, and it's able to say like, oh this was caught by this YARA rule, this piece of this file probably contains a web shell. 37:56.780 --> 38:01.920 And the next here is a pretty simple example with like backdooring services. 38:01.920 --> 38:11.360 So as hackers like to do this of course to get their malware to persist, and they can do this in a lot of ways, and so this is just a very simple example. 38:11.360 --> 38:20.340 But BlueSpawn will scan all the services on the system to find which might contain a piece of malware or what service is suspicious. 38:21.520 --> 38:34.100 So we want to get some feedback on RedTeam of course when we made this tool, and this was actually probably one of the first years they've ever had to contend with an open source tool being built by one of the teams. 38:34.160 --> 38:43.620 No one's really done that before just because it's a lot of work, and if other teams are using it then maybe you're not getting quite as much value out of it. 38:43.860 --> 38:53.200 But I think it worked out really well, and as you'd expect our RedTeams spent a lot of time analyzing the tool since it's open source. 38:53.200 --> 39:07.920 So the attackers know exactly what it can detect on, which is it's a bit hard to when you think about it you're like oh I don't know if I want the RedTeam seeing it, but what we found is that the it really pushed the attackers to move to new techniques. 39:07.920 --> 39:12.520 So they couldn't just rely on the same things over and over again because they knew we were going to catch that. 39:12.520 --> 39:23.980 So it forces them to keep moving and shifting their tactics, which means they might be less detectable, but it also really increases the barrier to make it harder for them. 39:24.200 --> 39:31.340 And honestly one of the coolest parts is that the RedTeam unveiled something called RedSpawn this year. 39:31.340 --> 39:35.660 So that was a tool that was apparently supposed to like attack and defeat BlueSpawn. 39:35.660 --> 39:44.760 So that feels like a validation to us for sure that BlueSpawn is effectively killing stuff that they used to rely on. 39:45.500 --> 39:56.160 So from the BlueTeam perspective, what we found in our experiences and other teams and all is that BlueSpawn works kind of like an EDR product that you'd expect to. 39:56.160 --> 40:00.680 So you can identify, it'll identify and respond to malware on the system. 40:00.740 --> 40:06.640 One of the cool things we found is that it's like a force multiplier, especially in these active defense situations. 40:06.760 --> 40:15.480 So imagine if your tool is deployed out across the multiple systems, right, you don't have to manually look through all like the auto runs yourself. 40:15.480 --> 40:18.980 It'll just flag which ones are most likely to be suspicious. 40:19.060 --> 40:24.440 And that way you can spend more of your efforts hunting where it counts to find the malware. 40:25.000 --> 40:26.580 And so that's really important. 40:26.980 --> 40:33.460 So we've prepared a little demonstration of what BlueSpawn looks like in action and how it can be actually used to hunt and then destroy malware. 40:35.220 --> 40:44.240 So I prepared a Windows Server 2012 R2 VM here and I filled up with a bunch of different random pieces of malware and their systems. 40:44.660 --> 40:52.980 So you can see here that I've got two active meterpreter sessions on it and I'm going to use BlueSpawn to go hunt and destroy them, among other things. 40:53.880 --> 40:58.080 So first I'll show you BlueSpawn's help menu just so you can see all the options it has. 40:58.080 --> 40:59.600 And that's a pretty simple interface. 41:01.400 --> 41:05.040 Because I want to go find bad things, I'm going to run it in hunt mode. 41:05.660 --> 41:11.220 I'm going to specify a normal aggressiveness just because I don't need to go too in-depth to find anything. 41:11.780 --> 41:14.700 When I find stuff, I want to react by deleting files. 41:14.700 --> 41:16.020 So I use the delete file reaction. 41:16.020 --> 41:17.000 I'm going to remove values. 41:17.000 --> 41:19.900 So remove value reaction and card memory. 41:20.820 --> 41:24.260 And then I want to log to a file so I can view it later. 41:24.320 --> 41:27.040 And then the console so I can see it now. 41:27.040 --> 41:29.220 Just press enter and now it runs. 41:29.380 --> 41:31.660 That's pretty much all there is to getting it to run. 41:33.200 --> 41:39.080 So here it found a process injection into SPC host PID 632. 41:39.340 --> 41:41.560 And I'll open it up in a process hacker. 41:43.620 --> 41:47.880 So you can see here that it actually tells me the memory address where it found the injection. 41:47.880 --> 41:50.800 So I can actually go take a look at that in process hacker. 41:51.080 --> 41:57.040 And you'll see here that it's RWX memory section, which generally is not a great thing. 41:57.140 --> 41:59.240 So I'll go ahead and carve that out. 41:59.400 --> 42:00.680 And here I found a couple more. 42:00.680 --> 42:02.440 So I'll go ahead and carve those out too. 42:03.800 --> 42:08.440 And here it found some process injection into win-startup.exe. 42:08.900 --> 42:10.860 And so I'll go ahead and carve those out. 42:16.900 --> 42:23.180 And now here it found the sticky keys backdoor that Jake was talking about earlier, the image file execution options debugger. 42:23.340 --> 42:28.160 And so I'll open that up in autorun so you can see that it's also found by autoruns. 42:30.940 --> 42:33.040 And it's under the image hijacks tab. 42:33.040 --> 42:34.800 Sometimes everything doesn't show it. 42:38.490 --> 42:40.030 You can see it there and there. 42:43.750 --> 42:45.030 So we'll go ahead and remove that. 42:45.030 --> 42:50.910 And here it found the run key that was running the process we found some injection in earlier. 42:51.150 --> 42:54.330 The window startup actions, which definitely is not legitimate. 42:54.470 --> 42:56.150 So go ahead and remove that run key. 42:56.410 --> 43:01.230 Here it found NetSH helper DLL, which is a sneakier persistence technique. 43:01.230 --> 43:02.730 You can see it in regedit. 43:03.030 --> 43:06.390 And BlueSpawn actually protects the files during scans. 43:06.390 --> 43:10.030 So this actually won't be able to show the signatures on it. 43:10.030 --> 43:12.130 But I assure you it's not good. 43:21.620 --> 43:24.520 So we'll go ahead and remove that value there. 43:25.900 --> 43:28.380 And now it found the PHP web shell. 43:28.380 --> 43:29.940 We can go ahead and remove. 43:33.580 --> 43:37.620 And here is the malicious service. 43:37.680 --> 43:39.000 So go ahead and remove that. 43:39.320 --> 43:41.700 And for some reason autoruns can't find it. 43:41.700 --> 43:44.940 But I'll show you in this command prompt that it absolutely is there. 43:53.210 --> 43:55.370 So I'll go ahead and remove that with BlueSpawn. 43:56.930 --> 44:00.450 And now I'll go ahead and remove the NetSH helper DLL file. 44:01.270 --> 44:04.230 And here's the win startup.exe that it didn't like. 44:04.790 --> 44:06.630 And here's the malicious service. 44:07.010 --> 44:08.150 And that's it. 44:08.150 --> 44:09.230 That's all you have to do. 44:13.550 --> 44:17.050 And here's autorun showing you that stuff it found has been cleared out. 44:19.250 --> 44:20.710 So next slide. 44:21.170 --> 44:24.070 So here's what happened to the interpreter sessions that I had open. 44:24.150 --> 44:26.050 They got killed when I carved out the memory. 44:29.170 --> 44:31.210 And now on to the future work. 44:31.290 --> 44:33.350 BlueSpawn still has a long way to go. 44:33.350 --> 44:34.990 A lot more features to be added. 44:34.990 --> 44:40.030 I'm going to talk here about some of the ideas and plans to come up with for future development on BlueSpawn. 44:40.310 --> 44:44.430 So most of our goals right now fall under three categories. 44:44.530 --> 44:49.670 Improving coverage, improving configurability, and improving integrity. 44:49.770 --> 44:53.590 So under coverage, we plan to continue adding new hunts and mitigations. 44:53.630 --> 44:57.270 Arguably our biggest goal here is to expand our data sources. 44:57.270 --> 45:03.630 So this would constitute things like API monitoring through a DLL load into all the processes or a kernel driver. 45:04.030 --> 45:07.210 Network traffic monitoring, user auditing, that sort of thing. 45:07.210 --> 45:11.210 We've also placed a large focus on improving our scanning capabilities. 45:11.210 --> 45:15.290 Admittedly, they are somewhat lacking right now, using only the very basic metrics. 45:15.630 --> 45:24.670 One of our goals with BlueSpawn from the start has been to kind of bridge the gap between incident response and active defense, taking past incidents into account for current threat hunting. 45:25.090 --> 45:34.150 Currently, BlueSpawn has taken some smaller steps towards integration between the two, but we intend to work on building that out further and making it really a much bigger feature. 45:34.890 --> 45:41.010 As we develop BlueSpawn, we've built most of our features to be very configurable from an API perspective. 45:41.010 --> 45:48.250 But as of now, BlueSpawn doesn't really do a good job of exposing those APIs, and the command line interface we have barely taps into the surface of that. 45:48.730 --> 45:56.670 We'd really like to expose more of these configurations to allow things like much more targeted hunts, customizable scanning, and mitigation presets. 45:57.050 --> 46:03.830 We'd also like to add a way for signatures and definitions to be configurable, so that if users have their own signature-based integrate, they'd be able to. 46:04.010 --> 46:11.730 As for integrity, right now, BlueSpawn has very little defenses against malware or malicious users actually tampering with it. 46:11.730 --> 46:22.110 To that end, we intend to work on hardening BlueSpawn itself, making it much more difficult for a malicious process from modifying it or causing problems with its execution. 46:22.110 --> 46:24.690 And this would most likely be through a kernel driver. 46:24.870 --> 46:28.470 BlueSpawn also assumes it has all the rights that an admin normally has. 46:28.470 --> 46:35.510 But if malware is trying to protect itself, it might restrict access to certain resources that BlueSpawn was assuming it'd just get with no problem. 46:35.610 --> 46:38.310 This also would likely be addressed to the same kernel driver. 46:38.790 --> 46:51.750 Finally, and this is more of a development feature, we intend to set up detailed Atomic Red Team tests, which are basically tests that test against one specific malware technique to ensure that each build has proper coverage for everything it should. 46:53.530 --> 47:00.250 Now, everything I've presented so far has been focused on our Windows client, but our plans go a lot beyond that. 47:00.250 --> 47:06.790 Just this past week, actually, we finished porting a version of BlueSpawn over to Linux, where we are now able to write hunts of mitigations. 47:07.010 --> 47:15.710 The Linux client is a decent bit behind the Windows one in terms of capability and coverage, but we plan to have an initial release at some point soon. 47:15.910 --> 47:22.790 We've also begun developing a server used to deploy BlueSpawn across the network and then aggregate the logs and manage the client at scale. 47:22.850 --> 47:27.390 This server is still in its early stages, but we plan to ramp up development in the next few months. 47:27.770 --> 47:30.790 Finally, the last major component to BlueSpawn is the cloud. 47:30.790 --> 47:34.930 Now, this is a long way off, and I'll admit we haven't even started thinking about developing it yet. 47:34.930 --> 47:45.030 But the idea is that the clients or servers could send off malware to the cloud to perform better, more detailed scans, likely doing some form of sandboxing or heuristic analysis. 47:45.150 --> 47:51.310 This could also serve as a threat intelligence repository, sending out IOCs to clients and servers. 47:52.790 --> 47:55.070 So, we've talked a lot. 47:55.070 --> 48:08.050 Hopefully, we've given you a really good overview of kind of at a high level, like why we built BlueSpawn, a bit really into the weeds of how it works, and how these types of solutions really work in the real world, and then kind of showing you what it's like in action, 48:08.050 --> 48:08.650 right? 48:08.690 --> 48:10.330 So, we're going to conclude. 48:10.810 --> 48:14.890 First, remember that BlueSpawn is very much still in the alpha stage. 48:15.510 --> 48:22.630 So, it can detect a lot of the most popular techniques, but there's certainly some things that it's going to miss, and it's a bit rough around some of the edges. 48:23.050 --> 48:34.550 Since all the code and detections are open source, though, we highly recommend you taking it out, just going to the GitHub page, and you can kind of find and look through, see exactly how it works. 48:34.550 --> 48:43.590 And because it's really important to us to shed light on kind of how these black box EDR solutions that you might have deployed out in your network might actually work. 48:43.870 --> 48:50.210 And we also want to extend a huge thank you, again, to the community projects that are listed here. 48:50.390 --> 48:58.890 Really, building something like this is not possible without these frameworks and libraries, so definitely check those two out as well. 48:59.290 --> 49:06.170 So, most importantly, if you've gained anything from this talk, we'd like you to walk away with these three things. 49:06.670 --> 49:14.170 First, using MITRE ATT&CK to be able to detect threats and think about your defenses is a great springboard. 49:14.170 --> 49:15.970 And really, think about it as a springboard. 49:15.970 --> 49:24.670 So, like we found when we were developing BlueSpawn, that MITRE ATT&CK might not have the most in-depth information on a particular technique, right? 49:24.730 --> 49:27.430 But you can use that and go as a rabbit hole. 49:27.430 --> 49:34.130 So, if you know attackers are going to abuse it, you can go look into that technique more to figure out how attackers might use it. 49:34.130 --> 49:36.970 So, that's a good, really good place to start. 49:37.430 --> 49:39.350 Second, knowing your coverage. 49:39.910 --> 49:46.470 So, we've used this more times than I can count, right, in our cyber defense competitions and all. 49:46.470 --> 49:48.930 And it translates really good to the real world, right? 49:48.930 --> 50:03.830 So, if you start thinking about, like, if you're X-ing techniques off of the attack matrix, right, you can actually get pretty far because if you think about it, the attacker isn't going to be able to use those techniques as well against you once you've got a little X over them. 50:03.830 --> 50:07.470 So, that's a great way to think about defense. 50:07.490 --> 50:16.870 And then finally, really, BlueSpawn is kind of like a massive experiment just to figure out and understand how modern-day defensive software works. 50:16.870 --> 50:24.790 So, just like you might tear apart, like, exploits and malware, we recommend doing the same thing for your defensive security solutions, right? 50:24.790 --> 50:31.830 And thinking about, learning about how they work, and then you can use that to kind of build and improve your own defenses. 50:32.070 --> 50:36.530 So, just a few housekeeping items, I guess, before we wrap up. 50:36.930 --> 50:38.990 Thank you all for listening today. 50:38.990 --> 50:44.810 We hope you've had as much fun as we have in creating this and talking this afternoon. 50:45.110 --> 50:48.810 We also would like to thank the conference volunteers, right? 50:48.810 --> 50:56.110 This would not have been possible without all their hard work and setting up the streaming and just making it all flow. 50:56.630 --> 50:59.670 Finally, we've linked the slides on the README. 50:59.670 --> 51:04.850 We'll have the DEF CON release, if you will, go live here in a bit after this talk ends. 51:04.850 --> 51:11.230 So, you can download the tool as we've been talking about it and kind of see a bit more what it's like. 51:11.230 --> 51:12.790 You can look at the slides. 51:12.830 --> 51:14.590 We also have a Discord for the project. 51:14.590 --> 51:25.170 So, if you have any questions and I think they're going to post a link to the Discord and all, hop in there and you can go chat with us afterwards and we'll let you know. 51:25.170 --> 51:27.550 We'll be happy to answer any questions you might have. 51:27.550 --> 51:29.910 So, thanks again, guys, for listening. 51:29.910 --> 51:31.350 We hope you really enjoyed it. 51:31.350 --> 51:32.130 Thank you. 51:32.850 --> 51:34.750 Well, thanks, Jake and Jack. 51:34.750 --> 51:35.950 That was a great talk. 51:35.950 --> 51:43.930 I look forward to see what BlueSpawn continues to develop into and appreciate you coming out to DEF CON and presenting to us. 51:43.930 --> 51:49.010 As a reminder, as they've got up here on the slide, the Discord channel takes you over to their server. 51:49.110 --> 51:57.910 It is also up in the General, under the General tab of our Discord channel, as well as a link in the actual Texthalk channel as well. 51:58.090 --> 51:59.950 Other than that, have a great day, guys.