So we just talked about a bunch of ways,
or maybe not a bunch, but a few locations in that Kill Chain,
and I love that we're all still bringing up Kill Chain,
even though MITRE ATT&CK is totally killing the Kill Chain.
I don't know, in my mind, that's how it's working.
But as far as breaking the chain of attack,
or the operations on the box from this specific malware infection,
it starts with the document.
And when we want to talk about prevention,
that's exactly where we need to look to start talking about prevention.
So, do you have some advice for what can we do to stop this thing from happening?
Like, we talked about stopping it from the HTTP from happening,
obviously, don't click the button in the first place,
but what are some technical preventions that we can put in place to stop
this from happening in the first place so we don't get further into
having to do a full incident response motion?
‑Well, probably the biggest one is just disabling macros.
If the organization,
and I know these sort of recommendations are usually hard
because everybody has a unique network, everybody has unique endpoints,
everybody deploys things different and have different needs,
but stopping the macros are really the first step,
whether it's the Salesforce style or the VBA.
If those macros can execute,
that really disables the threat right then and there.
Filtering on the emails, that's another step.
I mean, the further away from the user we can get,
I think the better, and layer things in,
the more likely that it's not going to get to them because then our
security really rests on that user not enabling that content.
From there,
we're going to see here in just a little bit a lot of
the process and behavioral patterns, both on the network and on the host,
and so seeing PowerShell launch from Excel.exe,
that's really odd,
I don't know very many folks that write legitimate Office
documents that use macros that launch PowerShell.
And so being able to, you know, if not prevent that behavior,
limit it, or at least be able to observe on it,
and know that maybe something has occurred on an endpoint.
We talked a little bit about these things change,
and so these Office documents, they're continuously evolving.
Oftentimes it's just minor modifications in order to bypass some endpoint
protection agent or or some filtering on its way to the endpoint.
And so we have to remain constantly vigilant on that
because they make a small tweak,
and maybe we were really reliant on them using PowerShell,
but all of a sudden, it's DLLs and run dll32,
and now they're bypassing these endpoints again.
So those are the sort of techniques that we really need to stay
up to speed on and make sure that in the environment we can
limit that to the max extent possible.
‑You mentioned one of my favorite keywords on security
keyword Bingo was behavioral detections,
and so I'm really excited to see what you have to share
about that because the more we can vector towards a
behavioral detection versus an indictor,
the less we have to change our prevention capability or detection capability.
‑Yeah, absolutely.
‑You have some documented behavioral action going.
Show me what you got.
‑Okay, so to start off with,
I'd like to spend just a little bit of time on those lures,
the images that are used inside of these malicious Office documents.
As a research project that I've personally undertaken,
I have found that those images can be a fairly strong indicator
for correlating threat activity and campaigns.
And so as you can see here,
extracting those images allows us then to identify related documents,
and again those related campaigns.
Threat actors, like Dridex, they tend to use a variety of different lures,
the lures being these images that are inside of the Office document.
And as we discussed, because these are,
the social engineering is really the primary point in
which they are attacking the user, they have to look very realistic.
Here's a Disney World one, one of my favorites.
I also have, as another example, one from Capital One.
And all of those common elements are present in this one as well.
We have the brand abuse from Capital One, as well as the Office theme.
We have some privacy sort of filter being employed,
arbitrary text being blurred out, and then we have that call to action.
The user needs to enable content in order to reveal whatever it is in
this document that they are being prevented from seeing.
So you can look at these images, and if you look at them enough,
you'll be able to identify the threat actors that are using them.
While there isn't right now a practical application
of this sort of image similarity, again,
it is actually quite a strong indicator because a lot of
these threat actors are using the same images or the same
group of images over their campaigns.
‑So, how is that working?
So you said that's a personal project of yours.
Are you, is that like an image hash, or like,
if we extract the image out and hash that image,
and now we're comparing those hashes?
Is that something that you're putting together for
connecting campaigns and documents?
‑Yeah.
So, that is pretty much the approach.
This technique has been applied for ransomware,
for example, looking at the images dropped by ransomware or the ransomware notes,
and can we correlate ransomware families off of those notes?
If you look at any group that is worried about copyright on their images,
there's an approach to say is anyone using an image that is similar to mine?
And this doesn't use straight hashing.
We don't take like an MD5 or a SHA‑1.
It actually uses a perceptual hash, which is more akin to a fuzzy hash.
And so we can get an approximation.
We can say, all right,
I have a collection of images that I've just extracted from all
these mail docs. Let's go with 90% similarity.
And once we've grouped them by that similarity threshold
using this perceptual hashing approach,
then we can connect them into these graphs,
and then from there,
we can assign them signatures and all sorts of really interesting things.
So if you're interested in that work,
there are some articles out there that discusses this,
as well as some code on GitHub.
‑Yeah, that's awesome.
I'd love to drop that in the notes for this course for everybody in
the exercise files so they can access that as well.
‑And then I Tweet it for every week.
‑Well, there's also that.
Yeah, so you won't let us forget about it.
That's good.
‑It's really interesting, though, because what happens,
as kind of a side note, you know, the classification of the document,
you might get one or two, but then three or four don't get classified.
Well, now if you've correlated them based off of the image,
and I have two images in this group that are classified and two that aren't,
we can sort of infer that the other two must have
been delivering the same family.
‑Interesting.
Yeah,
there's a ton of stuff you can start to infer between those connections as well,
and I can even see that being used as a a detection/prevention
capability when you're analyzing documents,
again, further away from the user.
That's really cool.
‑Yeah.
And on side note to the side note,
we do have a Cuckoo plugin that has operationalized this,
but that's way off topic.
‑Impressive.
Also, put it in the show notes, right?
‑Okay.
‑And don't stop Tweeting it.
‑Don't stop Tweeting it, yeah.
All right, so we've looked at the images.
To help provide a little better context,
here is one of these Dridex documents, just open it inside of Excel.
And you'll notice that there is yet another lure, another image being used.
There is the banner, the enabled content,
that's what they're trying to social engineer the user into clicking.
So, they will enable content, the macros will run.
Typically, the macros are tied into some lifecycle event,
like the auto open or the auto close, so that once they click the button,
the user's job is done.
Some documents will have a button like you see here,
OPEN AND VIEW, and that might additionally execute the macros,
but for the most part, the threat actors want a higher success rate,
so they're going to go ahead and they're going to have an auto capability,
auto open, run the macros when it's there.
Some stealthier actors actually don't do that.
They do rely on the button click,
and so you can think about that as sort of an anti‑analysis
technique and that if we throw this in a Sandbox,
our Sandbox probably isn't going to click the button,
but our users will,
and so they might look a little bit more benign as they're going
through the threat analysis at a larger scale.
‑That's really interesting,
especially just from a malware analysis inside of an
automated Sandbox perspective.
And kind of the first course in this series of prevention
and detection response also goes over why would you build
your own analysis capability.
Why would you have something like Cuckoo Sandbox or
build up your own analysis platform,
just a Windows 7 with a list of stuff loaded to analyze it.
And I always talk about that.
It's like,
there's lots of ways to evade or trick or be waiting for
user reaction as a piece of malware, in an automated sense that,
like stop execution from a Sandbox, that make it not 100% effective.
A great point, especially for this.
‑And that's one of the main reasons they would do that,
is just that the user is going to provide that manual interaction,
whereas the Sandbox at scale,
if I'm trying to analyze hundreds of these documents a day,
it's not an easy thing to do, and certainly,
I might miss that step as it's being introduced,
as these documents evolve and change over time.
And so it might go with much lower detection for several
days before I notice or observe that, oh hey,
I've got to click a button now in order to get these macros to execute.
‑Right.
And so this one is automated, though,
or you do have some automated samples you can show us executing.
Right?
Is that kind of what we're getting into?
‑Yeah, let's take a look at the first one.
Okay,
so we're going to go through a few samples here that are very exemplary
of how these these malicious Office documents operate.
We're going be using ANY.RUN,
a very popular online Sandbox platform with the Freemium model,
so anybody can go there, set up an account,
and start utilizing their capabilities.
Some things that I really like about the platform,
you'll see we have really three main components to our interface here.
We have the operating system view, which is the Office document right now.
To the right, we have the process activity,
so we can we can really observe what's happening on the system.
And then towards the lower left, we have all the network activity,
connections, DNS requests, IDS alerts, HTTP requests,
typically the really important stuff.
All of this information comes in in real time.
So when you upload a sample, it all starts to filter in in real time.
So here we can see an Excel document.
We have a Tesla lure.
Again, very similar to all the ones that we've previously discussed.
To the right, though, with the behavioral,
this is where we can really start to see some interesting patterns here.
We have our Excel doc.
So, Excel.exe, our main process.
When Excel launches, this would be very similar to Word,
Word.exe, or PowerPoint.
But the processes that it spawns are what are interesting.
So in this use case, we have Excel launching WMIC.
It's using some arguments to execute essentially another Excel document,
which it dropped itself.
And then that launches rundll32.
We'll notice that with those arguments,
not only do we see this sort of abnormal process behavior,
Excel launching WMIC, which is the Windows Management Instrumentation Console,
but then also run dll32.
You know, that in and of itself is pretty odd.
But the arguments also provide us information about where some of
these artifacts are written to the file system,
and so we can see that on these systems,
C:\Users\admin\AppData\Roaming\EDC6.xsl is a document that we could look for.
If we found these XSL documents,
likely the name is going to be generated randomly every time it runs,
but we could look in those folders,
and if we find evidence of these XSL documents there,
that could be an indicator of a possible infection or compromise,
very similar with the rundll32 command.
Rundll is going to be used to execute the trojan.
The trojans are DLLs.
So, it's not the same as what we would consider a normal executable.
These DLLs are being written to C:/Windows/Temp,
and then there's the name of the DLL, pjqbi.
And so we can now use that information about where these are being
written to the file system to either block write access,
which is hard to do with an app data folder,
that's why not only Dridex, but many threat family use that location,
but then also observe, maybe monitor,
or if we were doing some sort of proactive threat hunting
through maybe an EDR‑type solution,
we could look for evidence of these things in those locations.
‑Right.
Even from, you mentioned EDR,
from an EDR perspective trying to look at this for prevention,
I see a really good point here to say some of the more advanced EDR
will detect behavior of that process execution chain,
so like parent process launching this process,
which had originally spawned from Excel,
here you can see in ANY.RUNS does a really good job of drawing the little
line for you to tell you which one is the parent process.
Looks like Excel actually spawns a separate process as
opposed to being the parent for WMIC,
which would then also be an indicator in itself,
as it originally launched it,
and then removed itself from being the owner of that process.
That's another behavioral detection that EDR can use for this kind of thing.
Though, when you get into,
it depends what your environment is and how clean your environment is,
a lot of other software can do things that are similar to this.
So you have to kind of for prevention, like anything else,
EDR is just like IPS, that you need to tune it,
right, and make it and and test things before you implement a block rule.
Right?
‑Yeah, and that's the challenge with these sort of recommendations,
is we've touched on it earlier,
everybody's environment is going to be a little bit different,
and so you do have to spend the time monitoring,
observing, and sort of testing what happens in your environment,
and can you roll out a prevention technique based off of this process behavior,
and if so,
is it not going to impact any of your business
operations or any of your employees?
And so it does take a period of trial and error.
‑So that's what's happening on the device itself,
within the OS and processes, but I'm guessing there's,
especially since you mentioned the PE, kind of dropped the PE hints,
that's in the clear, it's going to ports that are not using TLS or SSL,
we can probably work on some detections there that we
can turn into preventions as well.
Is that accurate?
‑Yeah.
So, let's go ahead and talk a little bit about the network then.
One of the really important capabilities,
and it seems a little bit trivial when you look at a Sandbox
because it's all the data that you're looking at,
that the Sandbox is already filtering a lot of the
operating system level noise out.
If you've ever turned on Process Monitor from Sysinternals
on a host and started collecting events,
you'll understand what I'm saying.
It's a massive amount of information,
so it seems a little bit less important when it's already being filtered.
But one of the areas that is really hard,
but really valuable to draw a connection on is what
processes are making what network activity.
And with ANY.RUN,
you can see on the Connections tab that they are
drawing that correlation for us.
They are saying here are the process names,
the process IDs, and here are the connections that it's trying to establish,
and so that can be very helpful.
Although, again, in this scenario here,
it's a little bit more obvious as to most of this network activity
as related to our malicious Office document.
‑I do really like the idea of, and I run into this a lot,
especially with threat hunting,
is you look at everything going on in the operating system,
it's a lot of stuff, right?
And Windows does some weird things sometimes.
But if you narrow that down, it's like, okay, what's our chokepoint?
Like, how can we narrow this down?
Let's now get to processes that are reaching out to the internet,
and that like scopes you down quite a bit.
Now you can start to search through, like,
well, what's weird from here,
and kind of pull in other indicators to not have to look at so much stuff.
It's a great kind of methodology standpoint for this as well.
‑Yeah,
and that's hopefully one of the big takeaways that everybody
will get out of the session is that there's very few individual
alerts or signatures that will just will be an absolute 100%
something bad has happened.
A lot of it is contextual‑based, and looking at those TTP,
you know, looking at tactics, techniques,
and procedures, looking at patterns of behavior,
effectively filtering out the noise,
and sometimes we can do that in very broad swaths,
to say, okay, I don't want to see any activity that is to this set of IPs.
The other times we have to be a little bit more precise and say,
okay,
I only want to look at certain processes by name or by category or something.
And so it is very important.
And oftentimes we have to do that process of massaging
that data in order to get to and find the things that
we're interested in discovering.
‑ We're really just data scientists.
It's fine.
‑Yeah, I guess that's kind of where it's going, isn't it?
So with the connections, then,
it's important to not only understand what processes are
trying to create those network connections,
but then also where and how are they communicating?
So,
we can use the DNS tab to get a clearer picture of the
DNS names that are being utilized.
As I mentioned, typically with these Office documents,
they're going to reach out to compromise servers,
so they're not going to use an IP address to make a direct connection.
They're going to first resolve the domain name.
The challenge here is that they're compromised.
So, most of these servers are actually legitimate websites,
regardless of how unrecognizable their domain name is,
they're legitimate websites,
which makes it a little bit more challenging to
just block them at the perimeter.
Here you can see a few examples from the sample.
All of them would certainly raise my suspicion,
but if we were to visit them, and I'm not suggesting that anybody do that,
they're likely legitimate websites.
So we've got a domain name, that can be another indicator, right?
Here I see these rather suspicious domain names,
suspicious top‑level domains,
and that would kind of raise my curiosity and just
something bad is occurring on my network.
And from there, we can then move into the IDS alerts.
Now, for this particular sample, there really aren't any relevant IDS alerts.
There is one about a TLS handshake failure,
but that really doesn't matter in the context of what we're
trying to discover about this threat.
This threat is attempting to download a PE file.
I've said that most of the time the PE files will come from
those compromised servers in plaintext, so not obfuscated,
not encrypted,
and that's an opportunity to generate alerts from an intrusion detection system,
but all of those are absent here.
And so if we just let the analysis continue,
it eventually generates this message box that appears to be from
rundll that says there was a problem starting the DLL,
that is the argument, the path, for our rundll32 process.
Now, these message boxes, again, because they've written code,
macro code, they can simulate this sort of a message,
and that's something that some threat actors will do.
They'll give you an error‑looking sort of a message to
make it appear as if the document failed,
when in actuality, it actually succeeded.
In this case, though, this is an indication that the document failed.
It attempted to download the PE file of that DLL.
It wasn't able to obtain a valid PE file.
So that compromised host is no longer online,
DNS no longer resolves, maybe the DNS is sinkholed,
maybe the website owner actually is aware that they're
hosting malware and then they cleaned it up,
and this is a true error message.
So in this case,
the failures are that the malicious Office document got through to the user,
that they enabled the content,
but there is no persistent infection here because the
trojan never made it to the system.
‑Excellent.
And so when we talk about, again, reaching out,
trying to prevent this,
we're saying if that URL happened to already be on a bad
boy list somewhere and you had a threat feed at the edge
that was doing URL inspection, or even just DNS inspection,
and then cut off that connection, that would be a great place.
But again, they're changing those URLs frequently within this document,
so that's not necessarily even going to be a high
percentage of success for prevention.
Another point here is we see WMIC make an external network connection,
or at least being the source process for an external connection being made,
so maybe there's some sort of capability there,
though admins often use WMI internally.
Another tweak here is, hey, we use WMI internally,
we use it from maybe an admin server to
workstations or even between workstations,
fine, I mean not the best, but if you could limit that to say,
hey, this executable doesn't get to go external,
that'd be another great prevention point as well.
‑Yeah.
And I would assume, too, that standard user accounts,
just like PowerShell, if you disabled PowerShell,
with those standard users that, I don't know for sure,
but I would suspect that there's an ability very similar with our standard
users account to say you don't have this capability,
which would then be another potential to stop it from even getting
to the point where it can make that request.
You mentioned the domains, and with the compromised servers,
it's quite impressive how much infrastructure they have compromised.
We'll take a look a little bit more of the internals of this
document before the end of the session here,
and you'll see that all of these documents right now come
with 50 or 60 domains baked into them, and then it picks one at random.
So even with the one document,
you might get a different domain every time it runs
and tries to communicate with.
So, the odds that every single one of those domains is on a block list somewhere,
the odds, I think go down.
‑Right.
That makes a lot of sense.
And it's not like they don't understand that math, either, right?
That's on purpose.
‑Right.
Yeah.
They're just playing the numbers.
They figure eventually, they'll, you know,
the numbers are there, they have enough victims,
the techniques that they're using are working.
‑Okay.
So let's look at our next sample.
Here you can see process behavior is identical, or very close.
Excel, WMIC, rundll.
What I want to focus on are the IDS alerts because the IDS alerts are changing.
The context of what they're telling us about what occurred
on the network has changed a bit here.
We have this Suricata stream timeout.
You can ignore that one, that's just an underlying,
something kind of weird went on in the network.
The ones we want to focus on, though,
are the POLICY PE EXE or Windows file download,
and then the malicious SSL certificates.
So those are the two alerts that we can focus on.
So, what they're telling us is that with this document,
it was successful in retrieving that executable file,
the DLL.
That's what that first alert is telling us.
Now, we can't let that alert run all the time because,
as you may be thinking, well,
we probably have in any given network a lot of PE files being
downloaded on a regular basis because that's the primary
container for executable content in Windows.
But we'll get into the signature a little bit,
you'll see there's things called flow bits that allow us to
tie the executable download to other events,
so reducing the false positive noise,
making it more relevant to malicious activity.
Additionally, we see the use of an SSL certificate,
and so that clues us in to the fact that now the trojan
has switched its command control.
It's no longer using that compromised infrastructure,
which it does to retrieve the trojan,
it's now using a different set of infrastructure,
more permanent.
It uses things like secure sessions, and as you'll see in a little bit,
nonstandard ports, and other things that we can detect on.
So that's what that alert is telling us,
is that the trojan is now running on the system,
it's starting to beacon out, so you have a no kidding infection on this endpoint.
‑And so what I see from this is that this is very similar, but still changing.
I even see like what we're getting on the network traffic
is showing up a little bit different.
But we're also seeing that, like, I can't help but glance at the process,
but its capitalization is different for WMIC,
and so they're alternating a bunch of different
things to be able to avoid detection, or probably to try to avoid similarities.
So, are there more samples that you have that show kind of like another,
just another example?
‑Yeah.
The biggest difference between this one and the previous is
that there was a successful download.
So now we have an infection.
Some of the IDS alerts change.
Because of that change in network activity,
what's happening on the host itself via those processes is different.
The changing in casing of some of those words is exactly what you said,
it's oftentimes going to be used to try to bypass,
you know, very basic signature detection,
so a signature that's written to detect PowerShell.
If you've ever looked at the obfuscated code,
that's why you'll see the casing change,
or you'll see that they've taken the string PowerShell or WMIC,
and they've broken it up, and then they concatenate it back together.
It's very simplistic, but it's proven to be quite effective over the years.
The next sample, then,
that we have to look at is a couple of changes on really both of
those primary behaviors that we're observing.
First is that we don't see the WMIC rundll combination, we see regsrv32.
Different process, different operating system process.
It's one of those living‑off‑the‑land binaries,
but it serves the same purpose, right?
It's not a different payload that it's trying to execute,
it's that same Dridex DLL.
The other is in the network activity,
in that we not only have the observable detection of
that malicious TLS SSL certificate,
but we also have an alert now that's based off of this Feodo Tracker,
which it just is simply detecting based off of IP address.
The challenge with all of these is that they're
only as good as the data we have.
As soon as the threat actor changes its infrastructure,
if we don't have visibility into that yet,
then we don't have observability.
We can't have these alerts generated.
Dridex, much like the group formerly known as Emotet,
their infrastructure didn't change all that often,
and so we got pretty good at being able to track it
and to monitor and to observe it.
That didn't necessarily change their effectiveness,
but it did make it a little bit easier to know that when
something beaconed out to a command control IP,
that was a high fidelity alert.
‑Yeah, absolutely.
Again, this kind of reaches back to infrastructure.
A good point to call a definition between URLs and IPs.
Like, we all know this, but there can be multiple URLs and one IP,
but changing that IP if that's dedicated
infrastructure for them is much more difficult.
So yeah, that's something they'd have to,
especially if they have like a big network,
for C2, their bots, like changing that is kind of more of a bigger upgrade.
So, having these lists to be able to detect that, that's great.
‑You know, at the end of the day, the malware actors,
they're deploying software like normal, legitimate organizations.
Of course, there's some significant differences,
but some of the same challenges that anybody deploying software at scale has,
they have as well.
And so changing that infrastructure,
it's not something that they can simply just flip a switch,
and now they've got a whole new series of C2 nodes
that they can communicate with.
So,
there is just some inherent resiliency in the system of how all of this operates
and connects together that prevents them from moving along.
As I'd mentioned with Emotet,
they had massive operations for years before they were
finally taken out by law enforcement.
And so you might think that from their perspective,
what's the point of changing?
If people can see it and they can track it,
but it's not stopping us from infecting victims,
stealing their data,
then we'll just keep going with it until the pain of using those nodes and
operating that method becomes too great that it forces a change.
‑Yeah.
And that's, absolutely, keep making it costing them money,
too, just like it's costing us money and time.
And hopefully, we eventually catch up to them.
And then from, you know, kind of wrap up this prevention piece of it,
is we have endpoint EDR,
if we're talking about some advanced behavioral detections that
you have been able to apply in your environment,
they're not breaking other stuff,
there's a potential there to prevent that kind of
process execution based on the indicators.
It's talking about the parent process down to the target
process that's then also making a network connection and
the initiating part of that.
And if we can stop that initial connection,
like you said, it doesn't download the PE,
it doesn't launch, and we're safe.
And another point, probably much less effective,
is if we can notice that URL happens to be on a block list.
Although, again, they're compromised servers, right?
So, they are a legitimate server that they compromise and then launching from,
so kind of less likely to be on a list to be able to block.
But say we don't do those things,
I guess now we need to make sure that we're
detecting this live in the environment, right?
That's what we're going to talk about next.