Wireshark and Shodan for the tester

Objective 2.3 in this course covers reconnaissance tools — CompTIA names Nmap, Wireshark and Shodan specifically. Lesson 12 took Nmap; these are the other two, and they sit at opposite ends of the same problem: one shows you traffic you are part of, the other shows you exposure you never touched.

Why this matters

CompTIA names both, so both are examinable by name. More usefully, they cover the two blind spots a scanner leaves: Nmap tells you a port is open, Wireshark tells you what actually crosses it, and Shodan tells you what the internet already knows without you sending a single packet.

The lesson

Capture filters against display filters

The distinction is the first thing to get right, because it is examinable and because getting it wrong loses data permanently.

• A capture filter decides what is recorded. Anything it excludes is gone — you cannot recover it later, because it was never written.
• A display filter decides what is shown from what was recorded. Change it freely; the underlying capture is untouched.

The working rule: capture broadly, filter narrowly. Use a capture filter only to keep a long capture to a manageable size or to stay within what you are authorised to record — which is a real constraint under lesson 4, since traffic contains other people's data.

They also use different syntax, which is the usual source of confusion: capture filters use the packet-capture library's syntax, display filters use Wireshark's own protocol-field syntax.

Following a stream and extracting what crossed it

Individual packets are rarely the unit of interest. Reassembling a conversation is:

• Follow the stream to see an exchange as the application saw it, rather than as fragments.
• Export objects to pull files that were transferred — documents, images, executables.
• Protocol statistics to see the shape of a capture quickly: which hosts talk to which, which protocols dominate, what the largest conversations are. On a capture from an unfamiliar network this is the fastest orientation there is.
• Expert information surfaces retransmissions, resets and malformed packets — useful for the "is this network actually healthy" question that often comes up alongside a test.

Everything extracted is client data. Lesson 4's handling rules apply, and they apply hardest here, because a capture sweeps up material you never went looking for.

Spotting cleartext credentials in your own lab capture

This is the exercise, and it runs on the lab from lesson 2 with accounts you created.

Stand up a service that authenticates in the clear, log in to it, and find the credentials in your own capture. The point is not that cleartext protocols are bad — everyone knows that. The point is to see how little work it takes, so that when you write the finding you can describe it accurately.

Then repeat it with the encrypted version of the same protocol and observe what changes: the credentials are gone, but the fact of the connection, its timing, its volume and often the server name are still visible. Encryption protects content, not the existence of the conversation — a distinction that matters when a client asks whether TLS "fixes" something.

Extend it to the protocols from lesson 8 that answer strangers: watch name resolution fall back to a broadcast, and see what a host volunteers about itself before anyone authenticates.

Shodan as a passive view of exposed services

Shodan scans the internet continuously and publishes what it found. For a tester, that makes it a passive source under lesson 7's definition: reading a third party's records, touching nothing.

What it is good for:

• Confirming exposure without probing. A service visible in Shodan was reachable from the internet at the time it was scanned.
• Finding hosts the client did not list, by searching their address ranges and their certificate names rather than their domains.
• History. A service that has since been closed may still be in the record, which tells you what was exposed and for how long.

Its limits, which belong in any finding that cites it: the data is as of a scan date, not now; coverage is incomplete; and its service identification is a fingerprint with the same error bars as lesson 10's version detection. So Shodan is a lead and a corroboration, never the sole evidence for a finding about the present.

Searching for your own client's exposure, and only theirs

The scoping discipline from lesson 3 applies to search engines exactly as it applies to scanners, and it is easier to breach here because it feels like reading.

• Search by what you have established the client owns — their address ranges, their certificate names, their organisation registration — not by a product banner that happens to interest you.
• Looking at a result is passive. Connecting to it is not. A Shodan record includes an address; opening it in a browser is active reconnaissance against a host that may belong to someone else entirely.
• Findings about third-party hosts are reported, not tested, exactly as in lesson 9.

The broader professional point: these tools make other people's exposure trivial to browse. The thing that makes you a tester rather than a trespasser is the scope document, and it applies to a search box as much as to a shell.

What to take into the exam

• Capture filters decide what is recorded and lose what they exclude; display filters only change the view. Capture broadly, filter narrowly.
• Follow-stream and export-objects reassemble conversations; protocol statistics orient you fastest on an unfamiliar capture.
• Encryption protects content, not the existence, timing or volume of a conversation.
• Shodan is passive and historical: cite it with its scan date, corroborate before asserting present exposure.
• Search scope is scope. Reading a record is passive; connecting to the address in it is not.