Hello, and welcome back.
In the last clip, we looked at how Zeek can extract files from network traffic.
In this lesson,
we will look at how Zeek can help with post‑mortem
analysis of a compromised host.
Zeek post‑mortem analysis looks at all the network events that
occurred after a host is known to be compromised.
I will start with looking at the activity that occurs on a compromised host.
Then we will transition to lateral network connections
that are made within the enterprise.
Next,
we will look at DNS requests that occur in and around the
time the Globomantics host was compromised.
Adversaries will leverage encryption for command and control
channels and throughout the kill‑chain phases.
I will talk about how we gain some insight into the TLS
traffic related to the compromised host.
Lastly,
I will talk about some of the ways we can use Zeek to identify
communications that go outside the Globomantics enterprise network.
When a host is compromised,
any activity that the attacker or malware performs on the
system will not be captured in the Zeek logs.
We will only capture the information that leaves the
workstation and traverses the network.
Even if the system has robust login and endpoint
agents that track malicious activity,
Zeek only captures metadata about network connections and will
not generally have things like commands executed or changes
made to the host configuration.
An attacker will usually want to gain access to other
systems and resources on the network.
This activity is known as lateral movement.
The incident response team has said that the compromised happened on June 10.
So if we scope the logs to that date as a first start,
we can look at all connections from the compromised host and
outbound other systems within the Globomantics network.
Not all these connections will be malicious.
The intent is to collect all the data,
and then analyze and determine what happened.
Adversaries will use DNS for command and control,
data theft, or even various DNS attacks.
If the compromised host made any DNS requests that were benign or otherwise,
the Zeek DNS logs will have the details.
The amazing thing about Zeek is that the protocol analyzers will detect
unencrypted DNS traffic even if it uses a different port,
so there is no reliance on DNS being strictly on TCP or UDP port 53,
so we only need to scope our search in the Elastic Stack
to cover the time period in question,
and then analyze the DNS data for any potential issues.
Encrypted communications are prevalent in enterprise networks.
Fortunately,
Zeek produces an X509 and SSL log that provides us with a lot
of insight into these encrypted channels.
There are open‑source fingerprinting techniques built
around analyzing TLS connections, such as JA3 and JA3S.
If you're familiar with Doug Burks and the Security Onion team,
they have included the JA3 in their deployment of Zeek.
When enabled,
you get an additional field in the SSL log that
will include the JA3 fingerprints.
We can use the Kibana UI to aggregate the SSL and X509 logs associated with the
compromised host and analyze the data for threat activity.
The eventual progression to TLS version 1.3 will introduce
additional challenges to monitoring encrypted traffic.
Monitoring the volume of TLS version 1.3 connections pre and
post attack could provide some value.
When a system is compromised,
the attacker will try to control that system remotely.
The communication channel can manifest in many forms,
but almost always results in a connection that is located
outside the network of the victim. Using the Zeek connection
log data in the Elastic Stack,
we can analyze all the network activity that originated
from the compromised host to an external entity and any
corresponding return traffic.