Presenter: Adam Mashinchi, Director, Open Source Programs, Red Canary

This talk will review Atomic Red Team™, a library of simple, focused tests mapped to the MITRE ATT&CK® matrix. These adversary examples come with easy-to-use configuration and cleanup commands. Attendees will receive practical guidance on how to use and get started with testing, and offer additional resources to further their ability to validate defenses and defenders.

https://www.rsaconference.com/usa

Red Canary does managed detection and response, as we're talking about organizations that, like, what would you say you do here?

And I get to talk about open source stuff and community stuff.

I've got the privilege of talking about things we give away for free and have no revenue goals, which is very exciting for me because I can just do Goodwill stuff and talk to you all about other things.

I don't have to sell you anything, which is pretty fun.

So Red Canaries, I'm very fortunate to work for them, a great company.

Again, we have a big goal of having community outreach.

There's an entire department at Red Canary devoted exclusively to community efforts.

And that's very compelling, alright, because you can just do stuff to try to fill a room full of people and talk about something interesting, and I'm very fortunate to be able to do all that.

So we want to bring great information and projects to the public for free so that folks like you all who are interested in things like open source and red teaming and the like there can just get benefit from it.

And that's the only goal from my perspective.

If some of you go off and see this Atomic Red Team's GitHub repo and we get that view, That's a win in my book.

So, today I'm gonna be talking about, obviously, Atomic Red Team, where adversary emulation and EDR testing meet.

And Atomic Red Team is kind of the flagship product of Red Canary's open source initiative.

We're gonna have a lot of kind of casual conversation today about this stuff, and we'll leave some time for Q&A at the end.

We'll wrap things up early, so if any of You need to get out of here, that's cool, but again, for those of you who want to stick around, this is overflow for the keynote, so you don't even need to leave your seat if you want to watch that here.

Things, educational purposes, don't record me unless we said it was cool.

We will probably not use it all, but who knows.

We might just get talking and it'll be great.

But there's some key takeaways that really I'm going to make sure we try to hammer home in the time we have together.

I want you all to have an entry level understanding of what Atomic Red Team is.

If I haven't done that in a presentation about the thing, I've probably failed you, which would be very, very sad.

But we're going to give you some use cases about red team, blue team, purple team stuff that you'll have as a takeaway.

We'll get some terminology stuff ironed out here, techniques versus tests, and TTPs, and all that language.

We're going to talk about these things called execution frameworks to whatever degree you may or may not care about them, but you'll have an understanding of them.

We're gonna go through what it means to execute an atomic test, and hopefully we'll give you enough information so you can learn more once I'm done.

So You can find out this information for yourself and go look at a bunch of interesting stuff in the event you're like, oh, this sounds cool, tell me more.

For those of you who have not heard of Mitre Attack, How?

How have you not heard of MITRE ATT&CK at this point?

I think every vendor down there was like, and now with MITRE ATT&CK, and you're like, I don't understand how this applies, but neat.

So MITRE, if you've not heard of what MITRE ATT&CK is, MITRE is an organization, they're a company.

They are not for profit, they do a lot of government R&D, MITRE, big company, they do lots of stuff.

But they have this thing they made called ATT&CK.

We're gonna talk more about that, but ATT&CK is this grid of adversary tactics and techniques.

It's a breakdown of things adversaries can do.

So people say like, oh, the MITRE matrix, right?

No, it's not, we can't call it that, because MITRE's a company, ATT&CK is the matrix, And I wanted to make sure we all have the same terminology as we dive in on this sort of thing.

Because it's nomenclature we're going to use a lot.

Then in the context of this conversation, we're going to use the word adversary.

And adversary is the who is performing the malicious actions.

Now this does not necessarily mean, like, proper threat actors, nation states, or anything like that.

This could be a red team, right, in a certain context.

But the adversary is the individuals or organization performing the adversarial action at you as a defender or organization there.

Next up, there's a lot of conversation about TTPs we could have.

We're just gonna break it down into techniques.

So these are the things, how adversaries achieve their tactical goals.

For the sake of this conversation, We're wildly generalizing today, which I hope is fine, but that's what we're going to go with.

So this is the command, the script, the application that is executed to do the technique, the most specific of things.

But this is an Atomic Red Team 101 sort of course.

This slide is intentionally impossible to read.

The point of this is to create an industry standard and common language so that we, both as cyber defenders, red teamers, pen testers, what have you, and executives can all speak to these things the same way.

Credential dumping is an incredibly complex thing to understand if you have no background in this.

It means a lot of things to a lot of different people.

It has implications for CISOs that it may not have for a blue teamer.

But this gives us a methodology by way we can all talk about these things.

And these are all broken down into specific IDs, which is very, very neat, right?

So for example, the way you, the nomenclature you do is T1234, That's a specific technique ID.

There's all sorts of metadata and information tucked into each of these things, but this grid provides us with a mechanism but we can all talk about stuff adversaries are doing, which is kind of neat, that we can all use the same language here.

A friend of mine, Jeff McJunkin, he likes to think of this as like a red team pen tester.

And Jeff refers to this thing as a game of mind sweeper.

So if you're like a red teamer, well you want to achieve some of these tactical goals.

You want to do some of these adversarial things, but you don't know what the blue team and the cyber defenders might be monitoring.

And so any 1 of these things could be a mine that sets off your detection, right?

So there's all sorts of ways to think about this grid.

There's all sorts of analogies you can use.

And that's 1 of the benefits to something like MITRE ATT&CK is that any random person, like me, could stand up in front of you and give you a million analogies about that, and everybody can kind of be on the same page about it, which is very, very cool.

And then under the hood, it's all JSON, parsable, and a great old pun.

So that's the high-level overview of the attack matrix.

Let's break it down just a little bit more.

Example, credential access is a column that is a tactic that adversaries want to, like a goal they want to achieve.

And there's all sorts of ways they can do it.

And so these techniques are broken down further.

You can see here, brute force is a parent technique, but there's sub-techniques that hang off of it, like password guessing, password cracking, password spraying, credential stuffing.

And all of these things are different enough, and they all have different correlations, and they all have different examples, that they've been broken down into sub-techniques.

And so again, this is that common language, right?

These things have technical meanings, these things have implications and metadata associated with them, but now you have the same words that you all can use.

You can color this thing and be like, oh yeah, we are pretty confident that we defend against this 1, but not this 1.

And you can take this little grid and make it red and green, depending on how confident you are in your cyber defense or offense or what have you.

And you can put this down in front of somebody and be like, you know what?

I think I know what password spraying is.

Yeah, I kind of have a vague idea of this thing.

Even a non-technical person can kind of look at this stuff and be like, oh, seems reasonable.

So another example of a tactic discovery here.

Account discovery, This is something adversaries want to do.

Are they doing account discovery in a local environment?

All these things can be broken down and there's this parent-child relationship.

Okay, I've hammered this stuff pretty hard because it's really critical you understand this before we actually talk about Atomic Red Team, the thing you all came to hear about.

Another thumbs up from the back, thank you, appreciate that.

Okay, whew, now the thing you actually came to hear about.

There's a bird in the circle, look at that, That's great.

Atomic red team is a library of simple tests that any security team can execute to test their defenses.

Tests are focused, have few dependencies, and are defined in a structured format that can be used by automation frameworks.

That is the most concise way we've been able to sum up what this thing is.

In the fewest words possible while being as clear as possible.

However, we do know that we're missing some words here and there's lots of implications that you're all gonna immediately start to think of.

I'm not gonna show you any sort of like, and now we're gonna do automated red teaming.

So for those of you who are looking for that, I'm sorry, you can just leave, I guess, if you want to.

But we're talking about a library of examples here.

Now we will talk about how you would execute those things, but Atomic Red Team itself isn't software.

Again, you're all here to hear about open sourcey stuff.

So everything you're about to hear and see is all community driven.

Yes, this thing was created by Red Canary, the company, but the vast majority, by a distinct margin of everything you're about to learn was all community driven, by not Red Canary people.

So it's open source, and it was made by Red Canary, but, who works on this thing?

For those of you who are Googling Atomic Red Team and looking at the GitHub repo, who's actually adding tests to this library thing?

We have an amazing group of community, and contributors, and maintainers, and folks who just commit time to this, whether they get paid to do it or whatever job they're at, or whether they do it in their free time, it's amazing.

So huge shout out to the maintainers and contributors to Atomic Red Team.

I wouldn't be here if it wasn't for all of you.

So thank you to those of you who are around or hearing this or watching this on recording or whatever.

And like I said, most of the contributions to this thing are not done by Red Canary, the corporation.

So, that means a lot of the contributions we get are kind of smaller, iterative changes.

And all these atomic tests that we're about to talk about, they're community-derived, and so sometimes the long-form, the big scoping projects take a little bit more time.

However, all these amazing people I keep referencing, you all could join them.

So shameless plug, we're always looking for new contributors.

But seriously, I'm gonna talk, atomicredteam.io if you wanna learn how to contribute and get a t-shirt and become, it's super easy, you should do that.

Okay, 1 other thing I wanna mention before we actually move on to like, the meat of this thing.

We have intentionally done something in the creation of Atomic Red Team that has consequences, but also makes it super easy to get started with.

I have no doubt that the vast majority of you sitting here could add a test to Atomic Red Team inside of probably 30 minutes to an hour.

However, in making it that easy to do, there are some consequences of that down the road for folks who are using this in very applied, crazy, spooky ways.

We're gonna talk about those in a little bit, but I wanted to mention it now to say, any of you could be contributors, but this might come back to bite us in a little bit, and we're gonna have to think real smart about some stuff.

And I'm gonna talk about that here in a moment.

Okay, Spent a fair bit of time on the slide.

Back in 2017 at DerbyCon, Red Canary came and they did this presentation about blue team keeping tempo with offense.

And it was about how offense is really able to outpace defense when it comes to trying new stuff and weaponizing new stuff and doing more and more interesting things.

And at this point, there was kind of fisticuffs in the industry over telemetry, so defensive telemetry.

What is better to watch, the network that you're on or the endpoints that are on it?

And there was a lot of disagreement about this point, but Red Canary's team said, you know what?

We think endpoints are better to watch holistically.

It's not easier to do, but it's better to do.

And so what the idea was is, well, what if there was this set of unit tests, the way like programmers unit test their code to make sure it works reliably.

What if we could do that for endpoints and telemetry and detection?

Like how cool would that be if there was a library of tests you could just run and be like, hey, do we notice this stuff?

Then we just automatically fire it periodically to make sure our detections are working, to make sure our defenses and defenders are working?

And that was the idea that spawned Atomic Red Team.

So Atomic Red Team, an open source repository, was born.

For those of you who don't know a lot about open source licensing, great.

Just stay away from it if you don't have to think about it.

But the long and the short of it, MIT licensed the TLDR.

Anybody can do whatever they want with this, right?

And it's kind of silly, because if you all were to go back down to that expo booth, and you could find vendors who sell Atomic Red Team as a feature in their software, which is kind of cool from my perspective, because that means this thing has value, and that people have wrapped it in crazy GUIs and made marketing material about it and whatever.

I think this is a good thing, because that means that the platform has value, and it becomes a positive feedback loop.

If some corporation with a lot of money, or huge venture capital or whatever, is using this as a selling point, the likelihood that their staff is going to contribute back upstream is pretty high, which is neat, right?

So that's a good thing from my perspective.

But when this thing was born, the way it was structured is that it was all broken down by operating systems.

So it's like, okay, Windows tests live over here, Mac and Linux tests live over there, and then we'll break it down by the kind of the tactics that are in that, and that was the structure of this thing.

It turns out that was not the best way to do it, and so in April 2018, it all got restructured, and it all got based around, instead of being these onesie twosie scripts that some worked on Windows and some worked on Mac, it all got turned around into these YAML-formatted scripts and configuration files.

And for those of you who don't know, YAML's a common serialization language.

Not as crazy as XML, but it's pretty crazy.

But what's nice about it is it works in this sort of structure where you have lots of people contributing to 1 thing and they need a common format.

You don't have to deal with crazy brackets and indentation like you do with JSON, so it's pretty cool.

But the nice thing about formatting all these tests this way is that you can focus on the techniques and break it down like all the MITRE attack techniques can live in 1 thing, and it doesn't matter what operating system they run on or anything, It's great.

So that's the YAML stuff, which brings us to how it's structured today.

I have a brief interlude I want to do that's about businesses who create open-sourcey stuff.

Red Canary manages like the GitHub repo it lives on, provides support, staffing, t-shirts, stickers, people like me who stand up and wave their arms around for an hour about the thing, financial support to the project.

But I mentioned earlier, the community drives this thing.

Red Canary staff is the distinct minority of contributors to atomic renting, which is very, very cool.

And we have a group of maintainers, and they're the ones who audit everything that go into it.

And I mentioned again, vendors, they just use this thing all the time.

People sell it as a feature, which is very, very cool.

Again, only 1 of these people work for Red Canary, which is pretty neat.

I think we have at least 1 in the room right now, which is very exciting, very embarrassing for them.

But they're assisted to whatever degree they want to be by Red Canary's open source programs team, who act as product managers or project managers and provide, facilitate comms and that sort of thing.

So we're 15 minutes through this thing, and I haven't even talked to you about what it actually does.

I've just mentioned that it's a library of tests.

1 of the fun things about RSA is that a room like this is filled with all sorts of different professionals and students and people who are interested in this stuff of all sorts of different ilk.

And so I don't want to make any assumptions about who you all, what kind of mindset you all think in.

So we're going to break it down into red team, which is cyber offense stuff, blue team, cyber defense stuff, and then purple team, joint exercises between those 2 mentalities.

So we're gonna talk a little bit about this from a high level.

So if you're a red teamer, and you need to do cyber offense for whatever reason.

Maybe you're embedded inside an organization internally and this is your job, maybe you're a penetration testing firm and you've been brought in to do this.

Well, you need to simulate a variety of diverse threat actor behaviors, right?

There's always new threat actors coming out all the time and they do all sorts of wacky stuff and you want to be able to simulate those in your engagements.

Well, cool, how do you model threat actor behavior?

Generally, you read threat intel reports and for those of you who read threat intel reports, you probably know that they run the gamut about how educational they are.

Often, you will find that, you know, Threat Actor ABC has done the following MITRE attack techniques and it was very scary for the customers.

And you're like, cool, give me some examples of like, those techniques and like, the actual commands they use and whatever, and the Thread Intel report goes, no.

And you're like, well, that's less helpful for me because I want to do those things and see if I would notice them and the Thread Intel people say, cool, how much money do you have?

And you're like, Oh, great, thanks for that.

So if you are given nothing but Threat Actor ABC and these Smiter tech techniques, like where do you even get started?

Like how do you even know how to simulate those Smiter tech techniques, where do you go?

Hey, Atomic Red Team can do that for you.

So we're gonna show you that here in a wee bit.

So let's think about it from a blue teamer perspective.

Well, you've probably given some amount of money to 1 of those folks down in the expo hall, and they theoretically are helping protect you, whether it's an endpoint detection firm or an MDR firm or whatever.

Somebody's probably, hopefully, watching your environment for threat actor behavior.

How do you know that they're doing their job?

How do you know that they're awake or the thing is on?

Well, you probably should run some tests to see if their detections are working, if their signatures are working, or behaviors or new examples of behaviors are being monitored, right?

Well, Atomic Red Team can do that for you.

And then if you've got purple teaming, Red Team, Blue Team working together to make an organization safer and a nice cadence, well, you can use ATT&CK and Atomic Red Team as a joint mechanism, right?

You could say, hey, these are the examples we're going to use on Wednesday.

We're going to see if any detections light them up, right?

And you can create that common language between the 2.

It's that 1 mechanism, that 1 library that everybody can use together to think about these sorts of exercises.

We just did like red team, blue team, purple teaming in a single slide, so can I get some subtle nods?

Thumbs up, guys, thumbs up, that's not good.

Okay, let's break down an example of an atomic test.

So, attack ID technique, T1124, is system time discovery.

System time discovery, An adversary may gather the system time and or time zone from a local or remote system.

Threat actors do this for all sorts of reasons.

We don't need to debate the value of this sort of thing.

But The atomic test to just test for this 1 specific threat actor behavior is something like PowerShell get date.

See all RSA Conference transcripts on Youtube

Atomic Red Team: Where Adversary Emulation and EDR Testing Meet