How to Investigate Encrypted Network Traffic with Wireshark

Encryption protects online communication, but it also creates a challenge for digital investigators. When a connection uses HTTPS, the contents of the communication are generally unreadable in a packet capture unless the investigator has suitable decryption material. Does that mean investigators cannot trace suspicious network activity?

No. Even when application data remains encrypted, network traffic can expose useful metadata: IP addresses, ports, timestamps, packet sizes, connection patterns and, in some circumstances, DNS queries and TLS handshake details. When correlated with endpoint and security logs, these observations can help investigators reconstruct parts of an incident.

In this practical guide, we will use Wireshark and Windows PowerShell to examine ordinary encrypted web traffic, identify the information that remains visible and understand the limits of the evidence. The exercise uses a controlled lab, not a real cyberattack.

The Investigation Scenario

Imagine that a security team notices repeated outbound connections from a Windows workstation to an unfamiliar external address. The connections use encryption, and the team does not yet know whether the activity is legitimate.

The investigator needs to establish:

• Which remote systems communicated with the workstation?
• What can the captured traffic reveal about those connections?
• Can the network observations be correlated with Windows processes or logs?
• What additional evidence would be needed to support a conclusion?

To learn the workflow safely, we will generate normal HTTPS traffic to https://example.com and analyse it as an investigator would examine a captured connection. This domain is used for demonstration; its presence is not an indication of malicious activity.

Step 1: Capture network traffic with Wireshark

Install Wireshark from its official download page. Open the application and identify the active network interface, usually Wi-Fi or Ethernet.

Start a capture on that interface, open your browser and visit https://example.com. Load the page a few times, return to Wireshark and stop the capture. Save the file as https-lab.pcapng.

A packet capture records only the traffic visible at its collection point. Selecting the wrong interface, starting too late, packet loss or traffic using a different network path can leave gaps. In a real investigation, document the capture time, time zone, interface, software version and collection method. Preserve the original capture and analyse a working copy where appropriate.

After saving the capture and stopping the collection, calculate its SHA-256 hash in PowerShell:

Get-FileHash .\https-lab.pcapng -Algorithm SHA256

Record the resulting hash in your investigation notes. Recalculate it later to check whether the file has changed. A matching hash supports file-integrity verification against the recorded value, but does not prove that the original capture was complete, accurate or collected correctly.

Step 2: Investigate DNS activity

The Domain Name System (DNS) translates domain names into information such as IP addresses. DNS queries and responses can help connect a workstation's activity to a domain it attempted to reach.

In Wireshark, enter this display filter and press Enter:

dns

Select a query and inspect the packet details. Depending on the exchange, you may see the requested name, record type and response address.

Windows provides another view of current DNS information. In PowerShell, run:

Get-DnsClientCache |
  Select-Object Entry, Type, Data, Status, TimeToLive

To perform a new lookup, use:

Resolve-DnsName example.com -DnsOnly

These commands answer different questions. Get-DnsClientCache displays the local DNS cache; Resolve-DnsName requests a new resolution. A fresh lookup does not prove that the same query happened during an earlier incident. The cache may also have changed since the activity under investigation.

DNS evidence can be absent for several reasons: the capture started too late, the relevant cache entry expired, the application used a cached address, or DNS was encrypted using DNS-over-HTTPS or DNS-over-TLS. Therefore, not seeing a readable DNS query does not prove that a domain was never contacted.

Step 3: Examine TLS handshake metadata

Transport Layer Security (TLS) protects data exchanged through HTTPS and other encrypted protocols. Although the application content is protected, some handshake information may remain visible.

In Wireshark, apply:

tls

To focus on Client Hello packets, use:

tls.handshake.type == 1

If a suitable packet appears, expand the TLS handshake details. Depending on the connection, visible fields may include offered protocol versions, cipher suites and the Server Name Indication (SNI) extension.

SNI can reveal the requested server name when it is transmitted in an observable form. However, Encrypted Client Hello (ECH) can conceal the true server name, and protocol behaviour varies. HTTP/3 uses QUIC over UDP, so the traffic may not appear as a conventional TCP-based TLS session.

If a filter returns no packets, check whether the traffic used a different protocol, whether the capture began late, and whether Wireshark dissected the packets as expected. A missing field is not evidence of malicious activity.

Step 4: Examine encrypted application data and connection patterns

Apply this display filter:

tls.app_data

If Wireshark has dissected the traffic into TLS application-data records, you can select a packet and inspect its details and bytes. Without suitable decryption material and configuration, TLS application data generally remains unreadable in the packet capture. The visible metadata depends on the protocol version and connection features.

Next, open Statistics → Conversations and examine the TCP or UDP conversations. Wireshark can summarise endpoints, packet counts, byte counts, start times and durations for observed conversations.

Repeated connections, regular connection intervals, unexpected outbound volume or activity beginning immediately after a process launches may justify further investigation. However, these are investigative leads rather than proof of an attack. Software updates, cloud services, browser tabs and background applications can produce similar patterns.

Traffic volume also needs careful interpretation. The bytes recorded in a conversation describe what Wireshark observed, not necessarily the amount of useful data transferred or stolen. Protocol overhead, retransmissions, capture gaps and the chosen capture point can affect the measurements.

Step 5: Correlate the traffic with Windows

Network observations become more useful when they can be associated with activity on the computer that generated them.

While your browser is actively connecting to a website, open PowerShell and run:

Get-NetTCPConnection -State Established |
  Select-Object LocalAddress, LocalPort,
    RemoteAddress, RemotePort,
    OwningProcess, CreationTime |
  Format-Table -AutoSize

The output lists current established TCP connections, their local and remote endpoints, and the process identifier (PID) associated with each connection.

Choose a PID from your own output and inspect it:

$pidToCheck = 12376  # Replace with the PID from your output

Get-Process -Id $pidToCheck |
  Select-Object Id, ProcessName, Path

The number 12376 is an example only. Replace it with the actual PID from your own results. Some process details may be unavailable without elevated permissions, and the process may exit before you inspect it.

This method has an important limitation: Get-NetTCPConnection reports current TCP connection state, not a complete history of past connections. It does not identify the owning process for every UDP flow. Short-lived TCP sessions may disappear before inspection, too. For historical reconstruction, investigators may need endpoint detection records, Windows event logs, firewall records, DNS logs or network flow data.

Timestamps also require care. Packet captures, endpoint logs and central logging systems may use different time zones or clocks. Investigators should document and reconcile these differences before claiming that one event preceded another.

What can investigators actually conclude?

Suppose a capture shows repeated encrypted connections to an external address. DNS records associate that address with a domain, while endpoint logs show an unfamiliar process starting shortly before the connections began.

Together, these observations may support the hypothesis that the process communicated with an external service and deserves further examination. They do not automatically prove malware infection, data theft or the identity of an attacker.

An IP address may belong to shared cloud infrastructure. A domain may serve legitimate and malicious customers. A large outbound transfer may be a backup or software update. Stronger conclusions require corroboration from independent evidence, such as process execution records, authentication events, file artifacts, security alerts or server-side logs.

Decryption may sometimes be possible when investigators have authorised access to appropriate TLS session secrets or other suitable evidence. It is not guaranteed. Private keys and session secrets must be handled securely because they may expose sensitive communications. Consult the Wireshark User’s Guide for the requirements and limitations of TLS decryption.

Final checklist for network investigators

• Preserve the original packet capture and record its SHA-256 hash.
• Document capture time, time zone, interface, tools and collection limitations.
• Inspect DNS activity, TLS handshake details and connection statistics.
• Correlate network observations with endpoint and security logs.
• Distinguish directly observed facts from investigative hypotheses.
• Avoid declaring a domain, IP address or connection malicious based on one indicator.
• Record what the available evidence cannot establish.

Encrypted traffic analysis is not about recovering every hidden message. It is about extracting reliable observations from what remains visible, correlating those observations with independent evidence and explaining the limits of the conclusions.