So we're back.
Here's where we're at in the scenario.
We didn't prevent it.
Or at least we didn't think we did.
We're starting to see maybe some signs or some user
reports that something weird's going on.
Now as a defender, it's our job to detect it.
And so as I understand it, you have some stuff prepared to talk about.
We already talked about network traffic a little bit.
And now I just want to prep everybody for a second about you have to capture
the traffic and/or you have to be inspecting the traffic.
You don't necessarily always have to capture it,
but you have to be inspecting that traffic.
Preferably, I think in this case, and totally correct me if I'm wrong,
we're talking mainly north‑south traffic,
or south to north really.
So internal to external traffic is going capture at your edge.
And we're going to apply signatures and analysis at that point.
So that's where we're going to inject here,
and, Josh,
thanks so much for being the expert on this and showing us all the
awesome Suricata stuff you're about to get into.
‑‑Yeah, absolutely.
And, yes, that's 100% correct.
We're going to have to peel back the next layer of how detections can occur,
what's currently available.
This will give you some insight into maybe the stuff that
you're paying for and how they're operating,
as well as, hopefully,
some ideas and some insights as to how you can create custom
signatures to help with your detections as well.
Most of this activity, in order for a threat actor to be successful,
they have to reach out of your network at some point in time.
There are scenarios where, say, they get ransomware in the environment,
and then it's all sort of self‑contained from there,
and they maybe don't have to beacon back out.
They wait for you to contact them at that point.
But in a lot of cases, Dridex is one of them,
it is reliant on checking into its command and control,
receiving additional commands.
And so, eventually, it is going to leave the perimeter.
The initial infection is where a lot of this activity is located.
So it's really one of the better chances we have at observing,
or not only preventing,
but then detecting this possible threat actor from being in the environment.
‑‑Perfect.
From my perspective, especially watching this kind of thing,
it's like, okay,
well any network I'm included on or a defender on or maybe even my home network,
I'm going to look for these detections and say,
What can I do to go find out and get some peace of mind that
this isn't running rampant in my environment.
So we're back here watching.
ANY.RUN's executed, and we see this network traffic.
That's kind of our start.
We're imagining now this is our device and our environment.
Let's get some detections on.
‑‑Yeah, so just to help kind of refocus that,
we're looking at those IDS alerts because that's where really the
signatures take place predominantly on the network side.
The value in learning how signatures work is that once
you understand what to look for, the patterns,
what becomes good content to create a signature,
whether you're writing it for an IDS system,
network activity, or something on the host or static file analysis,
the concepts really become quite similar.
We're going to take this traffic.
One of the benefits of many online sandboxes is that we can
export the network traffic as a PCAP,
and we can replay it in systems for analysis.
We also have the ability,
if you're monitoring these in real time on your network,
you're going to have a SIM or some capability,
some tool that's going to be inspecting the traffic,
looking for those alerts that are being generated,
and then providing you with a visual way,
a dashboard and other capabilities to identify when these things
occur and then to dig into them a little bit deeper.
We're looking at‑‑‑I'm going to use Suricata for all of
the PCAP processing here going forward.
One of the tools that is available,
sort of under the umbrella of the Suricata project,
is EveBox.
And EveBox is just a very straightforward rule and event manager.
So you can see here, we're looking at the alerts.
These are all the same alerts that we saw previously.
What we can use EveBox for is to triage those.
And so now we can select one of these alerts and dig a little
bit deeper into what that alert is telling us.
So one of our goals here is not just to understand the alert
itself but then to build some context around that.
‑‑So this is, again, the same process flow as now we're executed,
and now we're analyzing the PCAP.
I'm assuming, is this one downloaded from ANY.RUN because you can just click,
you can spoof that button, and you get a PCAP.
Is that what this is from specifically?
‑‑Yes, specifically, that's what this is from.
But we could also pretend that this was a dashboard that we're
monitoring regularly in our environment,
and all of a sudden these alerts popped up.
So what do we do next?
‑‑So that will be the same execution flow that we're looking at that executed,
needs to go download something.
So that's the first step.
And so, hopefully, we can catch it there.
‑‑This is really the first step we can take in peeling back the information.
We have the contextual data around the alert itself,
the source and destination IPs, as well as the ports.
We have the flow ID.
And that's something that's important because we're going to use that
in just a minute to take one more step further back.
To the right, you can see things like the signature,
which is normally the message that you get when the alert is generated.
We have the category,
the signature ID if we wanted to investigate the rule itself
because we need to understand the syntax of the rule to really
understand what this rule is telling us.
Sometimes it's quite obvious, a PE file is being downloaded,
that's fairly straightforward if you understand what the PE file is.
But other rules are going to be a little bit more difficult to
comprehend because that message is typically very terse.
The severity, that kind of goes into the color coding of the interface.
Red generally means bad, severity 1.
As we get away from 1, the severity decreases.
And so that's just the way that rule writers can help draw
attention to what they would consider higher severity events
that you should investigate.
‑‑In this case, I'm seeing a bit more of a mauve,
but red to pink ratio means bad.
Got it.
‑‑We also have the protocol data.
So something that isn't always immediately obvious when an
alert is generated is what happened around it.
This alert was associated with an HTTP event,
that is, the PE file is downloaded over the HTTP protocol.
So here's all the content around that HTTP request and response.
Some of this can become very valuable information to detect on,
to look in the environment for,
either previously unknown activity as you're trying to scope an incident
or to consider maybe creating additional detections on.
So we have user agents; sometimes these user agents can be quite distinct.
You might have to look,
and hopefully you have the ability in your environment to compare that to
all the other traffic on the network because if something like the user
agent emerges as a very unique piece of content,
then that helps you to scope this particular threat actor a little bit better.
Oftentimes, these requests are quite minimal,
and we'll see some examples of that here a little bit later on.
The URL, the URL and the host fjb2016.com,
I can't look at that and say it's good or bad.
Seems a bit odd, but it's likely a legitimate website,
so we can't just instantly condemn that as communication to a compromised host.
Same with the URL.
Yeah, it's a bit suspicious to me to see a rather terse,
somewhat random‑looking PHP file,
the request being made to that PHP file and the fact
that it's returning a PE file,
especially since it's buried so deep in the path structure of the server.
But, again, it's not something that we can just instantly say,
This is 100% bad traffic.
Okay, so I mentioned the flow ID,
and what the flow ID allows us to do is to take that step
further back and try to get broader context around the
activity generated from this alert.
So not only the HTTP request, but as you see here,
we have information about different flows,
in this case the TCP session.
We have the alert that was generated based off of that HTTP request.
And then we even have a FILEINFO event,
which can be really helpful because that can be data that can allow us
to more quickly gain and gather other information about this file that
now has just come across the network.
‑‑So for Suricata, to relate this to Wireshark,
which maybe a few more people have done,
the right‑click TCP follow,
this is like that but on steroids because you're getting everything within
the TCP connection but then kind of more granular as well.
So was there a file transfer?
That's extracted with that Suricata framework.
Same thing for, now let's go next level to HTTP protocol.
That's extracted as well but all within a TCP flow.
Would that be a good way to describe that?
‑‑Yeah, absolutely.
And so maybe it looks a little less impressive with just the singular event,
but you can imagine as there's more activity,
more alerts, more things happening from an infection,
the flow really helps to take that step back and start to
paint that picture of what's going on.
So with each one of those event types,
and not to get too deep into the specifics of how Suricata generates data,
but every record,
every transaction that happens on the network comes out as an event type.
So we can look at those event types to get even more data.
In this case, we're taking a look into that FILEINFO event.
And here you can see that we have the libmagic,
so the file identification PE32 DLL.
We have the different checks and values, the hashes.
So MD5, SHA1, SHA256, whichever hash value that we want.
And having that data can be helpful because now we have a hash from the network
that all we had to do was look into a dashboard somewhere,
grab it,
and we can search for it on the URLhaus or abuse.ch or take it to VirusTotal.
Suricata as an engine has the ability to do file extraction as well.
So there is some potential to automate not only the
identification but then the extraction and then sending
those files off to different workflows.
It's not limited to just PE files.
Of course,
it does have some limitations in terms of the file types
and the protocols that it supports.
But it's all very well documented.
So I would refer you to the docs to figure out if it meets your needs there.
‑‑So that's all the output that we get from this if we want to
make this custom for our environment because,
again, everything changes, so we can't just necessarily use this MD5,
but we could if you detected it in your environment.
You take the MD5,
and now you can find out everywhere that may be or everywhere that may
have been downloaded and maybe a historical capture.
But if we want to change that, we can do that in this.
‑‑Yeah,
and that's a really important point because a lot of the ability to threat hunt
is dependent upon having the data to go back and look at.
And so you can run in IDS mode, and it can generate alerts,
and you can kind of stop caring about all of the data that
it's also generating and logging that and having that
historical sort of archival capability.
But that's really important because we could,
we could take that hash, we could now say,
All right, any FILEINFO records that have this hash,
I want to see them.
And that might help us to discover other endpoints
that have downloaded this Trojan,
maybe from different IPs or different hosts that went previously undiscovered.
We'll take a look at the signature in a minute,
and we'll talk about some of the caveats with signatures.
Signatures are still signatures; they can be bypassed.
And then ways we can customize them to help make them
more unique to your environment.
Okay, so I briefly pointed out the signature ID, or the SID.
Signature IDs don't follow a very strict form in terms of how
you assign signature IDs or create them.
But, generally speaking,
Suricata as an engine will not let you have duplicate SIDs.
So for the most part, the rulesets that you're consuming,
they should be de‑conflicted to some degree.
That SID allows you to look at the rule, and so we can use visual tools.
You can see here, I'm actually using what's called Scirius from Stamus Networks,
an open‑source project you can find on GitHub.
You could just look at the rule file itself,
and Suricata configuration will direct you to where those rules are.
Then you could cat the file, grep on the SID,
and get the syntax that you're seeing here.
The syntax is unique to Suricata, much like if you were to look at another IDS,
such as Snort.
It also has its own syntax.
But, again,
what we're trying to identify are unique enough patterns that are
repeatable by this either activity that we're investigating or a
particular threat actor that makes for a solid alert,
something that will generate an alert,
that will really raise an event that will draw our
attention to something we should investigate.
We won't go through all of the structure here.
It's a little bit‑‑‑we could spend a couple hours doing that.
But what it really boils down to is certain keywords,
the dark blue content that you see in the screenshot,
certain keywords that tell the engine where to look.
And, again, this is very common.
Think about ClamAV.
When we write a signature for an AV,
we need to tell it where to look in the files that it's scanning.
So where do we look?
And then the content that follows is what are we looking for?
So if you can identify the file data,
then that is a content match on the first two characters,
MZ.
And those are the first two bytes typically in PE files, MZ.
From there,
it does a little bit more of a thorough detection in that it
looks a little bit further into the file to say,
Okay, if we find the bytes MZ, then 60‑some odd bytes later,
we should also find another signature, which is the PE signature.
And you'll see that sort of in the middle of this rule here.
That's an attempt to reduce the false positives because,
yeah, in any sequence of bytes,
the characters M and Z are probably going to be there.
And so getting a little bit more thorough helps to reduce that noise.
The other thing that's important to point out here is that it's really hard,
from an IDS engine perspective, to correlate all this activity and say,
Okay, if I see this, this, and this event,
then generate an alert.
And you'll notice in the middle of this rule, there's a flowbits.
And a flowbit is just a way to basically track a Boolean to say,
If this event occurs, so traffic matches on another rule,
and then traffic matches on this rule, now generate the alert.
And so that's how‑‑‑I mentioned with the PE files,
what we're trying to, because PE files are commonly downloaded all the time,
we're trying to reduce that noise.
It a PE file comes from Windows update,
don't set the flowbit so that we don't alert on a PE file download.
If a PE file comes from evidence of a PowerShell command,
set the flowbit, and then if a PE file comes,
generate the alert.
‑‑So this flowbit piece, and this is great even for me, so we're saying set it.
And then what is the ET.http.binary?
Is that what's reducing, wait for this thing to happen?
What are we‑‑‑what is that referring to?
‑‑So not to get too deep into the flowbit,
but it's considered a Boolean variable.
You either set it or you read it, and so you have the flowbit and the action,
and then that's just like the variable,
so that's going to be a unique variable that the engine will load,
and that's how it knows where to check other flowbits to see how it's been set.
So you can have different‑‑‑if you look at the different IDS rulesets,
Emerging Threats Open, Emerging Threats Pro,
Open is the free one,
there are actually a number of alerts that are rules that
are written to alert on PE file downloads.
Some of them will have different flowbit scenarios though,
dependencies then that are created so that they don't
always alert on the same conditions.
‑‑So specifically for this malware for Dridex,
is this rule specifically for Dridex that we're looking for,
at least for the EXE download behavior?
‑‑This type of a rule is far more generic.
There are a couple of flowbits in this one.
The first instance of the flowbits is looking if an
ET.INFO.WindowsUpdate is not set.
So, again, it's a bit broad in that if it's not related to Windows Update,
some other rule somewhere else is setting that flowbit,
which you could then look at the ruleset to figure out,
then it's generating.
So we're going to see these kind of regardless.
Using that structure, though,
we can begin to create more custom scenarios where maybe there is a
particular type of executable that we care about,
or maybe there's some additional content in the
executable that we always see that is there.
That's more of a research activity.
So for common threat defense, Blue Teamers,
we just don't have the time to go through and do that sort of research.
That's what companies like Emerging Threats and Proofpoint,
that's what they do on our behalf is they look for those patterns,
and they try to make them as as unique and also then be able to
detect very specifically as they possibly can.
But it's not always the case.
However, again,
with this sort of information, it really disguised the limit then and
how you can take it and apply it to your environment.
‑‑Yeah.
And as a defender, so I can take something like this that's more generic,
we know that executable for Dridex has to download,
and whether whatever the extension of the file is,
it still has the MZ and the‑‑‑this can now execute in DOS or whatever.
And so it's going to have that stuff in it.
I can get that alert.
But in context with other alerts that are also either
more or less specific to Dridex, that starts to help me figure out,
I have a higher confidence that this is a true positive.
‑‑Yeah.
And that's a great‑‑‑you could take a rule like this and you could,
once you became comfortable with the rule syntax,
you could add additional content matches and say,
Okay, not only do I want to look for the evidence of a PE file,
but if it came from a .php or a .tar or a .zip or something
that is a very nonstandard file extension that you wouldn't
expect a PE file to come from,
we could use very specific examples from behaviors to see with Dridex.
We could be a little bit more broad or generic.
Again,
it really boils down to how much time you have in order to
customize your detections in your environment.
‑‑Do we have some more higher fidelity rulesets for Dridex that we can show off?
‑‑Yes.
So we do have the ability then to try to get a little bit higher fidelity.
Here are two examples.
We have two alerts.
The Feodo Tracker Command and Control Server.
This is an alert that's going to be generated because we've
identified previously IPs that we know are related to some
threat actor or some group.
In this case,
the alert's a bit more generic in that it's saying it's
part of this broader tracker service.
The other, and this one is a bit more precise,
and, again,
the quality of the rule all depends on what we observe in the threat actors,
how much research is done, how unique the patterns that they leave behind.
So here we have a detection based off of the TLS,
the SSL certificate, they still use SSL in the names.
And more specifically, you'll see they saw three alerts that were Dridex.
So they're saying, Yeah, I'm pretty confident that's Dridex but maybe not 100%.
And that's true.
It can be, when we start looking at some of these other detections,
well, they can be very high fidelity in some situations.
They also have a tendency to be a little bit more
noisy in terms of the false positives.
So let's take a look at these two alerts real quick.
‑‑Especially with certificate detection,
that's really near and dear to my heart because I think it's
something that sometimes gets bypassed.
So let's check it out.
‑‑Okay,
so the first thing I'll do is just step into the alert
information here as we saw with the previous alerts,
source and destinations.
We have ports.
So this one is communicating over 443.
So we can suspect that a TLS session is to follow, although not a guarantee.
We'll actually use the flow ID, though,
and we'll pivot off of the flow ID in order to get that broader context here.
And here you can see how all of these alerts actually tie together.
It's not always 100% clear when looking at that
sort of inbox approach of alerts.
So we have the TCP session established, then we see we have a TLS event.
So the first alert is generating just simply off of the IP address.
So it's using an IP reputation capability within the Suricata engine.
From there, once we have established or once that TLS session,
as that's being established, information from the certificate,
there is a rule that has been written in order to generate detections
based off of that or to generate that alert there.
And that's where then those alerts follow.
So, in fact, we have four different alerts,
but they're all related to the same activity,
the same connection to a singular host.
‑‑Theoretically, and just to set this up for like a real‑time detection,
if I take this to an environment I'm working on now,
inspect the traffic,
I may not get the first alert because it just may not be
on the black list for the C2 server.
But this is, in fact,
we did have clear text or unencrypted communication for the first stage,
but now this is TLS secured connection for C2.
And so, hopefully, we got lucky and it is on a black list.
But if we didn't get lucky for that, we may only see the certificate alert.
‑‑Right, right.
And that's, again,
that's the challenge with these detections is that if that IP
address isn't being tracked and reported,
and we don't have good fidelity on that,
then we lose the visibility.
Same with the certificate.
The certificates obviously can change, they can be set up,
they can get changed out as with all of the infrastructure that they're using.
And so a lot of the detections are very reactive.
We don't know that there's a new C2 node until there's a new C2 node.
We don't know that they changed their TLS cert until they change their TLS cert.
We can try to be generic,
and that's one of the things that some of the detections that
we create hope to be is that we can say,
All right,
if we see a lot of high entropy content in the name of the TLS certificate,
well, that seems a bit odd.
So let's try to be proactively alerting on that.
But, again,
it's not a 100% way of ensuring coverage of preventing any sort of activity.
So we have to take all this stuff and kind of combine it together and
layer it together and hope that through all of it,
we are effective.
Let's look at both of the detections.
The first one is the Command and Control, that Feodo Tracker, that's IP rep.
And here is the rule.
It's actually pretty straightforward in that if you look
at the very beginning of an IDS rule,
the first verb is just what it's supposed to do,
alert or drop or reject.
It's that action that it takes.
The default is just to alert so it doesn't modify the traffic.
The next is what is it looking at?
So we're looking at IPs.
And then from there at the very end of the rule,
we see IP rep, and there's some dst, a unique number,
a greater‑than sign, and a 1,
and that is just simply saying that in the configuration for,
in this case, Suricata, it's been configured to use an IP reputation list.
And if this IP is on that list, then generate this alert.
Okay,
the last rule is‑‑‑you can just eyeball this one and
see it's a lot more complicated.
It is just an alert rule.
Again, you can modify those as you see fit in your environment,
but it's looking for just TLS.
And it's not bound to TLS on a certain port.
It's bound to any TLS session that the engine identifies.
How this one is being matched is a bit more generic,
like I had mentioned, in that they're using the PCREs,
the PERL Compatible Regular Expressions,
to try to write a more generic enough pattern to‑‑‑you don't want a
signature to be so precise that it only alerts on one TLS cert.
If it does that, then they make a change,
one small change to it, and now that alert is no longer good.
And so trying to make something a bit more generic,
particularly as it associates with how a particular threat actor is operating,
that's what they're attempting to do here.
So this one, these are a challenge.
I can't look at that.
My ability to just process regular expressions on the fly just never existed.
It's like trying to solve a Rubik's cube.
It's like that part of my brain just never developed.
And so I can't just look at that and say,
Oh, it's obviously matching on this pattern.
That one takes a while to really digest.
But it shows how, on one hand, rules can be very strict,
and then on the other, they can be a bit more broad.
So, again, it's really up to you to decide how to use this information,
how to create detections in your environment.
‑‑Well, hopefully‑‑‑I'm not a regex ranger either,
but, hopefully, if we have viewers out there,
someone is highly focused on regex in their group.
Like me, I'm just like, I don't know, let me go test it on,
there's that Java site where you can test your regex to make sure it works,
and let me just make sure this works.
And that's every single time for me.
Like I have zero confidence in my regex abilities.
But, ideally, someone's sitting there making this happen,
and in a lot of cases, especially when you see like the capital A to Z,
lowercase a to z, it's like, okay,
well, that's the whole known character set uppercase and
lowercase and 0 to 4 of these letters, that kind of thing.
But one thing we get to here and ahead of what you're trying to
get to is if they are randomly generated,
we can look at something like string entropy for the fields that are
randomly generated and attempt to try to use that.
So it's not like known words and that kind of stuff.
‑‑Yeah,
and it's also important to note that the rules are
only as effective as the author.
And so not all rules are created equal.
So you can't always just assume that what you're receiving is 100% awesome.
You do want to give it a critical eye before deploying it in
production or using it as the basis that creates something
custom for your environment.
‑‑Yeah, and so from a network perspective,
that's us looking at certificates and kind of understanding the way that those
are filled out, what's always interesting to me is I'm mentally tying that to
someone in a chair filling out the certificate.
And sometimes its automated, but at some point,
someone had to make the automated tool to generate the certificates.
And so they had to like‑‑‑we're basically just making
regex that describes how they type.
And so they thought it was really cool to use four
letters first and then do this.
And so it's really just kind of modeling human behavior,
which is always interesting to me.
That being said, computers are a lot more predictable in my mind.
And so one thing that we did see was on the endpoint,
and just to give a little bit of endpoint perspective for detection,
is this process execution change.
And not that they can't change, but there are only so many LOLBins,
or living off the land binaries, that can execute other code or execute a file.
And so there's kind of an inherently small list that
we can detect onto that behavior.
Now, this isn't like 100% test or anything,
but I'm going to share this in the exercise documents.
I want everybody to be able to have the idea of what we were talking about.
Now super basic, again, but if you're looking to detect this on a device,
or you can shove this out to a bunch of devices,
feel free to modify this as you see fit.
I'm going to get stuff to yell at me because I use aliases 100% of the time,
and 100% of the time, it tells me that they're going to break,
and they never do.
They haven't broken for 10 years, and they've been fine.
So I'm going to continue to use these aliases.
But, basically,
what we're saying here is I'm setting different variables and
then waiting to see if those variables are true,
and it'll write out, Hey,
we've got some Dridex detectors and indicators detected.
And we're, just like you mentioned before,
we can look at, hey, I'm sharing the right screen.
‑‑Yeah, I see, it looks like Visual Studio.
‑‑Perfect.
Okay.
The main thing we're looking for here is the command lines
that are executed kind of with some variance.
And, again, if we use like here, at least in PowerShell, we get rid of the case.
So this will, especially when we're looking for WMIC,
if we're looking for WMIC running,
it's going to catch it whether whatever the case may be.
So that's just one thing to look at when you run these kind of things.
And, yes, this does apply to other stuff.
And so there's kind of one that matched one of the samples that we were
looking at and one that matches the other samples.
Really, its phases of execution,
are we at the point where Excel is using DDE to launch another file?
Is Excel the parent process?
That's the more high fidelity.
And so that's why that's the requirement.
So #3 is, Does the parent process of rundll launch WMIC.
And then we can, in addition to the other indicators that are all there,
that's something kind of real quick that we can launch to try to detect that.
And then the same thing for if we happen to catch it
with Excel; #6 there is saying, Does Excel launch regsvr.
And that's kind of what we're looking at while simultaneously launching and
looking at the command line that's used to see if DDE is used.
So, again,
always to say just because that happens doesn't mean it's something bad,
but the more indicators we can get successively,
kind of even like a YARA rule.
So this is like a YARA rule for process execution on Windows to say,
If all of these are true, it's even more likely that it's bad.
And that's what this goes after.
So this will be available.
You can run this on Windows and modify it as you see fit in the exercise files.
I wanted to just present that real quick to get a
little bit of an endpoint perspective.
And then even as we talk about the endpoint piece,
really, a lot of these detections are if you find it,
what does that mean?
What happens if we actually find this?
Like we're in deduction mode, we find it,
that means we're infected, and we have to go to incident response mode.
So that's what we're going to talk about next.
How do we leverage these detections to help us with our incident response,
and what do we do to clean this up?