‑Hey humans.
I am here today with Dr.
Josh Stroschein, and we're going to talk about the Dridex Banking Trojan,
ways that we can analyze its behavior to understand how to detect it,
prevent it,
and respond in case we get infected with that or we find it in our enterprise.
So, thanks, Josh, for being here today, I really appreciate it.
I'm excited to jump into this.
‑Yeah, thanks, Aaron.
I am also excited to be here and for all of you to be joining us as well.
To get started then, I've just got a few slides,
provide an overview, and then a brief introduction here,
and then we'll get into a lot of demonstration and hands on.
So, we'll start with an introduction to Dridex, what it is, and what does it do.
We'll then move into three primary categories,
preventing Dridex, we'll look at some tips and techniques for you,
helping you to prevent an infection, we'll talk about detection,
how can you identify key behaviors,
and finding those ever‑important indicators of compromise.
We'll look at response,
discuss some tasks that you should consider if in the
unfortunate case an infection occurs.
Right, so with that, I think we're ready to get into our introduction.
So a real brief background on Dridex.
Dridex has been around for quite some time.
It was first seen in early 2014,
and if you really get into the history of Dridex,
you'll see that it has evolved from some previous malware families.
So it has some genealogy and some code patterns that have stayed really
persistent as it's grown into the modern threat that it is today.
Dridex has a very modular design, and it has been consistently kept up to date,
which is one of the reasons why we're discussing it here.
The modular design then is something to keep in mind in that
while it is primarily a banking Trojan, because it is modular,
it does allow it to bring in additional capabilities,
and so we really need to consider this or view Dridex as an all‑purpose threat.
It is delivered primarily through malicious Office
documents using VBA and Excel 4‑style macros.
We'll get into those in a bit more detail here in just a bit.
And as I said, it's primarily targeting banking information.
It's able to perform web injects,
so stealing credentials directly out of the browser,
performing key logging,
as well as even taking screen captures to get that information,
but it doesn't limit itself to just that purpose.
With that modular nature, it allows it to expand its capabilities.
‑I have a few questions based on this and some other
malware that we've talked about in the past.
So the first thing is we talk about banking Trojans,
and I want to be clear that when we talk about what industry vertical that is,
we're talking about the customers for the bank,
right, this isn't malware specifically designed to attack Bank of America,
or JPMorgan, and Chase at their enterprise,
this is to attack the customers at their house,
is that accurate?
‑Yeah, yeah, that's that is absolutely correct.
The primary focus is getting in front of the everyday
user to steal their banking credentials,
to then steal money or whatever nefarious deeds they want
to perpetuate with those credentials,
and then also to make those systems part of this
larger botnet that then they become,
they can be utilized for spreading additional malware and other,
again other malicious activity.
‑Oh, I see, yeah, and then much like some other malware,
we've seen the trade access to other organizations or sell it off,
that kind of deal.
‑Yeah, they certainly can.
So it's important to think about where it's most relevant or where the
greatest opportunity is to prevent an infection from Dridex,
and with Dridex, as with many modern threats,
stopping the infection from the very beginning is
really the most important step.
As I previously noted,
Dridex is delivered primarily through Office documents using Word and Excel,
while it hasn't, I haven't observed any PowerPoint usage,
PowerPoint has the same macro capability,
so it is feasible.
‑I was going to say, these macros,
they're a little bit different because it's not
just necessarily just like a .vbs.
like the 4.0 macros are like a language that's kind of built into
the Office documents or the Office capability,
is that accurate?
‑Yeah, yeah.
The difference with, and why we differentiate between VBA and Excel 4,
Excel 4 macros of course are just limited to Excel.
They've been deprecated, and like many things that we see with Microsoft,
even though they've been deprecated for the newer style,
the VBA style, Visual Basic for Applications,
the OfficeSuite still supports them.
And so what's happened is that as they've kind of fallen
off the radar over the last few years,
Excel 4 macros I think were created back in the '90s,
they've been forgotten,
and a lot of our detection and our tooling has been
then built around the VBA style.
Because then they've been overlooked for so long,
when they were sort of reintroduced a couple of years ago,
they were stealthy,
and they were getting and kind of flying under the radar
of a lot of our security products,
and so they were quite effective of getting through the perimeter,
getting on the host, and then getting in front of the user,
so that they would hopefully enable the content.
Once they're in front of the user, it's very similar,
the enable content type of a ribbon, as as you see here,
they have to rely on the social engineering.
There really isn't a lot of exploit use.
A few years ago, 2017, there was the Equation Editor that was,
and it's still used to this day, but it was quite heavily used at the time.
And the power of that was that you didn't have to get
the user to interact with the doc,
you just were able to exploit it once they opened it on the system.
With the VBA and even the Excel 4,
most organizations are set up to block the initial execution of macros,
but they get the option, they still give the user the option to enable content.
And so they really rely heavily, and this isn't unique to just Dridex,
many threat actors that are distributing through Maldoc,
they rely very heavily on the social engineering.
‑Yeah, I think there's two awesome points,
as one, it's still users clicking buttons,
right, and then two, it's basically,
it's so old that we don't detect on it anymore,
like Excel 4.0 because it's been deprecating,
and so I would like to make a point on this one about just
because it's old doesn't mean it's more secure because there's
some groups that like to say like, oh, it's so old and secure,
like a mainframe, right, and that's not necessarily true.
It's so old it may not be in our signatures at that point.
So, awesome.
‑Yeah, yeah,
and while we don't have time to get into all of the
intricacies of how these documents are written,
something that I've observed with the Excel 4 macros is
there is a lot more anti‑analysis in them.
The code is written in a way to test for certain environmental variables,
is it a windows host, does the host have a mouse,
doesn't it have the ability to play sound,
and that also then contributes to sort of the stealthy nature
from the threat researcher perspective,
in that we throw these things in mass in a sandbox,
they look like they're benign,
and then they don't get pushed out into the threat feeds
that a lot of organizations are consuming.
So here you can see a really good example of that
social engineering I mentioned.
Oftentimes, there's going to be brand abuse.
Here you can see two brands that are being abused.
Walt Disney World is the primary,
and then there is the Office theme in the main image in the center.
Beyond that,
there's typically some enticement as to why the user needs to enable content.
In this case, it's because you've got all these,
this privacy feature that is blocking out certain critical content,
and this, what looks to be an invoice, a guest invoice.
So again, the real weak point here in the delivery is just getting,
once it's passed any sort of email filtering that the
organization is deploying or utilizing, it's really up to the user,
or how the environment,
how the organization has configured the environment to help prevent what
happens if this malicious Office document gets on the host.
Once, and if it, so if it gets to the user,
they enable content,
it's very typical for these to move into living off the land style techniques,
that is using built‑in capabilities in the operating system.
PowerShell has been prevalent now for quite some time,
rundll32, which we'll talk about today,
as well as Regsvr32 binaries that they can use on the system
to help avoid creating additional noise,
trying to limit what they're writing to the file system,
trying to limit the tools that they're bringing in.
So we'll see that in action today.
There are quite a few host and network‑based indicators,
and what we're going to explore is how you can identify them to help
with the identification and with the prevention.
And then finally, if you're following along with your MITRE ATT&CK bingo sheet,
this falls under MITRE ATT&CK T1566.001.
And how we're going to approach the discussion to their conversation is
really just kind of move through MITRE from left to right,
from delivery to infection, and some of the post infection activities.
‑Perfect.
Yeah.
Looking forward to it.
We're saying phishing is really the 100,
are we seeing anything other than phishing from this malware,
would be the main question I have.
‑This is primarily phishing.
I have not seen much else.
I can't say 100% that they don't have other techniques,
but by and large, the vacuum that has been left behind by EMOTET,
there's a question as to who's going to fill that,
fill that vacuum.
Is it going to be actors like Dridex or TrickBot?
And if so,
I think that those actors will continue to work in
the sort of at‑scale techniques, and certainly phishing,
and phishing campaigns is an effective at‑scale technique
for getting a large number of victims.
‑I was going to say that's a really good discussion
about the vacuum that's left behind, whether it's EMOTET going down,
or in the future, TrickBot is now taken down,
and who's feeling that.
It's not from a perspective of users are really sad because
they're not getting phished as much anymore,
that's certainly not it, it's more from an economic standpoint.
Within black markets, there is a desire to buy access to things,
there's a desire to buy valid bank emails,
there's a desire to conduct that criminal activity,
and that exerts economic pressure that creates a vacuum
where criminals will then fill that by being the new
TrickBot or in this case Dridex.
So, I think that's an excellent conversation.
‑Yeah, yeah, and with the phishing and the phishing campaigns,
that that scales well.
If you look at groups that may be attack organizations,
they go after infrastructure, they look for exposed RDP,
that's been an issue with the way that things have changed this last year.
Well, you can automate that.
I think there's also an element of that that's a bit more
manual and maybe even a bit more sophisticated.
So Maldocs unfortunately are going to be around for a while,
maybe eventually they'll go the way of the exploit kit,
but I don't see that happening anytime real soon.
Moving on to the Trojan itself,
so the delivery of the Office document is one thing.
It's one event part of an attack scenario that we
can focus on and try to prevent, but once that document gets in,
typically the next thing that happens is some network activity and
HTTPS requests in order to download the Trojan,
the loader, and it's modular.
So, once the loader is there, what we would see is the Dridex Trojan,
that means other things can eventually follow.
What's interesting about this is they use a vast
network of compromised infrastructure.
That compromise infrastructure is used to host the Trojan,
and recently that has been a DLL, or a dynamically‑linked library.
You'll see that it's still a PE file, a Portable Executable.
There's some activity that we can alert on on the network,
and we'll explore that here in just a minute.
In fact, you can see it on the screenshot,
or in this slide, and then how it's executed,
executing a DLL change is a little bit of what happens on the host via the
binaries that then are being utilized in order to execute that.
The payload typically is requested with a variety of file extensions.
That is the total red herring, the HTTP request is arbitrary.
We can create a request for anything as long as the server knows how to
respond with the content that the requester wants,
whether it's a .dll, or a .pdf, or a .jpeg,
or .zip, it really doesn't matter.
So they use a lot of file extensions, and by and large,
I assess that to just be a way to try to throw off your analysis.
The other thing that I think is a bit interesting is that
all of these DLLs that are on these compromised hosts are
unobfuscated and unencrypted.
That means that they're just sitting there.
While they're in their binary form, they're an executable file,
there's nothing taken to further obfuscate that.
That means that when they,
when the infected system makes the request for this payload,
then it can be easier to observe when it's coming across the network because oh,
by the way, they also tend to avoid using HTTPS or a TLS session at this point.
Okay, so last thing I want to talk about is just a generalized overview.
Let's lay out the sequence of events that we're going to look at today.
We start with our malicious Office document,
Word, Excel are the two predominant types.
We have macro execution, so social engineering,
the user, in order to enable that content,
VBA style or Excel 4, really the end result is the same,
that is to generate an HTTP request to download the next stage.
This is typically executed then by rundll32,
WMIC, it could be PowerShell, this changes a lot,
and so it is important to really keep kind of up to speed
with how these documents are evolving.
Because these are being delivered typically at scale to a number of users,
we tend to see not significant changes in their structure,
but regular enough changes that we have to constantly be monitoring how they
behave in order to understand how best to prevent and detect.
As I mentioned,
typically this is where the Trojan will be downloaded
from a series of compromised hosts.
That doesn't always have to be the case,
it's the predominant use case right now.
It could be that the DLL is actually embedded inside of the document.
So it could come along inside of that Office doc,
and then written to disk, and executed there.
But again,
the predominant use case right now is that a
request is made across the internet.
Now, if it fails to retrieve the Trojan,
then in a sense the infection has failed.
You still had a malicious document get in front of a user,
they still enabled content, so there's still plenty of issues to address,
but you don't necessarily have Dridex running on that system.
So again, some indicators,
some behaviors that we'll be able to look into to help you better
scope when Dridex has come after your organization.
And then finally, we move into post infection,
post infection activity, post infection traffic,
and this changes.
Certainly we see, on the network side, we see a change in infrastructure.
The C2 nodes that it now communicates with are different.
Typically it's not a quad, typically you see TLS,
and so everything changes a bit, and we'll explore that as well.
‑So we have the whole attack chain here.
When I look from like left‑to‑right on the screen,
obviously initial access, we have execution,
we then have like kind of a stage being brought down,
or a stager being brought down, and then now this is official infection.
So you're saying, the main thing I wanted to call out is like that,
that request goes out, if it's blocked in any way on,
whether it's on the network or on the device from
executing after it drops back down the DLL,
you don't, you're not infected.
There's no like additional logic within that document to tell us,
okay, let's try again later, or there's nothing dropped into memory to say,
hey, try this every 5 minutes or anything like that,
not that you've seen?
‑Right, not that I've seen,
and that's not to say it isn't possible because when writing macro code,
they're powerful, they're capable,
it is certainly possible that there could be some sort
of persistence mechanism built there, but generally speaking,
the macro documents, macro‑enabled documents are really kind of one shot.
If they get in front of the user, they enable content,
the macros run, they might try to make a request to one compromised server.
That's typically what we see with Dridex, that tries one request.
Some of them might loop through a whole series of domains,
and it'll try 5, 6, 7 in a row,
maybe there'll be a little bit of a sleep between the different HTTP requests,
but ultimately if it fails, then it fails,
and it's done.
It exits and it doesn't try again.
The document itself doesn't try to leave any sort of persistent thing behind.
If the Trojan's already there embedded in the document,
and that is able to run, then maybe that actually persists,
but again, that's not generally what we're seeing with Dridex.
So yeah, if it fails to make that HTTP request,
it fails to get the next stage, the actual Dridex loader,
then you can consider yourself probably lucky at that point.
‑Yeah, so that gives us a lot of opportunities,
defenders to look at,
prevention points in this kill chain that we can start to talk about it,
and really it's what we're about to talk about next,
so I'm looking forward to that.