We're now ready for our first hands‑on demonstration. In this demonstration,
we're going to start by exploring the Arkime viewer,
the viewer that we'll use in order to analyze our network traffic.
We'll then move on to identify key patterns and characteristics
of spear phishing‑related network traffic.
From there,
we'll extract some key artifacts from this network traffic
in order to perform further analysis.
And finally,
we'll wrap up this demonstration by discussing some techniques
that you can use to do proactive threat hunting.
For these demonstrations, I'll be using Ubuntu 20.04.1 LTS,
and I have already gone through the Arkime installation according to the
documentation that you can find on their website. Now,
as we previously discussed, there's really three components to this.
There's the viewer, there's the capture service, and then there's elastic.
Now,
you'll find that some of the components within Arkime
still use the older terminology, Moloch,
which is the case here.
We have the molochviewer.service.
We can use systemctl in order to check the status of the service,
and what we want to see is that it's active, or running.
If your viewer is not running, you can issue the start command,
and that should start the Arkime viewer.
If you run into problems with your viewer being able to start,
then you'll need to consult the documentation and
the FAQs on the Arkime website.
The next component is the capture service,
and this one we don't actually need to be running.
This could have an active state of failed.
Finally, there is elastic.
We can also use systemctl with a status command,
and we should see the same active, or running, state for elastic.
To see the viewer,
you simply need to open up a browser and navigate to localhost:8005,
which is the default port that the viewer listens on.
Now, you'll notice that we get an Oh no, Arkime is empty!
message, and that's fine.
There are usually two reasons that this can happen.
One is that we simply have no data in elastic yet, which is the case here.
The other is that we may actually be looking at a period of
time for which we have no network traffic.
When using pcaps,
we'll often get the timestamp that that traffic was originally captured on,
which means that even though we just ingested it now,
we have to go back to when it was originally captured.
We can check in the upper left‑hand corner the time frame that we're looking at.
By default, it's the last hour.
Selecting any one of these will cause the interface to update.
To the right, we have actual dates and times.
Selecting those will bring out a datetime picker,
and from there we can select a very precise start and end time.
For these demonstrations,
it'll be okay just to select all because the traffic
contained within these pcaps will be very short.
So how are we going to ingest those pcaps?
Well, I've provided a shell script in order to help facilitate this.
We won't spend a lot of time going through all the details here,
so I'll leave that up to you, but I will summarize it quickly.
This script will do three important things.
First, it will clear elastic so all previous data will be erased,
allowing us to focus on just the traffic from the
pcap that we're about to ingest.
It will then use the capture service in order to ingest the pcap.
And finally, it will restart the viewer.
Once the script is done,
you'll need a wait a few seconds before you try to
look at the data in the viewer, as it can take a little bit of time to populate.
Now we're ready to use the script.
We'll use the sudo command,
./ to tell the system to look in the current
directory to execute our shell script, and then the path to the pcap file.
This pcap file is also on my desktop.
We can now run the script.
You'll know that your network traffic is ready for analysis
when you begin to see data in the Session tab.
That is the main window when looking at the Arkime viewer.
One of the things we want to think about as we're analyzing
this traffic is how can we begin to filter this traffic down
to traffic that interests us, anomalies or something malicious?
One of the powerful features of Arkime is that just about
everything that you see can be applied as a filter.
For example, we can look under the destination port column.
Click on any piece of data that's present there,
and we'll get a pop‑out menu that allows us to apply that
particular instance of data as a filter.
Let's go ahead then and add port 80 as a filter for our query.
This will show up in the filter bar.
This is also a great way to explore the many filters and
their syntax that are available under Arkime.
Another location is to click in the upper left‑hand corner on the Arkime logo.
While maybe not the most obvious place to find help, this is where you'll
find all of the primary documentation for using the viewer.
Once we've added the filters that we want to apply,
we need to click on the search box.
This will adjust whatever view that we're looking at.
Our goal right now, though,
is to begin to narrow down all of the traffic that we're
currently analyzing to help us focus on something that's
anomalous or possibly malicious.
And we've done that already by filtering out all traffic
that did not communicate over port 80.
Why would we use port 80?
Well, HTTP commonly uses port 80 for non‑secure connections.
Thinking back to how we set up this demonstration,
we know that in a very common attack scenario threat actors
will use port 80 in order to make an HTTP request to download
the next stage of their attack.
As we begin to apply filters,
we should generally see the number of entries being reduced.
As you can see here, we only have five entries right now.
But let's pretend that we had more entries.
We could continue to filter.
Another good technique is to use negation.
So let's take a look under the information column.
We have in certain occasions the URI,
so oftentimes when there is an HTTP request that's being made.
We can click on that drop‑down and select the and not
in order to add that as a filter.
So that'll get rid of everything that matches this URI.
Now, this may be a little more precise than we need,
so we can further refine our filters by removing certain
components of the URI and maybe adding in a wildcard.
So we'll get just the domain and wildcard everything else.
And you can see we've now reduced the number of entries from 5 to 3.
Again,
this seems a bit trivial when we only have a few
entries to deal with in the first place,
but this can be a really good approach for helping you to get
rid of the known good traffic to help sift through and narrow
the scope of what you're looking at.
So what do we have left?
Well, we still have requests to domains that are likely good,
DigiCert and Microsoft.
It's very unlikely that something malicious is
coming from those particular hosts,
so we could continue to narrow or filter those out.
However,
we can see our last session includes a URI to a less
common TLD, top‑level domain. That is .ir.
Another piece of data that I oftentimes use is the Databytes/Bytes column.
This tells you how much data was returned, both in the request
and the response from that particular session.
Here you can see that we had quite a bit of data that was returned.
So if this is in fact a PDF file, it's a really large PDF,
and that stands out as a bit odd to me.
We can also use databytes in order to help divide our traffic, because
this can be used as filters as we're already doing.
We could look for sessions that have very large databyte sizes and
potentially identify downloads of malicious artifacts such as
executables or DLLs. When we're ready to investigate more details
about any particular session, we can click on the icon on the
leftmost side of the interface.
This will expand that session, and now we can get more refined details.
Not only do we get more details,
but you can see we have a lot more data that we could use as filters.
The first portion of this is about the TCP data. Of course, this data will
vary based off the protocols that you're investigating.
So if we scroll down a little bit further,
we'll see information about the application layer protocol, in this case,
the HTTP request and response, as well as additional
information that can be generated by Arkime, such as the MD5
hashes of the HTTP payload, that is,
the content of the body. We'll actually come back to
this information in just a moment.
Scrolling down yet a little bit further will show the
actual content from that session.
So here we can see the HTTP request which is on the left‑hand
side in red and the HTTP response, which is in blue on the
right‑hand side. For the request, you'll observe that there are very few headers.
This is often an indication of some sort of a scripting
language that made the HTTP request.
That is, they used very minimal amount of HTTP headers.
This is in contrast to our browsers.
Browsers tend to use a lot of headers when making HTTP requests.
So this is something that we can use in order to try to identify that
anomalous or potentially malicious traffic we can actually use this header
count in order to identify these particular sessions.
And we'll do that in the next demonstration.
The response is also quite odd in that while it looks like a PDF was
requested, we can see that it was a PE file that was returned.
There are a few ways in order to recognize this,
such as the first two bytes, which are the magic
numbers for a PE file; the DOS stub,
which is typically this program cannot be run a DOS mode; and then
there's some other elements of the file format itself.
So what would be the next logical step if we had identified
this type of traffic in our own environments?
Well, we'd likely want to investigate this PE file.
One of the quickest and usually easiest things to do is to
try to generate a hash of the file itself.
Since we can clearly see the evidence of the PE file in this HTTP response,
we don't need to suspect that there is obfuscation.
This means that we can use the body MD5 that was generated
by Arkime in order to search on other threat intelligence
platforms, such as VirusTotal.
What if we wanted to extract the file ourselves and
perform different analysis on it, such as additional static analysis,
or maybe uploading it to a sandbox on our own?
Well,
here we can use the viewer in order to extract that
file from this network traffic.
If you click on the show images and files, that will change the interface.
And instead of providing you with the content of the HTTP response,
it'll identify that as a file and turn it into a hyperlink in which you can
click on and then save that file to your file system. In our next
demonstration, we'll go ahead and we'll not only use some of these same
techniques in order to identify some malicious traffic,
but then we'll also begin to explore patterns in C2, or
command and control communications.