1
00:00:09,610 --> 00:00:14,170
And welcome back, everybody, to DEF CON 28 Safe Mode, Blue Team Village.

2
00:00:14,530 --> 00:00:17,530
We're going to start our next set of speakers.

3
00:00:17,550 --> 00:00:19,710
We've got a great topic coming up today.

4
00:00:19,990 --> 00:00:26,070
The title of this talk is Building BlueSpawn, an open-source active defense and EDR software.

5
00:00:26,310 --> 00:00:28,690
Jake Smith and Jack McDowell will be presenting.

6
00:00:28,930 --> 00: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.

7
00:00:40,090 --> 00:00:42,370
I'll have that in there in one second.

8
00:00:42,630 --> 00:00:46,110
And on that note, over to you, Jake and Jack.

9
00:00:46,430 --> 00:00:47,290
All right.

10
00:00:47,290 --> 00:00:48,290
Thank you.

11
00:00:48,510 --> 00:00:50,090
So how's everyone doing today?

12
00:00:50,110 --> 00:00:53,770
Just a few quick notes before we get into the presentation.

13
00:00:53,850 --> 00: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.

14
00:01:00,430 --> 00: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.

15
00:01:07,570 --> 00:01:09,290
So a huge thank you to them.

16
00:01:09,790 --> 00: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.

17
00:01:16,890 --> 00: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.

18
00:01:24,430 --> 00:01:27,090
But first, a little bit of background about the two of us.

19
00:01:27,090 --> 00:01:29,550
We went to the University of Virginia.

20
00:01:29,630 --> 00: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.

21
00:01:40,430 --> 00:01:49,130
And these competitions we'll talk about more are some of the reasons why we created BlueSpawn and all.

22
00:01:49,450 --> 00:01:53,310
So an important caveat, too, before we get into the presentation.

23
00:01:53,310 --> 00:01:58,430
When we say we this afternoon, we're referring to all six of us on the slide.

24
00:01:58,430 --> 00: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.

25
00:02:09,310 --> 00:02:14,550
So it's really a team effort that we've been doing to create this.

26
00:02:15,810 --> 00: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.

27
00:02:28,770 --> 00: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.

28
00:02:38,110 --> 00:02:43,450
So first, we'll start with your Endpoint Detection and Response, or EDR, tools.

29
00:02:43,510 --> 00:02:49,050
That's your CrowdStrikes, your Carbon Black, your Defender ATP, Sentinel-1, and all.

30
00:02:49,610 --> 00:02:55,030
They obviously used to, like 10, 15 years ago, AVs were pretty simple.

31
00:02:55,030 --> 00: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.

32
00:03:02,170 --> 00: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.

33
00:03:12,690 --> 00: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.

34
00:03:22,910 --> 00: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.

35
00:03:39,130 --> 00:03:45,490
There's not a whole lot of great ones, but definitely Sysinternals is probably one of the best.

36
00:03:45,490 --> 00: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.

37
00:03:56,850 --> 00:04:00,930
Just, they do a great job of finding malware on the system.

38
00:04:01,030 --> 00: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.

39
00:04:07,670 --> 00: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.

40
00:04:20,610 --> 00:04:22,210
Next is Process Hacker.

41
00:04:22,210 --> 00:04:24,670
Process Hacker is another really great tool.

42
00:04:24,690 --> 00:04:30,610
There's not much automation or security focus, but it's really good at just analyzing.

43
00:04:30,610 --> 00:04:37,530
It's like Task Manager on steroids, really, and you can even look at like a specific region in memory.

44
00:04:37,850 --> 00: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.

45
00:04:47,910 --> 00: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.

46
00:04:56,110 --> 00:04:57,870
The idea is pretty simple behind the tool.

47
00:04:57,870 --> 00: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.

48
00:05:08,210 --> 00:05:13,230
The only downside, if it's really a downside, is that it's limited to scanning processes.

49
00:05:13,230 --> 00:05:19,030
So it's not going to find like other malware, say, like that's hiding in the registry on a system.

50
00:05:20,250 --> 00: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.

51
00:05:30,090 --> 00: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.

52
00:05:36,830 --> 00: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.

53
00:05:46,570 --> 00: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.

54
00:05:57,510 --> 00:06:02,910
So that's one thing to be aware of, like they'll set conflicting values or miss critical settings and whatnot.

55
00:06:03,870 --> 00: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.

56
00:06:12,870 --> 00: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.

57
00:06:20,270 --> 00:06:24,950
You're probably not going to go into work Monday and deploy BlueSpawn in production.

58
00:06:25,110 --> 00: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.

59
00:06:31,990 --> 00: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.

60
00:06:44,070 --> 00:06:49,550
So with all things, all great ideas, I guess, start in Slack and whatnot.

61
00:06:49,550 --> 00: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.

62
00:07:07,610 --> 00:07:09,450
And we didn't find a whole lot out there.

63
00:07:09,630 --> 00:07:15,590
So that kind of led us to creating BlueSpawn.

64
00:07:15,770 --> 00: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.

65
00:07:23,930 --> 00:07:28,990
Honestly, frankly, I tell some people that I just do go to school for competitions and all.

66
00:07:30,010 --> 00: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.

67
00:07:42,550 --> 00:07:45,390
So you can imagine how that kind of thing goes.

68
00:07:45,490 --> 00:07:48,030
And the red team pretty much always wins.

69
00:07:48,030 --> 00: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.

70
00:07:52,830 --> 00:07:54,750
So we have to rely on open source tools.

71
00:07:54,750 --> 00:07:59,450
That's kind of another reason why we focus so heavily on the open source aspect.

72
00:08:00,010 --> 00: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.

73
00:08:08,690 --> 00: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.

74
00:08:21,170 --> 00:08:26,990
And so that is where the idea of active defense comes in.

75
00:08:27,570 --> 00:08:29,670
And then the next is coverage.

76
00:08:29,670 --> 00:08:33,070
So when doing these cyber defense competitions, it's time limited.

77
00:08:33,070 --> 00:08:35,290
You're stressed and whatnot.

78
00:08:35,290 --> 00:08:39,350
So you don't have the luxury of, say, being able to look at everything very closely.

79
00:08:39,350 --> 00:08:45,850
And you can't pull up a process explorer and look at every individual process to hunt for process injection.

80
00:08:46,350 --> 00: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.

81
00:09:01,170 --> 00:09:02,830
And finally, open source software.

82
00:09:02,830 --> 00:09:04,670
So this is a call to everyone out there.

83
00:09:05,190 --> 00: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.

84
00:09:11,550 --> 00:09:16,350
So definitely building more open source blue team software, I think, is really important.

85
00:09:16,350 --> 00: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.

86
00:09:27,670 --> 00: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.

87
00:09:42,830 --> 00:09:46,570
So that's where it's doing continuously monitoring.

88
00:09:46,710 --> 00: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?

89
00:09:54,590 --> 00:10:00,470
This is kind of the ideas that we're heading towards as we spend more and more time developing this.

90
00:10:00,470 --> 00:10:02,050
And then also proactive defense.

91
00:10:02,050 --> 00:10:08,630
So it's not enough that you can detect malware and respond to it, right?

92
00:10:08,630 --> 00: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.

93
00:10:16,910 --> 00:10:21,630
So we've talked a lot about active defense so far, but what do we really mean by it?

94
00:10:21,630 --> 00:10:26,750
And how does BlueSpawn approach the idea of finding anomalous or malicious behavior?

95
00:10:26,910 --> 00:10:29,090
And that's kind of what I'll get into in this section.

96
00:10:29,870 --> 00: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.

97
00:10:38,550 --> 00:10:40,730
For their use cases, this is a very good thing.

98
00:10:40,730 --> 00:10:44,710
People don't want alerts about everything that may or may not be malicious.

99
00:10:45,090 --> 00:10:50,250
But when you've been compromised, or even when you think you've been compromised, that might not be enough.

100
00:10:50,250 --> 00:10:53,790
This is where our concept of active defense comes into play.

101
00:10:53,810 --> 00:10:59,750
Rather than sit in the background, only rarely making noise, BlueSpawn is meant to be a tool that's actively used.

102
00:10:59,750 --> 00:11:06,370
The goal is to find absolutely everything that could be malicious, not just the things it knows for sure are malicious.

103
00:11:06,630 --> 00:11:08,790
In such an approach, there are drawbacks.

104
00:11:08,790 --> 00:11:12,790
In catching all the things, we're sure to catch some things that aren't actually bad.

105
00:11:12,790 --> 00:11:16,770
But for an active defense situation, that's a trade -off we want to make.

106
00:11:17,210 --> 00:11:19,830
So how does BlueSpawn go about approaching this?

107
00:11:20,090 --> 00: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.

108
00:11:28,830 --> 00:11:36,770
And this hunting involved the typical registry scans, file scans, or process scans that an AV or EDR product would use.

109
00:11:36,770 --> 00: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.

110
00:11:45,590 --> 00:11:51,350
And I think what makes BlueSpawn different is we also factor event logs into our hunts.

111
00:11:51,350 --> 00: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.

112
00:11:59,590 --> 00:12:05,830
And we're trying to basically use that to bridge the gap between incident response and what EDR products do.

113
00:12:05,830 --> 00:12:11,950
And as we move towards continuous monitoring, we extended these hunts to be able to run as needed.

114
00:12:11,950 --> 00:12:14,890
And I'll talk more about how we did that shortly.

115
00:12:16,310 --> 00:12:22,790
So as I mentioned on the previous slide, BlueSpawn is built pretty heavily around the idea of what we call hunts.

116
00:12:22,790 --> 00: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.

117
00:12:36,350 --> 00: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.

118
00:12:45,050 --> 00:12:49,470
Monitoring, as I mentioned a while back, is really just an extension of the hunts we've already written.

119
00:12:49,490 --> 00:12:55,970
Each hunt creates triggers for when it should be rerun, and when those triggers occur, it gets run again.

120
00:12:56,350 --> 00:13:02,850
Now, MITRE recently released sub-techniques, which break down each technique attackers may use into subcategories.

121
00:13:02,850 --> 00: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.

122
00:13:10,530 --> 00:13:15,210
So these hunts are really great for finding the starting points in malicious behavior.

123
00:13:15,210 --> 00: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.

124
00:13:21,690 --> 00: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.

125
00:13:29,690 --> 00: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.

126
00:13:38,690 --> 00:13:40,830
And those files, well, you get the idea.

127
00:13:41,430 --> 00: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.

128
00:13:47,950 --> 00:13:51,850
The result from this is a network of evidence of malicious activity.

129
00:13:51,910 --> 00:13:55,750
In the next section, I'll go into a bit more detail about how this actually gets built.

130
00:13:56,950 --> 00: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.

131
00:14:05,070 --> 00: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.

132
00:14:12,590 --> 00:14:16,530
So before I get into any of the features, I want to preface with a disclaimer.

133
00:14:16,550 --> 00:14:18,450
BlueSpawn is still in alpha development.

134
00:14:18,470 --> 00: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.

135
00:14:24,710 --> 00:14:29,010
Everything I'm presenting is currently implemented, but it's not entirely without its bugs.

136
00:14:29,130 --> 00:14:33,210
And the biggest example of what I'm talking about is our scanning subsystem.

137
00:14:33,210 --> 00: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.

138
00:14:41,130 --> 00: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.

139
00:14:48,750 --> 00:14:51,290
And none of this is to say BlueSpawn isn't effective.

140
00:14:51,290 --> 00: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.

141
00:15:00,290 --> 00:15:03,050
And now that's out of the way, onto the features.

142
00:15:03,150 --> 00:15:07,930
BlueSpawn has five major components, each of which we'll discuss in detail in this section.

143
00:15:07,930 --> 00: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.

144
00:15:27,050 --> 00: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.

145
00:15:37,550 --> 00: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.

146
00:15:46,910 --> 00: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.

147
00:15:59,350 --> 00: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.

148
00:16:06,610 --> 00: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.

149
00:16:14,570 --> 00:16:20,670
We also see it mitigating services and software installed on a system, rather than just the base operating system.

150
00:16:20,790 --> 00:16:29,370
And finally, our biggest envisioned change is for Mitigation mode to serve as really an aid in performing a system audit.

151
00:16:29,370 --> 00: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.

152
00:16:41,230 --> 00: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.

153
00:16:50,150 --> 00:16:54,190
So I'm going to be using the word detection a lot, and it's just that, detection.

154
00:16:54,370 --> 00: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.

155
00:17:00,710 --> 00:17:04,110
It could be like a file, a registry key, a process, or something else entirely.

156
00:17:05,030 --> 00:17:08,810
Next, there's an association, which is also just what it sounds like.

157
00:17:08,810 --> 00: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.

158
00:17:19,010 --> 00:17:25,530
Next thing is certainty, and this is the metric we use for determining the likelihood that a detection is actually bad.

159
00:17:25,610 --> 00:17:27,370
There are three components to it.

160
00:17:27,370 --> 00:17:31,130
The two of them get combined, so in practice, there are really only two.

161
00:17:31,190 --> 00:17:33,570
The first is what I call intrinsic certainty.

162
00:17:33,570 --> 00:17:36,530
This is the certainty that comes from the detection itself.

163
00:17:36,530 --> 00: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.

164
00:17:45,380 --> 00:17:47,830
The next is contextual certainty.

165
00:17:47,830 --> 00:17:51,210
This comes from the context surrounding the detection.

166
00:17:51,210 --> 00: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.

167
00:17:58,030 --> 00:17:59,290
They're really combined.

168
00:17:59,370 --> 00: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.

169
00:18:09,570 --> 00: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.

170
00:18:17,470 --> 00: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.

171
00:18:24,930 --> 00:18:28,170
Say we've got a file and we found it loaded into a process.

172
00:18:28,290 --> 00: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.

173
00:18:39,810 --> 00:18:44,750
Now that I've got those definitions out of the way, I can move on to how BlueSpawn actually works.

174
00:18:45,010 --> 00:18:50,510
The core of all detection management, and really the core of BlueSpawn itself, is our detection register.

175
00:18:50,510 --> 00:18:52,910
This tracks everything that BlueSpawn's found.

176
00:18:52,930 --> 00:18:59,610
Whenever a hunt or a scan or whatever finds anything that might be bad, it sends it to the detection register.

177
00:18:59,650 --> 00:19:03,890
The register will record the detection and send back a reference to it.

178
00:19:03,890 --> 00: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.

179
00:19:12,750 --> 00:19:15,730
The detection register has three storage mechanisms.

180
00:19:16,890 --> 00: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.

181
00:19:24,810 --> 00:19:28,050
That way we can just make sure we're not redoing the same work.

182
00:19:28,050 --> 00:19:31,730
We also keep a record of all detections regardless of whether or not they've been scanned.

183
00:19:32,590 --> 00:19:35,190
So now for how registration actually works.

184
00:19:35,390 --> 00: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.

185
00:19:43,150 --> 00:19:45,370
If it does, they get merged together.

186
00:19:45,370 --> 00:19:52,410
And generally the only thing that changes when this happens is their contextual certainties and their contexts get merged.

187
00:19:52,410 --> 00:19:59,450
If this merge causes their overall certainty to exceed a certain threshold, it then gets logged and its reactions get triggered.

188
00:19:59,450 --> 00: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.

189
00:20:05,770 --> 00:20:09,650
That way it's just keeping track of the detection that we care about.

190
00:20:09,650 --> 00:20:11,450
Otherwise it's to the new detection.

191
00:20:11,550 --> 00:20:18,030
After all this is handled, if the detection register needs to queue scans for the detection, it will.

192
00:20:18,030 --> 00: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.

193
00:20:27,310 --> 00:20:32,890
The associated detections then get registered and the scans for those get queued and so on.

194
00:20:34,110 --> 00:20:38,870
So here I've got a diagram for how the detection register lays things out.

195
00:20:38,870 --> 00: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.

196
00:20:44,450 --> 00:20:47,730
So the register itself has three main storage mechanisms.

197
00:20:47,730 --> 00:20:53,630
There's the queue of things that haven't been scanned yet, things that have been scanned, and then everything overall.

198
00:20:53,690 --> 00:21:00,630
And you can see that all these storage mechanisms really just store references to detections that are stored elsewhere.

199
00:21:01,010 --> 00:21:08,230
I've also broken down one detection, in this case ID2, to show what kind of information detection actually holds.

200
00:21:08,270 --> 00:21:12,970
So it first has its ID, which is just an ID, a unique identifier to refer to it.

201
00:21:12,970 --> 00: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.

202
00:21:20,110 --> 00: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.

203
00:21:27,830 --> 00:21:33,650
There's also the data, and this stores information about what actually did it find.

204
00:21:33,690 --> 00: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.

205
00:21:41,150 --> 00:21:46,130
Its name persists and it's pointing to this file called bad.exe.

206
00:21:46,630 --> 00:21:51,370
The next thing I have is the scan information, which stores information about how it was scanned.

207
00:21:51,370 --> 00:21:57,910
That has the certainty, which combines the intrinsic and the contextual certainties, and then the associative certainty.

208
00:21:58,210 --> 00:22:05,530
The last part of this is the associations, which identifies which detections are associated with this one.

209
00:22:05,530 --> 00:22:11,730
In this case, detection ID1, which I'm using to refer to as bad.exe, is associated with it.

210
00:22:12,770 --> 00:22:15,770
There's also a remediator, and I'll get to that a bit later.

211
00:22:16,590 --> 00: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.

212
00:22:22,950 --> 00:22:26,170
Each one covers one minor attack technique.

213
00:22:26,330 --> 00:22:31,570
Each hunt, we then break down into sub-techniques, which can be run independently of each other.

214
00:22:31,650 --> 00: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.

215
00:22:44,930 --> 00:22:48,130
The idea is to keep it as simple and small as possible.

216
00:22:48,350 --> 00: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.

217
00:22:57,650 --> 00:23:02,170
Most of the things we check get a quick scan, which just performs the most elementary scans.

218
00:23:02,170 --> 00:23:06,710
It's a very quick test to determine whether or not something deserves more detailed scans.

219
00:23:06,810 --> 00: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.

220
00:23:13,950 --> 00:23:18,950
Then the scans I discussed get run on it and make a determination, find other related things, and so on.

221
00:23:20,690 --> 00:23:23,010
Here's an example of what a hunt looks like.

222
00:23:23,170 --> 00:23:25,930
In this case, this is a T1547.

223
00:23:25,930 --> 00:23:29,990
The hunt itself really just runs all sub-techniques underneath it, you can see here.

224
00:23:32,250 --> 00:23:37,050
And then here's the sub-technique number four, which I picked out because it was pretty simple.

225
00:23:37,770 --> 00:23:45,890
The first part of it just compares the winlogon values for the shell and username against known goods.

226
00:23:45,890 --> 00: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.

227
00:23:56,830 --> 00:24:01,590
The next sub-section refers to the winlogon notify values.

228
00:24:01,590 --> 00:24:06,850
Any of these that we find get a detection created for it, just because they aren't used very commonly.

229
00:24:06,890 --> 00:24:12,590
And we create that with a weak contextual certainty, because again, if you find one, chances are it's not great.

230
00:24:12,590 --> 00:24:17,470
Now you'll notice during each of these, I specify cursory when I initialize a sub-section.

231
00:24:17,510 --> 00:24:23,410
That comes from... when you run bluespawn, you specify how closely it should be looking for things.

232
00:24:23,410 --> 00:24:25,710
There's cursory, which is a very quick check.

233
00:24:25,710 --> 00:24:28,870
There's intensive, which is a very slow but careful check.

234
00:24:28,870 --> 00:24:31,370
And there's normal, which is somewhere in between.

235
00:24:31,450 --> 00: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.

236
00:24:41,590 --> 00: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.

237
00:24:48,490 --> 00:24:52,590
Since then, everything we've done really has been taking what we had and proving it.

238
00:24:52,590 --> 00: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.

239
00:25:00,910 --> 00: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.

240
00:25:09,810 --> 00:25:14,630
For example, we might make an event watching a folder for new files or old files being edited.

241
00:25:14,730 --> 00:25:19,230
When the event gets triggered, hunts that care about that folder get rerun.

242
00:25:19,230 --> 00:25:24,690
Of course, there's some obvious inefficiencies in this, which is a big reason why we divided hunts into sub-sections.

243
00:25:24,930 --> 00:25:30,210
Now, when hunts create events, they specify which sub-section should get run for each event.

244
00:25:30,830 --> 00:25:36,050
Now, I'll admit monitoring is unfortunately one of the areas that hasn't received as much attention as others.

245
00:25:36,050 --> 00: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.

246
00:25:46,510 --> 00:25:49,310
In the coming months, this is going to be one of our big focuses.

247
00:25:49,430 --> 00:25:56,310
Adding things like event tracing for Windows or API monitoring should position bluespawn to be able to catch much more.

248
00:25:57,790 --> 00:26:05,550
So, here's an example of how monitoring sets up its... or hunt sets up all of its monitoring triggers.

249
00:26:05,610 --> 00:26:11,350
So, if you noticed my example hunt two slides back, each of these sub-techniques gets a scope passed into it.

250
00:26:11,350 --> 00: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.

251
00:26:23,350 --> 00:26:28,530
So, whenever I create an event here, I specify which sub-sections are pertinent to it.

252
00:26:29,310 --> 00: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.

253
00:26:41,970 --> 00:26:46,450
So, the last component I'm going to talk about here is the reaction framework.

254
00:26:46,450 --> 00:26:52,030
As the name would imply, this is responsible for taking care of that BlueSpawn has determined are bad.

255
00:26:52,150 --> 00: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.

256
00:27:04,150 --> 00: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.

257
00:27:11,070 --> 00: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.

258
00:27:19,590 --> 00: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.

259
00:27:28,410 --> 00:27:34,290
Currently, we have five reactions available, but there is somewhat of a less defined six, and I'll get into that.

260
00:27:34,690 --> 00: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.

261
00:27:42,910 --> 00:27:44,850
I'll talk about that in the next slide.

262
00:27:45,290 --> 00:27:48,670
The less defined reaction I just mentioned is for special cases.

263
00:27:48,710 --> 00:27:53,270
Remember back to the WinLogon hunt where it was comparing some values against known goods?

264
00:27:53,310 --> 00:27:56,970
It wouldn't be very good to just delete these values if they were malicious.

265
00:27:56,970 --> 00:27:58,730
They need to be properly restored.

266
00:27:58,790 --> 00:28:02,970
And to handle things like that, when a detection is created, it can be given a custom remediator.

267
00:28:03,010 --> 00:28:07,350
This remediator gets precedence over all other reactions if it's present.

268
00:28:08,050 --> 00: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.

269
00:28:14,110 --> 00:28:18,650
Future reactions might include things like de-registering service or blocking certain commands.

270
00:28:20,410 --> 00:28:24,750
So I promised that I'd get into what I meant by memory carving, so here we are.

271
00:28:24,910 --> 00: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.

272
00:28:34,490 --> 00: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.

273
00:28:43,170 --> 00:28:46,890
It's not perfect, and it can cause problems, but it's better than nothing.

274
00:28:47,690 --> 00:28:50,330
This reaction works in five steps.

275
00:28:50,330 --> 00:28:55,910
First, we suspend the process so that nothing we're doing causes problems with the way the process works.

276
00:28:56,430 --> 00: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.

277
00:29:04,930 --> 00: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.

278
00:29:11,930 --> 00:29:14,810
If or when we find this, we kill any thread that does that.

279
00:29:14,890 --> 00: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.

280
00:29:21,970 --> 00: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.

281
00:29:28,170 --> 00:29:32,410
After that, we scan all memory pointers to the memory segment in question.

282
00:29:32,410 --> 00:29:35,650
If or when we find them, we check the address in question.

283
00:29:35,650 --> 00:29:38,810
If it's data, we patch it with zero, so it can't read anything important there.

284
00:29:38,810 --> 00: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.

285
00:29:46,610 --> 00: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.

286
00:29:56,430 --> 00: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.

287
00:30:06,250 --> 00:30:09,710
Once we're done with all that, we resume the process and let things continue.

288
00:30:09,930 --> 00: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.

289
00:30:17,350 --> 00: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.

290
00:30:27,410 --> 00:30:30,890
Now, we are working on a few features to improve the stability of this.

291
00:30:30,890 --> 00: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.

292
00:30:46,360 --> 00:30:51,540
Now, BlueSpawn would have been nearly impossible to build from the ground up without any libraries or integration.

293
00:30:51,680 --> 00: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.

294
00:31:00,460 --> 00:31:05,940
YARA and YARA rules written by the community have provided immense value in being able to scan files and make determinations.

295
00:31:06,260 --> 00: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.

296
00:31:12,900 --> 00: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.

297
00:31:23,600 --> 00:31:30,240
In summary, BlueSpawn's abilities can be broken into three categories, prevention, protection, and response.

298
00:31:30,240 --> 00:31:35,380
Under prevention, we have mitigate mode, which integrates STIGs and MITRE's ATT&CK framework.

299
00:31:35,380 --> 00: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.

300
00:31:47,100 --> 00:31:51,800
Scan mode then analyzes what was found in hunt mode to find associations and make determinations.

301
00:31:51,800 --> 00: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.

302
00:31:59,540 --> 00: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.

303
00:32:10,860 --> 00:32:16,880
And so now we're going to move into talking about just like seeing the tool in action, right?

304
00:32:16,880 --> 00: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.

305
00:32:28,260 --> 00: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.

306
00:32:40,140 --> 00:32:44,960
The largest is by CCDC, and it's held in about 10 regions across the U.S.

307
00:32:44,960 --> 00:32:52,080
with qualifiers, regionals, and nationals, and about 230 universities compete each year actually.

308
00:32:52,120 --> 00: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.

309
00:33:01,720 --> 00:33:06,200
So these competitions are basically what's known as an inherit and defend competition.

310
00:33:06,200 --> 00:33:11,000
The student teams work in a group of eight, and they're basically work as a fictional company.

311
00:33:11,000 --> 00:33:15,780
So like they have a whole set of networks they have to defend, and typically that's on-prem.

312
00:33:15,780 --> 00:33:21,380
There's cloud aspects, and that's usually done in like ESXi or AWS.

313
00:33:21,780 --> 00:33:26,660
So here you can see an example of a network map from actually last year.

314
00:33:26,660 --> 00: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.

315
00:33:35,980 --> 00: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.

316
00:33:47,340 --> 00:33:51,780
So that's they kind of emulate a modern corporate environment the best they can.

317
00:33:51,780 --> 00:33:55,940
And there's of course stuff like Exchange, and web apps, and databases, and all.

318
00:33:56,080 --> 00:33:58,220
And so basically there's two goals in these competitions.

319
00:33:58,220 --> 00: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.

320
00:34:08,760 --> 00:34:12,600
And really frankly that ends up in situations like this.

321
00:34:12,600 --> 00: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.

322
00:34:28,920 --> 00:34:39,260
And they also do things like defacing the websites, and RMRFing boxes, or overriding MBRs when they get too much access.

323
00:34:39,260 --> 00: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?

324
00:34:48,380 --> 00:34:53,580
So the red team spends all year writing malware for these competitions, and are probably watching right now.

325
00:34:53,580 --> 00:34:54,960
So hi red team!

326
00:34:56,340 --> 00: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.

327
00:35:08,200 --> 00:35:13,720
So with that kind of backstop in mind, we're going to look at some example screenshots of BlueSpawn.

328
00:35:13,720 --> 00:35:16,940
So here we just have the system.

329
00:35:16,940 --> 00:35:19,480
There's two Cobalt strike beacons running.

330
00:35:19,620 --> 00:35:26,680
One is just an HTTP beacon, and then the other is an SMB beacon living in explorer.exe.

331
00:35:26,780 --> 00:35:29,760
And so this is how BlueSpawn goes about finding it.

332
00:35:29,800 --> 00: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.

333
00:35:43,500 --> 00: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.

334
00:35:51,360 --> 00: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.

335
00:36:00,140 --> 00:36:04,280
So that's an example of how BlueSpawn is responding to the threat.

336
00:36:04,920 --> 00:36:07,380
And here's another classic threat.

337
00:36:07,380 --> 00: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.

338
00:36:17,720 --> 00: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.

339
00:36:31,880 --> 00: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.

340
00:36:39,380 --> 00: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.

341
00:36:49,160 --> 00: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.

342
00:37:00,500 --> 00:37:04,020
So then it goes and correlates that with the file associated with it.

343
00:37:04,020 --> 00:37:10,040
So we have two detections, one for the file and one for the registry key that contains the badness.

344
00:37:10,760 --> 00:37:13,920
Next, here is a good old run key.

345
00:37:15,020 --> 00: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.

346
00:37:28,780 --> 00:37:30,240
Here's a web shell.

347
00:37:30,240 --> 00:37:34,740
This is a great, I like to use this for showing how the context works.

348
00:37:34,740 --> 00: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.

349
00:37:56,780 --> 00:38:01,920
And the next here is a pretty simple example with like backdooring services.

350
00:38:01,920 --> 00: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.

351
00:38:11,360 --> 00: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.

352
00:38:21,520 --> 00: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.

353
00:38:34,160 --> 00: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.

354
00:38:43,860 --> 00: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.

355
00:38:53,200 --> 00: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.

356
00:39:07,920 --> 00: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.

357
00:39:12,520 --> 00: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.

358
00:39:24,200 --> 00:39:31,340
And honestly one of the coolest parts is that the RedTeam unveiled something called RedSpawn this year.

359
00:39:31,340 --> 00:39:35,660
So that was a tool that was apparently supposed to like attack and defeat BlueSpawn.

360
00:39:35,660 --> 00: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.

361
00:39:45,500 --> 00: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.

362
00:39:56,160 --> 00:40:00,680
So you can identify, it'll identify and respond to malware on the system.

363
00:40:00,740 --> 00:40:06,640
One of the cool things we found is that it's like a force multiplier, especially in these active defense situations.

364
00:40:06,760 --> 00: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.

365
00:40:15,480 --> 00:40:18,980
It'll just flag which ones are most likely to be suspicious.

366
00:40:19,060 --> 00:40:24,440
And that way you can spend more of your efforts hunting where it counts to find the malware.

367
00:40:25,000 --> 00:40:26,580
And so that's really important.

368
00:40:26,980 --> 00: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.

369
00:40:35,220 --> 00: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.

370
00:40:44,660 --> 00: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.

371
00:40:53,880 --> 00:40:58,080
So first I'll show you BlueSpawn's help menu just so you can see all the options it has.

372
00:40:58,080 --> 00:40:59,600
And that's a pretty simple interface.

373
00:41:01,400 --> 00:41:05,040
Because I want to go find bad things, I'm going to run it in hunt mode.

374
00:41:05,660 --> 00: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.

375
00:41:11,780 --> 00:41:14,700
When I find stuff, I want to react by deleting files.

376
00:41:14,700 --> 00:41:16,020
So I use the delete file reaction.

377
00:41:16,020 --> 00:41:17,000
I'm going to remove values.

378
00:41:17,000 --> 00:41:19,900
So remove value reaction and card memory.

379
00:41:20,820 --> 00:41:24,260
And then I want to log to a file so I can view it later.

380
00:41:24,320 --> 00:41:27,040
And then the console so I can see it now.

381
00:41:27,040 --> 00:41:29,220
Just press enter and now it runs.

382
00:41:29,380 --> 00:41:31,660
That's pretty much all there is to getting it to run.

383
00:41:33,200 --> 00:41:39,080
So here it found a process injection into SPC host PID 632.

384
00:41:39,340 --> 00:41:41,560
And I'll open it up in a process hacker.

385
00:41:43,620 --> 00:41:47,880
So you can see here that it actually tells me the memory address where it found the injection.

386
00:41:47,880 --> 00:41:50,800
So I can actually go take a look at that in process hacker.

387
00:41:51,080 --> 00:41:57,040
And you'll see here that it's RWX memory section, which generally is not a great thing.

388
00:41:57,140 --> 00:41:59,240
So I'll go ahead and carve that out.

389
00:41:59,400 --> 00:42:00,680
And here I found a couple more.

390
00:42:00,680 --> 00:42:02,440
So I'll go ahead and carve those out too.

391
00:42:03,800 --> 00:42:08,440
And here it found some process injection into win-startup.exe.

392
00:42:08,900 --> 00:42:10,860
And so I'll go ahead and carve those out.

393
00:42:16,900 --> 00:42:23,180
And now here it found the sticky keys backdoor that Jake was talking about earlier, the image file execution options debugger.

394
00:42:23,340 --> 00:42:28,160
And so I'll open that up in autorun so you can see that it's also found by autoruns.

395
00:42:30,940 --> 00:42:33,040
And it's under the image hijacks tab.

396
00:42:33,040 --> 00:42:34,800
Sometimes everything doesn't show it.

397
00:42:38,490 --> 00:42:40,030
You can see it there and there.

398
00:42:43,750 --> 00:42:45,030
So we'll go ahead and remove that.

399
00:42:45,030 --> 00:42:50,910
And here it found the run key that was running the process we found some injection in earlier.

400
00:42:51,150 --> 00:42:54,330
The window startup actions, which definitely is not legitimate.

401
00:42:54,470 --> 00:42:56,150
So go ahead and remove that run key.

402
00:42:56,410 --> 00:43:01,230
Here it found NetSH helper DLL, which is a sneakier persistence technique.

403
00:43:01,230 --> 00:43:02,730
You can see it in regedit.

404
00:43:03,030 --> 00:43:06,390
And BlueSpawn actually protects the files during scans.

405
00:43:06,390 --> 00:43:10,030
So this actually won't be able to show the signatures on it.

406
00:43:10,030 --> 00:43:12,130
But I assure you it's not good.

407
00:43:21,620 --> 00:43:24,520
So we'll go ahead and remove that value there.

408
00:43:25,900 --> 00:43:28,380
And now it found the PHP web shell.

409
00:43:28,380 --> 00:43:29,940
We can go ahead and remove.

410
00:43:33,580 --> 00:43:37,620
And here is the malicious service.

411
00:43:37,680 --> 00:43:39,000
So go ahead and remove that.

412
00:43:39,320 --> 00:43:41,700
And for some reason autoruns can't find it.

413
00:43:41,700 --> 00:43:44,940
But I'll show you in this command prompt that it absolutely is there.

414
00:43:53,210 --> 00:43:55,370
So I'll go ahead and remove that with BlueSpawn.

415
00:43:56,930 --> 00:44:00,450
And now I'll go ahead and remove the NetSH helper DLL file.

416
00:44:01,270 --> 00:44:04,230
And here's the win startup.exe that it didn't like.

417
00:44:04,790 --> 00:44:06,630
And here's the malicious service.

418
00:44:07,010 --> 00:44:08,150
And that's it.

419
00:44:08,150 --> 00:44:09,230
That's all you have to do.

420
00:44:13,550 --> 00:44:17,050
And here's autorun showing you that stuff it found has been cleared out.

421
00:44:19,250 --> 00:44:20,710
So next slide.

422
00:44:21,170 --> 00:44:24,070
So here's what happened to the interpreter sessions that I had open.

423
00:44:24,150 --> 00:44:26,050
They got killed when I carved out the memory.

424
00:44:29,170 --> 00:44:31,210
And now on to the future work.

425
00:44:31,290 --> 00:44:33,350
BlueSpawn still has a long way to go.

426
00:44:33,350 --> 00:44:34,990
A lot more features to be added.

427
00:44:34,990 --> 00: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.

428
00:44:40,310 --> 00:44:44,430
So most of our goals right now fall under three categories.

429
00:44:44,530 --> 00:44:49,670
Improving coverage, improving configurability, and improving integrity.

430
00:44:49,770 --> 00:44:53,590
So under coverage, we plan to continue adding new hunts and mitigations.

431
00:44:53,630 --> 00:44:57,270
Arguably our biggest goal here is to expand our data sources.

432
00:44:57,270 --> 00:45:03,630
So this would constitute things like API monitoring through a DLL load into all the processes or a kernel driver.

433
00:45:04,030 --> 00:45:07,210
Network traffic monitoring, user auditing, that sort of thing.

434
00:45:07,210 --> 00:45:11,210
We've also placed a large focus on improving our scanning capabilities.

435
00:45:11,210 --> 00:45:15,290
Admittedly, they are somewhat lacking right now, using only the very basic metrics.

436
00:45:15,630 --> 00: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.

437
00:45:25,090 --> 00: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.

438
00:45:34,890 --> 00:45:41,010
As we develop BlueSpawn, we've built most of our features to be very configurable from an API perspective.

439
00:45:41,010 --> 00: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.

440
00:45:48,730 --> 00: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.

441
00:45:57,050 --> 00: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.

442
00:46:04,010 --> 00:46:11,730
As for integrity, right now, BlueSpawn has very little defenses against malware or malicious users actually tampering with it.

443
00:46:11,730 --> 00: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.

444
00:46:22,110 --> 00:46:24,690
And this would most likely be through a kernel driver.

445
00:46:24,870 --> 00:46:28,470
BlueSpawn also assumes it has all the rights that an admin normally has.

446
00:46:28,470 --> 00: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.

447
00:46:35,610 --> 00:46:38,310
This also would likely be addressed to the same kernel driver.

448
00:46:38,790 --> 00: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.

449
00:46:53,530 --> 00: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.

450
00:47:00,250 --> 00: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.

451
00:47:07,010 --> 00: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.

452
00:47:15,910 --> 00: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.

453
00:47:22,850 --> 00:47:27,390
This server is still in its early stages, but we plan to ramp up development in the next few months.

454
00:47:27,770 --> 00:47:30,790
Finally, the last major component to BlueSpawn is the cloud.

455
00:47:30,790 --> 00:47:34,930
Now, this is a long way off, and I'll admit we haven't even started thinking about developing it yet.

456
00:47:34,930 --> 00: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.

457
00:47:45,150 --> 00:47:51,310
This could also serve as a threat intelligence repository, sending out IOCs to clients and servers.

458
00:47:52,790 --> 00:47:55,070
So, we've talked a lot.

459
00:47:55,070 --> 00: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,

460
00:48:08,050 --> 00:48:08,650
right?

461
00:48:08,690 --> 00:48:10,330
So, we're going to conclude.

462
00:48:10,810 --> 00:48:14,890
First, remember that BlueSpawn is very much still in the alpha stage.

463
00:48:15,510 --> 00: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.

464
00:48:23,050 --> 00: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.

465
00:48:34,550 --> 00: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.

466
00:48:43,870 --> 00:48:50,210
And we also want to extend a huge thank you, again, to the community projects that are listed here.

467
00:48:50,390 --> 00:48:58,890
Really, building something like this is not possible without these frameworks and libraries, so definitely check those two out as well.

468
00:48:59,290 --> 00: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.

469
00:49:06,670 --> 00:49:14,170
First, using MITRE ATT&CK to be able to detect threats and think about your defenses is a great springboard.

470
00:49:14,170 --> 00:49:15,970
And really, think about it as a springboard.

471
00:49:15,970 --> 00: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?

472
00:49:24,730 --> 00:49:27,430
But you can use that and go as a rabbit hole.

473
00:49:27,430 --> 00: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.

474
00:49:34,130 --> 00:49:36,970
So, that's a good, really good place to start.

475
00:49:37,430 --> 00:49:39,350
Second, knowing your coverage.

476
00:49:39,910 --> 00:49:46,470
So, we've used this more times than I can count, right, in our cyber defense competitions and all.

477
00:49:46,470 --> 00:49:48,930
And it translates really good to the real world, right?

478
00:49:48,930 --> 00: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.

479
00:50:03,830 --> 00:50:07,470
So, that's a great way to think about defense.

480
00:50:07,490 --> 00: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.

481
00:50:16,870 --> 00: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?

482
00:50:24,790 --> 00: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.

483
00:50:32,070 --> 00:50:36,530
So, just a few housekeeping items, I guess, before we wrap up.

484
00:50:36,930 --> 00:50:38,990
Thank you all for listening today.

485
00:50:38,990 --> 00:50:44,810
We hope you've had as much fun as we have in creating this and talking this afternoon.

486
00:50:45,110 --> 00:50:48,810
We also would like to thank the conference volunteers, right?

487
00:50:48,810 --> 00: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.

488
00:50:56,630 --> 00:50:59,670
Finally, we've linked the slides on the README.

489
00:50:59,670 --> 00:51:04,850
We'll have the DEF CON release, if you will, go live here in a bit after this talk ends.

490
00:51:04,850 --> 00: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.

491
00:51:11,230 --> 00:51:12,790
You can look at the slides.

492
00:51:12,830 --> 00:51:14,590
We also have a Discord for the project.

493
00:51:14,590 --> 00: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.

494
00:51:25,170 --> 00:51:27,550
We'll be happy to answer any questions you might have.

495
00:51:27,550 --> 00:51:29,910
So, thanks again, guys, for listening.

496
00:51:29,910 --> 00:51:31,350
We hope you really enjoyed it.

497
00:51:31,350 --> 00:51:32,130
Thank you.

498
00:51:32,850 --> 00:51:34,750
Well, thanks, Jake and Jack.

499
00:51:34,750 --> 00:51:35,950
That was a great talk.

500
00:51:35,950 --> 00: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.

501
00:51:43,930 --> 00:51:49,010
As a reminder, as they've got up here on the slide, the Discord channel takes you over to their server.

502
00:51:49,110 --> 00: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.

503
00:51:58,090 --> 00:51:59,950
Other than that, have a great day, guys.