Lab Overview
In this lab, I explored Zeek’s readback mode using the http.pcap file. The goal was to gain familiarity with the various logs that Zeek produces when analyzing captured network traffic. This lab builds on the foundation of working with Zeek logs to understand how different IDs such as conn_uids and fuid are generated and how they relate across files.
Understanding Zeek IDs
One of the key takeaways from this lab is the distinction between static content in the logs and dynamically generated IDs:
- conn_uids: Unique identifiers for a connection.
- fuid: The file unique identifier that ties files in files.log back to specific connections.
Exercise 1
Run Zeek in readback mode using http.pcap to become familiar with the logs it generates. Begin by instructing Zeek to read the http.pcap file and produce logs:

This generates several log files:

We can see that Zeek has created five log files as a result of parsing the packet capture file. Let’s examine these.
Look at the contents of conn.log, which records the different connections observed:

You see a couple of lines of comments, including the field names followed by the field types. These lines define the structure of Zeek logs. Every log file that Zeek produces will be similarly headed, which defines the field names and types for that file’s contents in this instance.
It is difficult to tell the wrapped text, so we will use the zeek-cut command to present the output in a more coherent format. This command reads and formats log file output into a tabular format and should output Zeek-cut using a pipeline.
Let’s first look at the help for zeek-cut:

It’s time to put this tool to use. When we use it in our first run, we will supply several arguments to zeek-cut to modify the output:
-u option to print the time as a UTC timestamp. The raw output of time is in seconds and fractions of seconds since the UNIX epoch isn’t very human-friendly.
The ts argument indicates that we wish to see the ts field, which contains the time value.
The uid argument indicates that we wish to see the uniquely generated ID for this connection.
The id.orig_h argument indicates that we wish to see the IP address of the host that originated the connection.
The id.orig_p argument indicates that we wish to see the port number used by the host that originated the connection.
The id.resp_h argument indicates that we wish to see the IP address of the responding host in the connection.
The id.resp_p argument indicates that we wish to see the port number used by the host that responded in the connection.
The orig_bytes argument indicates that we wish to see the number of bytes sent by the originating host.
The resp_bytes argument indicates that we wish to see the number of bytes sent by the responding host.
Let’s put this all together to look at the connection log again:

This provides a much easier to read output than simply using the cat tool on the log file!
Next, see if you can figure out how to use the zeek-cut command to display the following fields:
- Number of packets that were sent by the originator
- Number of packets that were sent by the respondent
- The source port used by the originator
How many packets were sent and received in the connection where the source port is 36499?

35 packets were sent and 34 packets were received in the connection where the source port is 36499.
Next, try to use zeek-cut to display the source IP, source port, destination IP, destination port, and the name of the server in the only connection in ssl.log. What is the name of the server used?

The name of the server was www.google.com
The files.log contains data about any file Zeek finds in any connection for which it has an appropriate protocol analyzer that exposes files. This means that it doesn’t matter if the file was sent over HTTP, FTP, TFTP, or any other supported protocol that has the notion of a file; a record of that file transfer will appear in the files.log.
Use zeek-cut to display the file id (fuid), the source host, the destination host, and the connection id. Unlike the uid value, the fuid value remains the same for every run.

There is a single files.log record. You can discover the connections found in other logs with related protocol information (where that protocol understands files) by issuing a grep command for the unique fuid value

In what other Zeek log was the same file seen?
It was seen in the http.log file.
Now search for the connection id found in files.log to discover all the logs that contain information about this connection.
In which logs, other than files.log, was the same connection observed?

The connection ID was found in:
conn.log and http.log
This is helpful when you would like to find related activity for a given connection.
Extracting the file contents of the files referenced in files.log is very easy in Zeek. This can be very useful if you suspect some malware has been downloaded and you want to analyze the suspect file.
A Zeek script has been provided that will extract all of the files in a packet capture automatically. This file is in /sec503/Exercises/Day4/zeek/zeek-run/file-extract.zeek.
Use the Zeek script file-extract.zeek to extract the file:

A directory named extract_files is created in your current working directory. Change into that directory. You will find a single file within. When using this script, each extracted file has a name that begins with ‘extract’, followed by the raw timestamp:

Examine the contents of the file. What standard web server return code message does the www.google.com server return to the sender?

The message returned by www.google.com indicates that the requested document has moved. It is an HTTP 302 message.
Exercise 2
Description: Run Zeek in sniffing mode to examine traffic. Zeek is configured to sniff from the loopback interface on the VM. You will use the tcpreplay tool that can play back previously captured traffic. You will direct the traffic to the loopback interface where Zeek will be sniffing traffic.
I must be root to accomplish the various commands in this exercise. I used the sudo su command to become root:

Now you want to start Zeek Control with the zeekctl command:

Next, load all Zeek scripts with the install command:

Finally, tell Zeek to begin monitoring and logging with the start command:

Check to make sure Zeek is running with the status command:

we have provided a simple signature found in /sec503/Exercises/Day4/outbound.sig. We have also configured the /usr/local/zeek/share/zeek/site/local.zeek so that it is loaded when we start Zeek in live mode. local.zeek is effectively the master configuration for your Zeek cluster.
The signature provided looks for HTTP traffic with a source IP in the 192.168.0.0/16 range going to a destination IP not in that range. An HTTP request header that begins with “User-Agent” and is followed by any other content will generate a message of “Outbound HTTP traffic” in signatures.log.
Open another ssh connection to the VM. This is a second connection to the VM (use whichever ssh tool you’ve been using, just another connection). Elevate your permissions sudo su to root again. You must be root to execute these commands.
In this new ssh connection, change directories to /sec503/Exercises/Day4/zeek/zeek-run, where the http.pcap is located.
Run tcpreplay using an interface (−i) value of “lo” (loopback) and specify the http.pcap file as follows. You will see a bunch of messages and warnings; however, it should run successfully:

With tcpreplay complete, in this same ssh window as root, examine the file signatures.log in /usr/local/zeek/logs/current. This is the directory where the log files are created when running in live mode. Make sure you see the signature message of “Outbound HTTP traffic” in the variable event_msg in signatures.log.

Congratulations! You have successfully started Zeek in live sniffing mode with a customized signature that has detected some noteworthy traffic simulated by running tcpreplay. Zeek has generated files that allow you to examine the specific connection that triggered the signature.
Return to the terminal where you started Zeek in live sniffing mode. Enter stop to stop Zeek and then exit to exit zeekctl.
