In this demo,
I will show you how to leverage Zeek data in the Elastic Stack to
hunt for indicators of network reconnaissance.
I will start with identifying the DNS servers and
zones that belong to Globomantics.
Then I will show some indicators of DNS recon in the Kibana UI.
With the help of the asset list,
I will identify any organic network scanners so we can
accurately assess any later suspicious findings.
After all of that,
I will show you how to enable the built‑in Zeek TCP scan detection script.
The demo will conclude when I show two examples of how to detect
network scans on the internal Globomantics network.
So we're back in the Kibana web UI. I have a saved query that will give us an
idea of the DNS servers in use on the Globomantics network.
The saved search eliminates some whitelisted servers and
scopes the results to the relevant subnets.
If we look at the destination IP, we can see a few of the
DNS servers being used on the network.
A visualization will show all entries including the use of third‑party DNS
servers. It does not hurt to compare the version of facts contained in the
data with the information on the asset list.
So far, everything looks as expected.
Now let us see if we can hunt down evidence of DNS reconnaissance.
I'm going to add another filter using the DNS question registered domain field.
We have documentation from the DNS administrator that shows globomantics.com
is the only authoritative zone served by the DNS servers.
We have identified the DNS servers and now know they respond to
queries for the globomantics.com subdomain.
Using that information,
we can look at the DNS question subdomain field and see if
we can find any anomalous activity. This time, instead of
clicking on the visualization,
I will add the field as an additional column in the search
results so we can quickly see if there is any strange activity.
Right away, it seems a bit curious that these requests are only
a few milliseconds apart.
However, that by itself is not anomalous without more context.
First, if none of these subdomains exist,
then it is anomalous, but let's keep looking before we
address the validity of subdomains.
I want to see the source IP addresses that are making these requests.
Wow, that is not good.
We have one system in our server subnet making 99% of these
subdomain requests that are milliseconds apart.
This, my friend, is a classic example of DNS
enumeration, and based on the source,
we could have a compromised system in the server network.
Globomantics.com has five legitimate subdomains,
but this attacker does not have that knowledge.
This is a rather noisy and high risk reconnaissance,
but according to a Cisco security research report,
91% of malware uses DNS in some capacity,
and 68% of organizations do not monitor DNS for security events.
So while this may seem unlikely, it is worth the effort to ensure
your hunt teams are checking for this type of recon. The DNS
response code tells us if a DNS request was successful or if some
error occurred. If we did not know there were only a few subdomains
that were legitimate,
then we could look at the response code and see if there were
a lot of failed responses to the requests.
This would be another confirmation. Response code
of two means the request failed,
which is consistent with our knowledge of the existence
subdomains. The correspondent name is servfail,
which just means the DNS server was unable to process the query.
There is one organic network scanner on the Globomantics network
that could be the source of this activity,
but the IP address does not match.
Therefore, this system will need to be investigated.
Now let's move to the console of the master sensor and look at
how we can enable the built‑in Zeek scan detection script and
then come back here and examine the data. I have remotely
connected to the Zeek master sensor,
which is also the management host for the cluster.
Any configuration changes for the cluster is made on this
system and then distributed to the other nodes.
In this case, I'm going to edit the local site policy.
If you are following along,
you should see a line that describes the scan detection script.
If you're using a custom deployment,
you may have to add this line manually if it was removed and
double‑check the scan.zeek file exists in the directory tree.
Once I've removed the comment, I will need to tell the cluster about the change.
This is done using the zeek redeploy command.
Remember to pay attention to the user account if you notice
errors. After the configuration change deploys,
we will move back to the Kibana web UI. The Zeek TCP scan detection script will
generate an entry in the notice.log whenever it detects a scan of hosts on the
network. We can view these messages by filtering on the notice.log and then
looking at the Zeek notice note field.
The scan port scan is what will be generated each time a scan is detected.
Selecting this field will give us the logs that are
associated with this message.
Let's take a look and see if we can find out which host performed the
port scan and which host was the victim. It looks like the victim was
the Globomantics domain controller and the system that performed the
scan is in the user network.
If you're wondering if we can detect these scans without
the performance hit of this script, then I have good news.
We can detect these scans by using the connection log and
looking for those one‑to‑many relationships.
I've saved us some time and created a dashboard that will quickly show
if a system has performed a potential port scan.
What you see on the screen is a dashboard that shows the top systems on the
network and the count of how many unique ports they have connected to in
the past 30 days. It is obvious that one system has been remarkably busy
compared to the rest of the network.
This is where things start to get even more exciting.
If I hide the 28.2 IP address, we can get a look at the rest of the systems.
It looks like the average is around 2 unique ports, so that 27.17 system with
14,000 unique ports against 1 system is guilty as charged.
This is great and does not depend on the scan script whatsoever.
Some of you are probably wondering how I built the dashboard, and I will
finish up this lesson by going through the settings.
You can pause the video at each point if you want to follow along and I've
included the dashboard in the course assets. Let's take a look behind the
scenes and see how this dashboard was built.
I used the conlog filter and the Zeek connection state,
which is set to S0 or a connection attempt that did not have a response.
This is typical in SynScan tools, such as Nmap.
I also copied the source and destination IP addresses to fit all the
subnets that reflect the Globomantics internal network.
Once you have these values,
then we can use some aggregations starting with the
horizontal axis that is comprised of the top source IP
addresses ranked by unique destination ports.
The vertical access is a unique count of destination ports.
The breakdown is the top destination IP addresses.
That's it.
You can adapt these values for hunting all sorts of
scan types. See you in the next clip.