The network does not lie.
If a host is compromised remotely,
the attacker had to use a network. There's no way for them to erase the
fact that they made a connection or exfiltrated data.
Endpoint systems, however,
can be manipulated, such that even forensic techniques cannot determine
adversarial presence. In this module, we'll look at how threat hunters can use
Zeek to detect network recon and data exfiltration.
Then we will finish the module with how incident responders can use Zeek
to acquire evidence and conduct postmortem analysis.
There are many types and forms of network reconnaissance, but I cannot
cover them all in this course, so I will instead focus on DNS
reconnaissance and general network scanning in this clip.
According to the MITRE ATT&CK framework, DNS reconnaissance is
a network information gathering technique.
An attacker will try to enumerate the DNS infrastructure of
an organization in order to identify the DNS servers and
associated zone information.
This will provide valuable intelligence for any potential follow‑on attack.
Before we talk about detection,
there needs to be some reference that gives us validated
information about our DNS infrastructure.
The asset list can serve as that reference.
You can also contact the DNS administrator for details about
the configuration and security controls.
Once we have a solid idea about the composition of the DNS infrastructure,
we can use that information when we analyze the Zeek
DNS logs in the Elastic Stack.
The DNS log will contain the source system and the query
request made, along with the response code indicating if
the query was successful or not.
That combination of information in aggregate can help you determine
if a particular host is performing DNS recon.
If you host a public DNS server,
not much can be done to prevent enumeration of your
authoritative zones by anyone on the internet.
Internal DNS servers suffer from the same problem, and can be
enumerated by anyone on the internal network.
By design, an authoritative DNS server must answer queries for its own zones.
If these specific queries were blocked, then no one
could use the DNS for your zones.
You might say then, why should we care about someone looking up all
the DNS entries if it cannot practically be blocked and still
provide availability to legitimate users?
Well, there are several reasons.
In the case of an external DNS server,
the attacker will enumerate your DNS and learn about other systems
that are a potential vector into your network.
If you can detect the pre‑attack campaign,
then it becomes easier to correlate later attacks on those systems.
In the case of an internal DNS server, if you see enumeration,
then that is likely a possible indicator of compromise, or at the very least,
an anomalous event given the context. I should mention that
there are active and passive ways to get DNS information, so it
won't always be possible to detect.
It is crucial that you have monitoring in place for your DNS servers. On
the Globomantics network, the server sensor captures all requests to and
from the DNS servers, so we can use the Zeek logs in our SIEM to hunt for
evidence of DNS reconnaissance.
Some things you want to be on the lookout for are high‑volume queries from a
single host and unusual numbers of response code 2 and 3.
We will look at this in more detail later.
The 2021 Verizon Data Breach Investigations Report, or DBIR, lists automated
scanners as the top of the attacker opportunity funnel.
If you have a public‑facing service,
you are likely aware that there is a constant barrage
of scans from all over the internet.
There is value in understanding who might be targeting your organization and
being able to discern internet noise from a targeted attack, but in this lesson
our detection will focus on internal active scanning.
First, we need to understand what types of assets we have,
such as vulnerability scanners or other tools that perform
activities that will look like reconnaissance.
These systems will need to be white listed before analysts can
begin their hunts. Adversaries can and will operate within the
noise of your own network scanners, so you will need to conduct a
thorough risk assessment.
There have been a few times where I've seen junior analysts get excited
about what they thought was threat activity, only to find out it was
enterprise vulnerability scanners at work.
After we have our white list,
we can start looking at the Zeek connection log data and
try to find one‑to‑many relationships.
When a scan is launched from a system,
it will reach out to either one system and scan a few
well‑known ports, or a large range of ports.
Another technique is to scan an IP range or an entire subnet.
This will present as one host making several
connections to many other systems or ports.
Zeek comes bundled with a TCP scan detection script that will do a decent job
of detecting scans that have occurred in your environment.
There is a performance impact, which is why it's not enabled by default.
Earlier, I said that there are always scans happening at the border.
I have several of my own honeypots deployed, and I see hundreds of scans daily.
Most environments have massive investments on protecting the front door,
but we have years of evidence that the adversary only needs to
find one weakness in order to gain access.
We need to ensure that we have the capability to detect them while
they're trying to gain situational awareness.
In the next clip,
we will take a live look at how we can hunt for network reconnaissance.