For our next hands‑on demonstration,
we're going to look at traffic from a couple of prevalent threat families
and use this traffic to discuss command and control patterns associated with
these threat actors to explore the use of HTTP protocol for post infection
activity and then to analyze C2 patterns so that you can better detect this
activity from other malware.
For the first pcap that we'll analyze, this is traffic that comes from emotet,
and this traffic covers not only the dropping of the
trojan from the malicious office document,
but then the post infection beaconing so we're
going to analyze both aspects here.
So for this example, let's start by looking at the databytes.
While we could select any data from that column and apply that as a filter,
we can also sort it.
So we can click on the arrow in the column header.
Clicking on it once will sort from lowest to highest,
clicking on it again will sort from highest to lowest.
And here, we can see that we have a fairly large request and response.
If we expand that session and scroll down so that we can
investigate the HTTP response body,
we'll see pretty clear evidence of our PE file as we
did in the previous demonstration.
We could now extract this file and do some analysis,
do some further research to try to identify the
family that this malware belongs to.
That is oftentimes the first step when performing this type of investigation.
So what could our next steps be?
Well, we have a start and stop time for this particular session,
so it stands to reason that post infection traffic will likely occur
sometime around when this trojan was downloaded.
Of course, that's not a guarantee, but it's a good place to start.
So now we can click on both the start and the stop time,
and what that will do is that will apply those time
values to our time and date range filters.
Of course, this is just the start and stop time for this particular session.
So what we'll want to do is expand that timeframe,
so let's increase the end time by 5 minutes.
After we make that adjustment,
we'll want to click search and you'll notice that we have increased
the number of entries that we wanted to view.
Now what we can do is we can sort based off of the start and end time.
I'm going to set the sorting so that the most recent
time from this traffic is at the top.
The third session down we can see the request for our trojan.
Then we have two sessions that come after that and
this is our post infection traffic.
We've already uncovered some pretty important IOCs and that we
have a destination IP for both of these hosts.
You'll also notice that the command and controls infrastructure has changed.
Trojan was initially downloaded from some compromised infrastructure,
likely a legitimate website that has been compromised to host the malware.
Now that the malware has infected that system,
it's using a different set of IP addresses,
it's not using compromised host,
and it's checking in information about that victim and gathering
further command information from that different network.
So our next step is to investigate.
What did the trojan communicate from our victim,
our internal host, to these command and control nodes.
We can expand the session and begin to analyze the information that it contains.
If we continue to scroll down,
we'll be able to investigate the full HTTP request,
the data that was sent from our victim to that command and control network.
In terms of the HTTP headers,
this one looks a little bit more proper and that we have a number of
normal HTTP headers that we would expect to see,
particularly from HTTP traffic generated by our browsers.
We also have some of the key headers, such as the referrer.
In fact, there are IDS,
intrusion detection system alerts that will generate just on HTTP
traffic that is missing the referrer header.
Scrolling down a bit further, we can see the body of this HTTP request.
Here,
we can see a small amount of data and we can determine that this
a small just by simply looking at the size,
each character represents a byte and there is a relatively small
number of bytes that were sent back to that C2 node.
Now, unfortunately, we can't understand,
we can't see what these bytes represent,
and that's because emotet uses encryption in order to protect that data.
So even though it's not using a TLS connection,
a secure connection to communicate over its command and control network,
it is encrypting the content that it's sending.
One thing we know for sure that we haven't seen a
significant amount of data leave the network,
and likely.
this is rather minimal information about this new victim
that is reporting in to its C2 network.
Let's briefly look at another pcap in which the emotet
infrastructure responds just a little bit differently.
With this pcap, we can, again, sort by the databytes,
and what you'll receive is that the session that comes to the top,
that is that has the largest bytes in the request response, is
the one that we're the most interested in.
If we expand the session and scroll down to the HTTP request response,
you'll notice that the request itself is a little bit
different than what we were previously analyzing and that's
because this pcap is a little bit older.
As with a lot of prevalent malware families,
they tend to evolve,
they change the patterns, the way in which they check into their
command and control networks over time and emotet certainly has been
one that has been very consistent in doing that.
However, what we want to focus on here is the response.
Part of the reason why this had such a large amount of data is
because the response that we got from the command and control
network is considerably large.
You'll notice, though, that unlike previous payloads that we have discussed,
this one is not clearly identifiable as a PE file.
It's a common technique to see prevalent trojans used to not
only infect the system and steal data,
as well as provide other remote access capabilities,
but also to drop other malware.
Unfortunately, we can't identify this with the traffic that we see,
but based off of the size of this alone,
I would be very suspicious.
While, not present in this traffic sample,
we may also see evidence of additional beacon ing from other malware
families and now we can use the same approach to investigate that
traffic as well to help us identify the type of malware that may
additionally have been dropped here.
Okay, let's look at one more pcap.
With this pcap,
we're going to switch to a different view and spend some time using SPI view.
Now the first thing you'll likely notice if you're using
the all timeframe is that the all date range is not
allowed for this particular view.
That's an easy thing to fix.
You can either adjust the timeframe based off of the drop‑down,
or you can simply add a second to the start time.
In either case,
this will avoid the error message that you're receiving and
allow you to analyze all of the traffic that is currently
present in your elastic cluster.
The SPI view, or session profile information view, is a great
view in that it takes all of the metadata about the traffic
that is within your Arkime cluster and provides it in terms of
counts and with categories.
As you can see in this tab, we have general information about our traffic.
We have a number of session counts based off of protocol such as UDP, TCP, ICMP.
We can dig deeper into that General tab and we'll see information,
such as the actual hosts, destination IPs, and source IPs.
We can use this to not only identify counts,
how much are we seeing any particular piece of data show up in our traffic,
but then also as another way to explore the different filters that we can apply.
Keep in mind when using the different views,
any filter that you build from any other tab is applied
to the current tab that you're on.
So if we had left some filters from our session tabs,
those would be applied to the traffic under the SPI view.
For performance reasons, not all the data is loaded when you go to this page.
An example of this behavior is with DNS,
it is not loaded,
but it is indicating to us that DNS has 10 entries that we could then
click on the Load All tab and then view that information.
As we scroll down,
we're going to actually use the user agent in order to
try to investigate this traffic.
Sometimes the user agent can be a very distinct piece of
information that we can use to simply pivot and explore on
what's going on in our networks.
This is a LokiBot example,
and LokiBot has historically used a very prevalent user agent name.
Let's add this as a query value and go back to our Sessions tab.
LokiBot is the type of malware that uses a panel, it's what the
administrators of that particular malware family logs into in order to see
the victims that it's acquired during their campaigns,
as well as to communicate with the infected systems.
So with a LokiBot infection,
one of the first things that it does is it checks into its
panel. We can see evidence of this with the URI.
Pin.php is the page that it's been configured to
check into for this particular panel.
We can expand the first check‑in. If we focus on just the
content that was sent with this HTTP Post request,
we'll see some pretty important information, although, not a lot of
data. We'll notice that our username likely has been sent to this
panel, as well as likely the name of our PC.
The response is also quite telling in that the panel is
configured to provide a legitimate HTTP 404 not found.
It also includes in the HTTP response body file not found.
So this is meant to mislead the analyst in thinking that even
though there was an infection in the environment,
it wasn't able to actually check in.
If we weren't sure about that,
we could continue to analyze the additional check‑ins that we have.
So let's collapse this and move on to the next one.
This traffic is a bit more revealing, and while we can see
patterns from our previous check‑in,
we also see a lot more data that was sent back to that panel.
Much like our emotet traffic, we can see a substantial amount
of content now has left the environment,
but it's in a form that we can't easily recognize.
So while we can most certainly be suspicious that a more substantial
amount of information has left from that host,
we don't know exactly what it is.
On occasion,
researchers will publish information about how to decrypt the
command and control traffic from certain malware families and
that's always a next step that I would recommend looking to see
if there is any published work,
scripts, or other help in trying to identify what this
traffic may be, but it's not always the case,
and the only option we have is to create a hypothesis based off of our analysis.
Alright, excellent work everyone.
You now have a better understanding of how C2 traffic looks, ways in
which we can leverage Arkime to analyze that, as well as we did a
recap on how we can identify those payloads, executables, and extract
those for additional analysis.
We're now ready to move on to our next demonstration.