welcome to lesson for module to within the attack based stock assessments training course. In this lesson, we're going to talk about how you can analyze analytics to identify the attack techniques they might be able to detect.
This lesson fits into the third phase of our generic attack based stock assessment methodology,
and in particular really breaks it down into the analytics portion
of the analyzed components phase.
This lesson has two primary learning objectives.
Number one. After the lesson, You should understand why analytics are important with regards to the attack framework and number two, you should know how to analyze analytics to identify the attack techniques they might be able to detect.
So to kick off this lesson, we're gonna talk a little bit about analytics. Somewhat generically,
generally speaking, analytics are detection roles that are designed to detect specific behaviors. By contrast, signatures tend to hone in on specific indicators or artifacts.
There is, of course, some nuance in those definitions, and you'll sometimes see people use analytics and signatures interchangeably. But for our purposes, when we refer to analytics, we're really hoping to find you know, those rules that are looking for behaviors, although often you'll find, you know, more of the IOC or artifact based rules and
functionally, an analytic works relatively straightforwardly. You ingest a data source, you apply a filter to that data source, and then if you match a condition, you create an alert.
And here's an example data source taken from the cyber analytic repository. When you look at it, that first line that's gonna say Okay, we're identifying all processes. The second line says we're going to look for specific processes that match this specific condition.
The third line is going to apply a separate filter that looks for processes that match a third condition.
And then the fourth line is going to give you that conditional output where you get that intersection of lines two and three and then the last line line Number five is going to just say, Hey, output, that last conditional intersection that we found.
So why are analytics important for assessments? Well,
a lot of socks are already running some kind of analytics, you know, they might not be necessarily behavior based or strictly behavior based, but even if they're artifact based, they might be able to pick up on potential behavior.
Looking at these can allow us to potentially figure out what gaps the sock has identified and where they've been trying to fill things in.
Really, from an assessment perspective, each analytic can potentially detect an attack technique, even if it is IOC artifact base.
And so, if we map those custom analytics, we can then create a coverage map kind of showing some of what the sock might be able to cover
for those socks that you know already do that you know those that are using attack. They're tying the attack framework or they're tying their analytics to the techniques that they might detect. That's great. You don't necessarily need to run through this process.
But if you're doing this for a sock that isn't yet
tying their analytics to attack, this is really a great opportunity to understand how what you've previously been doing relates to the attack framework, really allowing you to understand how your prior mindset maps to adopting a threatened form defense.
So we've come up with a process that is relatively repeatable to analyze analytics to understand the techniques they might be able to detect.
First you find that the data source the analytic is keying off of
second, you'll try to determine in words what each filter is doing.
This is important just because when you're looking at analytics, you'll often find like different syntax is different formats, and it's sometimes hard to think about it in terms of code, but easier to determine what it's doing. When you're thinking about it in words,
then you look at that filter and map any identify IRS like strings or numbers
in that filter back to the attack attack framework. Here, you You look for, um,
you can look up these identifiers in the attack framework itself or consult third party sources.
You can also look at metadata for clues. Sometimes you'll get like a name of an analytic, and that can help you understand what the sock was going for their and then importantly, if you're looking for stuff and you don't find anything, it's okay to ignore it. You know a lot of analytics. They might not map to specific behaviors,
and then, for each technique that's identified by a filter and analytic, try to gauge coverage. Really, you need to read the attack page to help you gauge fidelity,
but you know, part of this is also setting a good coverage rubric rubric for how you want to gauge fidelity.
A couple of examples you know, something basic is like this Analytic is likely or unlikely to see the technique.
Something useful but kind of simple is that kind of high, medium or low confidence of detection that we like to use
something more advanced is, say, quantitative. This analytic provides 66 out of 100 detection coverage,
so let's not walk through an example where we're doing it. A little bit of analysis. This is another analytic taken from the cyber analytic repository
here. We're going to see that first line. We're going to see the processes that's going to map to process monitoring.
The second line is the filter. Um, when you dive into it, you put it in words you're gonna say, Oh, this is returning All processes spawned by reggae SVR 32
but not itself. It's again a little daunting when you first look at it, but when you put it into words, it's it's It's a little bit easier to understand
when you look up. Reggae SVR 32 dxy on the attack framework website you immediately see Oh, this maps to reggae SVR 30 to a specific sub technique.
And then when you read the attack page, you can see Oh, this is going to provide, you know, pretty pretty good coverage of it.
Here's another analytic taken from the Sigma repository. It's a little bit of a difference in Texas. You can see, but we can walk through the same process
here. We're gonna look at these two lines and say, Oh, this is referring to Cece Mon Event I D 13 will consult the attack data map project to see that that actually maps to a registry event.
And we can conclude that this maps to a specific Windows registry data source
for step two. We're going to look at these three lines here. These are filters looking for specific
Windows registry modifications. And what we can do is look for those specific and registry entries or, um
or or actually the these little identifiers here here we've highlighted image file Execution options is one of the identifiers to look for, and what's nice is you put this into the attack framework and you can immediately find a technique the image file, execution options, injection, sub technique.
And when you read through the page, you'll find that it provides some some good coverage of it just because that specific
registry event or registry key is indeed named on the page.
these two examples were pretty easy, but sometimes things can get hard.
So let's look at this previous analytic that we just analyzed and then see what happens if, say, we take out the first line Now we've only got these these bottom two lines to to look up when we're trying to understand what technique this might detect.
And here this gives us three potential identifiers this reporting mode, silent process, exit and monitor process.
And unfortunately, when you look each of these up in the attack remark, you don't get anything.
They don't show up as on any pages or at least in the attacks search bar.
So what we can do to fix this is to well, use Google. It actually makes things a lot easier.
So for silent process exit, what we can do is do a little bit more of an advanced search on the attack website. This provides a little bit more in depth. Um, you know, capabilities Here. We're going to take the silent process, exit string, put it in quotes, and then restrict our search just to the attack website itself. And when you do that,
you see that the image file execution options technique comes up right away
for reporting mode, we can do the same thing, but unfortunately nothing comes up.
So instead we do a different query where we just do reporting mode. And then we put the attack identify or next to it. So now we're just looking for the two together, not necessarily just on the attack website.
And here we can identify a website that indeed does mention this this string in conjunction with the attack framework. And indeed, it does point to the image file execution options technique.
So when I walk through a couple of ana analytics to do some mapping just as exercises, so your task is to look at the analytic here, try to figure out what technique in my technique or techniques that might be able to detect
so positive video when you come back, we'll we'll kind of walk through a potential solution.
Okay. Welcome back. Um,
for this analytic. It's fairly straightforward is from the cyber analytic repository. You can see the RL in the upper right.
Um, it's definitely not a complex one here. The first line is going to look at data sources. We're gonna see process monitoring again.
Our filter is looking for any e x c with cmd dot exe c as the match.
And then when you look up this string the CMD exe e string and the attack website,
you get the Windows Command shell sub technique
and then you'll see when you read through the page that it provides some coverage of it. We say some coverage here just because there's lots of false positives just because sometimes cmd dxy is used. Um, you know, not nefariously.
Now, what's interesting about this exercises? You can look at this another way to
when we look up cmd dot Exe c In the attack website, we actually see another entry for the CMD software.
So this is also a valid solution of this problem as well, and that what we can say is, oh, if it maps to the software, you might detect the software. And then when you look at the software on the attack website. You can see that it detects basically kind of half a dozen different other techniques.
And then you will say, Okay, since we're only looking at the software is executing them. We're again. We're
It's more of a maybe artifact based, you know, detection. Here. We're gonna provide maybe a little bit or some coverage of some of these. You know, it really depends on the context in which these techniques are being executed.
So here's another example. This one is taken from the Sigma repository. Um, we We were great out the u R l a little bit. Just because it gives it away right away. This one is a little bit more complex, but, you know, feel free, take a look. Try to figure out which technique this analytic might be able to detect. Um, you know, once we come back,
we'll walk through how we look at this and what the solution might be.
Okay. Welcome back. Um, we're gonna walk through this one. Um, as you can see, we're, you know, right away. We see category file event that was going to map to file monitoring
the filter is looking for any process is launched from the scr cons dot txt file. It's very specific there,
and that gives us really one main. Identify that scr con study XC identify there. But when you look that up on the attack website, you don't actually get any results. So we're gonna use our more advanced searching technique and look for it, um, on Google, but restricting our our search to the attack website itself.
This does not produce anything. So we'll do our even more advanced search query to just do scr cons along with attack.
And here you can see a couple of hits. The first one is this this website from Palo Alto Networks
which is going to describe, you know, a little bit of
what it looks kind of like an analytic. And when you look through the description of it, you're going to see oh,
the Windows management instrumentation standard event consumer scr cons. DXC executed a rare VB script or power shell script and that immediately says to you, Oh, hey, this is some good evidence that this is looking potentially for W m. I.
when you go and you read the website for the technique, you'll see that it might provide some coverage or maybe low coverage, but it does indeed map to the W my technique.
And here is the Ural of the of the analytic. If you want to go take a look on your own.
So if you summary notes and takeaways to close out this lesson,
number one analytics are detection rules designed to identify behaviors. This isn't really the focus, of course, of of this, this lesson or of this course itself. But generally one of your takeaways should be to to follow that analytics are detection rules designed to identify behaviors.
Many of your existing analytics may already mapped to the attack framework, including even some of your signatures,
and to analyze them, you can follow a relatively straightforward process.
Find the data's horses keying off of
Try to determine what each filter is doing within the analytic map. All identify IRS in the filter to the attack framework,
either searching on the attack website or using a search engine, and then for each technique identified by a filter, try to gauge coverage of that technique
and then, of course, record any map ing's for the analytics you analyze
and Lastly, keep in mind if you're doing this for the first time, you might not have any good attack analytics. That's totally okay.
Lot of socks when we're just getting started with a threat based defense or threatened form defense,
they're still trying to tow the line of, you know, getting into the more behavior based
detection approaches. So if you're looking at your analytics and you don't quite have anything keying off of the attack framework, that's totally okay.