0.5 Start Here: Your First Capture

Introduction

This is the last lesson of the orientation and the first one with evidence in it. It opens the capture Module 1 begins with, reads it three ways, and shows you how to work through the rest of the course. If your setup from lesson 0.4 is complete, every command here should give you exactly the output shown.

The capture is in the m01 folder of the lab pack. It records a few seconds of traffic from a small network: two workstations, a firewall, a web proxy and a DNS resolver on the inside, and servers on the internet beyond. Module 1 uses it to teach how a connection crosses a network and what each capture point can see. Here, it is simply the first evidence you open.

The lesson reads the capture three ways on purpose. capinfos says what the file covers. TShark shows the packets themselves, in order. Zeek turns them into logs that summarize the same activity. Each view answers different questions, and each misses things the others show, so an investigator learns early to move between them.

By the end of the lesson you will have used all three on the same evidence, and seen the same connection appear as packets in one and as a single log line in another.

Nothing here needs to be understood fully yet. Module 1 explains every field and every packet you see. The aim is to confirm your tools work, that your outputs match the course's, and to see the shape of the work before the detail.

Work from inside the m01 folder for every command in this lesson, and paste each command and its output into your command log as you go. When something differs from the lesson, the log is where you will find the reason. If you unzipped the pack where lesson 0.4 suggested, that is the folder called m01 in your nd directory.

Every exercise in the course starts the same way, and so does this lesson. Check the folder's files against the SHA256SUMS list that came with them:

$ sha256sum -c SHA256SUMS
inside.pcap: OK
outside.pcap: OK
hosts.txt: OK
traceroute-ws45.txt: OK

All 4 files report OK. That confirms you are looking at exactly the files the lessons were built on, and it is the first line of your command log for Module 1.

The check takes seconds, and it is worth doing every time you open a folder, not only the first. Files on a working machine get moved, edited, overwritten and half-copied more often than anyone expects, and a capture that has changed since you checked it is not the evidence the lesson describes.

Module 2 teaches why this habit matters in investigations, where the evidence you are handed may have passed through several people before it reaches you.

Notice what the check lists. Besides the two captures, the folder holds a text file describing the network's routes and address translation, and a traceroute from one of the workstations. Module 1 uses both; for now, they are context. Every folder in the pack has a file like hosts.txt or assets.txt that describes its network, and reading it before the captures is a habit worth starting now.

If any line reports FAILED instead of OK, stop and fix it before going on: unzip the folder again from the zip, or download the pack again if the zip's hash no longer matches lesson 0.4's.

The command itself is worth understanding, because you will run it many times. sha256sum computes a fingerprint of each file's contents; the SHA256SUMS file lists the fingerprints the files had when the pack was built; and the -c option compares the two, file by file.

Change a single byte in a capture and its fingerprint changes completely, so a match is strong evidence that nothing has changed. A missing file is reported as well, so the check also confirms the folder is complete.

Before reading any packet, find out what the capture covers: how many packets it holds and over what span of time. capinfos answers both, for each file you give it:

$ capinfos -c -u -a -e inside.pcap outside.pcap
File name:           inside.pcap
Number of packets:   128
Capture duration:    15.601059 seconds
Earliest packet time: 2026-11-09 19:42:03.288701
Latest packet time:   2026-11-09 19:42:18.889760

File name:           outside.pcap
Number of packets:   81
Capture duration:    14.642801 seconds
Earliest packet time: 2026-11-09 19:42:03.288895
Latest packet time:   2026-11-09 19:42:17.931696

The inside capture holds 128 packets over about fifteen seconds; the outside capture holds 81 over almost the same span. They started within a fraction of a second of each other, which is what you would expect from two capture points started together.

Those few numbers already raise questions, which is the point of reading them first. Why does the outside capture hold fewer packets than the inside one? Part of the answer is in the network: some of the inside traffic went only as far as the proxy or the resolver and never crossed the firewall.

Part of it is in what each capture point could see. Module 1's first lessons answer the question properly, and the habit it builds starts here: read a capture's extent before its content, so you know what any later finding can and cannot cover.

The time span matters too. Any statement you make from these captures is a statement about those seconds and nothing else. A host that was quiet in this window may have been busy before it, and the capture cannot say.

Write the counts and the times in your command log, exactly as capinfos printed them. When you run Zeek in section 4, its logs will cover the same span, and the counts are the first check that it read the whole file.

capinfos can report much more than this: the capture's file format, its link type, the snap length it was taken with, its data rate and the average packet size. The four lines shown are the ones to read first, because they bound everything else.

Module 2 adds the rest, and teaches how to tell from those extra lines whether a capture was truncated, filtered or taken with packets dropped, all of which change what it can be used to show.

Notice also that capinfos read the file without changing it and without needing any permission beyond reading. Every tool in the course treats the pack's files the same way.

Now read the first packets. TShark prints one line per packet by default: its number, the time since the first packet, the source and destination, the protocol, the length and a summary. The command cuts each line to fit the page, which drops the end of the longer summaries:

$ tshark -r inside.pcap -c 8 | cut -c1-84
    1   0.000000 1e:48:99:0e:4c:88 → Broadcast    ARP 42 Who has 10.20.30.1? Tell 
    2   0.000013 0e:fc:1a:26:c0:13 → 1e:48:99:0e:4c:88 ARP 42 10.20.30.1 is at 0e:
    3   0.000018  10.20.30.45 → 10.20.0.53   DNS 75 Standard query 0xf3b7 A www.ex
    4   0.000344   10.20.0.53 → 10.20.30.45  DNS 91 Standard query response 0xf3b7
    5   0.000497  10.20.30.45 → 203.0.113.80 TCP 74 40902 → 443 [SYN] Seq=0 Win=
    6   0.000518 203.0.113.80 → 10.20.30.45  TCP 74 443 → 40902 [SYN, ACK] Seq=0
    7   0.000528  10.20.30.45 → 203.0.113.80 TCP 66 40902 → 443 [ACK] Seq=1 Ack=
    8   0.002232  10.20.30.45 → 203.0.113.80 TLSv1.2 583 Client Hello (SNI=www.exa

Read it as a sequence. The first two packets are ARP: workstation ws45 asking which hardware address belongs to its gateway, and the gateway answering.

The next two are DNS: the workstation asking the resolver for the address of www.example.net, and the resolver answering. Then come the three packets of a TCP connection being set up to that address on port 443, and the first packet of a TLS handshake, whose summary includes the server name the workstation asked for.

That is a complete small story in eight packets: a workstation finds its gateway, looks up a name, connects to the address it got, and starts an encrypted session with the server it named. Every web connection on every network starts with some version of it, and most investigations in this course begin by finding one like it in a capture and asking what came after.

Notice what the summary does not show. Once the TLS session is established, the content is encrypted, and TShark can describe the packets but not what they carry. Module 6 teaches what can still be learned from encrypted traffic, which is more than you might expect and less than an investigator would like.

TShark can print any field it decodes, not just this summary. Module 3 teaches how to choose fields, filter packets and follow whole conversations; for now, the summary is enough to see that the capture holds what it should.

The time column is worth a moment too. It counts seconds from the first packet in the capture, to the microsecond, and it is the first place you see how fast a network exchange happens: the DNS answer arrived a fraction of a millisecond after the question, and the TCP setup took about the same.

On a real network those gaps are longer, and their sizes carry information about distance and load. Module 1 uses them to work out where each capture point sat.

Packets are the most detailed evidence, and the slowest to read. Zeek turns a capture into logs, one line per connection or protocol event, which are much faster to search. Run it on the inside capture, writing its logs to a folder of their own so they do not mix with the pack's own files or overwrite them:

$ mkdir -p /tmp/zeek-m01
zeek -C -r inside.pcap Log::default_logdir=/tmp/zeek-m01
ls /tmp/zeek-m01
conn.log
dns.log
files.log
http.log
packet_filter.log
ssl.log
tunnel.log
weird.log

The options matter. The -C option tells Zeek not to discard packets whose checksums look wrong, which is common in captures taken on the machine that sent them, because the network card fills in the checksum after the capture point sees the packet.

The -r option names the capture to read. The last argument sets the folder Zeek writes its logs to. Zeek prints nothing when it succeeds; the list of files is the evidence it ran.

Each log covers one kind of activity. conn.log has a line for every connection, whatever its protocol. dns.log, http.log and ssl.log have a line for each event of their kind, joined to conn.log by a connection identifier. files.log records files Zeek saw transferred. weird.log records things Zeek found unusual, which is worth reading in every investigation. tunnel.log and packet_filter.log record details of how Zeek read the capture.

Zeek also wrote these logs to the pack itself, when the pack was built, in the zeek folders of the later modules. Running it yourself and getting the same logs is a check that your Zeek behaves like the course's, which is worth doing once now and again whenever a lesson's Zeek output differs from yours.

Running Zeek also shows its first limitation. It wrote eight logs, but they describe only what was in this one capture: the inside capture point's view, for these few seconds.

Run it on the outside capture and you will get a different set of connections, with the firewall's address in place of the workstations'. Neither is wrong; each is a view from one place. Module 1 teaches how to read the two side by side, and the habit of asking which capture a log came from starts here.

conn.log is the log most investigations start from. zeek-cut prints the fields you name from it, and a short pipeline counts the connections by their endpoints, port, protocol and service:

$ zeek-cut id.orig_h id.resp_h id.resp_p proto service \
  < /tmp/zeek-m01/conn.log | sort | uniq -c | sort -rn
      2 10.20.30.46	10.20.0.53	53	udp	dns
      2 10.20.30.45	10.20.0.53	53	udp	dns
      1 203.0.113.80	10.20.30.45	3	icmp	-
      1 10.20.30.46	10.20.0.8	3128	tcp	http,ssl
      1 10.20.30.46	10.20.0.8	3128	tcp	http
      1 10.20.30.45	203.0.113.80	8443	tcp	-
      1 10.20.30.45	203.0.113.80	8080	tcp	-
      1 10.20.30.45	203.0.113.80	80	tcp	http
      1 10.20.30.45	203.0.113.80	5353	udp	-
      1 10.20.30.45	203.0.113.80	443	tcp	ssl
      1 10.20.30.45	10.20.30.46	8000	tcp	http

Zeek recorded 13 connections in these few seconds. Read the list from the top. Both workstations asked the resolver for names over DNS. One reached the proxy on its port, carrying HTTP and, inside it, TLS.

The other reached a web server on several ports, some with a service Zeek recognized and some without. And one line is ICMP from the server back to the workstation, which is a server saying something about a packet it could not deliver.

Each line raises a question an investigation would follow. Why did one workstation use the proxy and the other connect directly? Why did the second try several ports, and why did Zeek find no service on some of them? What was the ICMP message about? Module 1 answers all of these, and they are the kind of question every later module asks of a new conn.log.

The service column deserves a note. Zeek fills it in when it recognizes a protocol from the traffic itself, not from the port number. A connection to port 443 with ssl in the service column carried TLS; one to an unusual port with nothing in the column carried something Zeek did not recognize, or nothing at all. That distinction is one of the first things an investigator learns to read.

The mistake is natural because conn.log looks complete. It lists connections with their endpoints and services, sorted and counted, and nothing in it says what is missing. The habit that protects against it is the one this lesson has been building: read the capture's extent first, know which capture point the log came from, and ask what that point could not see before treating the log as the story.

Try one more pipeline of your own before moving on: print the duration and bytes of each connection, using the duration, orig_bytes and resp_bytes fields. You will see which connections carried data and which were only attempts, which is the first step in telling activity from noise.

Before moving on, it is worth listing what this first capture cannot tell you, because every investigation in the course asks the same question of its evidence:

The capture records which workstation sent each packet, by address, but not which person was using it; Module 12 teaches how to attach activity to an account and how far that attachment can be trusted. It records what was sent, but not why.

It shows that encrypted sessions happened, but not what they carried. And it cannot tell you, on its own, whether the capture point saw every packet; the next command, from the folder's notes, shows part of what you would need to know:

$ sed -n '1,9p' hosts.txt
# ws45: ip route
default via 10.20.30.1 dev eth0 
10.20.30.0/24 dev eth0 proto kernel scope link src 10.20.30.45 
# fw: ip route
default via 198.51.100.1 dev wan0 
10.20.0.8 dev dprx scope link 
10.20.0.53 dev dres scope link 
10.20.30.0/24 dev lan0 proto kernel scope link src 10.20.30.1 
198.51.100.0/24 dev wan0 proto kernel scope link src 198.51.100.10 

That is the firewall's routing and translation, recorded when the capture was taken. It says the firewall translates every connection leaving the network to its own outside address, which is why the outside capture shows a different source address from the inside one for the same connection. Module 1 uses that to teach what each capture point can and cannot see.

Writing down what the evidence cannot show is the habit the course treats as most important, and the one most often missing from investigations. You will practice it in every exercise.

A list like this is not pessimism about the evidence. Every item on it is a question that another source, or another module, can help answer: an account from the domain controller, content from a decrypted session or a file left on a host, completeness from the capture's own statistics.

Naming the gap is what tells you which source to look for next. An investigator who skips the list tends to fill the gaps with assumptions, and the assumptions end up in the report as findings.

Keep this list for the capture in your command log. When you reach Module 1's exercise, you will write the same kind of list for a new capture, and the answer guide will compare it with its own.

You have now done, on a small scale, what every lesson in the course does: checked the evidence, read its extent, read its content with two tools, and listed what it cannot show. The modules repeat that at increasing depth, and each one follows the same order:

Read each lesson with the pack open, and run every command as you reach it. Do the practice at the end of each lesson before moving on, because the next lesson assumes it. When you reach a module's exercise, answer every question in writing before opening its answer guide, then compare and resolve any difference by running the command that settles it.

Take the modules in order the first time through. The foundations in Modules 1 to 4 are dense, and everything after them assumes their methods. From Module 5 onward, each module stands more on its own, but the capstone in Module 14 draws on all of them.

Use the practice tool at the end of each module as a check before its exercise. It asks the judgments the module turns on, with real records from the pack in front of you, and it shows which lesson to revisit if an answer surprises you.

When you finish Module 14, take the course exam: a question pool drawn from every module, with case studies, which gives a verifiable certificate on a pass at 70.

When you are ready, begin with Module 1, lesson 1.1. It opens the same two captures you have just read and asks what each capture point saw.

Before you go, a word on pace. The course is long, and it rewards steady work more than bursts. A lesson a sitting, with its commands run and its practice done, gets you through a module in a week or two of regular sessions. Skipping the practice to move faster leaves gaps that the exercises find, and the capstone finds all of them.

Finally, keep your command log going. It started in lesson 0.4 with your versions and continues here with the checksums, the counts and the outputs from this lesson. By the capstone it will be a record of every investigation you have done in the course, which is useful in itself and the best evidence of what you have learned.

Versions this lesson relies on: Wireshark and TShark 4.6.9; Zeek 9.0.1 (LTS).