To install Zeek I copied the following into the terminal on my Ubuntu machine:

echo 'deb http://download.opensuse.org/repositories/security:/zeek/xUbuntu_22.04/ /' | sudo tee /etc/apt/sources.list.d/security:zeek.list
curl -fsSL https://download.opensuse.org/repositories/security:zeek/xUbuntu_22.04/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/security_zeek.gpg > /dev/null
sudo apt update
sudo apt install zeek-6.0

I then made a directory called "traffic"

And copied the zeek files to the ubuntu machine by using SCP from Kali to the Ubuntu machine:

I then edited my .bashrc file and added the following to the bottom of the file:

Deliverable 1:

To start I tested zeek with a simple command. I used the command sudo /opt/zeek/bin/zeek -i ens160 –C -w traffic.pcap and saved the traffic.pcap file in the "traffic" folder

I then checked the pcap file

Deliverable 2.1:

Deliverable 2.2:

There were 8 files created.

What do the files represent?

Conn.log - Network Connections

dns.log - DNS requests and responses

files.log - file transfers over the network

ocsp.log - Info about OCSP requests

packet_filter.log - active capture filters

reporter.log - Internal notifications and errors

ssl.log - SSL/TLS Connectioins

x509.log - X.509 Certificates

Deliverable 2.3 – Check the contents of the “conn.log” file. What do the headers in the file mean, and what do values such as (ts, uid, id.orig_h, id.orig_p, etc) represent?:

ts -The timestamp of when the connection was first made

uid - The Unique identifier for the connections

id.orig_h - The source IP address

id.orig_p - The source port

id.resp_p - The responding/destination port

proto - The protocol used in the connection

service - The detected application protocol

duration - The amount of time the connection lasted (in seconds)

orig_bytes - The # of bytes sent by the originator

resp_bytes - The # of bytes sent by the responder

conn_state - The state of the connection and it's outcome

local_orig - Indicates if the original sender is a local host or not

local_resp - Indicates if the responder is a local host

missed_bytes - The # of bytes missed in the connection

history - Shows a string describing the packet-level history of the connection

orig_pkts - The # of packets sent by the originator

resp_pkts - The # of packets sent by the responder

resp_ip_bytes - The total size of IP packets sent by the responder

tunnel_parents - Says if the connection was encapsulated in a tunnel

Using zeek-cut:

when using cat conn.log | zeek-cut id.orig_h id.orig_p id.resp_h id.resp_p proto What are the results displayed, and how could we add to those results the duration and a unique identifier for each entry?

Deliverable #2.4:

The results displayed are the id.orig_h, id.orig_p, id.resp_h, id.resp_p, and proto (which I described the purpose of in the deliverable above) and it show's these results in a more manageable and readable fassion.

To add the duration and a unique identifier for each entry all we need to do is edit the command like this:

cat conn.log | zeek-cut id.orig_h id.orig_p id.resp_h id.resp_p proto duration uid

Output:

Deliverable #2.5 – Where did you find the details for the domains you accessed in your testing? Provide answers for each of the three tests you made at the beginning of this part of the lab.

The details for the accessed domains are located in dns.log and we can find more specific information using zeek-cut

To access Zeek control we can use the command sudo /opt/zeek/bin/zeekctl and we will be given the zeekcontrol terminal:

Deliverable #3.1:

to get zeek to start properly you need to make sure that the interface in node.cfg is correct (in my case it was ens160) and then in zeekctl enter deploy and it will start properly.

Deliverable #3.2 – Answer based on that the following:

Print the disk usage stats

The df command allows you to check this

What scripts are currently loaded

The scripts command allows you to see what scripts are currently loaded:

What does the deploy command do

The deploy command starts Zeek after configuration changes or initializes Zeek processes based on the current configuration.

Where is the zeekbase and zeekscriptdir for Zeek

zeekbase: /opt/zeek/share/zeek/base

What is the running version of Zeek

6.0.8

Where are the logs of Zeek stored

/opt/zeek/logs

After unzipping the files I can the following commands in the pcap1 and pcap2 directories I made:

In pcap1:

sudo /opt/zeek/bin/zeek –Cr 2018-05-24-Trickbot-infection-in-AD-environment.pcap extract-all-files.zeek

In pcap2:

sudo /opt/zeek/bin/zeek –Cr 2018-05-24-Trickbot-infection-on-single-host.pcap

Deliverable #4.1 – After running the previous command, what changed in the directory where the results are stored?

After running those commands the files that were stored in each respective pcap file were extracted and stored in the pcap1 or pcap2 directories. You can see the results in the screenshot below:

Deliverable #4.2 – How can we check what file types are extracted?

By using the zeek-cut command we can cat files.log and check what file types are extracted by specifying the mime_type

Deliverable #4.3 – How can we identify each file and from where it was downloaded?

We can once again use the zeek-cut command but this time we'll specify the id.orig_h and id.resp_h:

Deliverable 5.1 RDP Brute Force Packets:

To start this I made a new Directory for this pcap and the log files called RDPTest and ran the command sudo /opt/zeek/bin/zeek -i ens160 -C -w test.pcap in order to enter promiscuous mode and read all the network traffic on the network. Once that command is running I went over to the Kali box and ran the same commands as I did in the last lab

Commands used:

crowbar -b rdp -s <ip-address> -U users.txt -C passwords.txt
hydra -L users.txt -P passwords.txt <ip-address> rdp

Crowbar:

Hydra:

XfreeRDP:

Now back on the XUbuntu we can ctrl+c the process and see that the log files and pcap have been made:

In the image you can see that there is a new log file that hasn't been there previously called "rdp.log" and we can use this file to analyze the traffic to see that chamuser had been successfully breached both times. I used the following zeek-cut command to narrow down the results to what was majorly important cat rdp.log | zeek-cut ts cookie uid id.orig_h id.orig_p id.resp_h id.resp_p security_protocol client_name and got the following results:

Xfreerdp cat:

cookie allows you to see the name of the user that had been rdp'd into and id.orig_h and id.resp_h allow you to see the IP addresses that were communicating with each other.

Deliverable 5.2 PsExec task:

Couldn't get to work

Deliverable 5.3 Mimikatz:

After making the new directory for the Mimikatz test I started the Zeek sessions using RDPTest and ran the command sudo /opt/zeek/bin/zeek -i ens160 -C -w mimi.pcap

Then back on the Kali box I started Sliver and used mtls to start the session between the Windows box and Kali and entered the shell:

And like the last lab, I entered the commands seen in this screenshot into the shell after changing into the C:\Users\champuser\Downloads directory.

Now on the Ubuntu machine, we can stop the session and if we LS the directory we can see a new file called ntp.log and weird.log where we will get the info we need from this traffic:

Using the zeek-cut command seen in the screenshot we can see that the Windows box (192.168.1.10) communicated with 89.116.246.10 in order to get the mimikatz password file

Weird.log shows any out-of-place network traffic that occurred on the network and because Mimikatz uses an address that is not commonplace on our network it shows what happened in this exchange in weird.log:

Deliverable 5.4 Exfiltration:

Once again I made a new directory for this test called exfil this time and I started the Zeek session with RDPTest and ran the command sudo /opt/zeek/bin/zeek -i ens160 -C -w exfil.pcap

With that started I switched over to the Kali box and started a PHP listener and ran the command systeminfo | findstr /B /C:"OS Name" /C:"OS Version" >> C:\Users\Public\Documents\Sysinfo.txt

On the Windows box you will see the file that was created:

Now we can end the Zeek session and check the directory

We can see that once again weird.log is back because of the strange network traffic that just occurred

The log shows us that 192.168.1.10 (Windows box) and 192.168.1.13 (Kali box) communicated and that there was a single line command that was run and caused something to happen on the Windows box (in this case it was making Sysinfo.txt)

Installing Zui:

I installed the Debian Linux version of Zui from this website https://www.brimdata.io/download/ onto my machine once that was installed I opened the terminal and entered sudo dpkg -i zui_1.18.0_amd64.deb and it'll install it properly onto the computer:

Deliverable 6.1:

There are 4 executables that you can see in the Trickbot-infection-in-AD pcap file and they're highlighted in the screenshot:

Deliverable 6.2:

This null session was attempted to a domain and not an IP like the rest of them. I used the filter _path=="smb_mapping" which can be achieved by either right-clicking on the smb_mapping sections or you can look up how to filter the results manually:

Deliverable 6.3:

This recording shows the filter command _path=="http" | "WinHTTP loader/1.0" which takes the path http and filters out all of the options that don't include "WinHTTP loader/1.0"

This lab was a lot. There was a lot of new software that I had never used before like Zeek and Zui but overall I enjoyed the learning experience. While confusing at some points I was very impressed by the versatility of Zeek. There was a point about halfway through this lab where I was having trouble figuring out what interface I should use to complete the Sliver deliverables but I found out that even tho the Kali box is on eth0 and the Xubuntu machine is on ens160 through the use of Zeeks "promiscuous" mode I could just set the interface to ens160 and it would still gather all of the traffic on devices running the same IP address.

Zui was probably the part I struggled with the most. Using Zeek to examine the pcap files in the command line was surprisingly easy but adding the GUI on top of that gave me whiplash since I had to figure out an entirely new way of sorting out the results. But once I figured out how filtering in Zui worked it wasn't so bad. I think my major complaint with that section is that was surprisingly hard to find decent documentation on how filtering works in Zui but with the help of some other classmates and further googling I was able to make it through just fine.