Cyber Security Quiz: Wireshark Basics
10 questions · exam conditions
0:00
Wireshark BasicsQuestion 1 of 10

An analyst starts a Wireshark capture using the capture filter tcp port 443. After stopping the capture, the analyst suspects that the workstation also sent DNS queries during the same period and applies the display filter dns, but no packets appear.

Which conclusion is best supported by this result?

The DNS packets are hidden because capture filters take precedence until the capture file is reopened.
The DNS packets were probably not captured, so changing the display filter cannot recover them.
The DNS packets are present but must be displayed with the capture-filter syntax udp port 53.
The DNS packets were discarded because Wireshark cannot capture DNS and HTTPS traffic simultaneously.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Wireshark Basics

Practice Wireshark Basics in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Wireshark Basics, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An analyst starts a Wireshark capture using the capture filter tcp port 443. After stopping the capture, the analyst suspects that the workstation also sent DNS queries during the same period and applies the display filter dns, but no packets appear.

Which conclusion is best supported by this result?

  1. The DNS packets are hidden because capture filters take precedence until the capture file is reopened.
  2. The DNS packets were probably not captured, so changing the display filter cannot recover them. (correct answer)
  3. The DNS packets are present but must be displayed with the capture-filter syntax udp port 53.
  4. The DNS packets were discarded because Wireshark cannot capture DNS and HTTPS traffic simultaneously.
Explanation: Wireshark operates with two distinct filtering layers, and confusing them is one of the most common mistakes analysts make. Capture filters (written in BPF syntax) run before packets are stored — they act as a gatekeeper, deciding what traffic even enters the capture buffer. Display filters run after capture, letting you slice and reorganize data that's already been saved. The critical implication: if a capture filter excludes certain traffic, no display filter can ever recover it, because those packets were never written to memory in the first place. In this scenario, the analyst used tcp port 443, which captures only TCP traffic on port 443 (HTTPS). DNS queries typically travel over UDP port 53 — a completely different protocol and port. Because the capture filter blocked all non-HTTPS traffic from being recorded, applying the dns display filter afterward finds nothing. That's why B is correct: the DNS packets were almost certainly never captured, and changing the display filter cannot retrieve what was never stored. A is wrong because there's no "precedence rule" where capture filters hide packets until a file is reopened — packets excluded at capture time are permanently gone. C is wrong on two levels: display filters use Wireshark's own syntax (e.g., dns or udp.port == 53), not BPF syntax, and the real problem is absence of data, not a syntax mismatch. D is wrong because Wireshark can absolutely capture multiple protocol types simultaneously — that's a fabricated limitation. For the exam, remember this rule: capture filters decide what you keep; display filters decide what you see. If the data was never captured, no display filter can save you.

Question 2

Wireshark uses relative TCP sequence numbers for a connection. After the handshake, a server sends one segment with sequence number 1 and TCP payload length 600. The client then sends an acknowledgment with acknowledgment number 601.

What does the client's acknowledgment number indicate?

  1. The client received only byte 601 and is still waiting for bytes 1 through 600.
  2. The client received all data through byte 600 and expects the next segment to begin at byte 601. (correct answer)
  3. The client received 601 payload bytes because the acknowledgment field increments from zero, not one.
  4. The client is acknowledging the server's TCP port 601, not the sequence range of the data.
Explanation: Whenever you see a question about TCP acknowledgment numbers, anchor yourself to this rule: the acknowledgment number tells the sender what byte the receiver expects next, which is always one more than the last byte successfully received. In TCP, sequence numbers track bytes of data. Here, Wireshark shows relative numbers, so the server's segment starts at sequence number 1 and carries 600 bytes of payload. That means the segment occupies bytes 1 through 600 (inclusive). Once the client receives all of those bytes intact, it sets its acknowledgment number to 1+600=6011 + 600 = 601, signaling: "I have everything up through byte 600; send me byte 601 next." That's exactly what B describes, making it correct. A has the logic completely backwards. An acknowledgment number of 601 confirms receipt up to and including byte 600 — it does not mean the client is missing bytes 1 through 600 and only has byte 601. C introduces a false arithmetic rule. The acknowledgment number is not counting a total of bytes received from zero; it reflects the next expected byte offset in the stream. The client received 600 bytes, not 601. D is a category error. Acknowledgment numbers operate at the data-stream layer and reference byte positions, never port numbers. Port 601 has no relevance to this calculation. As a study habit, remember the phrase: "ACK = last byte received + 1." On exam questions involving sequence and acknowledgment numbers, sketch the byte range the segment covers, then add one — that's always your acknowledgment number.

Question 3

A Wireshark capture contains a TLS connection. The unencrypted ClientHello shows a Server Name Indication value of store.example, followed by encrypted TLS application-data records. The analyst does not possess session keys or a server private key usable for decryption.

What can the analyst most reasonably infer from this capture?

  1. The client likely requested store.example, but the exact HTTP path and response body are not visible. (correct answer)
  2. The client definitely downloaded the home page of store.example, although the response body remains hidden.
  3. The exact HTTP request can be reconstructed from the sizes and sequence numbers of the TLS records.
  4. The SNI value encrypts only the host name, while the HTTP path remains readable in application data.
Explanation: When analyzing TLS traffic in Wireshark, the key framework to apply is understanding exactly what TLS protects and what it intentionally leaves visible. TLS encrypts the application-layer payload — the HTTP request, headers, path, and response body — while certain handshake fields, including the Server Name Indication (SNI) extension in the ClientHello, are transmitted in plaintext so that network infrastructure can route traffic correctly. This means the analyst can confidently identify which server the client intended to reach (here, store.example) because SNI is unencrypted. However, without session keys or a decryptable private key, everything after the handshake — the encrypted application-data records — is opaque. The analyst sees that data was exchanged, but not what was exchanged. Answer A correctly captures this boundary: the destination hostname is knowable, but the HTTP path, method, and response body are not. Answer B is wrong because "definitely downloaded the home page" introduces a false certainty. The client could have requested any resource — an API endpoint, an image, a checkout page — not necessarily the home page. You cannot infer the specific resource from SNI alone. Answer C is wrong because while traffic analysis (using record sizes and timing) can produce probabilistic inferences in research contexts, it does not reconstruct the exact HTTP request. That claim overstates what metadata reveals. Answer D is wrong and describes the opposite of reality. SNI exposes the hostname in plaintext; it does not encrypt it. The HTTP path is inside the encrypted application data, not "readable." Study tip: On TLS questions, always mentally separate the handshake (partially visible) from application data (fully encrypted). SNI = visible; HTTP content = hidden.

Question 4

An analyst wants to display both directions of every HTTPS connection involving host 10.0.0.8. The capture also contains HTTPS conversations between other systems.

Which Wireshark display filter most precisely meets the requirement?

  1. ip.src == 10.0.0.8 && tcp.srcport == 443
  2. ip.src == 10.0.0.8 && ip.dst == 10.0.0.8 && tcp.port == 443
  3. ip.addr == 10.0.0.8 || tcp.port == 443
  4. ip.addr == 10.0.0.8 && tcp.port == 443 (correct answer)
Explanation: When filtering network traffic in Wireshark, you need to think carefully about two things: which host you're targeting and which direction(s) of traffic you want to capture. HTTPS runs over TCP port 443, so any filter must account for both the IP address condition and the port condition simultaneously. To see both directions of every HTTPS conversation involving 10.0.0.8, you need packets where that host appears as either source or destination, restricted to port 443 traffic. The field ip.addr matches either direction (source or destination), and tcp.port matches port 443 on either end of the connection. Combining them with && (AND) gives you exactly what's needed: D — ip.addr == 10.0.0.8 && tcp.port == 443 — captures every HTTPS packet touching that host, inbound or outbound, without over-selecting. A fails immediately because ip.src == 10.0.0.8 only captures outbound packets from that host — you'd miss all the returning HTTPS responses. B is logically broken: requiring ip.src == 10.0.0.8 AND ip.dst == 10.0.0.8 simultaneously means a packet must originate and terminate at the same host, which no normal packet does — this filter returns nothing. C uses OR (||) instead of AND, which is far too broad: it shows every packet from 10.0.0.8 (on any port) plus every port-443 packet in the capture regardless of host, pulling in all those other HTTPS conversations you're trying to exclude. A reliable study tip: when you need bidirectional traffic for a single host and protocol, always pair ip.addr (not ip.src/ip.dst) with && and the port field — OR logic almost always over-captures on these exam questions.

Question 5

On a client, Wireshark marks the TCP checksum of many outbound packets as incorrect. Applications work normally, and corresponding packets captured on a separate monitoring device show valid TCP checksums.

Which explanation is most consistent with both observations?

  1. The client is sending corrupt packets, but the receiving server silently repairs each TCP checksum.
  2. Wireshark recalculates outbound checksums incorrectly whenever promiscuous mode is enabled.
  3. Checksum offloading lets the network adapter fill in checksums after the local capture point observes packets. (correct answer)
  4. TCP acknowledgments make checksum validation optional once the three-way handshake has completed.
Explanation: When you see a question pairing a local capture tool showing errors with a remote device showing valid packets, think about where in the packet's journey the observation is being made — this is the key to unlocking the scenario. Modern operating systems use TCP checksum offloading to improve performance. When your OS hands a packet to the network adapter, it intentionally leaves the checksum field blank or zeroed, letting the NIC hardware compute and insert the correct checksum at the last possible moment before transmission. Wireshark, however, captures packets at the OS/kernel level — before the NIC fills in the checksum. This is why Wireshark flags those checksums as invalid locally, while a monitoring device downstream sees perfectly valid checksums: the NIC did its job, just after the local capture point. This makes C the correct explanation — it perfectly accounts for both observations without requiring any unusual behavior. A is wrong because TCP has no mechanism to "repair" incoming checksums — if a corrupt packet arrives, the receiving host simply discards it. Silent repair doesn't exist in the protocol. B is wrong because promiscuous mode affects which packets Wireshark sees (all traffic vs. only traffic addressed to the host), not how it calculates or validates checksums. These are completely independent functions. D is wrong because TCP checksums are not optional at any stage of the connection. The three-way handshake has nothing to do with whether checksum validation is enforced — it always is. As a study tip, remember that checksum offload is the go-to explanation any time you see Wireshark reporting checksum errors on a machine that's otherwise functioning normally. It's one of the most common "gotcha" scenarios in network troubleshooting questions.

Question 6

A packet captured on a workstation has these fields: Ethernet source 00:11:22:33:44:55, Ethernet destination 00:aa:bb:cc:dd:ee, IPv4 source 10.20.30.40, and IPv4 destination 198.51.100.20. The Ethernet destination belongs to the workstation's default gateway.

What is the most accurate interpretation of the destination fields?

  1. The gateway is the application destination, while 198.51.100.20 identifies the next local Ethernet hop.
  2. Both destination fields identify the gateway, but Wireshark resolves one as an external address.
  3. The frame is addressed to the gateway for local delivery, while the IP packet is addressed to the remote host. (correct answer)
  4. The differing destinations prove that the frame was altered by an attacker after leaving the workstation.
Explanation: Whenever you see a question involving both Ethernet (Layer 2) and IP (Layer 3) destination fields, remember that these two layers serve different scopes. Ethernet handles local, hop-by-hop delivery, while IP handles end-to-end delivery across the entire network path. These goals are deliberately separate, and a captured packet will almost always show different destination addresses at each layer when traffic is leaving the local network. In this scenario, the workstation needs to reach 198.51.100.20, which is an external (non-local) host. The workstation knows it can't deliver that packet directly, so it wraps the IP packet inside an Ethernet frame addressed to the default gateway's MAC address (00:aa:bb:cc:dd:ee). The gateway receives the frame, strips the Layer 2 header, reads the IP destination, and forwards the packet onward. This is exactly what C describes — the frame targets the gateway locally, while the IP packet targets the remote host end-to-end. C is correct. A has it completely backwards. 198.51.100.20 is the IP destination (the remote application endpoint), not an Ethernet hop identifier. The gateway is the Ethernet destination, not the "application destination." B is incorrect because Wireshark doesn't fabricate or resolve one destination into another. The two addresses belong to different protocol layers and are both real; no tool is "resolving" one from the other. D introduces a false threat narrative. Differing Layer 2 and Layer 3 destinations are completely normal and expected for any traffic leaving a local subnet — not evidence of tampering. Study tip: Always ask yourself, "Which layer am I looking at?" When traffic crosses a router, the MAC destination changes at every hop, but the IP destination stays constant all the way to the final host. That distinction is a frequent exam target.

Question 7

A DNS query from a client to its configured resolver contains transaction ID 0x41a2, the query name portal.example, query type A, and a flag indicating that it is a query rather than a response. Several DNS packets follow.

Which packet is the best candidate for the corresponding DNS response?

  1. A resolver-to-client packet with ID 0x41a2, the response flag set, and an answer for portal.example. (correct answer)
  2. A resolver-to-client packet with ID 0x41a3, the response flag set, and an answer for portal.example.
  3. A client-to-resolver packet with ID 0x41a2, the query flag set, and the name portal.example.
  4. A resolver-to-client packet with ID 0x41a2, the response flag set, and an answer for mail.example.
Explanation: When a DNS resolver responds to a client's query, three fields must match the original request exactly: the transaction ID, the direction (response flag set), and the query name. Think of the transaction ID as a ticket number — the response must return that same ticket to prove it belongs to your question. Option A satisfies all three conditions: the transaction ID is 0x41a2 (matching the query), the response flag is set (confirming it's a reply, not another question), and the answer is for portal.example (the name that was actually queried). This is your correct answer. Option B fails on the transaction ID — 0x41a3 is off by one. This mismatch is the hallmark of a DNS spoofing attempt, where an attacker floods a resolver with forged responses hoping one lands before the real reply. A properly implemented resolver will silently drop any response whose ID doesn't match the outstanding query. Option C fails in two ways: it's a client-to-resolver packet with the query flag set, meaning it's another outgoing question, not an incoming answer. Responses always flow from resolver to client. Option D has the correct ID and response flag, but answers for mail.example instead of portal.example. A mismatched query name — even with a matching transaction ID — indicates either a misconfiguration or a forged packet, and should be discarded. Study tip: DNS response validation is a favorite exam topic because it directly ties to cache poisoning attacks. Always check all three fields — ID, direction flag, and query name — as a complete unit.

Question 8

A plaintext web application uses TCP port 8088. Wireshark labels its packets as TCP rather than HTTP, but following the TCP stream reveals readable text beginning with GET /status HTTP/1.1.

What is the best next step to make Wireshark dissect the traffic as HTTP?

  1. Change the displayed destination port to 80 so the packet headers identify the protocol as HTTP.
  2. Apply the capture filter http port 8088 so the existing packets are decoded again as HTTP.
  3. Install the server's TLS private key because all traffic on nonstandard web ports is encrypted.
  4. Use Decode As to associate the relevant TCP conversation or port with the HTTP dissector. (correct answer)
Explanation: When Wireshark captures traffic on a nonstandard port, it won't automatically know which application-layer protocol to apply — it just labels everything as raw TCP. The key concept here is protocol dissection: Wireshark separates capturing packets from interpreting them, and you can manually tell it how to interpret a conversation after the fact. The right move is D — Decode As. This built-in Wireshark feature lets you right-click a packet (or navigate to Analyze → Decode As) and map a specific port number or conversation to a dissector, like HTTP. Once applied, Wireshark re-parses all matching packets through the HTTP lens, giving you full field-level decoding instead of raw bytes. The readable text you already found via "Follow TCP Stream" confirms the traffic is HTTP — you just need to tell Wireshark's dissector engine that. A is wrong because you cannot edit packet headers inside Wireshark to change how packets are classified — Wireshark is a read-only analysis tool. Changing a display value doesn't alter the underlying capture or trigger re-dissection. B is wrong because capture filters run at collection time and filter which packets are saved — they don't re-decode packets you've already captured. There's also no valid Wireshark syntax like http port 8088 that retroactively changes dissection. C is wrong because the question explicitly tells you the traffic is plaintext — you can already read the HTTP request in plain text. TLS decryption is only relevant when traffic is encrypted (e.g., HTTPS). Study tip: On Wireshark questions, watch for the distinction between capture filters (what you collect) and display filters/Decode As (how you interpret it). "Decode As" is always your tool for nonstandard port dissection.

Question 9

A technician enables promiscuous mode on a laptop connected to an ordinary access port on a switched network. Wireshark shows the laptop's own unicast traffic and some broadcast traffic, but it does not show a file transfer between two other wired hosts.

Which action would most directly allow inspection of that file-transfer traffic?

  1. Apply a display filter for the two hosts so Wireshark requests their packets from the switch.
  2. Disable promiscuous mode so the adapter accepts frames addressed to the other two hosts.
  3. Capture from a configured switch mirror port or an appropriately placed network tap. (correct answer)
  4. Increase Wireshark's packet-list buffer so switched unicast frames are retained instead of dropped.
Explanation: Whenever you see a question about capturing traffic on a switched network, the core concept to understand is how switches handle unicast frames differently from hubs. A switch is intelligent — it learns which MAC addresses live on which ports and forwards unicast frames only to the intended destination port. This is fundamentally different from a hub, which broadcasts every frame out every port. This is why C is correct. Even with promiscuous mode enabled, your adapter can only capture frames that physically arrive at your port. On a standard access port, the switch delivers your own traffic and broadcasts, but the file-transfer frames between two other hosts never reach your NIC at all — they're forwarded directly between those two ports. To capture that traffic, you need either a mirror port (also called SPAN — Switch Port Analyzer), where the switch is explicitly configured to copy designated traffic to your monitoring port, or a network tap, a passive hardware device inserted inline that duplicates traffic without disrupting the flow. Choice A reflects a common misconception: Wireshark display filters only hide or show packets already captured — they cannot request or pull packets from the switch. The switch has no such interface. Choice B is backwards; promiscuous mode causes your adapter to accept frames not addressed to it, so disabling it would make things worse, not better. Choice D misunderstands the problem entirely — the frames aren't being dropped by a buffer; they simply never arrive at your port in the first place. As a study tip, remember: promiscuous mode fixes the NIC problem; mirror/SPAN or a tap fixes the switch problem. They solve different layers of the capture challenge.

Question 10

For one captured Ethernet packet, Wireshark reports a frame length of 1514 bytes and an IPv4 Total Length value of 1500 bytes. No VLAN tag is present.

Which explanation best accounts for the 14-byte difference?

  1. The IPv4 Total Length excludes the 14-byte Ethernet header but includes the IP header and its payload. (correct answer)
  2. The IPv4 Total Length excludes a 14-byte TCP header but includes all Ethernet addressing fields.
  3. Wireshark added 14 bytes because promiscuous mode duplicates the destination MAC address in memory.
  4. The packet was fragmented, and the missing 14 bytes must be contained in the next IP fragment.
Explanation: When analyzing packet captures, you need to think in terms of protocol layers — each layer adds its own header, and length fields are defined relative to that layer only. An Ethernet frame wraps an IP packet. The standard Ethernet header consists of 6 bytes (destination MAC) + 6 bytes (source MAC) + 2 bytes (EtherType) = 14 bytes. The IPv4 "Total Length" field counts only what belongs to the IP layer and above — the IP header plus its payload (TCP/UDP/etc.). It deliberately excludes the Ethernet header because Ethernet is a lower layer that IP has no reason to count. So when Wireshark reports a frame length of 1514 bytes, that's the full Ethernet frame; the IPv4 Total Length of 1500 bytes is that same data minus the 14-byte Ethernet header sitting in front of it. Answer A captures this exactly and is correct. Answer B is wrong on two counts: TCP headers are typically 20–60 bytes (not 14), and IPv4 Total Length certainly doesn't include Ethernet addressing — that's the opposite of how layering works. Answer C describes a fictional Wireshark behavior; promiscuous mode simply allows the NIC to capture all frames on the wire — it doesn't duplicate or pad data in memory. Answer D misunderstands fragmentation; fragmented packets are split at the IP payload level and reassembled, which has nothing to do with a consistent 14-byte offset tied to an Ethernet header. As a study tip, memorize the standard Ethernet header size (14 bytes) and remember that each protocol's length field counts only its own layer and above — this pattern appears repeatedly in packet-analysis questions.