[00:00.000 --> 00:04.840]  at the golden age of Insider Threats. I'm Adam Macinci, that's Bryson Bort. We'll introduce
[00:04.840 --> 00:10.420]  ourselves again here in a second. And just before we get started on anything else, yes,
[00:10.420 --> 00:16.380]  it is known to be misspelled kind of intentionally because it's you are the adversary within
[00:16.380 --> 00:20.020]  because it's about Insider Threats. It's a joke.
[00:20.020 --> 00:21.960]  We're paid to hack things, not tell jokes.
[00:21.960 --> 00:29.820]  Not tell jokes. It's not great. Anyway, real quick, who am I? I'm Adam Macinci. I do all
[00:29.820 --> 00:34.280]  sorts of stuff. I volunteer and speak with the Red Team Village. I do their one-on-one
[00:34.280 --> 00:38.760]  track. I'm a member of the C2 Matrix. I'm the head of product management at Scythe.
[00:38.760 --> 00:42.420]  I've got a background in enterprise solutions and crypto and privacy and whatever. That's
[00:42.420 --> 00:45.360]  me. And also here's Bryson.
[00:45.820 --> 00:53.780]  Ash said a lot of words. He's our token Californian. I founded Grimm eight years ago to build the
[00:53.780 --> 00:58.700]  best team of hackers because this is no longer an individual sport. It's a team sport. Defenses
[00:58.700 --> 01:05.720]  have gotten really good. About two years ago, I spun out Scythe. That's my full-time
[01:05.720 --> 01:10.100]  job for an adversary emulation platform where I work with MASH. And then I'm a co-founder
[01:10.100 --> 01:14.420]  of the ICS Village non-profit. So hopefully you have a chance here at DEF CON to also
[01:14.420 --> 01:16.060]  check out the ICS Village.
[01:19.130 --> 01:26.330]  All right. And so what we'll be talking about today is a bunch of things, not only Insider
[01:26.330 --> 01:31.350]  Threats, but also the value of post-exploitation and why that's important philosophically.
[01:31.370 --> 01:35.510]  And we'll talk about defense validation through threat emulation and why focusing on endpoints
[01:35.510 --> 01:40.010]  from a red team and from a blue team and from a purple team perspective is important. And
[01:40.550 --> 01:45.350]  obviously, Insider Threats and why their lives are a little easier than most folks when it
[01:45.350 --> 01:49.410]  comes to being adversaries and why boards and leadership cares and why defenders are
[01:49.410 --> 01:50.270]  overwhelmed.
[01:50.270 --> 01:54.350]  And then we'll talk about the cycle of red and blue working together towards purple teaming
[01:54.350 --> 01:57.770]  and why this is all relevant from an Insider Threat perspective.
[01:58.150 --> 02:06.130]  So first off, let's talk about the value of post-exploitation. And this is kind of a bit
[02:06.130 --> 02:10.890]  of a philosophical argument for us, but we generally have the following three principles
[02:10.890 --> 02:16.870]  that we as the InfoSec community just feel to be true. So one, it's not if, but when.
[02:16.870 --> 02:21.630]  So everybody has the potential to be compromised and it will inevitably happen. Every organization
[02:21.630 --> 02:27.230]  has the ability to be compromised. Two, there will always be zero days. There will always
[02:27.230 --> 02:31.630]  be end days. There will always be bugs in software, which creates a new exploit and
[02:31.630 --> 02:37.610]  that will always be the case. And then finally, social engineering and Insider Threats, to
[02:37.610 --> 02:42.390]  whatever degree you want to count that, will always work. There's always someone who will
[02:42.390 --> 02:46.050]  click the email link. There will always be someone who plugs in the thumb drive. That
[02:46.050 --> 02:49.110]  is inevitable and there's a lot of reasons for that.
[02:49.110 --> 02:56.690]  So if we believe those principles to be true, then kind of philosophically, post-exploitation
[02:56.690 --> 03:01.550]  behaviors from an adversary's perspective is more important than the exploit itself.
[03:01.550 --> 03:06.650]  It doesn't matter all the CVEs that we use to get in. It's what the adversary does once
[03:06.650 --> 03:10.270]  they are in. That's the thing that's more important philosophically.
[03:10.330 --> 03:15.150]  There's also two layers to this. So if you think about this simply, we're talking about
[03:15.150 --> 03:23.290]  access. Access, typically, people think of the antiquated way of, I have a perimeter
[03:23.670 --> 03:30.590]  and a third party has gained unauthorized access. And that is part of it. And so what
[03:30.590 --> 03:37.410]  you can summarize this is, is the ability to gain access is across an infinite scope
[03:37.410 --> 03:42.450]  of possibility because it's not just technical. It is a question of people and technology.
[03:42.450 --> 03:47.510]  The second part of access is there's also access within the organization. So once I've
[03:47.510 --> 03:53.790]  breached the perimeter, once I've compromised, then I'm still working the access problem
[03:53.790 --> 03:59.030]  in an iterative way as I try to work from where I am to where I want to go. And each
[03:59.030 --> 04:03.450]  one of those steps starts with that access problem, which again, can be solved through
[04:03.450 --> 04:05.510]  technical or social means.
[04:06.730 --> 04:12.890]  And this is all particularly pertinent when we're talking about it from a red team perspective.
[04:12.890 --> 04:17.830]  So for example, if we take a red team are performing an adversary test and we take the
[04:17.830 --> 04:22.990]  following two scenarios. So in the first scenario, they take a custom binary that they've made
[04:22.990 --> 04:28.510]  and they detonated on an endpoint during this engagement. Well, they've been caught and
[04:28.510 --> 04:33.990]  that's been burned. So that's a valid test of a security control that an unsigned piece
[04:33.990 --> 04:39.210]  of malware was able to be caught. That's a good thing. But an equally valid test from
[04:39.350 --> 04:45.090]  a red team perspective is creating that same custom piece of malware and then putting it
[04:45.090 --> 04:50.850]  in an allow list for that specific binary and then having it go through and not be caught
[04:50.850 --> 04:54.650]  and letting the behavior run after the fact. These are equally valid tests because in the
[04:54.650 --> 05:00.230]  first one, you validated the security control of do you block unsigned things that are potentially
[05:00.230 --> 05:05.890]  malicious, but in the latter, you're running an O day or an N day scenario as if that thing
[05:05.890 --> 05:10.810]  was able to work its way into being allowed and then fire its behavior after the fact.
[05:10.810 --> 05:15.610]  So it's important to point that out that these are equally valid tests from a red team perspective.
[05:16.990 --> 05:21.710]  So the other part here is we're validating our assumptions. I can't tell you how many
[05:21.710 --> 05:25.870]  conversations I've had with folks where we go in and they're like, oh, you know,
[05:25.870 --> 05:30.070]  we're paying this amount of money for this and we know it does this. Well, how do you know?
[05:31.270 --> 05:35.770]  Try it. Check it. Once you do that, you're building up that arsenal of validating those
[05:35.770 --> 05:41.590]  assumptions and keeping it going. Another way to look at this is it's like being
[05:41.590 --> 05:49.470]  an APT on the cheap. By proving the control works and then using configuration like allow list to
[05:49.470 --> 05:54.490]  allow something to go past control, that's the equivalent of a technical compromise like what
[05:54.490 --> 06:00.130]  an APT can do, right? We assume that they can do that. It's a question of if, not when. And
[06:00.130 --> 06:06.890]  by doing that allow list, you just, for free, with little effort, achieve the same goal as what that
[06:06.890 --> 06:17.290]  APT can. So with all that in mind, let's talk about insider threats and what's specific to
[06:17.290 --> 06:22.470]  them when we talk about insider threats from a red team perspective. And specifically, let's talk
[06:22.470 --> 06:28.950]  about today's endpoints. So for the sake of this conversation, an endpoint is something that a
[06:28.950 --> 06:33.030]  user interacts with. So it's not like a web app or a web server or something like that or an S3
[06:33.030 --> 06:39.350]  bucket. This is something that figures on keyboard, somebody's actually utilizing. And the reason
[06:39.350 --> 06:44.290]  we're focusing on this, especially from an insider threat perspective, is not only is this most
[06:44.290 --> 06:49.230]  likely what the user will be interacting with as an insider threat, but also this is where we see
[06:49.230 --> 06:54.570]  the majority of organizations compromised from. This is the phishing links and everything according
[06:54.570 --> 06:59.710]  to there. And ultimately, you know, all these systems are in place to try to protect users
[07:00.430 --> 07:05.110]  from all sorts of malicious stuff and patches are important and all these things are true.
[07:05.110 --> 07:11.270]  However, humans are difficult to secure. People are curious, they're willing to give out their
[07:11.270 --> 07:16.830]  password for a candy bar. Phishing is something that's really difficult to get rid of entirely.
[07:16.830 --> 07:22.770]  People plug USB drives into stuff all the time because of curiosity. And then taking it a step
[07:22.770 --> 07:28.270]  further, as an organization, you probably have all sorts of third parties and all sorts of vendors
[07:28.270 --> 07:32.910]  whose technology you're utilizing. And when they come on site, how do you make sure that the
[07:32.910 --> 07:37.810]  security controls that you have for your staff apply to them? And this is a very difficult problem
[07:37.810 --> 07:44.550]  to solve, as it turns out. So with this all said, we're down to these couple of points from an
[07:44.550 --> 07:51.250]  endpoint perspective, which is endpoint usage is really difficult to monitor. And it's particularly
[07:51.250 --> 07:58.090]  difficult to emulate. And to reiterate here, humans are random, they do all sorts of random
[07:58.090 --> 08:02.810]  things. And figuring out how to monitor for theoretically random behavior, even though
[08:02.810 --> 08:08.910]  that humans have trends, it can be very difficult to do. And then it's also tricky to emulate a
[08:08.910 --> 08:13.530]  perfect user in that way, because people do random stuff all the time. And they, especially when
[08:13.530 --> 08:18.190]  they're interacting heavily with a laptop, say, well, you can't always reliably and predictably
[08:18.190 --> 08:23.490]  say what a given user may or may not be browsing to. So it's just those are important to remember
[08:23.490 --> 08:31.690]  as we move forward. And to preface this upcoming slide, we love privacy and security and encryption,
[08:31.690 --> 08:36.930]  these are all good things that we believe in philosophically. But it becomes a little
[08:36.930 --> 08:45.470]  tricky when we talk about securing and specifically monitoring end users. So this has created a world
[08:45.470 --> 08:50.090]  because of the usability of encryption and privacy and all these pieces of technology,
[08:50.090 --> 08:55.310]  where it's kind of the best time ever to be an insider threat actor, they have a lot of
[08:55.310 --> 09:02.770]  capabilities at your disposal. And so just to call out a few, let's look at Firefox's scent,
[09:02.770 --> 09:08.130]  which is unfortunately been taken offline, because it was being used maliciously, of course. But for
[09:08.470 --> 09:14.470]  a long time, like almost a year, we had the ability for a high reputation domain that allowed
[09:14.470 --> 09:19.830]  end to end encrypted exfiltration and delivery of arbitrary things in another networks. Now,
[09:19.830 --> 09:25.730]  this is a great user privacy tool. But consequently, it was also be used to like deploy malware. And
[09:25.730 --> 09:31.290]  that's why it's now offline. And the same is true for all sorts of VPN technology, whether it's
[09:31.290 --> 09:41.510]  cloud flares, 1.1.1.1 plus warp, this is just instant VPN, DNS security at the consumer level.
[09:41.510 --> 09:47.210]  And these are things that we now like bring your own devices one clearly. And so everybody has
[09:47.210 --> 09:51.910]  these abilities running in the user space on their own devices. And it just allows for a lot of
[09:51.910 --> 09:57.750]  exfiltration events outside of an organization. So like MDMs have essentially lost, there is no
[09:57.750 --> 10:03.570]  real enterprise mobility solution. And then you pair all of these consumer technologies with the
[10:03.570 --> 10:09.430]  fact that enterprises are just using more cloud based technology. Well, that's instant high
[10:09.430 --> 10:15.510]  reputation exfiltration right there. So whether it's legitimate cloud use of Google Apps, or
[10:16.130 --> 10:20.950]  being able to use things like Dropbox, or what have you to steal data out, like who's going to
[10:20.950 --> 10:26.890]  block Google Drive in an enterprise that uses Google Drive, this is just opening up all these
[10:26.890 --> 10:33.610]  doors for insider threats to steal stuff out of a network. And of course, we now have the elephant
[10:33.610 --> 10:41.910]  in the room. In the pandemic era, 60% of all workers are remote. So you no longer have to
[10:41.910 --> 10:48.070]  worry about the challenge of how do I physically remove assets into a safe location because
[10:48.070 --> 10:54.970]  your safe location is already at home. So we now have, this is where we've seen a lot of
[10:54.970 --> 11:00.570]  enterprises moving to the cloud because it's a bandaid for security. Certainly VPN usage has
[11:00.570 --> 11:07.110]  bumped up because well, at least I can encrypt the corporate asset in the home environment to
[11:07.690 --> 11:12.530]  the corporate environment. And what I would offer just for some little extra free advice
[11:12.530 --> 11:19.930]  is think of the using least privilege in these circumstances, have them log into a essentially
[11:20.090 --> 11:25.390]  a demilitarized zone of minimum privilege access, and then they validate out of that to go further
[11:25.390 --> 11:30.150]  into the infrastructure. So offering those kinds of things slow them down. The other challenge we
[11:30.150 --> 11:35.570]  have here is around testing this. We are now talking about a mixed environment where it's no
[11:35.570 --> 11:42.490]  longer just corporate assets. We now have corporate assets in a private asset environment, right? Who
[11:42.490 --> 11:47.550]  owns that router? Who owns those other devices on that network? Those are the employees' personal
[11:47.550 --> 11:55.870]  devices and it makes it difficult to bring that in scope for a test. And this also ties
[11:55.870 --> 12:02.950]  into the challenge, of course, back in the old days where we did have BYOD where a lot of folks
[12:02.950 --> 12:10.690]  didn't necessarily have policies around that. And being able to identify IoT traffic and specific
[12:10.690 --> 12:19.240]  device fingerprinting is a very challenging problem. And that really leads us to the fact that
[12:19.240 --> 12:28.640]  although trust is critical, and we can't emphasize this enough, it's not only critical,
[12:28.640 --> 12:34.420]  but it's arguably more critical than ever. Because monitoring solutions, there's a whole
[12:34.420 --> 12:43.260]  suite of offerings in a pre-COVID-19 era. But now that everyone's at home, monitoring is an even
[12:43.260 --> 12:47.560]  trickier solution to try to implement when you have all these deployed endpoints in all sorts
[12:47.560 --> 12:54.480]  of different places. And so trusting your employees is critical because there's fewer
[12:54.480 --> 13:00.980]  and fewer ways to modify the things that you're doing and monitor always explicitly. And to all
[13:00.980 --> 13:06.900]  the things that Bryson just said, it's about restricting access now, not so much monitoring
[13:06.900 --> 13:12.880]  for every keystroke or every bit of browsing bit that goes on. And so we think about allow
[13:12.880 --> 13:17.780]  requirements, we think about how folks can circumvent blocks and all of these things,
[13:17.780 --> 13:22.260]  where we're now having to play whack-a-mole with all of the possible consumer solutions as well
[13:22.260 --> 13:28.100]  that come from legitimate providers and legitimate domains. This is very, very tricky. And so
[13:28.860 --> 13:33.860]  one of the ways I think about it is, it's not even so much like how do you prevent,
[13:33.860 --> 13:40.340]  or how do you emulate the APT or the highly motivated adversary? Instead, I think of it as
[13:40.340 --> 13:46.960]  how do you even prevent exfiltration from a slightly motivated adversary? Someone who doesn't
[13:46.960 --> 13:52.000]  necessarily know how to roll their own crypto, but they can download a VPN app on their device
[13:52.000 --> 13:58.620]  and turn it on. They have a motivation, they're just not highly motivated. And so that's where
[13:58.620 --> 14:02.700]  we get this idea of the slightly motivated adversary. And what to do about that scenario
[14:02.700 --> 14:14.820]  can be very, very tricky. So with all that about insider threats wrapped up, how do we think about
[14:14.820 --> 14:19.120]  all this from a red team perspective? Well, the good news, I mean, good news for the red team,
[14:19.120 --> 14:25.080]  maybe not so much for the blue. The red team can use all these principles and philosophical
[14:25.080 --> 14:31.760]  paradigms that we're in to create adversary scenarios that use all the advantages of these
[14:31.760 --> 14:37.540]  things. So this is things running in the user space, things running at runtime, no exploitation
[14:37.540 --> 14:41.700]  required, because if you're simulating an insider threat, well, they probably have the ability to
[14:41.700 --> 14:46.340]  double click something on their endpoint. And they're not necessarily doing so because they
[14:46.340 --> 14:49.520]  were tricked into doing it, they did it because they wanted to, and they're willing to kind of
[14:49.520 --> 14:59.130]  take a couple steps in order to achieve that goal. So now for the red teamer who's creating a campaign,
[14:59.130 --> 15:05.550]  they could do what the malware authors do, where they design things around, well, what are the
[15:05.550 --> 15:10.630]  capability of a slightly motivated adversary, so they can run in the user space, they've got access
[15:10.630 --> 15:15.090]  to valuable data, like, you know, their documents folder is probably important, there's probably some
[15:15.090 --> 15:21.930]  PII set more on that drive. Well, they also have access to those things and publicly accessible
[15:21.930 --> 15:26.650]  exfiltration tools, Pastebin. How many organizations have Pastebin allowed? Like, that's an
[15:26.650 --> 15:31.830]  exfiltration tool from a slightly motivated attacker perspective. And not only that, the red
[15:31.830 --> 15:37.750]  team also has on top of those capabilities, knowledge of ODAs and NDAs, knowledge about how
[15:37.750 --> 15:43.970]  to automate these things, deploy infrastructures to do more advanced exfiltration techniques,
[15:43.970 --> 15:47.930]  they know how to obfuscate, they know how to be more anonymous. So you ratchet these things
[15:47.930 --> 15:52.310]  together and you think, what do you get for free by pretending to be an internal adversary? And
[15:52.310 --> 15:55.750]  then you put on top of that all the stuff you could do as a red teamer. Well, that creates a
[15:55.750 --> 16:02.730]  very exciting scenario from a red team adversary perspective. Talking about Pastebin and
[16:03.350 --> 16:08.510]  executing in user space, check out the Blue Team Choose Your Own Adventure. We did a short
[16:08.510 --> 16:13.950]  Choose Your Own Adventure that involves ransomware that takes advantage of those.
[16:15.730 --> 16:19.910]  Yeah, that's an excellent point in and of itself. If we think about modern ransomware,
[16:19.910 --> 16:25.050]  you don't need to run as admin to do modern ransomware, like end users can create and
[16:25.050 --> 16:29.690]  delete files. They have permissions to do that. And ransomware says, great, I want to create and
[16:29.690 --> 16:33.590]  delete files, right? That's the point. It's all these things are in the user space, and you just
[16:33.590 --> 16:40.250]  get them for free, thinking of as an adversary does. So now that we know all the advantages,
[16:40.250 --> 16:45.890]  what can the red and blue teams do about it? Because the slightly motivated adversary is
[16:45.890 --> 16:51.890]  very, very powerful, and they have the ability to both accidentally and intentionally compromise
[16:51.890 --> 16:58.450]  endpoints. And given that the blue team now has to think about everything from a disgruntled
[16:58.450 --> 17:05.370]  staffer to an APT, well, that's a pretty big scope. Actually, I don't... Bryson, I don't know if I fully
[17:05.370 --> 17:14.670]  get your Joe Rogan, Elon Musk image on this one. Yeah, so what I was going for here was
[17:14.670 --> 17:20.050]  you got a picture of Elon Musk as the disgruntled staffer, and he's sitting there at home.
[17:21.270 --> 17:30.470]  I was employee 53. They don't take me seriously enough. They don't respect me,
[17:30.470 --> 17:35.210]  and I'm gonna quit. I'm gonna burn this place to the ground, and this is him taking his red
[17:35.210 --> 17:43.260]  stapler on the way out while it burns. Fair enough. There's your disgruntled role play.
[17:43.260 --> 17:49.460]  Yeah, that's good. I mean, defining Elon Musk as a staffer might be a bit of a stretch,
[17:49.460 --> 17:56.580]  but the analogy certainly plays. But given that that is inside a threat model for a blue team,
[17:56.580 --> 18:04.360]  that can be incredibly tricky, right? And so what do we do with all this? Well, an answer to this
[18:04.360 --> 18:11.240]  is shoring up the fundamentals. So it's not so much like would you detect a foreign country inside
[18:11.240 --> 18:17.680]  your organization slowly beaconing little documents over the course of years over DNS,
[18:17.680 --> 18:22.460]  but thinking about, well, would you notice standard exfil if someone started dumping gigs
[18:22.460 --> 18:27.100]  of data out in the middle of the night? These sorts of fundamentals are really important.
[18:27.120 --> 18:33.080]  And thinking about validating the controls and validating those tests in a repeatable way via
[18:33.080 --> 18:39.700]  adversary testing, this is that red and blue team working together. So real quick, before we dive
[18:39.700 --> 18:46.280]  deeper on that, I do want to make a quick note about the vendor industry on this one, which is
[18:46.360 --> 18:54.540]  a little awkward. So if we think about breach and attack simulation as a thing, so that is a
[18:54.540 --> 19:00.380]  Gartnerism that is way overly broad, and it can mean a wide variety of things. But generally speaking,
[19:00.380 --> 19:05.340]  we think of it as kind of spectrum. And on one end of the spectrum, we have controls validation
[19:05.340 --> 19:10.940]  tools. So these are agent-based things that repeat known signature actors and traffic in these sorts
[19:10.940 --> 19:14.220]  of PCAP replays and what have you. And then on the other end of the spectrum is more advanced
[19:14.220 --> 19:18.160]  adversarial testing. And there's a whole simulation versus emulation argument that we could talk
[19:18.160 --> 19:23.320]  about. And these are the kinds of tools on the other side that the red teams in Pentesters use.
[19:23.380 --> 19:26.660]  And there's all these sorts of other things we could talk about, like how they align to
[19:26.660 --> 19:33.420]  MITRE ATT&CK and why that's important. But for the most part, all of these things inside of the
[19:33.420 --> 19:39.260]  spectrum do satisfy this idea of assumed compromise and assumed breach scenarios, regardless of
[19:39.260 --> 19:43.940]  whether or not you're compiling something via MS Venom and Metasploit, or whether you're using
[19:44.140 --> 19:48.340]  a breach and attack simulation tool. You could use both of these things in an assumed
[19:48.340 --> 19:58.560]  compromised way. And that's worth noting about this whole spectrum of tools. I mean, the only
[19:58.560 --> 20:03.480]  thing I'd jump on here is where I throw out that MITRE ATT&CK is not a bingo card.
[20:04.900 --> 20:10.720]  What I mean by that is what MITRE ATT&CK is a great compendium of understanding all of the
[20:11.380 --> 20:19.100]  correction, a lot of the elements, because it may never be complete, of a common vernacular for us
[20:19.100 --> 20:24.100]  to describe attacks. You can't use it as a checkboard. You're like, I have successfully
[20:24.100 --> 20:31.060]  made sure that this can never happen. T1033 will never happen. That's the wrong way to look at it.
[20:31.060 --> 20:37.300]  And part of that is because I like to describe it as a periodic table. And the attacks in it
[20:37.300 --> 20:42.200]  are different elements. And the way and the order that those elements are combined is a
[20:42.200 --> 20:50.260]  chemical equation. And whether you get lead or gold depends on that order. And so the point
[20:50.260 --> 20:57.500]  being is that a static look of particular elements without understanding the context that they're in
[20:57.500 --> 21:02.680]  changes what that means. My ability to do lateral movement is going to be affected by
[21:02.680 --> 21:08.220]  whether or not I have credentials or not, for example. Simple example.
[21:11.560 --> 21:15.880]  And when we think about these sorts of chemical elements like Bryce is describing,
[21:15.880 --> 21:19.840]  and these sorts of things are accidentally using it as a bingo card, well, this can be
[21:19.840 --> 21:24.120]  exceptionally tempting when we're talking about something like a controls validation solution,
[21:24.120 --> 21:29.460]  where it's automatically testing whether or not you can send data to something that's known as
[21:29.460 --> 21:35.180]  evildomain.com over these firewall ports and all these sorts of things. Well, you can define
[21:35.180 --> 21:39.040]  these rules in the controls validation tool and have it automatically test those things over and
[21:39.040 --> 21:42.320]  over and over again and let you know if your configuration management's falling over and
[21:42.320 --> 21:47.460]  that sort of thing, which is all very valuable. But it is tempting to just say, oh, we're tagging,
[21:47.460 --> 21:52.260]  we're looking for that port for exfiltration, we're done with that MITRE ATT&CK ID. And again,
[21:52.260 --> 21:57.220]  it's important to note that these controls validation tools are very static. They're
[21:57.220 --> 22:02.140]  agent-based, they're signature-based. And kind of most important from our perspective,
[22:02.140 --> 22:06.640]  we're talking about internal adversaries and insider threats. These aren't production endpoints
[22:06.640 --> 22:11.740]  that these things are installed on. These things aren't simulating users or internal threat actors,
[22:11.740 --> 22:16.720]  necessarily. They're just doing, here's some analysis from the threat intel community,
[22:16.720 --> 22:21.540]  fire for effect, here's a PCAP. So it's not exactly what we're talking about here from
[22:21.540 --> 22:33.080]  an insider threat emulation perspective. Just to kind of finish that off, there's no people in the
[22:33.080 --> 22:37.100]  loop on this one, right? It's about automating these solutions and detecting these sorts of
[22:37.100 --> 22:41.100]  things. And so it is repeatable, and it is easy to implement these controls validation tools.
[22:41.100 --> 22:45.520]  But ultimately, they're not really something that the red team is going to utilize.
[22:45.680 --> 22:51.060]  And they're more about unit testing than adversary behavior. And often these are unfortunately at
[22:51.060 --> 22:56.280]  the mercy of the vendor, because the vendor is the thing that's pulling down the threat intel.
[22:56.280 --> 23:01.140]  It says, these are all the tests you can run, you might have very limited ability to change them a
[23:01.140 --> 23:06.040]  bit, but it's not a customizable tool. So that's a concern when we're thinking about controls
[23:06.040 --> 23:11.120]  validation from an insider threat perspective. The only thing I'll add there is what's at the
[23:11.120 --> 23:16.440]  top is that people are not in the loop. And what we mean by that is that these are great detection
[23:16.440 --> 23:22.660]  engineering tools, but you're not including the user affecting the behavior around looking at
[23:22.660 --> 23:27.900]  what those technical controls do or don't do. And then the second part is you're not able to
[23:27.900 --> 23:35.960]  measure the response, because it's a set stage for what your sock is looking at.
[23:36.140 --> 23:41.460]  But I think it was also a bit glossed over on what the pros here with change control,
[23:42.000 --> 23:46.520]  your ability to know what you're always going to see and building that library out.
[23:46.720 --> 23:50.980]  We take it for granted that things work the way that they're supposed to work,
[23:50.980 --> 23:56.120]  and that our challenge is finding attackers in that noise. There is also the challenge that
[23:56.120 --> 24:03.940]  tools break, configurations drift, things stop working for various reasons. And so knowing for
[24:03.940 --> 24:08.540]  sure what I'm looking for, be able to identify that is a significant value proposition.
[24:12.580 --> 24:18.000]  And so with all that in mind from a controls validation benefit, like cost benefit evaluation,
[24:18.560 --> 24:22.880]  let's look at the other kinds of tooling that we mentioned, which is adversary testing or
[24:22.880 --> 24:27.560]  adversarial testing. And so again, for the sake of this discussion, an adversarial test is more
[24:27.560 --> 24:31.860]  about behavior. And we've been talking about post exploitation behavior specifically,
[24:31.860 --> 24:37.180]  whereas a pen test is often focused on those exploitations. So here, it's about a red team
[24:37.180 --> 24:43.520]  creating a scenario where they can validate and see what the network defenders would notice. So
[24:43.520 --> 24:48.040]  will they notice exfiltration? Will they notice lateral movement? Will they notice if I increase
[24:48.040 --> 24:53.140]  my beacon heartbeats or the randomization of those heartbeats, that sort of thing. And this allows
[24:53.140 --> 25:00.140]  the red team or third party pen test or red teaming firm to test these things and to see if
[25:00.140 --> 25:04.920]  they can get an initial foothold and see what the remediation time on that looks like. And they can
[25:04.920 --> 25:10.880]  also define whatever artifacts they may choose to leave. So you could say, well, we think that in
[25:10.880 --> 25:17.080]  this kind of threat scenario, someone may want to... the adversary would drop this folder, or they would
[25:17.080 --> 25:22.400]  they try to create this key and leave that on an endpoint. Those can be predefined with an
[25:22.400 --> 25:28.740]  adversary test. And so moving a little further down that rabbit hole, these things are highly
[25:28.740 --> 25:34.180]  customizable, which can be a good and a bad thing. The more time a red team takes to create them,
[25:34.180 --> 25:39.940]  the more difficult it can be to replicate them. And especially when it comes to the idea of a blue
[25:39.940 --> 25:44.340]  team might want to remediate this thing and then test it again. Well, the more complex it was to
[25:44.340 --> 25:49.500]  create it, the more difficult it is to test it and validate it again. So although there's a lot
[25:49.500 --> 25:54.060]  of flexibility from creating these sorts of engagements that are very red team adversarial
[25:54.060 --> 25:59.880]  focused, they are fairly technical, there's a high learning curve, and they tend to be more expensive.
[25:59.880 --> 26:04.300]  And then finally, one of the cons for them is that they are very limited snapshot in time.
[26:04.400 --> 26:10.280]  So for example, if a red team comes in and performs a high criticality test and nobody notices,
[26:10.280 --> 26:14.200]  the blue team could come back and say, oh, well, we didn't notice that because the person who would
[26:14.200 --> 26:18.220]  have noticed it was out on vacation. Can you come back and do it again? But if the level of effort
[26:18.220 --> 26:30.360]  for doing it again is significant, you have a bit of a problem now. So with all that said, let's talk
[26:30.360 --> 26:34.460]  about the goals for a blue team, not only from a red team, blue team perspective, but also what
[26:34.460 --> 26:40.400]  we're thinking about insider threat actors. What are the goals? Well, the initial goal should be,
[26:40.400 --> 26:46.100]  do you notice network anomalies, those baselines again? Would you notice if there's weird
[26:46.100 --> 26:50.620]  exfiltration happening at odd times from odd places? Would you notice if someone was downloading
[26:50.840 --> 26:56.640]  a bunch of stuff off of a shared drive from their house? Are those sorts of things, the anomalies,
[26:56.640 --> 27:03.540]  the big ones, noticeable? And how do you handle the signal to noise ratio? How do you handle weird
[27:03.540 --> 27:08.620]  DNS traffic? Are you logging for things like PowerShell on workstations that probably don't
[27:08.620 --> 27:14.060]  need to be running PowerShell in the user space? And then how do you slowly but surely build those
[27:14.060 --> 27:19.820]  fundamentals and scale all the way up to more advanced persistent threats, more advanced admin
[27:19.820 --> 27:25.420]  capabilities, more advanced threat actors? And how do you internally build up those defenses
[27:25.420 --> 27:30.760]  over time? So this is one way to think about it from a defensive perspective of trying to catch
[27:30.760 --> 27:36.280]  the most verbose of insider threats or adversaries and then slowly working your way towards the more
[27:36.280 --> 27:47.480]  subtle adversaries. Now on the flip side of that, we have what are the goals for the red team? So
[27:47.480 --> 27:52.940]  the red team for the adversary is starting with crown jewel assets. And I'll actually let Bryson
[27:52.940 --> 27:59.400]  speak to that one because this is a Brysonism if there ever has been one. So if there's ever been
[27:59.400 --> 28:06.740]  I think I have many. I don't know that this one qualifies as special. This grew out of a
[28:06.740 --> 28:13.380]  Twitter discussion I was having around systemic risk yesterday. So for those of you who think
[28:13.380 --> 28:18.880]  that it's just unicorn and cooking picks, I also will occasionally lead what's sometimes fast for
[28:18.880 --> 28:23.820]  intellectual discussions on different aspects of InfoSec. Because I don't think I know everything,
[28:23.820 --> 28:30.580]  I think combined we all know a lot. So somebody in particular talked about crown jewels and the
[28:30.580 --> 28:35.640]  idea was talking around the fact that assets have different value, just like users have different
[28:35.640 --> 28:42.280]  value. There are different qualities of assets and insider threats based on that user and those
[28:42.280 --> 28:49.740]  assets and their access to those assets combined. And so we do not have unlimited resources. Nobody
[28:49.740 --> 28:55.120]  here has a limited time, people, or money to do everything that they want to do. And so the key is
[28:55.120 --> 29:00.820]  figuring out, well, what matters to the business? What are the critical things, the crown jewels, in
[29:00.820 --> 29:07.900]  the organization? And prioritizing those when we're looking at our assessments and emulations.
[29:08.740 --> 29:13.300]  And the simple metaphor that I use to describe this, which I'll pivot off of crown jewels, is
[29:13.300 --> 29:17.820]  you're circling the wagons around the campfire. You can imagine that you're on the Oregon Trail,
[29:17.820 --> 29:22.600]  only a few of your party have died of dysentery, camp down for the night, eating your squirrel meat
[29:22.600 --> 29:27.020]  that you hunted during the day, and you circle the wagons around that part of the organization
[29:27.020 --> 29:32.500]  that you know for sure you have some level of positive control about. The rest of the organization
[29:33.120 --> 29:41.880]  is on fire, pillaged by the wasteland. You start with what you can control effectively
[29:41.880 --> 29:47.300]  and then you slowly grow out from there in increasing priority with the context of the
[29:47.300 --> 29:56.680]  business. That's behind my crown jewels assets CJA Brysonism. That's perfect. And what we've
[29:56.680 --> 30:01.120]  seen from an industry perspective is that boards and executives are very comfortable with that idea
[30:01.120 --> 30:05.900]  of identifying the crown jewels and it's scaling out accordingly. Because there are things that
[30:05.900 --> 30:10.780]  the entire organization can absolutely agree on as being the most critical assets. And identifying
[30:10.780 --> 30:15.240]  those both from a technical and from an organization perspective is really important,
[30:15.240 --> 30:19.640]  as it turns out. And then moving with that from an operational perspective,
[30:19.640 --> 30:25.560]  creating reproducible scenarios to make sure that the defenses around those things are valid and
[30:25.560 --> 30:31.000]  they continue to be valid over and over and over again over time. And then taking that a step
[30:31.000 --> 30:35.820]  further, decoupling the techniques at the high level that you might be trying to execute on
[30:35.820 --> 30:40.920]  from its actual literal execution. Again, going back to the MITRE ATT&CK thing. Well, there's a
[30:40.920 --> 30:45.500]  ton of different ways to perform any individual technique. And keeping that in mind that you're
[30:45.500 --> 30:50.220]  not just coded to, oh, we block this one command and therefore we're good to go. You have to think
[30:50.220 --> 30:54.600]  of it iteratively. You have to think about it as an adversary growing over time and changing the
[30:54.600 --> 31:01.220]  way they execute these actions. And so don't ever hesitate to not only change the way you do things,
[31:01.220 --> 31:06.360]  but also use some of the same stuff that an internal adversary would. Maybe it's you're
[31:06.360 --> 31:10.900]  doing the slightly motivated attacker and you're just exfiltrating over a VPN that you downloaded.
[31:10.920 --> 31:15.920]  Or maybe you want to do something where you write a little bit of custom or download a little bit of
[31:15.920 --> 31:21.140]  something that's Google-able, right? Those sorts of things are absolutely in scope and they don't
[31:21.140 --> 31:26.260]  require Kali or Metasploit or any of these things. Because again, the slightly motivated insider
[31:26.260 --> 31:32.900]  threat actor probably doesn't know how to spin up a Kali USB bootable stick, right? So thinking
[31:32.900 --> 31:37.760]  about yourself in their shoes and the tools that they've got access to can create for some really
[31:37.760 --> 31:44.500]  interesting scenarios. Just picture Elon Musk on Joe Rogan.
[31:45.700 --> 31:49.280]  Just keep that in your mind as you're doing your threat actor analysis.
[31:50.780 --> 31:57.360]  So we would be remiss if we didn't bring this up in a red team, blue team analysis monitoring
[31:57.360 --> 32:02.340]  conversation. And we just want to make a quick note about AI and machine learning specifically
[32:02.340 --> 32:08.720]  for blue teams. There's a lot of things that are pitched as like AI machine learning,
[32:08.720 --> 32:17.800]  user behavior monitoring, adversary analysis stuff. Just be careful and remember that
[32:18.500 --> 32:24.420]  there's a reason most adversaries don't need to have AI and machine learning in their malware.
[32:24.420 --> 32:30.160]  It's because like their goals are pretty set. They know what they want to do and they don't
[32:30.160 --> 32:36.680]  need to have polymorphic logic about trying to create ransomware, right? Like it's pretty
[32:36.680 --> 32:42.820]  solid about what it wants to do. And so just remembering that their goals tend to be pretty
[32:42.820 --> 32:48.020]  explicit going back to those crown jewels. So you don't need a polymorphic circle of wagons
[32:48.020 --> 32:53.280]  around your fire necessarily. It's important to keep that simplicity sometimes is valuable,
[32:53.280 --> 32:57.280]  especially if you don't know the scope of what you're trying to monitor or the scope of the
[32:57.280 --> 33:03.540]  problem. And so just be careful when you're rolling out AI and machine learning based defenses
[33:03.540 --> 33:09.280]  and validate your vendor because some of them don't find anomalies correctly and some of them
[33:09.280 --> 33:14.220]  need to be trained. And if you don't know that going into it, you might not have the silver
[33:14.220 --> 33:19.640]  bullet you may have been paying for. And this is one of my favorite quotes, the difference between
[33:19.640 --> 33:24.220]  machine learning and AI. If it's written in Python, it's probably machine learning. If it's
[33:24.220 --> 33:29.220]  written in PowerPoint, it's probably AI. Just keep that in mind when you're hearing vendors say
[33:29.220 --> 33:40.930]  things about these to you. It's just an important perspective. So one other thing that's worth noting,
[33:40.930 --> 33:45.470]  and this was based off of some conversations we've had with experts in network monitoring,
[33:46.990 --> 33:51.370]  beacons as a thing, like the how often malware phones home for its next instruction or
[33:51.370 --> 33:56.950]  exfiltration. This is kind of an interesting use case for thinking of red team versus blue team or
[33:56.950 --> 34:02.410]  working together to train a network monitoring team or what have you. So if a piece of malware
[34:02.410 --> 34:06.750]  beacons home from an endpoint every five seconds, that's easy mode. It's pretty easy to notice that
[34:06.750 --> 34:13.690]  on the wire from a network analysis perspective. Cool. So maybe you add 20 seconds beacons with 25%
[34:13.690 --> 34:18.530]  randomization on that. Well, okay, now it's getting a little harder, but usually a team can identify
[34:18.530 --> 34:24.950]  that. Then when you say, well, what about a five minute beacon with 75% randomization on that? Well,
[34:24.950 --> 34:28.850]  it gets a little trickier, but it's still inside of scope for most network monitors.
[34:29.030 --> 34:35.190]  But there is this kind of belief that once you hit the 30 minute mark, well, threat actors don't want
[34:35.190 --> 34:39.670]  to have phone home every 30 minutes. That's impractical for them. So it's probably out of
[34:39.670 --> 34:43.850]  scope for most network monitors. This is what we're talking about when we talk about scaling up
[34:43.850 --> 34:50.030]  the fundamentals towards more advanced persistent threats, because beaconing home every 30 minutes
[34:50.030 --> 34:54.970]  is, that's an easy one. When if you're thinking about a real advanced persistent threat, whose
[34:54.970 --> 35:02.130]  engagement is not designed to last a week, it's designed to last years in total. And so,
[35:02.130 --> 35:09.050]  you know, thinking about it as, oh, well, we trained our data set based on known traffic. Well, if this
[35:09.050 --> 35:14.270]  user has been exfiltrating a gig of data to Dropbox every night for as long as you've been
[35:14.270 --> 35:20.270]  monitoring the network, like, don't just assume that that's not an anomaly, because that threat
[35:20.270 --> 35:24.650]  actor might have been there for a long time. And if they're slightly motivated, like they might not
[35:24.650 --> 35:29.750]  know how to write an automation framework, but they could probably Google how cron works or
[35:29.750 --> 35:34.930]  services work and how to, you know, dump a copy of something to Dropbox every night.
[35:34.930 --> 35:43.780]  So just a quick note on adversary testing there. All right, to summarize,
[35:45.340 --> 35:50.220]  employees are the best hackers. And this is another, thank you, Bryce. And this is a great
[35:50.220 --> 35:58.060]  line, because they will work hard to achieve their goals. And even if they won't work hard,
[35:58.060 --> 36:01.360]  they are slightly motivated to achieve their goals. And they're willing to try different
[36:01.360 --> 36:08.820]  things to circumvent. So keeping that in mind, the red team should run scenarios as if they are
[36:08.820 --> 36:12.960]  those slightly motivated attackers that have access to consumer grade tools that are very
[36:12.960 --> 36:18.780]  good for things like exfiltration. And the red team is there to help design repeatable adversary
[36:18.780 --> 36:23.760]  testing to help test the blue. The blue team should be working on baselines and shoring up
[36:23.760 --> 36:28.100]  the fundamentals and learning network norms and understanding the standard of traffic,
[36:28.100 --> 36:32.300]  which creates those purple team engagements. After you've identified the baseline together,
[36:32.300 --> 36:38.600]  you can then validate that those baselines are being held and continue to shore up more and more
[36:38.600 --> 36:44.440]  of the organization or better define these things as you move forward so that you can start to scale
[36:44.440 --> 36:53.680]  up to the advanced threat actor beyond the slightly motivated. And yeah, Bryson, do you
[36:53.680 --> 37:00.100]  have anything else before we wrap up? That's pretty much it. No, I look forward to a robust Q&A.
[37:00.820 --> 37:05.340]  Awesome. Thank you, everyone, for your time. There's some notes there about some of the sources
[37:05.340 --> 37:11.040]  we used, and we look forward to having discussions wherever those discussions maybe happen,
[37:11.040 --> 37:14.660]  whether it's in the DEF CON Discord or otherwise. Thanks, everyone.