In this demo,
I will show you how to verify that a Zeek file extraction policy is enabled.
This is the most important step in the process.
Once we have confirmation that the configuration is enabled,
I will browse to the directory that stores the extracted files and
take note of how many executable are already present.
After looking at a few of the files,
I will pivot to the Kibana web UI, where I will use the
information about the compromised workstation to find the
malicious file, fuid. Once I have the fuid,
I will go back to the Zeek sensor and identify the file on disk.
Let's get started.
I'm at the console of the management host for the Zeek cluster.
Remember, this host stores the centralized configuration that gets distributed
to the rest of the nodes. The local.zeek file is the recommended location for
local operational changes to the Zeek cluster.
We can view this file and check if there is an extraction policy enabled.
It appears that the default extract‑all‑files policy is configured,
and we also have the location for where all extracted files are
stored. In your own environment, you may find that the
ignore_checksum settings will avoid some issues with TCP offloading.
That is all we need to do here.
Next, I will navigate to the extracted_files directory and see
what we can find. The Globomantics system that was compromised is
a workstation in the user network.
When Zeek is configured as a cluster,
only the logs are sent back to the management host. The
extracted files stay on the appropriate sensor.
In order for us to view the extracted files,
I will need to remotely connect to the user‑sensor and
navigate to the path we saw in the local.zeek.
I could have started out on the user‑sensor, but I wanted to
show you this distinction. It looks like there are several
files that have been extracted.
The vector for the malicious file was through the HTTP protocol, so
let's see how many files we have that came from the web.
Nice.
I can see at least three potential candidates, but
we want to find the exact file.
The IR team said the notification of the compromise
happened on the 10th of June.
I could look at the file timestamps and make a pretty good guess as
to which file, but let's be a bit more thorough and head to the
Kibana web UI. We have the IP address of the compromised host, which
is 192.168.27.14, and the IR team has said that the compromise
happened on the 10th of June.
With that information, we can scope the data down and see if we can locate our
file. First, I need to filter the data by the files log. This is a good habit
to get into so you limit searching unrelated data. Then I will identify the
rx_host or the system that received the file, and select the IP address we
know to be the compromised host.
Now, before we continue,
I want to show you a few of the mime types that are
related to this compromised host.
Notice that the executables are not in the top of the list.
We could visualize and get a list like we did in previous modules, however,
that will not be necessary here, as we need the other
details associated with the log entry.
If I enter the mime_type field in the search bar and query
for Windows executables, we should be able to find the log
entry related to our file.
There we go.
Only one entry for June 10.
I could have also set the time period to only June 10.
As we go through this log file,
I want to pay attention to the IP address, the hash values, and most
important the fuid. We'll use this to identify which of the three
executables that were saved to disk is potentially the malicious file
deleted from the compromised system. It looks like our file is first in
the list. When I list the file,
you'll notice the date is June 11, so if we base our guess on
the date alone, we could have retrieved the wrong file or
incorrectly assumed it was not extracted.
Can you think of a reason why the date is different?
The sensors are all using UTC time zone, and the
Kibana web UI is using local time, which for me is Eastern Standard Time.
So if you do the conversion, 03:12 UTC is 23:12 Eastern
Standard Time. That completes this demo.
In the next clip,
I will continue this scenario as we talk about postmortem analysis using Zeek.