Stop Talking About Threats - Be the Threat

Presenter:

Trey Bilbrey

Transcript:

Good morning HOU.SEC.CON. Let's get warmed up here for session two. Hopefully everyone's caffeinated. Feeling good about the day. If you didn't get one on the way in, Ephram might have a few more belt buckles to hand out. If you're lucky, I'm going to give you a spoiler alert. This will be the last year. This is called two seconds.

So if you want to grab one, if you haven't already, hit him up in the back of the room there. That's all going to come out right after lunch this morning. We have, Trey Bilbrey talking to us here about the topic. Track two. I love the title of it. I'm fascinated to hear the content.

Stop talking about threats. Be the threats. That's very ominous. Trey is the lead for Scythe, specializing in purple team exercises, threat emulation, critical infrastructure, and cyber operations. With 17 years of experience as an educator, network defender, and mentor in cybersecurity. And his former roles include Http Academy Content Developer, the Army Corps of Engineers. Thank you for your service, ICS, Gator Pentesting, and the U.S. Marine Corps Cyber Operations.

He holds a CISSP, a GI exp, a GCP, and our tech certifications. So please join me in welcoming Trey to the podium. Woo. Thank you everybody okay. So as he said I'm not going to talk about a lot of this because he just gave you a nice little intro and bio. Thanks for that. Long story short I am the professional services lead at sites we do a lot in the purple teaming adversary simulation space.

Validation all of that fun stuff. If you haven't heard of us, go check us out on our socials or online. Plenty of cool content. So what are we talking about today? There's a lot of talks, actually. Just listen to a really interesting one talking about Salt, Typhoon, China in general, all typhoon, all these fancy names. Right? We hear about them all the time.

We're getting IOCs and Intel reports and all of these shippers and everything that come to us. But what are we doing with them? How are we validating? Oh, cool. Yeah, I could detect that. We've got alerts that work on that stuff. That's the point of today. We're going to talk through my framework and how you guys could effectively put that information to use and do something with it in your environment to help better your defensive posture overall.

We'll do that by kind of defining what threat emulation is. We'll jump into actually defining a threat, how we're going to collect information on them, putting it together into something useful. Then I'll round this out with some quick tips and resources for you guys. If you haven't noticed already, I tend to move around a lot, so I am going to be walking in and out around you guys.

Hopefully you're not afraid of impromptu questions. Our team is asking you if you can say no. Yeah, that is the worst. Okay, I will do that. But you can. It's not fun. I like to move. All right, so threat simulation 101. Let's kick this off. What are we really talking about here? The long story short is do what the is doing.

How else are you going to validate that? You can detect, alert, block, stop all of that craziness that you see going on. Right. In reality, what we're talking here is like understanding how these attackers operate. So you can understand your defensive posture and the potential gaps in it. We're looking to identify those weaknesses. Right. And the best way to do that is to actually test them.

But what does that really mean? This is a lot more than just a pen test, right? How many of you guys in here are doing some form of pen test? Red team vulnerability assessment quarterly, annually, whatever. Pretty much everybody in the room. Yeah. What are you guys doing with that information that comes back? Anything?

It's usually just another report that's getting filed away on a shelf for future action. Right. That's not the case here. What we're trying to do is leverage the information from this to improve you at that point in time, not somewhere in the near future. We're not throwing just the book at your environment and seeing what sticks. This is a very targeted approach.

We're looking to actually understand how these attackers operate, not just what can Metasploit Pro turn up from helping improve defenses. What we're looking at here is like your security controls validation. We're doing gap analysis. We're trying to actually understand if your SoC can see anything happening. If they do see something, what's their process? Are they triaging it? Is it just another ticket.

They're closing because they say, oh that looks legit. It's fine. Does your team understand your incident response procedures? There's so many different things that come into this process that it can sound very complicated, and it kind of is, but it's much more actionable. It is a very well tailored process for your organization as opposed to a generic pen test.

Yeah. There we go. So with that, let's talk about the recipe to a great campaign. All threat emulations. Got to start off with CTE right. Or Cyberthreat intelligence. We've got to actually read understand pick out pieces and parts from that threat. We're trying to emulate. We've all seen something that looks like this right. You've seen one of these little headlines or articles or threat actor cards before.

This is that big scary noise that a lot of your your senior leaders, your management, maybe your CEO or someone's going to see pop up on Bleeping Computer or CNN tomorrow morning and go, oh man, that's really scary. Are we protected from that? How do you answer those questions? Well, you've got to turn around and do your own little crazy process now, right?

Scramble to find information, validate if you guys have anything in place for it. And actually disseminate that information. We're going to walk through that. The first step here to even being able to do that is understanding yourself as an organization, taking a look in the terminal, so to say, by understanding the information you have. So like what are you holding on to?

Do you control credit card information? All of that data is going to make a difference in who potentially tries to target you. Right. The kind of information you have whether let's say like intellectual property, you're making some really cool piece of technology for the government, or maybe you work and belt buckle making and that's your thing, right? You've got the best belt buckles there are in the state of Texas.

The person targeting you making belt buckles is probably a vastly different threat than that. That's targeting, say, Raytheon or the DoD as a whole, something like that. So you've got to understand your information, but you also need to understand your industry and the regions are operating in. Do you work, like I just said, for the DoD, or maybe you make belt buckles.

Maybe you work in oil and natural gas. All of these are facing very different threats. So you can kind of see where I'm going with this, right? We're starting to narrow our scope by answering each one of these questions. What information do I have? What industry am I in with that industry? What region am I working in working in, let's say oil and gas or say just energy in general in the Midwest of the Americas is a vastly different landscape than the Middle East, right?

Two completely, totally different regions under different controls. Different people care about what's happening there. The Midwest. You're more likely to face what kind of a threat anybody willing to raise a hand, just shout it out. Your say again oil. Yeah. That's who we're talking about. You'd be facing more like hacktivism right. Weather could be an issue for you.

That goes kind of more into air space if we're talking traditional cyber threats. At this point you're thinking more like this is going to be something more political. This is going to be hacktivism. People don't want pipelines running through their backyards or some energy refinement plants like that popping up in their neighborhoods. All of a sudden. Whereas in the Middle East, this might be much more targeted, and offensive operations and threats that are focused on control in that region.

Then lastly, history. A lot of people overlook your organization and the historical threats and incidents you've responded to. When they start thinking about threat emulation and the intelligence they need to collect. The best place to start is on that bookshelf that you've been filing away. All of those reports and incidents and tickets you've triage, and all of the phishing campaigns you've had to respond to in those late night calls.

That is a great place to start. You already understand it. You've already triage it so you know how you responded. Now you can test that response again. Did you learn something as an organization, we take all of this information, roll it up and do something cool with it. But now that we kind of understand who we are as an organization, we've narrowed our scope from there on what we're focusing on.

We can move. Come on now. And to actually finding the good stuff. Well, what do I mean by CTE and the good stuff? We're looking for information, whether that's from public sources, government resources like SES, places like that or your closed sources. Maybe you pay for some Intel feeds, or you're getting all of the crazy new hotness from Microsoft or CrowdStrike or pick your vendor right?

All of those resources are going to help you to be able to build this picture of the threat you're trying to emulate, instead of just wondering about them. This slide here, I'm trying to kind of highlight some resources and things that I tend to use in my process day to day. This is what I do for organizations. I try to understand who they are as an organization, the threats they face.

Then I gather information about those threats and craft it into something cool and actionable to use in a threat. Emulation engagement. This first one here, the big picture this is called this is a start me page from a guy called InfoSec Ninja. If you've never seen this before, I can share the links out for that on my Twitter or for you personally after the fact.

But it is a really cool kind of single pane of glass. If you like that dashboard look and feel that has feed set up from all of the major security vendors that are in the space, whether they're government related, private, doesn't matter. This has a feed directly connected to them. What's cool about it is you can see the day to day trends and what everybody's reporting on, the threats they're seeing and facing, and see how that corresponds with your vertical.

It's a really interesting start time you page, and this is usually my go to when I'm trying to start this process. I want to see what's new out there. Right. I'm looking at this at least once a day every morning. Outside of that, some of the other resources I would recommend for you if you have not been paying attention to Cesa over the last couple of years, you're doing yourself a disservice.

The alerts and advisories that Sosa has been putting out, especially over the last two years, have been excellent. They're not just vague. Oh, hey, China's bad. You should do something about that. That's not helpful, right? No. They're saying, hey, look, here's a new advisory. Us and all of these other agencies have been seeing Volt Typhoon do some craziness.

Here's what that craziness looks like. They're actually giving you actionable Intel and behaviors that you can see, understand, emulate and hunt. So hands down my number one would be look at Sosa. The cool thing about them too is they're putting out, I mean, anything from 2 to 7 different alerts almost a day, whether that's an actual full scale advisory or that's them letting you know some new exploitation or vulnerability or something has happened.

They're trying to keep everybody really well informed. Going down this list a little more, you get into kind of a deeper report. They're more on the opposite side of CES. They put out really great content. It is very threat centric, threat focused, and it tends to be a little more focused on how the different payloads and implants and things like that function and are actually doing their thing during these intrusions.

It's really helpful when you're trying to deep dive and actually now start build out behaviors and build out a threat plan. The difference here is they're a little slow to post, right. If anybody follows deeper reports, sometimes it might be 2 or 3 public postings a month as opposed to 2 to 7 a day from like Cisco and other groups.

But it is very well detailed. It is very well articulated, is easy to understand and to utilize. If these still sound like too much for you and you're looking for just that, where do I start? What's going to be that single point that gives me the information I need to start doing? Threat emulation? A lot of people don't realize it yet, but I want to say was beginning of last year might have put out a new tab on their attack page called groups.

Under groups, they have detailed every threat actor group that they have reported on, or have tied into that miter attack matrix over their existence. To. Now it lays out who they are, aliases, who they typically target. It links all of the historical reporting they've utilized to build out that attack matrix. It is extremely useful, extremely helpful. And if you take nothing else away from this and you're focused on threats in general, I would look at my CTO tab.

It's great. Okay. Kind of last ones as a quick shout out Elastic Security Labs here. Lately their content has been amazing as well. They've really stepped up their game. They've got a really cool team in place there, and they're putting out actionable information. The Rosetta Stone, if you're having trouble understanding, well, who is apt? 33 don't you mean Peach Sandstorm or Refined Kitten?

Or pick the name some particular vendor calls them, right? The Rosetta Stone is a Google Sheet that's out there. Again, if this is something that interests you, I'll share it with you after the fact. That is basically correlating all of those names together so you can understand what they're called by what particular vendor. So as you're looking maybe you're doing your research trying to understand the threat.

You're not just tied to that one name and narrowing your field of view to where you're missing out on some potential goodness. You'll understand what they're named by, by each vendor and all the different reporting they have for those threats. So we've talked over how to kind of take a look in the mirror, right. See what information we already have and we care about narrowed our scope.

Now we've done a bit of collection.

Let's talk about what that collection should look like for a second. What we typically see, especially if you're just reading normal RSS feeds, blogs, Twitter verse, Mastodon. Pick your format right? They all look like something over there on the left or the center of this page. The left is very unhelpful. Right? They're basically saying, oh, hey, we know something bad happened.

It was bad, but it wasn't that bad. We promise your information is protected. Maybe, here, have a free year of credit monitoring. That's basically all this is telling us, right? It's not very helpful. There's nothing useful in here. There's no things that we can take action on. What's more, the norm, what we are typically starting to see on most people's postings nowadays is over here on the right.

They're using T codes. They're stepping up their game. Right. At least now we understand the behaviors that are being utilized. We don't actually know what those were, but we know the generalized category of what was seen. This is kind of the normal of what we're seeing from everybody nowadays, minus obviously the people that I talked about in the previous slide.

But what we're really looking for is this this is our best case scenario. This information is actionable. We can utilize this to test right. This call is out plain as day. Hey, here's what we saw them doing during this attack. Our investigation pulled up all of these different commands in the event log. We're seeing them running to. We're now seeing them outputting information based on that normal system, our environment, to some text files.

We're seeing them executing some Bat trials. PowerShell is being used. All of this now is perfect. I can recreate this. I can use this in my environment to see how my defenders respond. It's making sense. So this is ideally what we're looking for. We can put this to use to do so just as an example of like how we would rip that apart.

I threw this in here as a bit of an interactive slide. That final step was the deployment of the black suit ransomware binary they called Cui, which was distributed via SMB to remote systems throughout the network via CD shares. That attacker then manually connected to these systems after the fact, using RDP to execute said ransomware. Upon that execution, they then used VSS admin to delete shadow copies before they finalized encryption on the endpoints.

It's a lot of words, right? But in reality, if we want to break this down into actionable bytes or chunks haha. Punny bytes, cyber. Yay! Thank you. At least two people chuckled. It looks like what's down here below. We know those stages or steps are going to look like, hey, we've got to throw up our payload or our implant on some kind of share, right?

And we've got to move it around between the endpoints we're testing on via SMB. We're going to utilize those key dollar shares. Once we have a distributed we'll then utilize RDP. Move into those endpoints execute. As we do that we'll run VSS admin. We'll delete all of our shadow copies. And then we'll pull out because at that point we're done.

That was the scenario. That's our whole engagement. That's what we're trying to emulate. Now can your defender see that? Is your tooling stopping that execution? Is it identifying potential ransomware happening? Is it noticing this. See dollar lateral or see dollar shares lateral movement. There's a lot of questions this simple three step well let's call this a micro simulation can help us answer.

Guest. Starting to see the bigger picture here. And we're not doing anything crazy right? I didn't bring in any new tools. I'm not requiring you guys to go out and learn how to use Cobalt Strike, Nighthawk or make your own payloads and binaries. This is just a simple three step. Do a thing using everything that's already in your environment.

That's pretty cool. Right now. You can be a threat actor on the cheap.

So just as one other kind of extraction here, I had this initially set up to be like a live demo. Didn't realize I wasn't driving for my own computer, so I did make a quick change. Sorry about that, but I wanted to talk volte typhoon for a second. They have got a really awesome set of behaviors when it comes to user enumeration in the environment.

Go ahead and shout it out. Typically, when you think about a threat or a pen test, if you're going in, you're trying to do local user or domain user enumeration. How would you do it? Anyone? Maybe using. Net. Net commands PowerShell get technical user, get tech, add users, things like that. Right. We'll type who knows you're watching for those things because Sally and air should never be running.

Net user or opening PowerShell in general like that just doesn't happen. But they found some really cool ways of doing that enumeration by just looking at your event logs. That's what this is saying here. So instead of them looking for what's known bad known signature and they know they're going to get caught, nobody is watching their event logs.

They just care that they're there. You're not going to care that somebody accessed them, as long as they're still there for you to dig through later, or that information got written to your team right? That's the way most organizations think. Well, they take advantage of this by just go ahead and looking at that event code 4624 and saying, hey, what users have logged on recently into what endpoints.

So now they know who to target. They're looking for those potential administrator accounts, and they know where those users have active sessions at. That makes so much more sense than trying to just do a manual dump of users through your whole environment. Right? It's easier. This is stealthy and this is nothing fancy, but we can test this in several different ways, right?

We can scale this to meet the level of your organization. If you wanted to do it from a super simple perspective, you can just run some quick PowerShell commands during that whole get event log security. Bring it together and just open up a shell somewhere and run it. We'll talk through this more later, but then we could also maybe put this into a script, execute it via PowerShell, or utilize like unmanaged PowerShell or beacon object files.

There's a bunch of different ways that we can tier the stealthy ness and sophistication of this singular behavior that can turn into 3 or 4 different tests, just to see how your defenders respond and how your tools detect it. So this is getting pretty cool. This is the fun stuff. I love doing this. Just as an example, this is me taking that data that I found, pulling it all out, throwing it into a spreadsheet real fast.

The point of this slide is to say you don't have to be fancy. You don't need this crazy Intel collection engine and a bunch of different tools to sift it all. You can simply read that last slide, dump that data into a spreadsheet, and say, cool, I've got a plan. This is what I'm about to do. Look at that.

I'm a threat. I'm Volt Typhoon now. That's wild right? So what are some of the hurdles we're going to face when it comes to CTE in doing this kind of, behaviors? The biggest kind of elephant in the room here, right, is threat intelligence is very often historic. By the time we see it more often than not, it's six to, what, 18 ish months old at that point?

What's the big scary factor here because of that? This data is not accurate. It's not necessarily what that threat actor is doing at this point in time. That doesn't mean it's invaluable. This information is still useful because we can understand that these behaviors are something we've seen from them in the past. We might be able to retroactively find them in our environments.

But also I've noticed a lot of these groups are lazy. They'll follow the same cut sheet. They do the same behaviors regardless of affiliation. I mean, there's still groups that are out there following that original playbook from what, almost two decades ago now, at this point. So even though that data is historic, it can cause us a bit of a hurdle, especially when it comes to the efficacy and reality of the emulation for our teams, we shouldn't discount it.

It's still useful. The other thing here is getting a clear picture. Sometimes there's gaps in that reporting, right? They might have a ton of information on a specific payload that that threat actor used during a particular campaign. Maybe they outline kind of discovery how they did their thing, how they said persistence, but said nothing about lateral movement or how they actually got impact to happen.

That takes us as that now person doing the threat emulation or just as our team as a whole. When we're reading through the CTA, we're connecting the dots and building a clearer picture to fill in the holes in that campaign. If you want to do a full threat emulation. And waters all the way down there. Cool. I use this one on.

I appreciate you, sir. So with that, we need to be able to fill in those gaps using our knowledge, our understanding of these threats and how they operate historically to make a full kill chain per se, if that's how you want to operate.

Get on top. So lastly, we want to be beware of unsafe behaviors. I've seen this time and time again, both in doing these kind of engagements and working with teams. But also from my time in consulting and red teaming, just seeing people being completely willing to yeet new tools, completely untested at an environment, not understanding how they operate now, understanding what it's actually doing to that organization.

We are not trying to do that right. The whole point here is to be safe, to improve defenses, not open new holes. So we want to be aware of making new holes that potentially can cause impact to that organization. A really great example of this one thing I've seen quite a few times, surprisingly, is a pen test group or red team will come in.

They get their initial access through some web app, something edge facing right. They open up their own holes to make sure their C2 coms can talk in and out, and they can do their thing well. That hole isn't just usable by them, right? That's something anyone could stumble upon and now use. So inadvertently they're opening up new access, new ways of ingress for threads to potentially cause impact in that organization.

And a lot of the times, these teams aren't mature enough to understand or even look for cohabitation. So now they're they're using newer, untested tools. They're opening up gaps into your organization, and you're trusting them at the end of this to clean up after themselves, give you a report of everything they did, and ensure they didn't cause any undue impact or risk into your organization.

So we want to make sure that we're avoiding doing these same behaviors. These are pitfalls I see all of the time.

So we did our whole process right. We gathered CTI, we kind of understand what threats we care about. Now I've talked a good bit about all typhoon, so we'll stick with that. What do I do with that information? Not everybody processes it the same, uses it the same, or even has a template. So if you're kind of in that, new what do kind of mindset currently miter again to the rescue has come up with a couple of really good Intel report frameworks or just templates that you can utilize.

They're free 99 everybody's favorite price right. And they're actually really great formats. They've got one for basic Intel reporting. They've got one set up for incident response. They've got them for like overall profiling of threats, all kinds of different templates and formats that you can utilize. They're helpful. They set a standard and they're going to utilize the same normal conventions.

And taxonomy that the rest of the CTI space utilizes. If that's kind of not your deal and you're more of a visual person like I am, I really like this framework up here called Attack Flow. This is how I'll typically include in any of my engagements when we're doing in brief, and I'll brief as I'm building that threat.

I don't want to just see a bunch of words in line with a bunch of commands, a bunch of text. It's hard to understand and see the full picture. So I'll lay it out in this framework up here. Was that all good? Yeah, that was where I was like, I don't think that was me. So, and this framework here.

So we can kind of see it from that kill chain perspective. Right. What's that behavior I'm trying to emulate a quick description of what it is. And then the actual steps I'm doing down below, it gives me that more visual representation of what's happening. And I mean, in the end, when it comes to reporting, everybody likes pretty pictures, right?

Why why read ten pages when I can look at one picture and get that same knowledge? So this is when I really like to use. This is a great format. If you're looking for a way to start representing this information to your teams. The last one I will give as an honorable honorable mention here as well is the Purple Team Exercise Framework.

This is something as a sign that our organization has put out there for free. This is kind of a zero to hero on. I want to start doing purple teaming. I want to run collaborative engagements with my teams. How do I do that? Well, this GitHub repo will do that for you. It walks you through the whole process, what information needed, how to get people involved and gives you kind of some samples, report some sample simulations, all of that fun stuff.

So if this sounds cool to you, this sounds like a process. You might want to introduce. There's some resources to help you get started. So we've got our whole process down. We've got our documentation, we've got CTE collected. We found a really cool thread that we like now need to plan it out. Right. Well, I just put it down on paper.

I wrote my my tac flow, all that kind of thing. This is what I think I'm going to do. Big question is here is now do I have the capability to do that. I'm going to touch on this again. I'll probably say it like five more times because a lot of people tend to lose this. It has to be based in fact, we utilize CTE for that purpose, right?

We're not just trying to do this crazy cool, new like exploit chain we saw on a hack the box vulnerable VM right? That's not the point here. The point here is how can you stand up to a realistic threat. So make sure you're basing whatever you build on that intelligence and that understanding of the threat actors as a whole.

Next set up before we might have to get a little creative. You have to bridge those gaps. Well, how do we do that? Typically for us, we've got a little process will follow. If there's no reporting on a specific, say, campaign or threat actor in this current state and time frame of how they did lateral movement, we might look at stuff they've done historically.

If there's no real reporting on that actor as a whole, maybe we'll look at adjacent similar threat actors that are from that same region work in the same industries, things like that. If we still can't find that information, I'll be the threat. I'll utilize my own expertise, understanding who knows your organization better than you guys, right? How would you do the thing in your environment and fill the gap with that knowledge?

Now, I know I contradicted myself there a little bit, right? But I thought we said it all had to be based. In fact, as much as possible. We've already determined that that's not always the case. Right. But that doesn't discount that you understand there's a potential vulnerability already in your organization that needs highlighted, that needs brought up to attention.

This is a very easy way to show that potential risk and turn it into impact and easily sell it as hey, this impact now leads to dollar bucks loss. Dollar bucks loss means we all have a bad time and that's how you get stuff. Action, right? That's the end goal here is to introduce change, to validate your defenses, to improve the overall posture.

Lastly, emulation. When I'm planning this out, emulation doesn't mean an exact replication of what happened there. The thing a lot of people kind of lose sight of when they're looking at CTE and thinking about these threats is because that report is written based on the behaviors they ran in another organization's environment. You're not that organization. Your infrastructure is not the same.

You don't use the same hardware software. You might have some similarities, but you are not them. So trying to do an exact replication of what happened in that old test isn't necessarily going to serve you in your best interests. You're going to have to craft these scenarios in the information you're gathering to meet your organization. A great example of this, and I've seen it happen time and time again.

People lose their minds over some new key zero day vulnerability that pops up. A great example with SharePoint here. What a month ago, people lost their minds about that new SharePoint exploit that came out. Companies that aren't even Microsoft shops cared about it. Why it doesn't affect you? What's the point in trying to test if you're vulnerable to SharePoint when you're a Google Shop?

It doesn't make sense, right? So make sure you're crafting and tailoring these engagements to match you as an organization, not just exactly what you read on bleeping Computer yesterday. So we've all seen this pyramid of pain before, right? It wouldn't be a talk about threat emulation and purple teaming or CTF. I didn't mention the Pyramid of pain at least once, so let's talk about it for a second.

The bottom three tiers of this pyramid of pain. Right. Relatively easy, trivial information. You're getting all of this already from all of your CTE vendors, your security tooling, your your firewalls, all that fun stuff at a minimum, hash values, IP addresses, domain names. This stuff is easy to implement, easy to block, not so much easily to replicate. Right?

And not very useful in general. You can put these blocks in place. You could do some quick tests to say, hey, are we blocking known bad C2? Cool. We're done. Is that something we're emulating? No. Not really. What we care about is the stuff that actually will leave some kind of change or state or log being like network and host artifacts.

Are they dropping binaries to disk? Are they making changes to users to accounts, or are they making new use? What are they doing right? Are they running responder or are they just what's that behavior? What's the actual like physical change in the environment? What tools are they using? If it's something available to us, why not replicate it? Right.

Especially if it's something free known as a good tool. It's been validated by the community for the last ten years. The odds of it being something you know from that actual threat actor are low, right? Unless it came out of NPM recently, nobody. Sorry, I know I'm cheesy so tools. And then lastly the ttps their actual behaviors, the behaviors they run are easy to replicate, and it's a really good indicator.

It's something for us to latch on to is like, if I see there's probably a problem and I can start building my chain both directions from there, right? I can look historically and find their previous actions, and I can look ahead to try and get ahead of the threat and respond. So that's what we care about. We're caring about those top three tiers artifacts, tools, and ttps or behaviors.

To go on time. So now I need to emulate those capabilities. Right. We've got an idea. We know what we want to do. We've kind of built our plan. Now we need to put it to work. We were just talking about tools right as a piece to emulate. If they're out there, they're available. Utilize them right off the bat.

I've mentioned to here on these slides that I see in like four out of every five reports user got compromised. The threat actor, the first thing they did again was run minecarts or they're doing known C2 utilizing tools like Empire and Star Killer or Cobalt Strike. Almost every report is going to mention those names, right. Or those common tools.

If they're good enough for the threat actor to use, they're good enough for you to utilize in an emulation. Varying your techniques. If you're not able to execute those same exact procedures at the level of sophistication the threat actor could, what else could you do that have a similar effect? Is there something out there that gives it to you?

Maybe you need to back up a step instead of trying to do something crazy complicated, do a similar behavior in a simplistic way that still gives you that same effect. And then, if nothing else, if those capabilities out there don't exist for you, build it. If you have that time, resources, and abilities and your team, not everybody does.

Everybody has a big budget. But with the introduction introduction of AI nowadays, it is getting easier. I will say that it's lowering that barrier to entry. Some of those capabilities you're going to want to consider if you're trying to do threat emulation, how are you running C2? How are you going to actually set up your control channels? What kind of payloads are you using pre and post exploitation?

If that's something you care about, how are you generating all of this? These artifacts, all of these different indicators and behaviors that you're utilizing. These are the the laundry list of stuff you've got to consider from a threat perspective. If you're trying to actually emulate a kill chain, I know it looks like a lot. This can be daunting, but a lot of this is kind of already covered for us and taken up by several kind of public tools and framework.

Whether those are free or paid, right. On the free side, you've got stuff like Empire and Star Killer, Metasploit and Packet. All of these different tools provide a majority of the capabilities we're talking about here. From the paid side, you've got stuff like, you know, Cobalt Strike, Nighthawk. If you're getting more into the collaborative and AV space, you're now you're talking south Pike is those guys.

There's a lot of different tools and frameworks and capability sets out there for you guys to utilize. Don't be afraid to spend a bit of time researching them and looking at them. Just a real quick rehash. If you're looking for those free 99 that top list up, there is a great place to start. Empire Star Killer who's heard of atomic Red team.

It's a great resource if you're just starting out in this journey. It's a really quick and easy way to emulate simple micro behaviors, right? Like single piece kind of tests, but you get what you pay for. It is kind of sporadically updated. Some may work, some may not work, may not work for your environment. There's always quirks with that kind of tools.

Right from the paid side, you can get fancy if you need to. Not championing that, obviously, but it does make it easier, so you kind of get what you pay for. But what if you want to do it yourself? This was kind of an interactive piece I included in here. We talked about Volt Typhoon earlier, right. And how they were doing, log enumeration to validate users.

Well, how do you emulate that? The first one being just doing exactly what they did from that report, opening up a window shell. Throw PowerShell in there, run the get event log, or you can get a little fancier and do something like I did here. Developed a really cool script to utilize. I had the generic basic PowerShell way of doing it.

I can show it from unmanaged PowerShell, but I wanted to show it from another route to where I could do this in memory. I didn't want to drop an artifact on disk. I wanted to be a little more stealthy and sophisticated by trade. I am not a dev. I can read some languages. I can look at like Python, PowerShell, things like that.

I kind of know what's going on, maybe make some changes. But I could never write my own tool from scratch right now. At least I couldn't until things like cloud came up. So I kind of gave it an idea, said, hey, look, here's what I want to make. Here's how I'm trying to do this. This is the information it should output, how it should show it to me.

Oh, and as an example, this is the PowerShell command that I'm trying to emulate as a beacon object file. So I've never really written a beacon object file before. Is anybody actually know what those are? Buffs. Really cool tool, really cool way of executing behaviors. But I've never built one. So I asked my friendly GPT cloud to help me do that.

This was just kind of an example of that prompt. How it looks. The information I fed it in magic. It spit out code over here on the right, over there on the left. An exact breakdown of what's happening within that code. So this is now something one I can test and utilize, but I can also validate, go through and have an understanding of what this new boff is doing.

I'm not just trusting the magical AI overlord to give me what I need, and this is something that I can very easily take to one of my developer friends and say, hey, how does this look? Does this match up to my eyes? This looks okay. Do you see anything weird? Is there something wrong here? Did they magically stick a backdoor into this bar that I'm not aware of and validated?

So the use of AI and threat emulation now is really kind of helping level the game. If you're not big on the red side, if you're more of a defender on the blue side and you're trying to do this, it is very helpful. And I just wanted to show this as an example. When you're thinking about actually building out and developing capabilities, it's a cool space to be in.

Now. Now I'm getting close. I'm like five minutes out. I should be almost done. So I went ahead and just did it. Now I've got my three different ways that I wanted to show it. The very top one is that boss that I made running the middle here is going to be me doing that same kind of behavior from a PowerShell script utilizing unmanaged PowerShell.

The bottom end is me just doing it from a normal PowerShell run environment. Not being stealthy. No kind of craziness involved. And what that came to look like is now I'm getting this output kind of like this where it told me, oh yeah, hey, look, if you're looking for users that have logged in on those endpoints recently, here's purple Unicorn.

They're a domain user. They've logged in on this endpoint up there. An account name. Now I've successfully been the threat of emulated those behaviors that are known bad behaviors from a threat actor like vault typhoon. Now can my team hunt on this? Can they see this from just a basic PowerShell command being ran? Could they see my script execution?

If they could, can they see unmanaged PowerShell? Can they? Are they doing script logging? There's so many different questions we're answering from this now and then. Honestly, if I wanted to get real stealthy, did any of my crazy tooling such as like my editors or all of that AB actually catch the execution of this known malicious file type, right?

Did it see me run this thing in memory? What kind of capabilities do you have as a team and are they actually working? Those are all the questions we just answered with three different little lines. And behaviors. That's pretty cool, right? There we go then. Lastly, don't get so distracted trying to emulate these threats that you forget to be one yourself.

No one knows your organization better than you. If there is something truly wrong that needs address but you cannot get buy in, those are the perfect things to deviate on. Bring those into the scope. Look, I know we're really concerned about Salt Typhoon this week, but I see this kind of weird little hole over here. I want to test this to see how we respond and that's how you get by.

And that's how you build that trust. And you get stuff resolved not just by writing it into a report. You're showing impact now. You're showing that it is, in fact a problem, not just you think it's a problem. So I got like three minutes. Quick tips and resources, asking good questions when you're thinking threat emulation or you're trying to do this whole process, which we just did in about 35 minutes, from gathering CTI to actually executing some behaviors, not everything has to be a cyber effect.

This could be something as simple as, hey, we saw lateral movement happen, right? We did the thing. It crossed different lines of business. At what point do we need to escalate higher and get other business groups involved? Or maybe this is a full blown incident now, does legal need involved public affairs? Everyone else, when do we bring in sea level?

When is this a real problem? Asking simple questions like that will now cause this team that's traditionally focus just on everything in the weeds to step back and take a look at the bigger picture and say, oh, what am I supposed to be doing now? You're not just validating tools. Your response as a team, but as an organization.

Do you all understand the game plan? Do you know what to do when you're actually in the middle of incident response? So you're learning on multiple scales. Your whole organization will be better for it. Complexity doesn't make a great emulation. I just showed you from three different ways to do the same exact behavior, right? You don't have to go immediately to the crazy stealthy behavior.

You could just run some PowerShell. When in doubt, you a laptop with your normal tooling on it and a shell window is enough to be a threat. Then lastly, it is okay to use RDP. I hear teams dunk on this all the time. They're like, well, that's not realistic. We're letting you RDP and it was okay. It's known that lock, that vault typhoon, that salt typhoon, that black suit, that Alpha V black hat, all of these different threat actors and ransomware groups are using RDP.

They're using any disk, right? They're using Screen Connect. They're using ARM tools. If it's good enough for a threat actor, why is it not good enough for us to try to defend against invalidate? It make sense to think from that close minded perspective? Right? Just because you're using a built in native tool doesn't invalidate the test.

Then lastly, building trust as someone from the red side. Traditionally, trust is everything for me in what I do. If your organization does not trust me to operate, you're not going to bring me back. We're not going to do these things in overall. You're not going to grow from it because you're going to be too afraid that the people that are there, that are going to cause worse impact than the actual threats will so start small, grow over time, and ensure you stay to scope and you're not doing anything crazy.

You're introducing more impact. And lastly, these are supposed to be collaborative. You're supposed to be in that room with your defensive teams. You shouldn't be kind of like on the stealthy trying to be Batman and doing a bunch of stuff and sneak in and sneak out. They can be in the know. They can understand what's about to happen.

The whole point is that validation, right? Did they see your behavior? There's no reason you need to keep them in the dark. Resources. You saw all of these. If you would like some of these that you saw during the talk, hit me up after the fact and thank you. That was my talk.

Any questions for Trey? We can field 1 or 2 here. Questions, comments, concerns.

Oh cool. Thank you guys for your time.