‑Okay, the worst has happened.
We're getting ready to go home, and we're super excited,
like a new show just dropped on like Disney+ and we
want to go watch it with our family, and,
of course, it's Friday afternoon and we have detected Dridex.
Because we watched the show in the morning,
we tried all the cool detections that we just learned about,
and we actually found stuff,
and now we have to stay through the weekend and respond.
What lessons do you have for us about this malware that are going to
help that individual who is in that situation?
‑Number of things that are actually quite unique and interesting with
Dridex and how they deliver not only the Trojan itself,
but then once that Trojan begins running.
So we'll look at using some tools like Arkime,
formerly known as Moloch,
we'll talk a little bit of maldoc analysis and I'll point you
to some scripts that are available there,
and then config extraction and some tools that can help pull out
additional command and control node information.
All of that as we look at the response phase.
‑Excellent.
And hopefully with these kind of key details,
we hope that individual will get out of there maybe
early in the night, or probably not.
Most likely at least they'll be able to get home before the weekend's
over if they can leverage some of these capabilities.
That sounds good.
What do you do first?
‑Yeah,
first let's take a look at ways in which we can discover already known URLs or
domains that are being utilized to distribute this Trojan.
‑When we talk about URLs, again, we came into this situation,
we've detected it,
and we probably only detected it one or two places now that we're in
scoping mode. What's the extent of this infection?
What's the extent of this incident response that
we're going to have to worry about?
And so we're going to leverage those URLs that you're
about to talk about to figure out, hey, let me try to detect it everywhere now.
‑Right,
so hopefully an organization has their own internal threat
intelligence feeds and the data that they can go back,
network data that they can go back and comb through.
There's a lot of great resources available online,
and the URLhaus, part of abuse.ch, is one of those.
A lot of support from the community, the threat research community,
to analyze malware families like dridex and get as much
indicators out there as possible.
Here you can see an example. We're just going to use
curl to interact with the URLhaus API.
We're going to filter by the tag Dridex,
so what this will provide us with is data on every URL that has been
submitted to the URLhaus that's been classified as Dridex.
And that classification comes from a number of sources.
It can be user submitted, so let's say you and I found some URLs right now.
We knew they were dropping Dridex.
We could tag that as we submitted.
Abuse.ch also has its own process of identifying and
adding those signatures as well, YARA rules,
and IDS actually plays a pretty big role in that infrastructure.
Once the response comes back, it's going to be JSON.
We'll pipe that through a very handy command line utility called jq.
If you haven't heard of it, jq will just help us to work with that JSON data.
So we'll filter it, and we'll extract just those URLs.
What this will end up looking like then‑‑‑here's some results.
These are from the time of the recording anyway,
the most thousand recent URLs that were submitted.
The database goes back quite a bit further,
and with their API being available,
you can search for a specific domain rather than just consuming what
has already been submitted in this broader list.
So this is a really great place to go and look.
I would say that if any of the requests in my
environment are showing up on the URLhaus,
there's probably an issue there.
Not only that, but oftentimes the URLhaus and abuse.ch,
they have other projects.
They do a really good job of providing those signatures.
You go to a place like VirusTotal,
and you'll get 74 out of 87 antiviruses detect this as bad.
Well, that's great, and it typically does better with files rather than URLs.
‑Who do you trust?
I don't know?
Do I trust the 74 or do I trust the other, like, 12?
I don't know.
‑And what is it?
That's the other thing is, how do you take 60 AD labels and distill it and say,
oh, this is Dridex or, oh, this is malware.
‑Well, it's bad.
That's all we really know.
‑That's all you really know.
So it does that distillation for you, so it can really be quite powerful.
So it has all of this data that's available.
It also has rule sets,
so we talked a lot about IDS now. You can get the the SSL malicious cert list,
you can get IP lists, you can get lists that are,
or rule sets that are made specifically for Suricata.
And I really encourage you to check those out.
Some of them are going to generate more noise,
and so it's something that you have to test in your environment,
maybe you don't deploy it across the entire enterprise.
All those things have to be considered.
The other thing that's interesting to point out here is you get a
pretty good example as to the number of just,
or the variety in the compromised hosts that Dridex is using.
While I'm sure none of these sites I would recognize,
as many of you probably wouldn't, they're all legitimate websites.
In fact, if you look towards the top, there's logitech.pe,
kind of a domain‑squatting sort of a scenario there.
It's not all WordPress,
although you can certainly see a lot of WordPress sites. Anything that has wp‑,
it's pretty strong indicator that that's a WordPress.
And then the resource, the file that's being requested,
there's a lot of .php, there's some .tar,
there's some .zip.
All of that's actually irrelevant because the response is returning a PE file.
‑Yeah.
And we mentioned there's no real obfuscation but they do
just variate the extension of the file,
even though it doesn't actually change the file.
‑Right, right.
So you'll see a lot of times the PHP files and
we'll even the .tar and the .zips,
they just have this sort of random‑looking name.
Something was generated in order to give those a name.
How the site is structured, how are they were able to compromise that,
what they ultimately have access to,
that's going to also dictate to an extent the full URL that they use.
Oftentimes, these hosts will serve multiple PE files,
there'll be multiple locations that they're set up,
different paths.
So just because you get a payload from one URL,
it doesn't mean that that same payload isn't six or
seven other places on that host.
‑Yeah, absolutely.
And then so we take these URLs that we just got back,
and now we're going to look for this activity historically in our environment.
That the ide?
‑Yeah, it can go either way.
If we're specifically concerned about a Dridex infection,
maybe some of the previous indicators that we've talked
about are leading us down that path, we might pull these URLs and say,
all righty, have any of these domains shown up in the environment?
That would be one way to do it.
We could take the URLs that we find and search for them on the URLhaus,
and then if they show up we might get better fidelity than on,
well, one, if they're even there.
If they're there, that's an issue.
And two, maybe get some classification.
We'll see some historical context because the
URLhaus provides not just the domain, but a lot of information about it.
When was it reported, those signatures as we talked about,
and other tags get applied to it.
And so it can help to better understand maybe the
broader context of the infection,
as well as maybe more data and more fidelity on what's going on.
‑And so we take these URLs, and these URLs are really what's
inside that maldoc, so on it goes all the way full circle back
to the maldocs in the first place.
So you mentioned before we might take a look at what that script looks like
and how it contains URLs that it's going to randomly select.
Do you have an example of that?
‑Yeah, so unfortunately,
we don't have the time to get into the analysis of a maldoc,
but that is something that I've spent a great deal of time on
and worked on with some colleagues as well.
An interesting thing with these Dridex documents is they embed a
lot of domains into the maldocs themselves.
And then when the maldoc executes, they decode,
they obfuscate these domains, and there's, last I checked,
four or five different techniques in which they do this obfuscation.
They decode those and then they pick one at random,
and so you could have a document that you execute once,
and it tries to reach out to host1.xyz.
You run it again and then it reaches out to host2.abc.
It can vary.
But because all of that content is there,
if we can extract all those domains,
now we can possibly obtain quite a bit better understanding
as to other network‑based indicators.
So you'll see this command.
It's a Python script that's actually available on GitHub under BromiumLabs,
and I'm sure we'll include a link in the course resources.
This script was designed really to recreate the logic in
the macro code to then parse the files, identify those indicators,
and you'll see it's just going to print them out to a file.
So this was one document,
and at the very end of this command I just cat the contents.
56 domains were extracted, so just from one single document.
So from like a threat research perspective,
the scale's really awesome,
because now we can just harvest these Excel docs and scrape URLs
and then submit them to the URLhaus all day long.
From an incident perspective,
this would be very valuable because I would want to look at
this and take any one of these domains now,
these URLs, and look for that in my environment, as well,
because maybe the incident I'm investigating,
two or three other people got the same document and it reached out to a
different node and had slightly different behaviors.
It was, it was a regsvr32 versus a RunDLL or something.
‑We can start to assume, and maybe it's not true,
but it's a great starting place to say that the email
addresses have the same URL at the end,
and if that was being sprayed out in kind of an automated sense that they
likely got the same document within a specific period of time.
And so excellent, yeah, from a behavioral perspective,
even from how an attacker changes the malware perspective,
it's reasonable to assume that at least more than one person,
if not your entire organization,
got hit with the same doc around the same period of time.
‑Yeah, right,
or slight variations of‑‑‑and this goes to highlight where not every
organization has the budget to have a full security team to include
malware analysts and threat researchers.
But just understanding that maybe there's some tools out there like
this script that can help for some quick wins,
really.
You don't have to get in and reverse engineer the maldoc or anything here.
You're really dependent upon the tool.
Of course, with that dependency comes, well,
if this changes, and this changes all the time. As we develop these scripts,
every couple of weeks they change something very
minor in how the macro code executes,
which then necessitates a change on our end.
And so if you're using our tool,
you become a bit dependent on us staying on top of things.
But as long as that tool source is staying on top of things,
it can be very valuable.
And having some malware analysis capability can be really helpful because you
may have never even known that this mountain of IOCs existed had you not been
able to pull these documents apart a little bit.
‑Yeah, and like you showed, a few seconds to grab the document,
run this against it,
and now that just really made your day from an incident response perspective,
for sure.
‑Yeah.
‑So where do we go from here?
What's what's our next step?
So, we have these to look for,
and now we're going to go look kind of for network indicators across
the environment? Is that the next idea? ‑Yeah,
so there's a few other,
there's some other data that's generated that can be helpful in
trying to observe this activity and broadening the scope in which
we're doing some of that discovery.
So we'll go back to to EveBox,
we'll take a look at a couple of additional alerts.
The two alerts we're going to focus on is the JA3 hash,
which is generated by Suricata as it's processing the network traffic,
particularly the TLS certificate information.
And then this other alert, which is in yellow,
which is the Executable Retrieved With Minimal HTTP Headers.
So let's start with the minimal HTTP headers because what this is telling us,
and when we talked about flowbits a little bit ago,
and saying, well, rules,
it's hard to make them understand broader context in
which they're generating alerts on, the traffic that they're looking at.
We can't really tie events together.
We can, but it's it's really limited.
And this is an example of that in that this minimal HTTP header is saying,
all right,
if I see an HTTP request that only has one or two or three HTTP headers,
that's probably from some sort of a script,
not from a user in their browser,
and therefore, it's more likely to be suspicious.
So let's set that flowbit, and then if in that same flow a PE file's downloaded,
all right, now let's generate our alerts,
and we hopefully have a little bit better fidelity on the situation.
And that type of TTP, then, we can use that to alert on all sorts of activity,
not just that minimal HTTP header, but really broadens the capability for
not only prevention and detection but even response.
Because another important thing,
a lot of folks think about IDS alerts as this sort of forward‑moving thing,
they're being generated in real time.
But if you have archival network traffic,
you can pull swaths of your traffic, run it through Suricata in offline mode,
and it'll go back and generate IDS alerts.
So let's say you're performing an investigation,
you've crafted this new rule,
now you can apply it to Suricata and go back and run a pcap from 24 hours ago.
And it'll generate new alerts based off of those
updated rules that you're using.
‑Yeah, that's amazing, and applause to you.
Great callout on the HTTP headers.
From perspective detection and behavioral detections,
like I said before, it's a big keyword for me.
What a really cool artifact of things being automated in
the way that that malware communicates, is to look at minimal HTTP headers.
That's a great callout.
Probably should put a note.
I'm sure we can find some sort of good writeup on that too.
Probably should put a note for that in the exercise follows as well,
because, like you said, that's more than just Dridex.
That's something we can use to chain to other stuff,
and I think is really, really helpful from a defender perspective,
start getting in that same kind of mindset.
That's one I hadn't‑‑I don't think I've actually used that one before.
So that's one that's excellent.
Thank you for that.
‑Yeah, so to help with that,
we're going to transition to one of my favorite tools, Arkime,
formerly known as Moloch.
Arkime is amazing in that it really makes it easy to look and hunt
and pivot through your network traffic, because it essentially
takes all of that network traffic data, particularly the metadata,
and it makes it a facet, it makes it so that we can search.
So I have a full course on Arkime if you're interested in that.
Again, we don't have time to get in all the details here.
But what we're looking at is this breakdown of HTTP‑specific data,
and not only can we see very specific data,
like the value from the hostname header or the user agent,
but then it also has the ability to interpret that data for us,
to say, well, let's look at the Has Src Header count.
And now using that property, we can create a filter,
and we could say, all right,
let's look for any HTTP request that has a source header count less than 4.
And now we've taken that rule,
maybe that was only looking for 2 or less and we've
made it a little bit broader, or we've made it certainly flexible.
Because now we're not writing rules at this point;
we're just exploring our traffic, and we're seeing the results that come back.
We're taking this this mountain of network data,
and we're starting to narrow it down.
Here we can see we have two requests.
Both of these requests are to a suspicious‑looking host,
a not very common TLD, a PDF file.
It's requested over port 80, and if we were to expand that session,
there's a PE file, and that, of course, would raise our suspicions even further.
And so now we've been able to take these broader techniques that we see
with how this malware operates and use that to turn that into a proactive
hunting technique to help us in kind of scoping,
or were there other hosts? I mean, that's probably the biggest goal here,
is how many‑‑‑can we identify maybe previously undetected malicious behavior,
or if we're in like that incident response mode,
are there other hosts that are part of this attack?
And we need to get them into scope and investigate and isolate and do all
the things that we would do in our incident response plan.
‑Right, and we're pattern matching at this point.
And when you're in the incident response flex motion,
we're pattern matching for our specific environment for the
infection in our specific environment.
So we got URLs, but we also have, again,
awesome callout on headers and not just using that as a behavior like,
oh, it seems like there's few HTTP headers.
More of, like, in this specific event that we're concerned about,
there's less than four.
And when I look across all of my network traffic,
that reduces that down to two sessions, and that should tell me something,
is we're taking behavioral indicators and using them as signatures.
And so, yeah, of course, we don't‑‑‑signatures versus behavioral indicators.
But still the behavior of less than four headers ends up being something we can
look for across our environment near all that traffic down,
like you said, identify their hosts that are exhibiting the same behavior.
And that helps us scope.
Now, we know what we need to do.
We can ring the bell and say, hey,
let's remediate all these devices and make some edge
rules to block this kind of traffic,
and then I can go home and I can watch my Disney+
show that just came out on Friday.
‑Those are the type of patterns that we can look for that can be
really powerful in trying to identify this suspicious,
malicious activity.
Another area that I'd like to focus on, then, is the JA3 hashes.
‑Yeah, please do.
Also, thanks, Salesforce.
And I want to make a quick callout.
Arkime is from AOL, just in case.
So thanks, AOL.
Lots of the time put into both these things that
are really helpful for all of us.
‑Yes, absolutely.
So sticking within Arkime, there is in the same view,
and Arkime has different views that we can look at the
data, this view's breaking things down by protocol, we
have the TLS. And this allows us, then,
to see not only just the raw data from the TLS session,
the certificate that went back and forth,
but then that data that it generated, the JA3 hash,
in this case.
JA3 hashes, again, it's not a precise science.
It does lend itself to false positives based off of the
way that this hash is being generated.
Previously, we were looking at HTTP,
and the reason that we could see the HTTP data is because
it wasn't over an encrypted session.
So either the connection just doesn't use TLS,
or maybe the organization is able to pry into that
secure connection to see that content.
Not as common as a scenario.
So threat actors that use a TLS session,
we lose visibility, but we don't lose total visibility.
We still have some information,
such as the hosts that they're connecting to and information from the TLS cert,
as well as things that can be generated.
So that's where the JA3 hash comes in.
It's generated based off of some of the data from the TLS certificate,
and it's another open source technology that you can go
to the GitHub and read all about it.
This hash, so any TLS session that is being recorded‑‑‑in this case,
the traffic is either being recorded by Arkime so it can do
the network capture for you on the network,
or it can also do pcap replay.
So it's going to generate those hashes.
And once those hashes are there, we can we can pivot on them.
So,
earlier we talked about the file hash and that if we took the
file hash and we filtered by the Suricata data,
it has that file information.
So any session that has that file hash, we can filter on that.
And then it's very similar here with the JA3.
We can now create a filter that says any session that
matches this generated JA3 hash, let me see it.
So here we have, what do we have?
Two unique sessions, two different hosts,
and they're communicating with the same hash,
but they're also over non‑standard and both different TLS ports.
And so maybe we had initially some observed bad
activity from one of these hosts.
Well, this JA3 would possibly allow us, then,
to pivot and get this other host into purview.
And certainly we would want to make that part of our investigation.
‑For Dridex specifically, the initial piece of this was,
it reached out and we see that behavior being over HTTP,
or not encrypted.
It's not using TLS to pull down the executable.
And that was kind of like that detection flow.
Now, if you have an active infection, the C2,
because we did do the certificate alert as well, that C2,
that's using TLS.
Is that true?
‑Right, yes.
‑And so now this allows us to then do, hey,
the first phase of attack, like,
if you saw these set of IPs or endpoints that alerted
on the HTTP with the PE download, then they got to that stage.
If we missed all of that and we just see C2,
it still means that probably happened in the past,
and we now have an active infection.
‑Right.
‑So really cool how we can use these different kinds of
detections to focus on different parts of even the specific
malwares like chain of compromise.
‑Yeah, yeah.
And and it's very common that the patterns to bring this back to
being a little bit more about Dridex again,
the C2, the command and control after infection,
very common for it to use TLS.
A number of different hosts.
Oftentimes it's going to communicate with those not via DNS.
It's not going to have to resolve the hostname; it's
just going to direct to an IP address.
It's also common to see these nonstandard ports as well.
And so another view on our network traffic would be to say,
show me any TLS session that is not to port 443,
and that might elicit something worth inspecting.
And then you could cross‑reference those IPs with some of the other
techniques that we've been discussing and help to understand.
It's sort of a blurry line we get into and then when you start
trying to really respond to an infection you kind of go into
this proactive threat‑hunting mode,
and maybe you're going to start uncovering other things you didn't know about.
And so you may take a note of that something is abnormal here,
but keep in mind the task at hand,
which is this infection that now we're trying to to really uncover,
unearth, scope, and begin mitigation and recovery.
‑Where do we go from here?
We have a really good, honestly, inspection,
pretty much, of every phase of this kill chain.
What are we missing?
There's just a couple of things left that I'd like to point out.
There's many different rabbit holes,
so I'm not trying to say these are the only things you have to look at,
but to me these are the big ones.
We can expand that network traffic in Arkime.
You just expand the session, and you'll see that more granular data,
just like with alerts.
We were drilling down with alerts.
So here we have information about the TLS.
Of course, we have the JA3 and JA3S.
We also have information about the cert.
So when was it issued?
When does it expire?
What is the subject organization, the subject common name?
And that also becomes information that can help identify
that a TLS session may be a bit suspicious,
because here is an example.
This is from Dridex, of course.
And those are really uncommon names for the subject common and the subject org.
And so creating signatures on that or using that to try to
pivot in the network data can yield results.
It's not always, but it certainly can.
And it's another piece of data, particularly with the TLS session,
that we can investigate to help us better understand what just occurred.
‑Yeah, and dare I say you could take that and use it in a Suricata rule,
like the rule that you showed us before in detection and kind of make
something that matches that certificate to go a bit faster.
Because we're looking at session data here,
and being able to filter by that's one thing; having a really
quick kind of PCRE detection can help too,
especially in processing a big mountain of data.
‑Right, yep, yep, absolutely.
And, again, even stepping back, again, for a moment from Dridex specifically,
you can look for just misconfiguration, OpenSSL,
default generated TLS certificates.
If I see Internet Widgits Pty, well, maybe that's not bad guys,
but maybe that's some self‑signed certificate in the
environment that shouldn't be there.
So there's still a lot of value in not just responding,
detecting threats,
but even in just trying to figure out what's going on in your networks.
The last thing is just a config extractor.
So a lot of malware, again, if you think about it in terms of, its software.
It's just the intent that changes, big picture. Like a lot of software,
it'll have configuration files.
And what what a lot of researchers and companies have gotten really good at
over the last few years is identifying those families that have
configurations and then figuring out how to extract them.
So Triage,
which is from more or less the same group that brought you the Cuckoo Sandbox,
they do a phenomenal job of writing these config extractors.
And so here you can see one of our samples from earlier today.
We have the tagging that runs in those sort of
color‑coded tags right underneath the score.
They did a great job of identifying this as Dridex,
and because they did that, they also have a config extractor.
So, now they've extracted all of the C2 notes.
And so with that information, we can, again,
take that back to the network, look for any communication to those IPs,
update our rules to block, whatever we need to do,
and it helps because it broadens that approach.
Just like with the Excel documents we talked about earlier,
there's 56 domains in that one document that we looked at.
And if we extract those,
we can be much more thorough in knowing where that document communicated to.
Same with the Trojan.
Now we can be much more thorough in knowing,
well, based on the configuration,
it has these three posts that it's going to communicate to,
so let's see if there's any traffic going there.
‑I haven't seen this before, so thank you for showing it to me.
Really, really cool.
Maybe a lot of other people have seen it, but just awesome.
Exactly what you said, we're in our incident response scenario,
and it would be great to have the information that
the C2's using for its config, and, here we go,
we have a tool to be able to do that.
That's going to make our day a lot easier.
A really great thing.
Again, we'll include some notes for this in the exercise files,
so this is phenomenal, great information to pivot off of.
‑Of course not every family has a config extractor created.
They're just kind of strewn throughout the internet as well.
But places like Cuckoo or, I'm sorry, places like Triage,
probably the most popular Cuckoo forks, CAPE,
they do a lot more with the config extractors. And much like
the conversation around the Excel docs,
it allows us to leverage some some really high‑level reverse engineering
skills without having to do it all ourselves. Because if we had to extract
these IPs, we'd either have to get lucky in the sense that if we throw it in
a sandbox that it's going to try to communicate with all three of them. Not
everything's going to do that. Or we have to have the time and the skills to
get into and do that extraction ourselves, which can be really time
consuming.
You could spend weeks just trying to reverse engineer something. In that
case, well, the damage is done. ‑The passwords are gone, man.
‑Yeah.
‑Leave them behind.
Yeah, yeah, don't look at your bank account because it's not going to be great.
So our focus here getting through the incident response,
a ton of great tools to really, how do I detect it, how do I scope it, if I do
detect it? So now I'm coming in and understanding every device that it's on.
Ideally, if we're looking at initial access and I'm trying to understand root
cause but really looking at phishing, likely a maldoc, and so we can stop that
capability by blocking maybe just that one file but maybe also blocking some of
these behaviors?
And then clean up all those devices.
So hopefully if you're responding to this,
you have some sort of automated SOAR capability,
you can click the button and it remediates, or your flashing drives,
that kind of thing.
But if you back up your user data. So really, really cool. Anything else you
wanted to add to that piece for the incident response?
Anything kind of left behind? Even recovery we can check for C2 with
that config. ‑Yeah, with this type of threat actor,
it's going to create noise on the network. It's
going to create noise on the host.
The modular behavior makes what happens on the host a little less predictable.
What happens on the network, I think, is a little more predictable,
although you could argue both ways.
So that's really where a lot of this focus has been. It is going to communicate
out; it does have a C2 network. That is how it's designed.
Of course, that can change, as all malware families do. They're just like
regular software. They evolve; they adapt. It's a constant back and forth with
understanding what defenders are doing and just tweaking things enough to get
past their detections and their capabilities.
But it's a great place to start. I think there's a lot of, fortunately for us,
a lot of strong indicators to build off of some really good research
that's being done. The script I mentioned with the maldocs, a colleague
is running that every day on all of the Excel,
or I'm sorry,
the Dridex documents that he gets his hands on and submitting that all to
URLhaus. And so there's some great communities out there. Much like we
saw with Cryptolaemus and Emotet, they're really focused on trying to
take that group down or reduce its operational capability and let law
enforcement take them down.
A lot of support around this, since it is one of the
more prevalent groups that's out there.
‑Yeah,
and that's always the idea. Even though like I can't go
physically arrest the person who launched the phishing
malware myself, but like you said,
like we saw with Emotet, that will happen eventually. It just will. And the
other piece of this is, in the meantime we can all work as a community with
things like URLhaus and other open source indicators. There's plenty of
people doing research, where we can make it more and more and more
expensive for the actors behind Dridex to operate, and expensive being
whether it's man hours, whether it's no return on investment,
whether it's actual costs, because these people get paid
too, or whatever it is, at some point, just like any other business,
there's a, hey,
I'm spending more money that I'm making. This really isn't worth it. And
the more we can do that across the board, but again,
this one's specifically about Dridex,
the less likely they're going to be able to continue to innovate quickly.
If they're making tons of money, they can pay people and completely outpace us.
They can be a really big dev shop.
But if they're not making any money and they can't pay
people, we start to get into how we're impacting their
business operations capability, like you said.