HackBlue

Tools · Network tools · 23 / 24

NetworkMiner: sessions, DNS, and parameters

Sessions summarize who talked. DNS lists the names in the file. Parameters lists cleartext fields. Together they are a map of the case. A single flag or a byte in one frame still belongs to tshark.

14 min read · practice only with authorization

Sessions are the middle layer

A session is a conversation NetworkMiner grouped: addresses, ports, protocol, and time. It answers whether the web tier ever talked to the files VM, which is the same question as a tshark conversation row, in a form you can click from the host. Use it to pick the one session the ticket is about, then confirm the handshake or the state in tcpdump or conn.log if the exact ending matters.

Session byte counts are a reason to open Files or to look at direction. They are not a transcript. If two tools disagree on the count, say which tool, and go back to the pcap for the disputed session rather than averaging them.

DNS and parameters

The DNS tab is the name inventory: questions and answers that were in the file. Check it against the runbook the same way you check dns.log. A name that appears only here and not in Zeek means one of the parsers disagreed. That is a reason to look at the frame, not a reason to pick a favorite tool.

Parameters are cleartext keys and values from protocols such as HTTP. They show the shape of a form or a query. Redact values that are secrets. A parameter named token is the same defect as a token in http.log, seen from the GUI. After you have the shape, the Zeek row is the better thing to quote, because it has a uid.

  • Start at the host, open its sessions, pick the pair from the ticket.
  • Use DNS to confirm a name before you blame the server that never saw a packet.
  • Use Parameters to see whether a cleartext form carried a secret.
  • Return to the pcap when you need a flag, a frame number, or a field the GUI does not show.

A worked defensive case

Sessions under 10.8.0.20 show a short TCP session to 10.8.0.40:443 and a longer TCP session to 10.8.0.40:80. DNS shows files.lab.internal to 10.8.0.40, which now matches the corrected runbook. Parameters on the port 80 session show a token field. The port 443 session has no parameters, which fits TLS.

You split the notes. Port 80 is the cleartext token, already covered by the http.log ticket, with the Parameters view as the GUI confirmation. Port 443 is the hang, with no application fields in this tool, handed back to the service log. One product, two different depths, and you do not force the TLS session through the Files tab.

Where this is documented

Netresec's tab list includes Sessions, DNS, and Parameters alongside Hosts and Files. Zeek remains the join key when the case needs a uid in a log pipeline.

Use a host-only lab network, or a capture the owner already handed you. These commands read that file or record a single lab host. They are not a scan of the public internet.

Commands

The same port 80 pair as HTTP rows, to quote a uid beside the GUI
zeek-cut -m ts uid id.orig_h id.resp_p method host uri status_code < /lab/zeek/http.log

Diagram

From a host, to one session, to the log that can be quoted

  1. Host

    10.8.0.20 in the inventory, and no unexpected subnet.

  2. Session

    Port 80 to 10.8.0.40 is the cleartext one. Port 443 is the TLS one.

  3. Parameters

    The token field is visible only on the cleartext session.

  4. Uid

    http.log supplies the uid you cite. The TLS session goes to the service log.

Check yourself

1. You need to know whether 10.8.0.20 ever talked to 10.8.0.40. Which view answers that first?

2. Parameters lists token on the port 80 session. What is that?

3. The port 443 session shows no parameters and no carved file. What do you conclude?