at the golden age of Insider Threats. I'm Adam Macinci, that's Bryson Bort. We'll introduce
ourselves again here in a second. And just before we get started on anything else, yes,
it is known to be misspelled kind of intentionally because it's you are the adversary within
because it's about Insider Threats. It's a joke.
We're paid to hack things, not tell jokes.
Not tell jokes. It's not great. Anyway, real quick, who am I? I'm Adam Macinci. I do all
sorts of stuff. I volunteer and speak with the Red Team Village. I do their one-on-one
track. I'm a member of the C2 Matrix. I'm the head of product management at Scythe.
I've got a background in enterprise solutions and crypto and privacy and whatever. That's
me. And also here's Bryson.
Ash said a lot of words. He's our token Californian. I founded Grimm eight years ago to build the
best team of hackers because this is no longer an individual sport. It's a team sport. Defenses
have gotten really good. About two years ago, I spun out Scythe. That's my full-time
job for an adversary emulation platform where I work with MASH. And then I'm a co-founder
of the ICS Village non-profit. So hopefully you have a chance here at DEF CON to also
check out the ICS Village.
All right. And so what we'll be talking about today is a bunch of things, not only Insider
Threats, but also the value of post-exploitation and why that's important philosophically.
And we'll talk about defense validation through threat emulation and why focusing on endpoints
from a red team and from a blue team and from a purple team perspective is important. And
obviously, Insider Threats and why their lives are a little easier than most folks when it
comes to being adversaries and why boards and leadership cares and why defenders are
overwhelmed.
And then we'll talk about the cycle of red and blue working together towards purple teaming
and why this is all relevant from an Insider Threat perspective.
So first off, let's talk about the value of post-exploitation. And this is kind of a bit
of a philosophical argument for us, but we generally have the following three principles
that we as the InfoSec community just feel to be true. So one, it's not if, but when.
So everybody has the potential to be compromised and it will inevitably happen. Every organization
has the ability to be compromised. Two, there will always be zero days. There will always
be end days. There will always be bugs in software, which creates a new exploit and
that will always be the case. And then finally, social engineering and Insider Threats, to
whatever degree you want to count that, will always work. There's always someone who will
click the email link. There will always be someone who plugs in the thumb drive. That
is inevitable and there's a lot of reasons for that.
So if we believe those principles to be true, then kind of philosophically, post-exploitation
behaviors from an adversary's perspective is more important than the exploit itself.
It doesn't matter all the CVEs that we use to get in. It's what the adversary does once
they are in. That's the thing that's more important philosophically.
There's also two layers to this. So if you think about this simply, we're talking about
access. Access, typically, people think of the antiquated way of, I have a perimeter
and a third party has gained unauthorized access. And that is part of it. And so what
you can summarize this is, is the ability to gain access is across an infinite scope
of possibility because it's not just technical. It is a question of people and technology.
The second part of access is there's also access within the organization. So once I've
breached the perimeter, once I've compromised, then I'm still working the access problem
in an iterative way as I try to work from where I am to where I want to go. And each
one of those steps starts with that access problem, which again, can be solved through
technical or social means.
And this is all particularly pertinent when we're talking about it from a red team perspective.
So for example, if we take a red team are performing an adversary test and we take the
following two scenarios. So in the first scenario, they take a custom binary that they've made
and they detonated on an endpoint during this engagement. Well, they've been caught and
that's been burned. So that's a valid test of a security control that an unsigned piece
of malware was able to be caught. That's a good thing. But an equally valid test from
a red team perspective is creating that same custom piece of malware and then putting it
in an allow list for that specific binary and then having it go through and not be caught
and letting the behavior run after the fact. These are equally valid tests because in the
first one, you validated the security control of do you block unsigned things that are potentially
malicious, but in the latter, you're running an O day or an N day scenario as if that thing
was able to work its way into being allowed and then fire its behavior after the fact.
So it's important to point that out that these are equally valid tests from a red team perspective.
So the other part here is we're validating our assumptions. I can't tell you how many
conversations I've had with folks where we go in and they're like, oh, you know,
we're paying this amount of money for this and we know it does this. Well, how do you know?
Try it. Check it. Once you do that, you're building up that arsenal of validating those
assumptions and keeping it going. Another way to look at this is it's like being
an APT on the cheap. By proving the control works and then using configuration like allow list to
allow something to go past control, that's the equivalent of a technical compromise like what
an APT can do, right? We assume that they can do that. It's a question of if, not when. And
by doing that allow list, you just, for free, with little effort, achieve the same goal as what that
APT can. So with all that in mind, let's talk about insider threats and what's specific to
them when we talk about insider threats from a red team perspective. And specifically, let's talk
about today's endpoints. So for the sake of this conversation, an endpoint is something that a
user interacts with. So it's not like a web app or a web server or something like that or an S3
bucket. This is something that figures on keyboard, somebody's actually utilizing. And the reason
we're focusing on this, especially from an insider threat perspective, is not only is this most
likely what the user will be interacting with as an insider threat, but also this is where we see
the majority of organizations compromised from. This is the phishing links and everything according
to there. And ultimately, you know, all these systems are in place to try to protect users
from all sorts of malicious stuff and patches are important and all these things are true.
However, humans are difficult to secure. People are curious, they're willing to give out their
password for a candy bar. Phishing is something that's really difficult to get rid of entirely.
People plug USB drives into stuff all the time because of curiosity. And then taking it a step
further, as an organization, you probably have all sorts of third parties and all sorts of vendors
whose technology you're utilizing. And when they come on site, how do you make sure that the
security controls that you have for your staff apply to them? And this is a very difficult problem
to solve, as it turns out. So with this all said, we're down to these couple of points from an
endpoint perspective, which is endpoint usage is really difficult to monitor. And it's particularly
difficult to emulate. And to reiterate here, humans are random, they do all sorts of random
things. And figuring out how to monitor for theoretically random behavior, even though
that humans have trends, it can be very difficult to do. And then it's also tricky to emulate a
perfect user in that way, because people do random stuff all the time. And they, especially when
they're interacting heavily with a laptop, say, well, you can't always reliably and predictably
say what a given user may or may not be browsing to. So it's just those are important to remember
as we move forward. And to preface this upcoming slide, we love privacy and security and encryption,
these are all good things that we believe in philosophically. But it becomes a little
tricky when we talk about securing and specifically monitoring end users. So this has created a world
because of the usability of encryption and privacy and all these pieces of technology,
where it's kind of the best time ever to be an insider threat actor, they have a lot of
capabilities at your disposal. And so just to call out a few, let's look at Firefox's scent,
which is unfortunately been taken offline, because it was being used maliciously, of course. But for
a long time, like almost a year, we had the ability for a high reputation domain that allowed
end to end encrypted exfiltration and delivery of arbitrary things in another networks. Now,
this is a great user privacy tool. But consequently, it was also be used to like deploy malware. And
that's why it's now offline. And the same is true for all sorts of VPN technology, whether it's
cloud flares, 1.1.1.1 plus warp, this is just instant VPN, DNS security at the consumer level.
And these are things that we now like bring your own devices one clearly. And so everybody has
these abilities running in the user space on their own devices. And it just allows for a lot of
exfiltration events outside of an organization. So like MDMs have essentially lost, there is no
real enterprise mobility solution. And then you pair all of these consumer technologies with the
fact that enterprises are just using more cloud based technology. Well, that's instant high
reputation exfiltration right there. So whether it's legitimate cloud use of Google Apps, or
being able to use things like Dropbox, or what have you to steal data out, like who's going to
block Google Drive in an enterprise that uses Google Drive, this is just opening up all these
doors for insider threats to steal stuff out of a network. And of course, we now have the elephant
in the room. In the pandemic era, 60% of all workers are remote. So you no longer have to
worry about the challenge of how do I physically remove assets into a safe location because
your safe location is already at home. So we now have, this is where we've seen a lot of
enterprises moving to the cloud because it's a bandaid for security. Certainly VPN usage has
bumped up because well, at least I can encrypt the corporate asset in the home environment to
the corporate environment. And what I would offer just for some little extra free advice
is think of the using least privilege in these circumstances, have them log into a essentially
a demilitarized zone of minimum privilege access, and then they validate out of that to go further
into the infrastructure. So offering those kinds of things slow them down. The other challenge we
have here is around testing this. We are now talking about a mixed environment where it's no
longer just corporate assets. We now have corporate assets in a private asset environment, right? Who
owns that router? Who owns those other devices on that network? Those are the employees' personal
devices and it makes it difficult to bring that in scope for a test. And this also ties
into the challenge, of course, back in the old days where we did have BYOD where a lot of folks
didn't necessarily have policies around that. And being able to identify IoT traffic and specific
device fingerprinting is a very challenging problem. And that really leads us to the fact that
although trust is critical, and we can't emphasize this enough, it's not only critical,
but it's arguably more critical than ever. Because monitoring solutions, there's a whole
suite of offerings in a pre-COVID-19 era. But now that everyone's at home, monitoring is an even
trickier solution to try to implement when you have all these deployed endpoints in all sorts
of different places. And so trusting your employees is critical because there's fewer
and fewer ways to modify the things that you're doing and monitor always explicitly. And to all
the things that Bryson just said, it's about restricting access now, not so much monitoring
for every keystroke or every bit of browsing bit that goes on. And so we think about allow
requirements, we think about how folks can circumvent blocks and all of these things,
where we're now having to play whack-a-mole with all of the possible consumer solutions as well
that come from legitimate providers and legitimate domains. This is very, very tricky. And so
one of the ways I think about it is, it's not even so much like how do you prevent,
or how do you emulate the APT or the highly motivated adversary? Instead, I think of it as
how do you even prevent exfiltration from a slightly motivated adversary? Someone who doesn't
necessarily know how to roll their own crypto, but they can download a VPN app on their device
and turn it on. They have a motivation, they're just not highly motivated. And so that's where
we get this idea of the slightly motivated adversary. And what to do about that scenario
can be very, very tricky. So with all that about insider threats wrapped up, how do we think about
all this from a red team perspective? Well, the good news, I mean, good news for the red team,
maybe not so much for the blue. The red team can use all these principles and philosophical
paradigms that we're in to create adversary scenarios that use all the advantages of these
things. So this is things running in the user space, things running at runtime, no exploitation
required, because if you're simulating an insider threat, well, they probably have the ability to
double click something on their endpoint. And they're not necessarily doing so because they
were tricked into doing it, they did it because they wanted to, and they're willing to kind of
take a couple steps in order to achieve that goal. So now for the red teamer who's creating a campaign,
they could do what the malware authors do, where they design things around, well, what are the
capability of a slightly motivated adversary, so they can run in the user space, they've got access
to valuable data, like, you know, their documents folder is probably important, there's probably some
PII set more on that drive. Well, they also have access to those things and publicly accessible
exfiltration tools, Pastebin. How many organizations have Pastebin allowed? Like, that's an
exfiltration tool from a slightly motivated attacker perspective. And not only that, the red
team also has on top of those capabilities, knowledge of ODAs and NDAs, knowledge about how
to automate these things, deploy infrastructures to do more advanced exfiltration techniques,
they know how to obfuscate, they know how to be more anonymous. So you ratchet these things
together and you think, what do you get for free by pretending to be an internal adversary? And
then you put on top of that all the stuff you could do as a red teamer. Well, that creates a
very exciting scenario from a red team adversary perspective. Talking about Pastebin and
executing in user space, check out the Blue Team Choose Your Own Adventure. We did a short
Choose Your Own Adventure that involves ransomware that takes advantage of those.
Yeah, that's an excellent point in and of itself. If we think about modern ransomware,
you don't need to run as admin to do modern ransomware, like end users can create and
delete files. They have permissions to do that. And ransomware says, great, I want to create and
delete files, right? That's the point. It's all these things are in the user space, and you just
get them for free, thinking of as an adversary does. So now that we know all the advantages,
what can the red and blue teams do about it? Because the slightly motivated adversary is
very, very powerful, and they have the ability to both accidentally and intentionally compromise
endpoints. And given that the blue team now has to think about everything from a disgruntled
staffer to an APT, well, that's a pretty big scope. Actually, I don't... Bryson, I don't know if I fully
get your Joe Rogan, Elon Musk image on this one. Yeah, so what I was going for here was
you got a picture of Elon Musk as the disgruntled staffer, and he's sitting there at home.
I was employee 53. They don't take me seriously enough. They don't respect me,
and I'm gonna quit. I'm gonna burn this place to the ground, and this is him taking his red
stapler on the way out while it burns. Fair enough. There's your disgruntled role play.
Yeah, that's good. I mean, defining Elon Musk as a staffer might be a bit of a stretch,
but the analogy certainly plays. But given that that is inside a threat model for a blue team,
that can be incredibly tricky, right? And so what do we do with all this? Well, an answer to this
is shoring up the fundamentals. So it's not so much like would you detect a foreign country inside
your organization slowly beaconing little documents over the course of years over DNS,
but thinking about, well, would you notice standard exfil if someone started dumping gigs
of data out in the middle of the night? These sorts of fundamentals are really important.
And thinking about validating the controls and validating those tests in a repeatable way via
adversary testing, this is that red and blue team working together. So real quick, before we dive
deeper on that, I do want to make a quick note about the vendor industry on this one, which is
a little awkward. So if we think about breach and attack simulation as a thing, so that is a
Gartnerism that is way overly broad, and it can mean a wide variety of things. But generally speaking,
we think of it as kind of spectrum. And on one end of the spectrum, we have controls validation
tools. So these are agent-based things that repeat known signature actors and traffic in these sorts
of PCAP replays and what have you. And then on the other end of the spectrum is more advanced
adversarial testing. And there's a whole simulation versus emulation argument that we could talk
about. And these are the kinds of tools on the other side that the red teams in Pentesters use.
And there's all these sorts of other things we could talk about, like how they align to
MITRE ATT&CK and why that's important. But for the most part, all of these things inside of the
spectrum do satisfy this idea of assumed compromise and assumed breach scenarios, regardless of
whether or not you're compiling something via MS Venom and Metasploit, or whether you're using
a breach and attack simulation tool. You could use both of these things in an assumed
compromised way. And that's worth noting about this whole spectrum of tools. I mean, the only
thing I'd jump on here is where I throw out that MITRE ATT&CK is not a bingo card.
What I mean by that is what MITRE ATT&CK is a great compendium of understanding all of the
correction, a lot of the elements, because it may never be complete, of a common vernacular for us
to describe attacks. You can't use it as a checkboard. You're like, I have successfully
made sure that this can never happen. T1033 will never happen. That's the wrong way to look at it.
And part of that is because I like to describe it as a periodic table. And the attacks in it
are different elements. And the way and the order that those elements are combined is a
chemical equation. And whether you get lead or gold depends on that order. And so the point
being is that a static look of particular elements without understanding the context that they're in
changes what that means. My ability to do lateral movement is going to be affected by
whether or not I have credentials or not, for example. Simple example.
And when we think about these sorts of chemical elements like Bryce is describing,
and these sorts of things are accidentally using it as a bingo card, well, this can be
exceptionally tempting when we're talking about something like a controls validation solution,
where it's automatically testing whether or not you can send data to something that's known as
evildomain.com over these firewall ports and all these sorts of things. Well, you can define
these rules in the controls validation tool and have it automatically test those things over and
over and over again and let you know if your configuration management's falling over and
that sort of thing, which is all very valuable. But it is tempting to just say, oh, we're tagging,
we're looking for that port for exfiltration, we're done with that MITRE ATT&CK ID. And again,
it's important to note that these controls validation tools are very static. They're
agent-based, they're signature-based. And kind of most important from our perspective,
we're talking about internal adversaries and insider threats. These aren't production endpoints
that these things are installed on. These things aren't simulating users or internal threat actors,
necessarily. They're just doing, here's some analysis from the threat intel community,
fire for effect, here's a PCAP. So it's not exactly what we're talking about here from
an insider threat emulation perspective. Just to kind of finish that off, there's no people in the
loop on this one, right? It's about automating these solutions and detecting these sorts of
things. And so it is repeatable, and it is easy to implement these controls validation tools.
But ultimately, they're not really something that the red team is going to utilize.
And they're more about unit testing than adversary behavior. And often these are unfortunately at
the mercy of the vendor, because the vendor is the thing that's pulling down the threat intel.
It says, these are all the tests you can run, you might have very limited ability to change them a
bit, but it's not a customizable tool. So that's a concern when we're thinking about controls
validation from an insider threat perspective. The only thing I'll add there is what's at the
top is that people are not in the loop. And what we mean by that is that these are great detection
engineering tools, but you're not including the user affecting the behavior around looking at
what those technical controls do or don't do. And then the second part is you're not able to
measure the response, because it's a set stage for what your sock is looking at.
But I think it was also a bit glossed over on what the pros here with change control,
your ability to know what you're always going to see and building that library out.
We take it for granted that things work the way that they're supposed to work,
and that our challenge is finding attackers in that noise. There is also the challenge that
tools break, configurations drift, things stop working for various reasons. And so knowing for
sure what I'm looking for, be able to identify that is a significant value proposition.
And so with all that in mind from a controls validation benefit, like cost benefit evaluation,
let's look at the other kinds of tooling that we mentioned, which is adversary testing or
adversarial testing. And so again, for the sake of this discussion, an adversarial test is more
about behavior. And we've been talking about post exploitation behavior specifically,
whereas a pen test is often focused on those exploitations. So here, it's about a red team
creating a scenario where they can validate and see what the network defenders would notice. So
will they notice exfiltration? Will they notice lateral movement? Will they notice if I increase
my beacon heartbeats or the randomization of those heartbeats, that sort of thing. And this allows
the red team or third party pen test or red teaming firm to test these things and to see if
they can get an initial foothold and see what the remediation time on that looks like. And they can
also define whatever artifacts they may choose to leave. So you could say, well, we think that in
this kind of threat scenario, someone may want to... the adversary would drop this folder, or they would
they try to create this key and leave that on an endpoint. Those can be predefined with an
adversary test. And so moving a little further down that rabbit hole, these things are highly
customizable, which can be a good and a bad thing. The more time a red team takes to create them,
the more difficult it can be to replicate them. And especially when it comes to the idea of a blue
team might want to remediate this thing and then test it again. Well, the more complex it was to
create it, the more difficult it is to test it and validate it again. So although there's a lot
of flexibility from creating these sorts of engagements that are very red team adversarial
focused, they are fairly technical, there's a high learning curve, and they tend to be more expensive.
And then finally, one of the cons for them is that they are very limited snapshot in time.
So for example, if a red team comes in and performs a high criticality test and nobody notices,
the blue team could come back and say, oh, well, we didn't notice that because the person who would
have noticed it was out on vacation. Can you come back and do it again? But if the level of effort
for doing it again is significant, you have a bit of a problem now. So with all that said, let's talk
about the goals for a blue team, not only from a red team, blue team perspective, but also what
we're thinking about insider threat actors. What are the goals? Well, the initial goal should be,
do you notice network anomalies, those baselines again? Would you notice if there's weird
exfiltration happening at odd times from odd places? Would you notice if someone was downloading
a bunch of stuff off of a shared drive from their house? Are those sorts of things, the anomalies,
the big ones, noticeable? And how do you handle the signal to noise ratio? How do you handle weird
DNS traffic? Are you logging for things like PowerShell on workstations that probably don't
need to be running PowerShell in the user space? And then how do you slowly but surely build those
fundamentals and scale all the way up to more advanced persistent threats, more advanced admin
capabilities, more advanced threat actors? And how do you internally build up those defenses
over time? So this is one way to think about it from a defensive perspective of trying to catch
the most verbose of insider threats or adversaries and then slowly working your way towards the more
subtle adversaries. Now on the flip side of that, we have what are the goals for the red team? So
the red team for the adversary is starting with crown jewel assets. And I'll actually let Bryson
speak to that one because this is a Brysonism if there ever has been one. So if there's ever been
I think I have many. I don't know that this one qualifies as special. This grew out of a
Twitter discussion I was having around systemic risk yesterday. So for those of you who think
that it's just unicorn and cooking picks, I also will occasionally lead what's sometimes fast for
intellectual discussions on different aspects of InfoSec. Because I don't think I know everything,
I think combined we all know a lot. So somebody in particular talked about crown jewels and the
idea was talking around the fact that assets have different value, just like users have different
value. There are different qualities of assets and insider threats based on that user and those
assets and their access to those assets combined. And so we do not have unlimited resources. Nobody
here has a limited time, people, or money to do everything that they want to do. And so the key is
figuring out, well, what matters to the business? What are the critical things, the crown jewels, in
the organization? And prioritizing those when we're looking at our assessments and emulations.
And the simple metaphor that I use to describe this, which I'll pivot off of crown jewels, is
you're circling the wagons around the campfire. You can imagine that you're on the Oregon Trail,
only a few of your party have died of dysentery, camp down for the night, eating your squirrel meat
that you hunted during the day, and you circle the wagons around that part of the organization
that you know for sure you have some level of positive control about. The rest of the organization
is on fire, pillaged by the wasteland. You start with what you can control effectively
and then you slowly grow out from there in increasing priority with the context of the
business. That's behind my crown jewels assets CJA Brysonism. That's perfect. And what we've
seen from an industry perspective is that boards and executives are very comfortable with that idea
of identifying the crown jewels and it's scaling out accordingly. Because there are things that
the entire organization can absolutely agree on as being the most critical assets. And identifying
those both from a technical and from an organization perspective is really important,
as it turns out. And then moving with that from an operational perspective,
creating reproducible scenarios to make sure that the defenses around those things are valid and
they continue to be valid over and over and over again over time. And then taking that a step
further, decoupling the techniques at the high level that you might be trying to execute on
from its actual literal execution. Again, going back to the MITRE ATT&CK thing. Well, there's a
ton of different ways to perform any individual technique. And keeping that in mind that you're
not just coded to, oh, we block this one command and therefore we're good to go. You have to think
of it iteratively. You have to think about it as an adversary growing over time and changing the
way they execute these actions. And so don't ever hesitate to not only change the way you do things,
but also use some of the same stuff that an internal adversary would. Maybe it's you're
doing the slightly motivated attacker and you're just exfiltrating over a VPN that you downloaded.
Or maybe you want to do something where you write a little bit of custom or download a little bit of
something that's Google-able, right? Those sorts of things are absolutely in scope and they don't
require Kali or Metasploit or any of these things. Because again, the slightly motivated insider
threat actor probably doesn't know how to spin up a Kali USB bootable stick, right? So thinking
about yourself in their shoes and the tools that they've got access to can create for some really
interesting scenarios. Just picture Elon Musk on Joe Rogan.
Just keep that in your mind as you're doing your threat actor analysis.
So we would be remiss if we didn't bring this up in a red team, blue team analysis monitoring
conversation. And we just want to make a quick note about AI and machine learning specifically
for blue teams. There's a lot of things that are pitched as like AI machine learning,
user behavior monitoring, adversary analysis stuff. Just be careful and remember that
there's a reason most adversaries don't need to have AI and machine learning in their malware.
It's because like their goals are pretty set. They know what they want to do and they don't
need to have polymorphic logic about trying to create ransomware, right? Like it's pretty
solid about what it wants to do. And so just remembering that their goals tend to be pretty
explicit going back to those crown jewels. So you don't need a polymorphic circle of wagons
around your fire necessarily. It's important to keep that simplicity sometimes is valuable,
especially if you don't know the scope of what you're trying to monitor or the scope of the
problem. And so just be careful when you're rolling out AI and machine learning based defenses
and validate your vendor because some of them don't find anomalies correctly and some of them
need to be trained. And if you don't know that going into it, you might not have the silver
bullet you may have been paying for. And this is one of my favorite quotes, the difference between
machine learning and AI. If it's written in Python, it's probably machine learning. If it's
written in PowerPoint, it's probably AI. Just keep that in mind when you're hearing vendors say
things about these to you. It's just an important perspective. So one other thing that's worth noting,
and this was based off of some conversations we've had with experts in network monitoring,
beacons as a thing, like the how often malware phones home for its next instruction or
exfiltration. This is kind of an interesting use case for thinking of red team versus blue team or
working together to train a network monitoring team or what have you. So if a piece of malware
beacons home from an endpoint every five seconds, that's easy mode. It's pretty easy to notice that
on the wire from a network analysis perspective. Cool. So maybe you add 20 seconds beacons with 25%
randomization on that. Well, okay, now it's getting a little harder, but usually a team can identify
that. Then when you say, well, what about a five minute beacon with 75% randomization on that? Well,
it gets a little trickier, but it's still inside of scope for most network monitors.
But there is this kind of belief that once you hit the 30 minute mark, well, threat actors don't want
to have phone home every 30 minutes. That's impractical for them. So it's probably out of
scope for most network monitors. This is what we're talking about when we talk about scaling up
the fundamentals towards more advanced persistent threats, because beaconing home every 30 minutes
is, that's an easy one. When if you're thinking about a real advanced persistent threat, whose
engagement is not designed to last a week, it's designed to last years in total. And so,
you know, thinking about it as, oh, well, we trained our data set based on known traffic. Well, if this
user has been exfiltrating a gig of data to Dropbox every night for as long as you've been
monitoring the network, like, don't just assume that that's not an anomaly, because that threat
actor might have been there for a long time. And if they're slightly motivated, like they might not
know how to write an automation framework, but they could probably Google how cron works or
services work and how to, you know, dump a copy of something to Dropbox every night.
So just a quick note on adversary testing there. All right, to summarize,
employees are the best hackers. And this is another, thank you, Bryce. And this is a great
line, because they will work hard to achieve their goals. And even if they won't work hard,
they are slightly motivated to achieve their goals. And they're willing to try different
things to circumvent. So keeping that in mind, the red team should run scenarios as if they are
those slightly motivated attackers that have access to consumer grade tools that are very
good for things like exfiltration. And the red team is there to help design repeatable adversary
testing to help test the blue. The blue team should be working on baselines and shoring up
the fundamentals and learning network norms and understanding the standard of traffic,
which creates those purple team engagements. After you've identified the baseline together,
you can then validate that those baselines are being held and continue to shore up more and more
of the organization or better define these things as you move forward so that you can start to scale
up to the advanced threat actor beyond the slightly motivated. And yeah, Bryson, do you
have anything else before we wrap up? That's pretty much it. No, I look forward to a robust Q&A.
Awesome. Thank you, everyone, for your time. There's some notes there about some of the sources
we used, and we look forward to having discussions wherever those discussions maybe happen,
whether it's in the DEF CON Discord or otherwise. Thanks, everyone.