Cybersecurity and Network Forensics: Wireshark, TLS Traffic, and AitM Phishing

Network Forensics in Modern Incident Response

In defensive cybersecurity operations, endpoint event logs and EDR telemetry provide indispensable insights, but frequently present an incomplete or manipulated perspective of an active intrusion. Sophisticated adversaries clear Windows event logs, alter Linux /var/log/syslog files, or evade static endpoint signatures via memory-only living-off-the-land execution.

However, one operational layer cannot be retroactively tampered with once traffic has been captured: the network wire.

Network Forensics involves the capture, deep packet inspection, and protocol reassembly of network traffic to mathematically reconstruct the chronological attack lifecycle: initial access vectors, internal lateral movement, automated beaconing, and sensitive data exfiltration.

This technical guide provides an exhaustive engineering workflow for analyzing raw packet captures (PCAP/PCAPNG files): from advanced protocol dissection over non-standard ports in Wireshark and semantic traffic filtering to JA4 client TLS fingerprinting, forensic analysis of Adversary-in-the-Middle (AitM) phishing flows, and media sanitization standards under NIST SP 800-88.

---

Methodological Workflow: Network Forensic Incident Triage

Structured forensic triage proceeds through four systematic phases, converting raw packet buffers into actionable Indicators of Compromise (IoCs):

flowchart TD
    subgraph Capture_Phase ["1. Evidence Acquisition"]
        A[SIEM / EDR / IDS Alert] --> B[Full Packet Capture - FPC<br/>tcpdump / tshark / Network TAP]
        B --> C[Cryptographic Evidence Sealing<br/>SHA-256 Hashing / Chain of Custody]
    end

    subgraph Triage_Phase ["2. Triage & Protocol Dissection"]
        C --> D[Apply BPF Capture & Display Filters]
        D --> E{Non-Standard Port?}
        E -->|Yes| F[Force Dissection: Decode As...]
        E -->|No| G[TCP Stream Reassembly & Flow Analysis]
    end

    subgraph Inspection_Phase ["3. Cryptographic & Protocol Analysis"]
        F --> H[Inspect TLS 1.3 Metadata / SNI]
        G --> H
        H --> I[JA3 / JA4 Client Fingerprinting]
        I --> J[Reconstruct HTTP Payloads & Export Objects]
    end

    subgraph Output_Phase ["4. Remediation & Media Sanitization"]
        J --> K[Extract IoCs: IPs, FQDNs, Payloads]
        K --> L[Enforce Perimeter Rules: Firewall / SIEM / EDR]
        L --> M[Sanitize Forensic Workstations: NIST SP 800-88]
    end

    classDef capture fill:#181825,stroke:#f38ba8,stroke-width:2px,color:#cdd6f4;
    classDef triage fill:#1e1e2e,stroke:#6366f1,stroke-width:2px,color:#cdd6f4;
    classDef inspect fill:#181825,stroke:#a6e3a1,stroke-width:2px,color:#cdd6f4;
    classDef output fill:#181825,stroke:#f9e2af,stroke-width:2px,color:#cdd6f4;
    class Capture_Phase capture;
    class Triage_Phase triage;
    class Inspection_Phase inspect;
    class Output_Phase output;

---

1. Deep Wireshark Triage: Dissecting Non-Standard Ports

Wireshark automatically identifies protocols based on IANA well-known port bindings. By default, it dissects TCP port 80 as HTTP, 443 as TLS, and 3868 as DIAMETER.

In real-world incidents, adversaries and legacy internal services frequently route protocols across arbitrary ports to evade naive inspection mechanisms (e.g., establishing SSH tunnels over port 443 or hosting unencrypted HTTP APIs on port 8443 or 3879). In such scenarios, Wireshark displays opaque hexadecimal payloads.

Leveraging the "Decode As..." Feature

To instruct Wireshark's protocol engine to apply the correct dissector:

1. Select the anomalous packet in the main packet list.
2. Right-click and choose "Decode As...".
3. Verify that the Field column reflects the target port (e.g., TCP port 3879).
4. In the Current column, select the intended protocol dissector (e.g., HTTP, TLS, or DIAMETER).
5. Clicking Apply forces Wireshark to reparse the entire TCP stream in memory, exposing structured headers, REST parameters, or Diameter AVPs.

Essential Forensic Display Filters

Unlike capture filters (configured prior to logging using Berkeley Packet Filter syntax), display filters allow interactive querying across multi-gigabyte PCAP files:

• Isolating Outbound Web Requests & TLS Handshakes:

  http.request or (tls.handshake.type == 1)

• Detecting DNS Tunneling & Exfiltration:

DNS tunneling utilities encode arbitrary data into long subdomains:

  dns.flags.response == 0 and dns.qry.name.len > 50

• Filtering HTTP Injection Patterns & Application Errors:

  http.response.code >= 400 or http.request.uri matches "(?i)(\\.\\./|union|select|script)"

• Detecting Port Scanning & TCP Window Anomalies:

  tcp.flags.syn == 1 and tcp.flags.ack == 0 and tcp.window_size <= 1024

---

2. Forensic Analysis of Encrypted TLS Traffic & JA4 Fingerprinting

With over 95% of web and enterprise traffic encrypted with TLS 1.2 and TLS 1.3, analysts must extract high-fidelity telemetry from cleartext metadata negotiation.

Cleartext Metadata in the TLS Handshake:

Before ephemeral symmetric encryption keys are negotiated via ECDHE, the client transmits an unencrypted Client Hello packet. This payload yields crucial forensic artifacts:

1. SNI (Server Name Indication): The fully qualified domain name (FQDN) the client attempts to reach (e.g., login.microsoftonline.com.phishing-infrastructure.net).
2. Cipher Suites: The exact collection of cryptographic suites supported by the calling application binary.
3. Supported Elliptic Curves & Extensions: Specific cryptographic capabilities unique to the client's network stack.

Client Fingerprinting with JA3 and JA4

Different operating systems, browsers, and programming frameworks assemble TLS Client Hello parameters in distinct orders. A genuine Google Chrome browser on Windows produces a signature radically different from a Python requests script, a PowerShell web client, or a Cobalt Strike implant.

The JA4 standard computes a deterministic cryptographic hash of these parameters:

• If network traffic claims to be an interactive web browser, but its JA4 hash matches a known headless HTTP utility (go-http-client or curl), incident responders can quickly classify the connection as automated malicious activity.

Laboratory Decryption with SSLKEYLOGFILE

In controlled lab environments, dynamic malware analysis sandboxes, or internal security audits, analysts can decrypt encrypted sessions by logging ephemeral symmetric keys.

Set the environment variable on the test client:

export SSLKEYLOGFILE=/tmp/tls_secrets.log
google-chrome --user-data-dir=/tmp/sandbox &

Then in Wireshark:

1. Navigate to Edit → Preferences → Protocols → TLS.
2. Locate the (Pre)-Master-Secret log filename field and point it to /tmp/tls_secrets.log.
3. Wireshark automatically decrypts corresponding TLS 1.2 and TLS 1.3 sessions, displaying decrypted HTTP/2 streams and application payloads in cleartext.

---

3. Dissecting an Adversary-in-the-Middle (AitM) Phishing Attack

Traditional credential-harvesting phishing sites (which merely clone landing pages and capture usernames and passwords via static backend scripts) have been neutralized by widespread multi-factor authentication (MFA) adoption.

Modern threat actors utilize Adversary-in-the-Middle (AitM) reverse proxy frameworks such as Evilginx, Muraena, or Modlishka.

How AitM Phishing Operates:

1. The adversary registers a deceptive domain (e.g., login.micros0ft-security.com) and deploys a transparent reverse proxy.
2. The target clicks a lure link and connects directly to the adversary's proxy.
3. The proxy establishes a concurrent, legitimate session with the authentic Identity Provider (IdP) (e.g., Microsoft Entra ID or Google Workspace).
4. The proxy relays authentic MFA challenges (such as SMS codes, TOTP prompts, or authenticator app number matches) directly to the target.
5. Once the victim approves the authentication challenge, the genuine IdP issues an authenticated session cookie (ESTSAUTH, session JWT, etc.).
6. The proxy intercepts and stores this session cookie before redirecting the victim to their genuine corporate portal. With this cookie, the adversary bypasses MFA entirely and assumes the user's authenticated session.

sequenceDiagram
    autonumber
    actor V as Victim (Browser)
    participant P as AitM Reverse Proxy (Evilginx)
    participant IdP as Genuine Identity Provider (IdP)

    V->>P: 1. Initial HTTP request to lookalike domain
    P->>IdP: 2. Proxy initiates session with genuine IdP
    IdP-->>P: 3. Real credentials form & MFA challenge
    P-->>V: 4. Relays live genuine authentication form
    V->>P: 5. User submits credentials and MFA token
    P->>IdP: 6. Proxy forwards credentials & token to IdP
    IdP-->>P: 7. IdP validates MFA and issues Session Cookie
    Note over P: Proxy intercepts & stores the Session Cookie
    P-->>V: 8. Redirects victim to legitimate application
    Note over P: Adversary hijacks session using intercepted cookie

Forensic Indicators in Network Packet Captures:

Investigating PCAPs associated with AitM attacks reveals telltale operational signatures:

• Round-Trip Time (TCP RTT) Discrepancies: Because the proxy introduces an intermediate hop between the victim and the legitimate IdP, latency for authentication POST requests exhibits measurable increases compared to direct traffic.
• Proxy Headers in Reassembled Streams: Inspecting reassembled HTTP streams frequently exposes proxy-injected headers (X-Forwarded-For, X-Real-IP, or rewritten Host headers).
• The Definitive Defense: FIDO2 and Passkeys: This attack vector underscores why SMS and TOTP multi-factor mechanisms are vulnerable. Only hardware-backed FIDO2 / WebAuthn Passkeys, as covered in our guide on Authentication vs. Authorization, provide cryptographically bound origin verification that defeats AitM proxies.

---

4. Chain of Custody & Media Sanitization Standards (NIST SP 800-88)

A forensic investigation carries zero evidential weight if the chain of custody is breached or digital media is improperly handled.

Evidence Preservation (RFC 3227)

Prior to loading a PCAP capture into analysis tools:

1. Cryptographic Sealing: Calculate cryptographic hashes (SHA-256) of the original artifact immediately:

   sha256sum network_evidence_20261027.pcapng > network_evidence_20261027.pcapng.sha256

1. Working on Verified Copies: Never perform analysis directly against primary evidence files. Always create verified forensic clones and confirm hash integrity.

Secure Media Sanitization: Beyond Basic Formatting

When decommissioning forensic workstations, analysis disks, or cloud storage volumes, standard formatting or rm -rf commands fail to destroy data. These commands merely unbind filesystem index pointers; raw data blocks remain intact and easily recoverable using carving tools like TestDisk or Foremost.

The NIST SP 800-88 Rev. 1 standard establishes three distinct sanitization tiers:

1. Clear: Logical overwriting of user-accessible storage sectors.
2. Purge: Advanced techniques that render target data unrecoverable against laboratory attacks (addressing remapped bad blocks and hidden areas).
3. Destroy: Total physical destruction via degaussing, shredding, or incineration.

Overwriting Workflows in Linux:

For traditional mechanical drives and virtual disk volumes:

# Multi-pass cryptographic overwriting with shred (3 random passes + 1 zero pass)
sudo shred -v -n 3 -z /dev/sdb

# Single-pass overwriting using kernel cryptographic entropy
sudo dd if=/dev/urandom of=/dev/sdb bs=4M status=progress conv=fdatasync

The Nuance of Solid State Drives (SSD & NVMe):

Modern flash drives employ Wear Leveling and Over-provisioning controllers. Consequently, software overwriting commands like dd or shred cannot guarantee physical erasure of all underlying flash memory blocks.

For modern NVMe and SSD hardware, always leverage native firmware sanitization commands:

# Inspect NVMe cryptographic erase support
sudo nvme id-ctrl /dev/nvme0 | grep -E "fna|sanicap"

# Execute native NVMe cryptographic erase (Cryptographic Erase)
sudo nvme format /dev/nvme0 -n 1 --ses=2

---

Conclusion

Network traffic analysis and strict evidentiary hygiene represent the cornerstone of incident response operations. Mastering deep packet inspection in Wireshark, evaluating encrypted TLS metadata with JA4 fingerprinting, and dismantling advanced vectors like AitM phishing empowers security teams to isolate intrusions rapidly and protect critical infrastructure.

Integrating these forensic competencies with proactive SSH Server Hardening, secure container architectures as detailed in Docker Architecture & Security, and continuous DevSecOps Verification builds an end-to-end resilient security posture.

If your organization needs advanced network forensics training, infrastructure traffic auditing, or incident response consulting to counteract active phishing and credential threats, explore my Cybersecurity Consulting Services or reach out directly on my About Me profile.