[00:09.610 --> 00:14.170]  And welcome back, everybody, to DEF CON 28 Safe Mode, Blue Team Village.
[00:14.530 --> 00:19.710]  We're going to start our next set of speakers. 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:31.910]  Jake Smith and Jack McDowell will be presenting. As always, please direct all questions to the
[00:31.910 --> 00:38.970]  Tech Talks Track 1 channel, or you can connect to their Discord server as well and send messages to
[00:38.970 --> 00:45.390]  them directly. I'll have that in there in one second. And on that note, over to you, Jake and
[00:45.390 --> 00:52.430]  Jack. All right. Thank you. So how's everyone doing today? Just a few quick notes before we
[00:52.430 --> 00:57.170]  get into the presentation. We definitely want to take a moment to say thank you to all the
[00:57.170 --> 01:02.870]  volunteers and organizers of the Blue Team Village. Putting this event on in a normal
[01:02.870 --> 01:08.050]  year is a lot of work, and I can only imagine what they've done to make this happen. So a huge
[01:08.050 --> 01:14.890]  thank you to them. So today, Jack and I are going to be talking about an open-source project we've
[01:14.890 --> 01:19.910]  been developing for about a year now. It's called BlueSpawn, and you'll notice the emphasis on
[01:19.910 --> 01:26.010]  active defense here, so we'll get into more about that later. But first, a little bit of background
[01:26.010 --> 01:32.510]  about the two of us. We went to the University of Virginia. Both of us got our start in InfoSec doing
[01:32.510 --> 01:38.230]  really all kinds of cyber competitions, CTFs, and whatnot, and that's been a fantastic way to
[01:38.230 --> 01:45.710]  kind of get into security. And these competitions we'll talk about more are some of the reasons why
[01:45.710 --> 01:53.310]  we created BlueSpawn and all. So an important caveat, too, before we get into the presentation.
[01:53.310 --> 02:00.050]  When we say we this afternoon, we're referring to all six of us on the slide. It turns out that
[02:00.050 --> 02:07.670]  developing a large open-source project with already like 20,000 lines of C++ is a huge,
[02:07.670 --> 02:14.550]  huge undertaking. So it's really a team effort that we've been doing to create this.
[02:15.810 --> 02:21.590]  So, and also before we get into talking about BlueSpawn specifically, we're going to do a brief
[02:21.590 --> 02:26.950]  overview of some of the available tools out there and kind of where they shine, where they have some
[02:26.950 --> 02:33.690]  shortfalls, and more. And really, this is just all the tools that we're going to mention do a
[02:33.690 --> 02:39.110]  fantastic job, which is part of the reason why we want to talk about them as well. So first,
[02:39.110 --> 02:45.310]  we'll start with your Endpoint Detection and Response, or EDR, tools. That's your CrowdStrikes,
[02:45.310 --> 02:53.450]  your Carbon Black, your Defender ATP, Sentinel-1, and all. They obviously used to, like 10, 15 years
[02:53.450 --> 03:00.390]  ago, AVs were pretty simple. They look for bad hashes and whatnot, and now kind of that's, they've
[03:00.390 --> 03:04.290]  increased, and they've gotten really, really good. So these commercial tools, and they're a bit
[03:04.290 --> 03:10.130]  expensive in some ways, but they really raise the bar for finding the low-hanging fruit, especially
[03:10.130 --> 03:14.910]  in some, even some of the more advanced malware. They're obviously not all created equal, but
[03:15.670 --> 03:19.130]  one of the things we noticed when we started developing BlueSpawn is that
[03:19.130 --> 03:24.290]  these defensive security solutions are pretty opaque overall. There's obviously a lot of
[03:24.290 --> 03:29.930]  offensive tools out there, but it's really hard to get your hands on and kind of understand how
[03:29.930 --> 03:37.630]  these modern AV and EDRs work, which leads us into a bit about some of the free tools that
[03:37.630 --> 03:43.970]  are out there. There's not a whole lot of great ones, but definitely Sysinternals is probably
[03:43.970 --> 03:49.710]  one of the best. If you haven't used the Sysmon, if you haven't used much just beyond like Sysmon
[03:49.710 --> 03:55.450]  to improve your logging, highly recommend taking a look at like Autoruns and Process Explorer and
[03:55.450 --> 04:02.230]  Procmon. Just, they do a great job of finding malware on the system. They're more geared though
[04:02.230 --> 04:06.990]  toward the system analysis side, so they don't really, they're not going to say like, hey, this
[04:06.990 --> 04:13.750]  is malware. They might show like a different color if this is like encoded or something, but they're
[04:13.750 --> 04:19.610]  not going to point out and like say this is MITRE attack technique 1547, right, for example.
[04:20.610 --> 04:26.350]  Next is Process Hacker. Process Hacker is another really great tool. There's not much automation or
[04:26.350 --> 04:32.310]  security focus, but it's really good at just analyzing. It's like Task Manager on steroids,
[04:32.310 --> 04:39.530]  really, and you can even look at like a specific region in memory. So like if you know that
[04:39.530 --> 04:46.050]  one process was injected, for example, then you could go and analyze each bit of the memory
[04:46.050 --> 04:52.790]  yourself. And then on the like purely defensive side, we've definitely found PE-Civ to be one of
[04:52.790 --> 04:57.870]  the best free and open source tools out there by far. The idea is pretty simple behind the tool.
[04:57.870 --> 05:03.870]  It's basically look at all the processes running on the system, and then it can find hooks, process
[05:03.870 --> 05:09.530]  hollowing, process injection, shellcode, all that kind of good stuff. The only downside,
[05:09.530 --> 05:14.850]  if it's really a downside, is that it's limited to scanning processes. So it's not going to find
[05:14.850 --> 05:19.030]  like other malware, say, like that's hiding in the registry on a system.
[05:20.250 --> 05:27.470]  And finally, in this kind of available tool section is like the collections of YARA rules,
[05:27.470 --> 05:32.770]  Sigma rules, Sysmon configs out there. Even just a few years ago, there just wasn't really a whole
[05:32.770 --> 05:38.570]  lot out there, especially on the defensive side in way of signatures. But these projects are doing
[05:38.710 --> 05:43.710]  a really good job of starting to share threat intel a bit more widely and can help you find
[05:43.710 --> 05:49.950]  threats just on a particular system. The only thing, I guess, the caveat is like with hardening
[05:49.950 --> 05:55.570]  scripts, for example, a lot of the stuff you'll find out there is very, I guess, more script-like
[05:55.570 --> 06:00.250]  and not fully fleshed out. So that's one thing to be aware of, like they'll set conflicting values
[06:00.250 --> 06:08.550]  or miss critical settings and whatnot. But so that, I mean, that's kind of the reasons why we
[06:08.550 --> 06:13.890]  got into building BlueSpawn, which we'll talk about here more shortly. And one of the key
[06:13.890 --> 06:19.330]  things we want to emphasize this afternoon is that is the ideas and principles on which we
[06:19.330 --> 06:23.590]  built this tool. You're probably not going to go into work Monday and deploy BlueSpawn
[06:23.590 --> 06:28.730]  in production. And I guess you could, but that's maybe not something you want to do quite yet
[06:29.370 --> 06:34.350]  because the project's not quite that far along. But that said, you can use the information in
[06:34.350 --> 06:40.610]  today's talk to conduct your own security research and begin kind of improving your own defenses too
[06:40.610 --> 06:48.210]  and looking at how these kinds of solutions work. So with all things, all great ideas, I guess,
[06:48.210 --> 06:53.890]  start in Slack and whatnot. So this was, I went into our archives, this was last year, like we
[06:53.890 --> 06:59.130]  started with this really simple idea, like what if we could like scan one particular thing, like
[06:59.130 --> 07:06.790]  look at GS registry run keys, like as a way to detect threats and whatnot on a system and like
[07:06.790 --> 07:14.470]  an open source tool. And we didn't find a whole lot out there. So that kind of led us to creating
[07:14.470 --> 07:20.850]  BlueSpawn. And as I said, we were students or we are students, so we compete in a lot of these
[07:20.850 --> 07:26.410]  different cyber defense competitions and whatnot. Honestly, frankly, I tell some people that I just
[07:26.410 --> 07:34.850]  do go to school for competitions and all. But basically, these cyber defense competitions are,
[07:34.850 --> 07:40.190]  basically, you get a network and you're asked to secure it against active attackers, who
[07:40.190 --> 07:44.450]  unfortunately for the students are industry red teams. So you can imagine how that kind of thing
[07:44.450 --> 07:50.290]  goes. And the red team pretty much always wins. So in these competitions, though, we can't really,
[07:50.290 --> 07:54.750]  we can't use commercial tools and we can't bring in scripts. So we have to rely on open source tools.
[07:54.750 --> 08:00.470]  That's kind of another reason why we focus so heavily on the open source aspect. And so we
[08:00.470 --> 08:07.710]  built BlueSpawn on one really particular focus is that we want to be able to stop threats as
[08:07.710 --> 08:13.770]  quickly as possible. So I think that you should be able to run this tool and find as many, if not the
[08:13.770 --> 08:19.370]  majority or more of all the threat, all of the malware that's running on your system as quickly
[08:19.370 --> 08:26.990]  as possible. And so that is where the idea of active defense comes in.
[08:27.570 --> 08:32.530]  And then the next is coverage. So when doing these cyber defense competitions, it's time
[08:32.530 --> 08:37.870]  limited. You're stressed and whatnot. So you don't have the luxury of, say, being able to
[08:37.870 --> 08:43.050]  look at everything very closely. And you can't pull up a process explorer and look at every
[08:43.050 --> 08:49.970]  individual process to hunt for process injection. So our idea is that if you can get 60, 70, 80%
[08:49.970 --> 08:56.030]  of the way there on finding the most common threats, and you know what your tool is going
[08:56.030 --> 09:02.030]  to be looking for, you can spend more time on those other areas as well. And finally, open
[09:02.030 --> 09:07.750]  source software. So this is a call to everyone out there. There's a lot of stuff on the offensive
[09:07.750 --> 09:13.850]  side, but there's just not really as much on the defensive side. So definitely building more
[09:13.850 --> 09:19.210]  open source blue team software, I think, is really important. And it's a great way for people to learn
[09:19.830 --> 09:25.530]  about how these kinds of things work and how you might detect, say, one particular technique in the
[09:25.530 --> 09:34.210]  attack matrix. So as time went on, from that simple idea that we posted a while ago in Slack,
[09:34.660 --> 09:41.230]  we started moving BlueSpawn towards what you might term as calling EDRs type solution
[09:41.230 --> 09:48.610]  today. So that's where it's doing continuously monitoring. And we're asking questions like,
[09:48.610 --> 09:54.590]  what if we could just deploy BlueSpawn across the whole network like you might deploy like Falcon?
[09:54.590 --> 09:59.650]  This is kind of the ideas that we're heading towards as we spend more and more time developing
[09:59.650 --> 10:07.830]  this. And then also proactive defense. So it's not enough that you can detect malware and respond
[10:07.830 --> 10:14.010]  to it, right? We also, one of the core focuses is the idea of being able to prevent these malicious
[10:14.010 --> 10:20.590]  activities in the first place. So we've talked a lot about active defense so far, but what do we
[10:20.590 --> 10:25.930]  really mean by it? And how does BlueSpawn approach the idea of finding anomalous or malicious
[10:25.930 --> 10:31.810]  behavior? And that's kind of what I'll get into in this section. So typical antivirus or EDR
[10:31.810 --> 10:36.130]  products are meant to kind of run in the background behind everything, only raising alerts and acting
[10:36.130 --> 10:40.730]  when there's something definitely bad going on. For their use cases, this is a very good thing.
[10:40.730 --> 10:45.570]  People don't want alerts about everything that may or may not be malicious. But when you've
[10:45.570 --> 10:50.470]  been compromised, or even when you think you've been compromised, that might not be enough. This
[10:50.470 --> 10:55.230]  is where our concept of active defense comes into play. Rather than sit in the background,
[10:55.230 --> 11:00.370]  only rarely making noise, BlueSpawn is meant to be a tool that's actively used. The goal is
[11:00.370 --> 11:05.210]  to find absolutely everything that could be malicious, not just the things it knows for sure
[11:05.210 --> 11:10.350]  are malicious. In such an approach, there are drawbacks. In catching all the things, we're sure
[11:10.350 --> 11:15.470]  to catch some things that aren't actually bad. But for an active defense situation, that's a
[11:15.470 --> 11:21.890]  trade-off we want to make. So how does BlueSpawn go about approaching this? Originally, this worked
[11:21.890 --> 11:27.210]  by just performing a scan of the system at a point in time to identify all the threats that
[11:27.210 --> 11:33.270]  were currently on there. And this hunting involved the typical registry scans, file scans, or process
[11:33.270 --> 11:40.430]  scans that an AV or EDR product would use. But again, BlueSpawn tried to be more in-depth, taking
[11:40.430 --> 11:45.890]  more time to look at things, with more of a focus on finding anything that's not normal. And I think
[11:45.890 --> 11:52.670]  what makes BlueSpawn different is we also factor event logs into our hunts. So correlating what
[11:52.670 --> 11:58.270]  Windows events have occurred with what is currently on the system to identify any sort of
[11:58.270 --> 12:02.370]  malicious behavior there. And we're trying to basically use that to bridge the gap between
[12:02.370 --> 12:09.010]  incident response and what EDR products do. And as we move towards continuous monitoring,
[12:09.010 --> 12:13.910]  we extended these hunts to be able to run as needed. And I'll talk more about how we did that
[12:13.910 --> 12:21.110]  shortly. So as I mentioned on the previous slide, BlueSpawn is built pretty heavily around the idea
[12:21.110 --> 12:26.410]  of what we call hunts. For each MITRE attack technique we support, which is basically a way
[12:26.410 --> 12:32.410]  attackers do things if you're not familiar, we've created a hunt, which basically is a search for
[12:32.410 --> 12:38.330]  any sort of evidence of malicious activity using technique. We'll get into more detail about how
[12:38.330 --> 12:42.710]  specifically these hunts work in a bit, but for now, just know that they're really the starting
[12:42.710 --> 12:47.470]  point for everything BlueSpawn does. Monitoring, as I mentioned a while back, is really just an
[12:47.470 --> 12:53.390]  extension of the hunts we've already written. Each hunt creates triggers for when it should be rerun,
[12:53.390 --> 12:58.370]  and when those triggers occur, it gets run again. Now, MITRE recently released sub-techniques,
[12:58.370 --> 13:03.590]  which break down each technique attackers may use into subcategories. And BlueSpawn has just
[13:03.590 --> 13:08.470]  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:19.590]  We can find registry keys that run files around startup libraries that aren't meant to be
[13:19.590 --> 13:24.130]  included at all, all sorts of fun stuff. But malware tends to have a number of different
[13:24.130 --> 13:28.610]  components that it uses, or even if it doesn't, it exists in multiple different forms in multiple
[13:28.610 --> 13:33.370]  different places. Maybe there's a registry key that points to a file, and then that file is
[13:33.370 --> 13:37.470]  loaded into a process, and then that process is changing other registry keys, and those keys
[13:37.470 --> 13:43.730]  point to files. And those files, well, you get the idea. To address this, BlueSpawn searches each
[13:43.730 --> 13:48.570]  piece of evidence it finds in order to see if it can catch anything related to it. The result from
[13:48.570 --> 13:53.190]  this is a network of evidence of malicious activity. In the next section, I'll go into
[13:53.370 --> 13:58.890]  a bit more detail about how this actually gets built. Now that I've given a higher-level overview
[13:58.890 --> 14:03.410]  of our methodology, I'm going to take a deeper dive into the different things BlueSpawn can do
[14:03.410 --> 14:08.330]  with a focus on how it does them. And this section is going to get a little bit technical, but I'll
[14:08.330 --> 14:14.350]  finish it with a more broad overview if you don't catch anything. So before I get into any of the
[14:14.350 --> 14:18.970]  features, I want to preface with a disclaimer. BlueSpawn is still in alpha development. So far,
[14:18.970 --> 14:23.850]  we've been mostly focusing on infrastructure, that is, building out the core of the features I'm
[14:23.850 --> 14:27.830]  getting into. Everything I'm presenting is currently implemented, but it's not entirely
[14:27.830 --> 14:32.270]  without its bugs. And the biggest example of what I'm talking about is our scanning
[14:32.270 --> 14:37.750]  subsystem. I'm going to say things like, this is where BlueSpawn scans X, but the actual scans
[14:37.750 --> 14:42.530]  performed are new and not necessarily heavily tested. At this point, I'd say a lot of the
[14:42.530 --> 14:48.350]  features described here are better talked about as a framework than a fully fleshed-out product.
[14:48.750 --> 14:52.570]  And none of this is to say BlueSpawn isn't effective. We've spent a long time building
[14:52.570 --> 14:56.930]  our hunts and expanding our coverage, and it's proven to be pretty good at its job, as Jake will
[14:56.930 --> 15:03.050]  showcase in his case studies section. 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:12.730]  There's Mitigate, which applies security settings, Hunt, which runs the hunts I was talking about
[15:12.730 --> 15:19.130]  earlier, Scan, which determines how bad detections really are and finds associations, Monitor,
[15:19.130 --> 15:24.990]  which hunts over time, and React, which handles responses to what HuntMode and ScanMode have
[15:24.990 --> 15:31.830]  identified. So Mitigate mode sits somewhat apart from the rest of BlueSpawn without really
[15:31.830 --> 15:37.090]  any integrations to the other modes, so I'll just talk about that first to get out of the way.
[15:37.550 --> 15:42.350]  Mitigations applied by BlueSpawn are all mapped to either a Security Technical Implementation Guide,
[15:42.350 --> 15:47.790]  or STIG, released by DISA, or the Miner Attack Mitigations Framework. When running Mitigate
[15:47.790 --> 15:52.230]  mode, BlueSpawn can either audit the current state of the system, which just says this is what it's
[15:52.230 --> 15:57.130]  currently set up as, or it can go ahead and apply the mitigations it finds aren't properly configured,
[15:57.130 --> 16:03.270]  with user confirmation, of course. Now, as of now, our mitigation framework is very quite simple,
[16:03.270 --> 16:07.410]  but we think it has a lot of potential as BlueSpawn continues to grow. We see it eventually
[16:07.410 --> 16:11.590]  being configurable through some sort of configuration file, so mitigations can be
[16:11.590 --> 16:16.530]  more uniformly and quickly applied across a network. We also see it mitigating services
[16:16.530 --> 16:21.750]  and software installed on a system, rather than just the base operating system. And finally, our
[16:21.750 --> 16:28.590]  biggest envisioned change is for Mitigation mode to serve as really an aid in performing a system
[16:28.590 --> 16:33.570]  audit. So this would perform some of the same tasks as enumeration tools, such as
[16:33.570 --> 16:38.950]  Seatbelt or JAWS, with a focus on finding and fixing things actually being vulnerable to being
[16:38.950 --> 16:44.790]  exploited. Now, before I get into the weeds of how everything works, I'm going to throw some
[16:44.790 --> 16:51.070]  definitions at you for how I refer to the ideas and concepts BlueSpawn uses. So I'm going to be
[16:51.070 --> 16:55.870]  using the word detection a lot, and it's just that, detection. It could be something good, it could be
[16:55.870 --> 17:01.050]  something bad, it's just something BlueSpawn identified as taking a closer look at. It could
[17:01.050 --> 17:06.550]  be like a file, a registry key, a process, or something else entirely. Next, there's an association,
[17:06.550 --> 17:11.910]  which is also just what it sounds like. It's a connection between two different detections, and
[17:11.910 --> 17:17.150]  in BlueSpawn, we represent associations as having a weight, representing how closely they are
[17:17.150 --> 17:22.970]  associated. Next thing is certainty, and this is the metric we use for determining the likelihood
[17:22.970 --> 17:28.890]  that a detection is actually bad. There are three components to it. The two of them get combined, so
[17:28.890 --> 17:34.050]  in practice, there are really only two. The first is what I call intrinsic certainty. This is the
[17:34.050 --> 17:39.190]  certainty that comes from the detection itself. This would be what we're talking about if a
[17:39.190 --> 17:44.750]  service was called Mimikatz, or if a file matched a Yara rule from Reterpreter, or something like that.
[17:45.380 --> 17:51.210]  The next is contextual certainty. This comes from the context surrounding the detection.
[17:51.210 --> 17:55.310]  In a lot of ways, this is very much like the intrinsic certainty, and in fact, BlueSpawn
[17:55.310 --> 18:00.070]  doesn't actually differentiate between the two. They're really combined. And what I mean by
[18:00.070 --> 18:07.930]  context is things like a file in System32 that's not assigned by Microsoft, and that's probably bad
[18:07.930 --> 18:14.130]  just because they usually are. Or any value listed under an app in a DLL is probably bad just because
[18:14.130 --> 18:19.310]  they aren't really used legitimately anymore. The last type of certainty I'm going to talk about
[18:19.310 --> 18:24.670]  is associative certainty, and this is the certainty that comes from the associations of detection.
[18:24.930 --> 18:30.250]  Say we've got a file and we found it loaded into a process. If the process is behaving maliciously
[18:30.250 --> 18:35.650]  and the file appears malicious, the file should be treated with a higher certainty than if all
[18:35.650 --> 18:42.050]  we had was a malicious-looking file. Now that I've got those definitions out of the way, I can move
[18:42.050 --> 18:47.430]  on to how BlueSpawn actually works. The core of all detection management, and really the core of
[18:47.430 --> 18:52.910]  BlueSpawn itself, is our detection register. This tracks everything that BlueSpawn's found.
[18:52.930 --> 18:58.410]  Whenever a hunt or a scan or whatever finds anything that might be bad, it sends it to the
[18:58.410 --> 19:04.130]  detection register. The register will record the detection and send back a reference to it. Now,
[19:04.130 --> 19:09.570]  this reference may or may not be the detection that was recorded, and I'll explain why next
[19:09.570 --> 19:14.410]  slide when I explain how the registration process actually works. The detection register has three
[19:14.410 --> 19:21.090]  storage mechanisms. So whenever a detection gets registered, it gets queued for a scan and we track
[19:21.090 --> 19:25.830]  all queued detection in one set and all scanned detections in another. That way we can just make
[19:25.830 --> 19:30.370]  sure we're not redoing the same work. We also keep a record of all detections regardless of whether
[19:30.370 --> 19:36.350]  or not they've been scanned. So now for how registration actually works. The first thing
[19:36.350 --> 19:42.030]  the register actually does when a new detection is being added is it checks if the detection
[19:42.030 --> 19:46.610]  already exists. If it does, they get merged together. And generally the only thing that
[19:46.610 --> 19:52.410]  changes when this happens is their contextual certainties and their contexts get merged.
[19:52.410 --> 19:57.910]  If this merge causes their overall certainty to exceed a certain threshold, it then gets logged
[19:57.910 --> 20:02.290]  and its reactions get triggered. If the detection being registered was merged with the pre-existing
[20:02.290 --> 20:06.590]  one, the reference that returned is actually to the pre-existing one. That way it's just keeping
[20:06.590 --> 20:12.170]  track of the detection that we care about. Otherwise it's to the new detection. After all
[20:12.170 --> 20:18.410]  this is handled, if the detection register needs to queue scans for the detection, it will. This
[20:18.410 --> 20:23.510]  constitutes calculating the intrinsic certainty, identifying associated detections, and then if the
[20:23.510 --> 20:28.370]  certainty is high enough after that, logging it and handling reactions. The associated detections
[20:28.370 --> 20:36.510]  then get registered and the scans for those get queued and so on. So here I've got a diagram for
[20:36.510 --> 20:41.250]  how the detection register lays things out. It looks kind of complicated, but I'll try to explain
[20:41.250 --> 20:46.750]  it so it's maybe not quite as bad as it looks. So the register itself has three main storage
[20:46.750 --> 20:52.110]  mechanisms. There's the queue of things that haven't been scanned yet, things that have been scanned,
[20:52.110 --> 20:57.370]  and then everything overall. And you can see that all these storage mechanisms really just store
[20:57.370 --> 21:03.990]  references to detections that are stored elsewhere. I've also broken down one detection, in this case
[21:03.990 --> 21:09.790]  ID2, to show what kind of information detection actually holds. So it first has its ID, which is
[21:09.790 --> 21:14.810]  just an ID, a unique identifier to refer to it. It has a context, which is the information
[21:14.810 --> 21:20.610]  surrounding how it was made and how it was found and when that happened and all that. So that'd be
[21:20.610 --> 21:25.890]  what time the detection occurred, what hunt found it, and when the first evidence of the detection
[21:25.890 --> 21:33.990]  was found. There's also the data, and this stores information about what actually did it find. So in
[21:33.990 --> 21:38.790]  this case, I've just decided for the purpose of an example, this detection is going to refer to a run
[21:38.790 --> 21:46.130]  key and its value name. 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:56.350]  That has the certainty, which combines the intrinsic and the contextual certainties,
[21:56.350 --> 22:00.610]  and then the associative certainty. The last part of this is the associations, which
[22:02.650 --> 22:07.130]  identifies which detections are associated with this one. In this case, detection ID1,
[22:07.130 --> 22:14.030]  which I'm using to refer to as bad.exe, is associated with it. There's also a remediator,
[22:14.030 --> 22:18.950]  and I'll get to that a bit later. So in the methodology section, I mentioned how hunts
[22:18.950 --> 22:22.950]  represent the starting point for pretty much all the threat hunting that BlueSpawn does.
[22:22.950 --> 22:29.430]  Each one covers one minor attack technique. Each hunt, we then break down into sub-techniques,
[22:29.430 --> 22:34.290]  which can be run independently of each other. Within each sub-technique, that gets broken
[22:34.290 --> 22:40.650]  down then into sub-sections, and one sub-section generally checks just one specific attack surface,
[22:40.650 --> 22:45.410]  whether it's a folder, a file, an event ID, or a registry key, or something else. The idea is to
[22:45.410 --> 22:51.470]  keep it as simple and small as possible. This design allows for much more targeted hunts if we
[22:51.470 --> 22:55.350]  know what we're specifically we're looking for, and I'll get into why that matters when I talk
[22:55.350 --> 23:00.930]  about how monitoring works. Most of the things we check get a quick scan, which just performs the
[23:00.930 --> 23:05.470]  most elementary scans. It's a very quick test to determine whether or not something deserves more
[23:05.470 --> 23:10.410]  detailed scans. If it does, we create a detection for it and register it with the detection register
[23:10.410 --> 23:15.210]  and kick off the whole scanning thing I just finished talking about. Then the scans I discussed
[23:15.210 --> 23:21.790]  get run on it and make a determination, find other related things, and so on. Here's an example of
[23:21.790 --> 23:27.650]  what a hunt looks like. In this case, this is a T1547. The hunt itself really just runs all
[23:27.650 --> 23:34.670]  sub-techniques underneath it, you can see here. And then here's the sub-technique number four,
[23:34.670 --> 23:39.970]  which I picked out because it was pretty simple. The first part of it just compares
[23:39.970 --> 23:47.390]  the winlogon values for the shell and username against known goods. If they don't match,
[23:47.390 --> 23:51.750]  we create detection with a moderate contextual certainty, because anything that doesn't match,
[23:51.750 --> 23:58.070]  chances are it's bad, even though the file itself might not be bad. The next sub-section
[23:58.070 --> 24:04.610]  refers to the winlogon notify values. Any of these that we find get a detection created for it,
[24:04.610 --> 24:08.970]  just because they aren't used very commonly. And we create that with a weak contextual certainty,
[24:08.970 --> 24:14.190]  because again, if you find one, chances are it's not great. Now you'll notice during each of these,
[24:14.190 --> 24:20.430]  I specify cursory when I initialize a sub-section. That comes from... when you run bluespawn,
[24:20.430 --> 24:25.030]  you specify how closely it should be looking for things. There's cursory, which is a very quick
[24:25.030 --> 24:29.990]  check. There's intensive, which is a very slow but careful check. And there's normal, which is
[24:29.990 --> 24:35.270]  somewhere in between. By specifying cursory here, we indicate that bluespawn should run these
[24:35.270 --> 24:39.770]  sub-sections whenever the intensity is greater or equal to the cursory.
[24:41.590 --> 24:45.870]  So when we originally had our first working version of bluespawn, it was just a few hunts
[24:45.870 --> 24:51.050]  we'd written and not too much else. Since then, everything we've done really has been taking what
[24:51.050 --> 24:55.710]  we had and proving it. When it came time to start monitoring systems in real time, rather than just
[24:55.710 --> 25:00.910]  performing a single scan, we realized we could reuse the hunts we had already written to do this.
[25:00.910 --> 25:06.390]  Each hunt we created already defines a number... sorry, each hunt we created defines a number of
[25:06.390 --> 25:11.210]  events that indicate something pertinent to the hunt has changed. For example, we might make an
[25:11.210 --> 25:16.570]  event watching a folder for new files or old files being edited. When the event gets triggered,
[25:16.570 --> 25:21.270]  hunts that care about that folder get rerun. Of course, there's some obvious inefficiencies in
[25:21.270 --> 25:26.670]  this, which is a big reason why we divided hunts into sub-sections. Now, when hunts create events,
[25:26.670 --> 25:32.170]  they specify which sub-section should get run for each event. Now, I'll admit monitoring is
[25:32.170 --> 25:36.330]  unfortunately one of the areas that hasn't received as much attention as others. It's
[25:36.330 --> 25:39.870]  certainly functional and it's effective at watching for things that hunts can catch,
[25:39.870 --> 25:45.570]  but so far we don't have that much that acts based off of behavior alone that we observe while
[25:45.570 --> 25:50.270]  monitoring. In the coming months, this is going to be one of our big focuses. Adding things like
[25:50.830 --> 25:56.310]  event tracing for Windows or API monitoring should position bluespawn to be able to catch much more.
[25:57.790 --> 26:04.550]  So, here's an example of how monitoring sets up its... or hunt sets up all of its monitoring
[26:04.550 --> 26:10.130]  triggers. So, if you noticed my example hunt two slides back, each of these sub-techniques gets a
[26:10.130 --> 26:17.510]  scope passed into it. Well, under the hood, what's happening is the sub-section macros I have
[26:17.510 --> 26:22.030]  actually check the scope against that sub-section ID to determine whether or not that sub-section
[26:22.030 --> 26:27.670]  should be run. So, whenever I create an event here, I specify which sub-sections are pertinent
[26:27.670 --> 26:38.070]  to it. And yeah, so here we have registry events, file and file events, but we also have event log
[26:38.070 --> 26:44.530]  events to watch for Windows events being created. So, the last component I'm going to talk about
[26:44.530 --> 26:49.210]  here is the reaction framework. As the name would imply, this is responsible for taking care of
[26:49.210 --> 26:54.830]  that BlueSpawn has determined are bad. Since BlueSpawn is designed around finding as much
[26:54.830 --> 27:01.070]  as possible and is bound to have some false positives, most things here require some sort
[27:01.070 --> 27:06.850]  of level of user confirmation before taking action. Now, obviously, when I delete a file,
[27:06.850 --> 27:11.070]  it's no longer an active threat, but there's still a reason for BlueSpawn to track it.
[27:11.070 --> 27:15.730]  To handle this error detection, each detection... sorry, to handle this error situation,
[27:15.730 --> 27:20.970]  each detection has a flag where we mark it as stale or not. Whenever detection... sorry,
[27:20.970 --> 27:25.850]  whenever reaction mitigates the detection, we mark it as stale, so that way other reactions don't go
[27:25.850 --> 27:31.350]  and try to mitigate it their way. Currently, we have five reactions available, but there is
[27:31.350 --> 27:37.770]  somewhat of a less defined six, and I'll get into that. BlueSpawn can delete files, quarantine files,
[27:37.770 --> 27:42.910]  delete registry entries, and that can be values or keys, suspend processes, or carve out memory.
[27:42.910 --> 27:47.530]  I'll talk about that in the next slide. The less defined reaction I just mentioned is for
[27:47.530 --> 27:52.450]  special cases. Remember back to the WinLogon hunt where it was comparing some values against known
[27:52.450 --> 27:57.250]  goods? It wouldn't be very good to just delete these values if they were malicious. They need
[27:57.250 --> 28:01.270]  to be properly restored. And to handle things like that, when a detection is created, it can
[28:01.270 --> 28:07.350]  be given a custom remediator. This remediator gets precedence over all other reactions if it's present.
[28:08.050 --> 28:12.530]  Now, as we continue to develop BlueSpawn, we of course intend to continue adding reactions and
[28:12.530 --> 28:16.750]  improving the ones we do have. Future reactions might include things like de-registering service
[28:16.750 --> 28:23.710]  or blocking certain commands. So I promised that I'd get into what I meant by memory carving, so
[28:23.710 --> 28:29.110]  here we are. The idea behind memory carving is that sometimes libraries or shellcode get shoved
[28:29.110 --> 28:34.950]  into processes, and these processes still serve a valid purpose and need to remain active. In cases
[28:34.950 --> 28:39.790]  like these where a restart isn't a good solution, we came up with a way to mitigate the effect of
[28:39.790 --> 28:44.770]  whatever malicious library or shellcode is living inside a process. It's not perfect, and it can
[28:44.770 --> 28:51.070]  cause problems, but it's better than nothing. This reaction works in five steps. First, we suspend
[28:51.070 --> 28:55.910]  the process so that nothing we're doing causes problems with the way the process works.
[28:56.430 --> 29:01.930]  First, what we do is we enumerate the threads in the process, searching for any thread whose stack
[29:01.930 --> 29:07.550]  overlaps the memory section in question. And that basically is an indicator that the thread is
[29:08.030 --> 29:13.250]  acting based off what that malicious memory section wants it to do. If or when we find this,
[29:13.250 --> 29:18.510]  we kill any thread that does that. Since malware generally doesn't like to share a thread
[29:18.510 --> 29:22.650]  with something benign, it shouldn't kill anything important to the process. Of course, if you got
[29:22.650 --> 29:27.730]  things like APC injection going on, there's not too much we can do about that right now.
[29:28.170 --> 29:33.370]  After that, we scan all memory pointers to the memory segment in question. If or when we find
[29:33.370 --> 29:37.770]  them, we check the address in question. If it's data, we patch it with zero, so it can't read
[29:37.770 --> 29:41.950]  anything important there. If it's code, we patch it with return instructions, so if it ever tries
[29:41.950 --> 29:48.330]  to call there or jump there, it gets immediately bounced right back. Then we go through and patch
[29:48.330 --> 29:53.170]  the entry point and all functions that are exported with return instructions, so anything trying to
[29:53.170 --> 29:58.370]  run any function inside the memory gets messed up. This can cause problems if we end up patching any
[29:58.370 --> 30:02.890]  function that requires the callee to clean up the stack, but without extensive work to figure out
[30:02.890 --> 30:06.890]  how much of the stack needs to be cleaned up, there's not too much we can do. Once we're done
[30:06.890 --> 30:11.330]  with all that, we resume the process and let things continue. We have tested this with a couple
[30:11.330 --> 30:15.510]  different pieces of malware, including CobaltStrike, Beacons, and Returpreter, and it seems to work
[30:15.510 --> 30:20.490]  without causing too many problems. Unless processes are storing function pointers in an abnormal
[30:20.490 --> 30:25.770]  manner, it should be very difficult to get anything in this memory segment working again after what we
[30:25.770 --> 30:31.330]  do occurs. Now, we are working on a few features to improve the stability of this. This includes
[30:31.330 --> 30:37.370]  things like forcibly walking threads back instead of just killing them, or finding out how much the
[30:37.370 --> 30:41.990]  stack needs to be cleaned up when patching returns, or properly unloading libraries as seen in Process
[30:41.990 --> 30:49.000]  Hacker rather than just breaking them. Now, BlueSpawn would have been nearly impossible to build
[30:49.000 --> 30:53.020]  from the ground up without any libraries or integration. As has been a major theme in our
[30:53.020 --> 30:58.960]  presentation, the MITRE ATT&CK framework has been invaluable in providing guidance around what sort
[30:58.960 --> 31:03.180]  of things we should go for. YARA and YARA rules written by the community have provided immense
[31:03.180 --> 31:07.380]  value in being able to scan files and make determinations. The stakes around which we built
[31:07.380 --> 31:11.620]  our mitigations make it very clear what we should prioritize and give us a framework to convey our
[31:11.620 --> 31:17.580]  coverage. Finally, PESib is a great open source tool we use to scan any process for any sort of
[31:17.580 --> 31:22.660]  fileless execution or any form of execution that's not properly mapped to a file.
[31:23.600 --> 31:29.120]  In summary, BlueSpawn's abilities can be broken into three categories, prevention, protection,
[31:29.120 --> 31:34.380]  and response. Under prevention, we have mitigate mode, which integrates STIGs and MITRE's ATT&CK
[31:34.380 --> 31:40.780]  framework. Under detection, we've got monitor mode, which watches for changes to rerun hunts,
[31:40.780 --> 31:46.720]  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:56.260]  Finally, under response, we have our reactions, which aim to mitigate or remove a threat,
[31:56.260 --> 31:58.120]  and then logging to report what was found.
[31:59.540 --> 32:05.120]  All right, so that was a lot, but we wanted to really give you a deep insight into kind of how
[32:05.120 --> 32:10.640]  some of these AV and EDR type programs, and obviously BlueSpawn in particular, work.
[32:10.860 --> 32:17.200]  And so now we're going to move into talking about just like seeing the tool in action, right? So
[32:17.200 --> 32:21.180]  we're going to walk through a case study with some kind of specific point in time screenshots
[32:21.180 --> 32:26.740]  of BlueSpawn catching malware, and then also we're going to have a video of kind of the tool
[32:26.740 --> 32:32.540]  in action. And I mentioned cyber defense competitions have been a really important
[32:33.180 --> 32:41.940]  learning tool at the beginning, so first I want to emphasize that again. The largest is by CCDC,
[32:42.260 --> 32:47.220]  and it's held in about 10 regions across the U.S. with qualifiers, regionals, and nationals,
[32:47.220 --> 32:54.140]  and about 230 universities compete each year actually. So that's one way if you're looking
[32:54.140 --> 33:00.120]  to volunteer to help in the community, highly recommend looking into a competition like that
[33:00.120 --> 33:06.200]  or others. So these competitions are basically what's known as an inherit and defend competition.
[33:06.200 --> 33:11.100]  The student teams work in a group of eight, and they're basically work as a fictional company. So
[33:11.100 --> 33:16.340]  like they have a whole set of networks they have to defend, and typically that's on-prem. There's
[33:16.340 --> 33:24.880]  cloud aspects, and that's usually done in like ESXi or AWS. So here you can see an example of a
[33:24.880 --> 33:31.660]  network map from actually last year. So you have some on-prem workstations, there's like a on-prem
[33:31.660 --> 33:37.040]  cloud if you will, and like ESXi, and then there's even like an AWS component. And you'll see
[33:37.040 --> 33:43.260]  the stuff in there ranges from Windows Server 2008, so like really old stuff, to Windows Server
[33:43.260 --> 33:49.240]  2019, and every flavor of Linux distro really. So that's they kind of emulate a modern
[33:49.740 --> 33:54.460]  corporate environment the best they can. And there's of course stuff like Exchange, and web apps, and
[33:54.460 --> 33:58.840]  databases, and all. And so basically there's two goals in these competitions. You have to keep your
[33:58.840 --> 34:04.620]  services online, and then just like you would in a real company, and then you have to stop the
[34:04.620 --> 34:11.020]  right team from really just totally destroying everything. And really frankly that ends up in
[34:11.020 --> 34:18.820]  situations like this. So on the left hand side you see this is from the national competition this
[34:18.820 --> 34:25.240]  year, and it's where a picture of the red team's Cobalt strike instance, where you can see they
[34:25.240 --> 34:31.340]  just have pwned dozens of machines against this poor team. And they also do things like defacing
[34:31.340 --> 34:39.260]  the websites, and RMRFing boxes, or overriding MBRs when they get too much access.
[34:39.260 --> 34:46.600]  But really what that means is that in all reality is that these are a great testing ground
[34:47.040 --> 34:51.520]  for defensive tools, right? So the red team spends all year writing malware for these competitions,
[34:52.000 --> 34:59.120]  and are probably watching right now. So hi red team! But so their tool set is everything from
[34:59.120 --> 35:05.280]  like Metasploit and Cobalt strike, what's pretty commonly used, to really custom malware that's
[35:05.280 --> 35:10.560]  just written for the purposes of CCDC. So with that kind of backstop in mind, we're going to look
[35:10.560 --> 35:18.240]  at some example screenshots of BlueSpawn. So here we just have the system. There's two Cobalt strike
[35:18.240 --> 35:24.880]  beacons running. One is just an HTTP beacon, and then the other is an SMB beacon living in
[35:24.880 --> 35:30.980]  explorer.exe. And so this is how BlueSpawn goes about finding it. It's looking at, when Jack
[35:30.980 --> 35:36.460]  talked about process injection earlier, and the carved memory reaction, you can see BlueSpawn's
[35:36.460 --> 35:43.500]  finding the malware in both explorer.exe, and then also in the PowerShell that's running.
[35:43.500 --> 35:48.620]  And then it starts prompting the user like, hey we found this malicious activity, and all they did,
[35:48.620 --> 35:53.920]  all the user did was just run BlueSpawn. And then it's offering to kill the threads, and once it
[35:53.920 --> 35:59.220]  kills it, then we reach a situation like this, where those beacons basically just stop calling
[35:59.220 --> 36:06.140]  back in. So that's an example of how BlueSpawn is responding to the threat. And here's another
[36:06.140 --> 36:14.000]  classic threat. It's not used obviously as much now, but the sticky keys backdoor is where the
[36:14.000 --> 36:19.800]  registry key is configured with command prompt as a debugger. So BlueSpawn's able to look for that,
[36:19.800 --> 36:26.380]  and that's T1546 sub technique 8, if you're following along on the MITRE ATT&CK matrix,
[36:26.380 --> 36:30.300]  so it knows to look for that, and then it goes and finds it, and it lets you remove
[36:30.300 --> 36:35.780]  that option. Next, this was probably one of the coolest examples we saw at a cyber defense
[36:35.780 --> 36:41.540]  competition that BlueSpawn caught earlier this year. Windows has these things called authentication
[36:41.540 --> 36:47.180]  packages and notification packages, and these exist in like the LSA subsystem, which is used
[36:47.180 --> 36:53.940]  for authentication and all. So BlueSpawn is able to map and is like, hey we found a registry key,
[36:53.940 --> 37:01.340]  it understands that in the hunt, that this hunt refers to things on disk. So then it goes and
[37:01.340 --> 37:06.180]  correlates that with the file associated with it. So we have two detections, one for the file
[37:06.180 --> 37:13.920]  and one for the registry key that contains the badness. Next, here is a good old run key.
[37:15.020 --> 37:19.640]  So there's a malicious BBS script that's configured to run in the registry,
[37:19.640 --> 37:25.520]  and again BlueSpawn is able to correlate the two and be able to connect that to generate detections
[37:26.300 --> 37:32.360]  and find both pieces of malware. Here's a web shell. This is a great, I like to use this for
[37:32.360 --> 37:38.700]  showing how the context works. So BlueSpawn uses a combination of regexes and YARA rules,
[37:38.700 --> 37:43.980]  and it's scanning all the stuff on the system in the web accessible directories,
[37:44.620 --> 37:51.120]  in say like IIS for PHP files, and it's able to say like, oh this was caught by this YARA rule,
[37:51.120 --> 37:59.640]  this piece of this file probably contains a web shell. And the next here is a pretty simple
[37:59.640 --> 38:04.960]  example with like backdooring services. So as hackers like to do this of course to get their
[38:04.960 --> 38:11.360]  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:17.280]  But BlueSpawn will scan all the services on the system to find which might contain a piece
[38:17.280 --> 38:24.200]  of malware or what service is suspicious. So we want to get some feedback on RedTeam of course
[38:24.800 --> 38:29.400]  when we made this tool, and this was actually probably one of the first years they've ever had
[38:29.400 --> 38:35.420]  to contend with an open source tool being built by one of the teams. No one's really done that
[38:35.420 --> 38:41.040]  before just because it's a lot of work, and if other teams are using it then maybe you're not
[38:41.040 --> 38:48.940]  getting quite as much value out of it. But I think it worked out really well, and as you'd expect
[38:48.940 --> 38:54.140]  our RedTeams spent a lot of time analyzing the tool since it's open source. So the attackers
[38:54.140 --> 39:00.800]  know exactly what it can detect on, which is it's a bit hard to when you think about it you're like
[39:00.800 --> 39:06.000]  oh I don't know if I want the RedTeam seeing it, but what we found is that the it really pushed
[39:06.000 --> 39:10.680]  the attackers to move to new techniques. So they couldn't just rely on the same things over and
[39:10.680 --> 39:14.680]  over again because they knew we were going to catch that. So it forces them to keep moving and
[39:14.680 --> 39:20.780]  shifting their tactics, which means they might be less detectable, but it also really increases
[39:21.400 --> 39:26.900]  the barrier to make it harder for them. And honestly one of the coolest parts is that the
[39:26.900 --> 39:33.040]  RedTeam unveiled something called RedSpawn this year. So that was a tool that was apparently
[39:33.040 --> 39:39.300]  supposed to like attack and defeat BlueSpawn. So that feels like a validation to us for sure that
[39:39.880 --> 39:44.760]  BlueSpawn is effectively killing stuff that they used to rely on.
[39:45.500 --> 39:51.480]  So from the BlueTeam perspective, what we found in our experiences and other teams and all is
[39:51.480 --> 39:58.120]  that BlueSpawn works kind of like an EDR product that you'd expect to. So you can identify, it'll
[39:58.120 --> 40:03.200]  identify and respond to malware on the system. One of the cool things we found is that it's
[40:03.200 --> 40:07.860]  like a force multiplier, especially in these active defense situations. So imagine if your
[40:07.860 --> 40:13.480]  tool is deployed out across the multiple systems, right, you don't have to manually look through
[40:13.480 --> 40:18.980]  all like the auto runs yourself. It'll just flag which ones are most likely to be suspicious.
[40:19.060 --> 40:22.200]  And that way you can spend more of your efforts hunting where it counts
[40:22.760 --> 40:28.860]  to find the malware. And so that's really important. So we've prepared a little demonstration
[40:28.860 --> 40:32.720]  of what BlueSpawn looks like in action and how it can be actually used to hunt and then destroy
[40:32.720 --> 40:41.880]  malware. So I prepared a Windows Server 2012 R2 VM here and I filled up with a bunch of different
[40:41.880 --> 40:47.380]  random pieces of malware and their systems. So you can see here that I've got two active
[40:47.380 --> 40:52.140]  meterpreter sessions on it and I'm going to use BlueSpawn to go hunt and destroy them, among other
[40:52.140 --> 40:58.080]  things. So first I'll show you BlueSpawn's help menu just so you can see all the options it has.
[40:58.080 --> 41:04.240]  And that's a pretty simple interface. Because I want to go find bad things, I'm going to run it in
[41:04.240 --> 41:09.740]  hunt mode. I'm going to specify a normal aggressiveness just because I don't need to go
[41:09.740 --> 41:15.160]  too in-depth to find anything. When I find stuff, I want to react by deleting files. So I use the
[41:15.160 --> 41:21.540]  delete file reaction. I'm going to remove values. So remove value reaction and card memory. And then
[41:21.540 --> 41:27.040]  I want to log to a file so I can view it later. And then the console so I can see it now.
[41:27.040 --> 41:31.660]  Just press enter and now it runs. That's pretty much all there is to getting it to run.
[41:33.200 --> 41:41.560]  So here it found a process injection into SPC host PID 632. And I'll open it up in a process hacker.
[41:43.620 --> 41:47.320]  So you can see here that it actually tells me the memory address where it found the
[41:47.320 --> 41:52.320]  injection. So I can actually go take a look at that in process hacker. And you'll see here that
[41:52.320 --> 41:59.240]  it's RWX memory section, which generally is not a great thing. So I'll go ahead and carve that out.
[41:59.400 --> 42:02.440]  And here I found a couple more. So I'll go ahead and carve those out too.
[42:03.800 --> 42:09.960]  And here it found some process injection into win-startup.exe. And so I'll go ahead and carve
[42:09.960 --> 42:20.980]  those out. And now here it found the sticky keys backdoor that Jake was talking about earlier,
[42:20.980 --> 42:26.080]  the image file execution options debugger. And so I'll open that up in autorun so you can see that
[42:26.080 --> 42:33.880]  it's also found by autoruns. And it's under the image hijacks tab. Sometimes everything doesn't
[42:33.880 --> 42:46.350]  show it. You can see it there and there. So we'll go ahead and remove that. And here it found the
[42:46.350 --> 42:52.310]  run key that was running the process we found some injection in earlier. The window startup
[42:52.310 --> 42:57.190]  actions, which definitely is not legitimate. So go ahead and remove that run key. Here it found
[42:57.190 --> 43:03.090]  NetSH helper DLL, which is a sneakier persistence technique. You can see it in regedit. And
[43:03.090 --> 43:08.870]  BlueSpawn actually protects the files during scans. So this actually won't be able to show
[43:08.870 --> 43:23.680]  the signatures on it. But I assure you it's not good. So we'll go ahead and remove that value
[43:23.680 --> 43:36.660]  there. And now it found the PHP web shell. We can go ahead and remove. And here is the malicious
[43:36.660 --> 43:42.200]  service. So go ahead and remove that. And for some reason autoruns can't find it. But I'll show
[43:42.200 --> 43:54.570]  you in this command prompt that it absolutely is there. So I'll go ahead and remove that with
[43:54.570 --> 44:02.110]  BlueSpawn. And now I'll go ahead and remove the NetSH helper DLL file. And here's the
[44:02.110 --> 44:08.430]  win startup.exe that it didn't like. And here's the malicious service. And that's it. That's all
[44:08.430 --> 44:17.050]  you have to do. And here's autorun showing you that stuff it found has been cleared out.
[44:19.250 --> 44:24.070]  So next slide. 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:34.370]  And now on to the future work. BlueSpawn still has a long way to go. A lot more features to
[44:34.370 --> 44:38.410]  be added. I'm going to talk here about some of the ideas and plans to come up with for future
[44:38.410 --> 44:44.430]  development on BlueSpawn. So most of our goals right now fall under three categories.
[44:44.530 --> 44:50.690]  Improving coverage, improving configurability, and improving integrity. So under coverage,
[44:50.690 --> 44:55.250]  we plan to continue adding new hunts and mitigations. Arguably our biggest goal here
[44:55.250 --> 45:00.550]  is to expand our data sources. So this would constitute things like API monitoring through
[45:00.690 --> 45:06.050]  a DLL load into all the processes or a kernel driver. Network traffic monitoring, user auditing,
[45:06.050 --> 45:11.210]  that sort of thing. 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:19.510]  One of our goals with BlueSpawn from the start has been to kind of bridge the gap between incident
[45:19.510 --> 45:24.670]  response and active defense, taking past incidents into account for current threat hunting.
[45:25.090 --> 45:29.270]  Currently, BlueSpawn has taken some smaller steps towards integration between the two,
[45:29.270 --> 45:34.150]  but we intend to work on building that out further and making it really a much bigger feature.
[45:34.890 --> 45:39.850]  As we develop BlueSpawn, we've built most of our features to be very configurable from an API
[45:39.850 --> 45:44.550]  perspective. But as of now, BlueSpawn doesn't really do a good job of exposing those APIs,
[45:44.550 --> 45:48.250]  and the command line interface we have barely taps into the surface of that.
[45:48.730 --> 45:52.930]  We'd really like to expose more of these configurations to allow things like much
[45:52.930 --> 45:58.290]  more targeted hunts, customizable scanning, and mitigation presets. We'd also like to add a way
[45:58.290 --> 46:02.090]  for signatures and definitions to be configurable, so that if users have their own signature-based
[46:02.090 --> 46:08.150]  integrate, they'd be able to. As for integrity, right now, BlueSpawn has very little defenses
[46:08.150 --> 46:13.350]  against malware or malicious users actually tampering with it. To that end, we intend to
[46:13.350 --> 46:18.210]  work on hardening BlueSpawn itself, making it much more difficult for a malicious process from
[46:18.730 --> 46:23.350]  modifying it or causing problems with its execution. And this would most likely be
[46:23.350 --> 46:28.470]  through a kernel driver. BlueSpawn also assumes it has all the rights that an admin normally has.
[46:28.470 --> 46:32.590]  But if malware is trying to protect itself, it might restrict access to certain resources that
[46:32.590 --> 46:36.890]  BlueSpawn was assuming it'd just get with no problem. This also would likely be addressed
[46:36.890 --> 46:41.810]  to the same kernel driver. Finally, and this is more of a development feature, we intend to set
[46:41.810 --> 46:47.050]  up detailed Atomic Red Team tests, which are basically tests that test against one specific
[46:47.630 --> 46:51.750]  malware technique to ensure that each build has proper coverage for everything it should.
[46:53.530 --> 46:56.570]  Now, everything I've presented so far has been focused on our
[46:56.570 --> 47:01.910]  Windows client, but our plans go a lot beyond that. Just this past week, actually, we finished
[47:01.910 --> 47:06.790]  porting a version of BlueSpawn over to Linux, where we are now able to write hunts of mitigations.
[47:07.010 --> 47:12.550]  The Linux client is a decent bit behind the Windows one in terms of capability and coverage,
[47:12.550 --> 47:17.490]  but we plan to have an initial release at some point soon. We've also begun developing a server
[47:17.490 --> 47:21.890]  used to deploy BlueSpawn across the network and then aggregate the logs and manage the client
[47:21.890 --> 47:26.110]  at scale. This server is still in its early stages, but we plan to ramp up development in
[47:26.110 --> 47:31.050]  the next few months. Finally, the last major component to BlueSpawn is the cloud. Now,
[47:31.050 --> 47:34.930]  this is a long way off, and I'll admit we haven't even started thinking about developing it yet.
[47:34.930 --> 47:39.530]  But the idea is that the clients or servers could send off malware to the cloud to perform
[47:40.110 --> 47:45.630]  better, more detailed scans, likely doing some form of sandboxing or heuristic analysis. This
[47:45.630 --> 47:51.310]  could also serve as a threat intelligence repository, sending out IOCs to clients and servers.
[47:52.790 --> 47:57.350]  So, we've talked a lot. Hopefully, we've given you a really good overview of kind of
[47:57.350 --> 48:02.270]  at a high level, like why we built BlueSpawn, a bit really into the weeds of how it works,
[48:02.270 --> 48:06.810]  and how these types of solutions really work in the real world, and then kind of showing you
[48:06.810 --> 48:12.170]  what it's like in action, right? So, we're going to conclude. First, remember that BlueSpawn is
[48:12.170 --> 48:18.130]  very much still in the alpha stage. So, it can detect a lot of the most popular techniques,
[48:18.130 --> 48:21.630]  but there's certainly some things that it's going to miss, and it's a bit rough around some
[48:21.630 --> 48:27.490]  of the edges. Since all the code and detections are open source, though, we highly recommend
[48:27.990 --> 48:32.890]  you taking it out, just going to the GitHub page, and you can kind of find and look through,
[48:32.890 --> 48:36.950]  see exactly how it works. And because it's really important to us to shed light on kind
[48:36.950 --> 48:42.370]  of how these black box EDR solutions that you might have deployed out in your network might
[48:42.370 --> 48:48.970]  actually work. And we also want to extend a huge thank you, again, to the community projects that
[48:48.970 --> 48:53.730]  are listed here. Really, building something like this is not possible without these frameworks
[48:54.310 --> 49:01.350]  and libraries, so definitely check those two out as well. So, most importantly, if you've
[49:01.350 --> 49:06.170]  gained anything from this talk, we'd like you to walk away with these three things.
[49:06.670 --> 49:12.130]  First, using MITRE ATT&CK to be able to detect threats and think about your defenses
[49:12.710 --> 49:17.390]  is a great springboard. And really, think about it as a springboard. So, like we found when we were
[49:17.390 --> 49:23.390]  developing BlueSpawn, that MITRE ATT&CK might not have the most in-depth information on a particular
[49:23.390 --> 49:28.770]  technique, right? But you can use that and go as a rabbit hole. So, if you know attackers are going
[49:28.770 --> 49:34.130]  to abuse it, you can go look into that technique more to figure out how attackers might use it.
[49:34.130 --> 49:41.510]  So, that's a good, really good place to start. Second, knowing your coverage. So, we've used this
[49:42.030 --> 49:47.230]  more times than I can count, right, in our cyber defense competitions and all. And it translates
[49:47.230 --> 49:50.830]  really good to the real world, right? So, if you start thinking about, like, if you're X-ing
[49:50.830 --> 49:55.570]  techniques off of the attack matrix, right, you can actually get pretty far because if you think
[49:55.570 --> 50:01.430]  about it, the attacker isn't going to be able to use those techniques as well against you once
[50:01.430 --> 50:08.370]  you've got a little X over them. So, that's a great way to think about defense. And then finally,
[50:09.770 --> 50:13.310]  really, BlueSpawn is kind of like a massive experiment just to figure out
[50:13.310 --> 50:19.430]  and understand how modern-day defensive software works. So, just like you might tear apart, like,
[50:19.430 --> 50:24.270]  exploits and malware, we recommend doing the same thing for your defensive security solutions,
[50:24.270 --> 50:28.670]  right? And thinking about, learning about how they work, and then you can use that
[50:28.670 --> 50:35.390]  to kind of build and improve your own defenses. So, just a few housekeeping items, I guess, before
[50:35.390 --> 50:42.570]  we wrap up. Thank you all for listening today. We hope you've had as much fun as we have in creating
[50:42.570 --> 50:48.810]  this and talking this afternoon. We also would like to thank the conference volunteers, right?
[50:48.810 --> 50:53.550]  This would not have been possible without all their hard work and setting up the streaming
[50:54.050 --> 51:00.570]  and just making it all flow. Finally, we've linked the slides on the README. We'll have the
[51:00.570 --> 51:05.430]  DEF CON release, if you will, go live here in a bit after this talk ends. So, you can download
[51:05.430 --> 51:11.850]  the tool as we've been talking about it and kind of see a bit more what it's like. You can look at
[51:11.850 --> 51:17.330]  the slides. We also have a Discord for the project. So, if you have any questions and I think
[51:17.330 --> 51:22.470]  they're going to post a link to the Discord and all, hop in there and you can go chat with us
[51:22.470 --> 51:28.150]  afterwards and we'll let you know. We'll be happy to answer any questions you might have. So,
[51:28.150 --> 51:32.130]  thanks again, guys, for listening. We hope you really enjoyed it. Thank you.
[51:32.850 --> 51:37.430]  Well, thanks, Jake and Jack. That was a great talk. I look forward to see what
[51:37.430 --> 51:43.930]  BlueSpawn continues to develop into and appreciate you coming out to DEF CON and presenting to us.
[51:43.930 --> 51:48.090]  As a reminder, as they've got up here on the slide, the Discord channel takes you over to
[51:48.090 --> 51:54.770]  their server. It is also up in the General, under the General tab of our Discord channel,
[51:54.770 --> 51:59.950]  as well as a link in the actual Texthalk channel as well. Other than that, have a great day, guys.