July 7, 2026
Day 2 of My SOC Journey: Hands-On Network Traffic Analysis with Wireshark
By madmax
3 min read
After spending Day 1 of my SOC journey diving into the theory of Security Operations Centers and understanding the day-to-day responsibilities of an L1 Analyst, I knew I needed to get my hands dirty. Theory is great, but seeing actual malicious traffic on the wire is where things really click.
This article documents my lab analysis of live network traffic and PCAP files to identify malicious activities, including a port scan and DNS tunneling indicators. It also demonstrates the critical vulnerabilities of unencrypted protocols.
The Lab Setup
To safely capture and analyze malicious traffic, I set up a localized, isolated virtual lab.
Host & Attacker Machine
Operating System: Kali Linux (Host)
Role: Served as the primary Security Operations Center (SOC) analyst interface for packet sniffing (via Wireshark) and acted as the offensive machine to generate targeted network traffic and reconnaissance scans (via Nmap).
Victim Machine
Operating System: Windows 10 (Virtual Machine)
Role: Served as the vulnerable endpoint receiving the simulated attacks and generating baseline operational traffic.
To ensure accurate traffic capture, the Windows 10 Virtual Machine was provisioned with a dual-adapter network configuration.
Adapter 1 (Primary): Configured for standard outbound connectivity to generate normal internet-bound baseline traffic (such as HTTP and DNS requests).
Adapter 2 (Secondary – Host-Only): Configured specifically as a Host-Only network adapter.
This established a private, securely bridged network segment directly between the Windows 10 VM and the Kali Linux host. This isolation ensured that all simulated attacks are easily captured by Wireshark listening on the host interface.
Task A: Live Capture & Protocol Baseline
Before looking for anomalies, an analyst has to know what "normal" looks like.
I launched Wireshark on the Kali Linux host and started a live packet capture on the primary network interface (e.g., eth0). I then opened a terminal on the Kali host and generated standard network traffic by executing the following commands:
ping -c 4 8.8.8.8 (Generates standard ICMP echo requests and replies).
curl http://neverssl.com (Intentionally generates unencrypted, plaintext HTTP traffic).
nslookup example.com (Generates standard DNS query and response traffic).
To verify the baseline, the following display filters were applied one at a time in Wireshark:
dns: Filtered for all standard DNS queries and responses to observe normal name resolution.
http.request: Filtered specifically for outbound web requests to expose the HTTP method, host, and URI.
icmp: Filtered to verify the success of the ping commands.
tcp.flags.syn==1 && tcp.flags.ack==0: Filtered for initial TCP connection attempts (bare SYNs) to establish what normal connection initiation looks like before observing a port scan.
Task B: Finding the Port Scan
Next, it was time to simulate an attack. I started a live Wireshark capture on the Kali host, monitoring the bridged network interface connected to the Windows VM. From the Kali host terminal, I executed an Nmap SYN stealth scan targeting the Windows VM.
Command Executed: nmap -sS 192.168.56.102
I allowed the scan to run while Wireshark captured the resulting traffic flow between the host and the victim machine.
To isolate and confirm the port scan, the following analysis steps were performed:
Filter Application: Applied the display filter tcp.flags.syn==1 && tcp.flags.ack==0. This specific filter isolates "bare SYNs" – TCP connection attempts where a SYN packet is sent, but the handshake is never completed.
Conversation Analysis: To confirm the pattern of a single source hitting multiple destinations rapidly, I navigated to Statistics > Conversations > TCP tab in Wireshark. The results were then sorted by port and packet volume to clearly view the distribution of the attack.
Task C: Spotting Suspicious DNS & Tunneling
Attackers often use DNS to exfiltrate data or establish Command and Control (C2) beacons. This task was completed using a hybrid approach, analyzing both provided PCAP file and live traffic.
PCAP Analysis (Length Anomalies): Loaded a labeled PCAP file into Wireshark to search for pre-captured instances of malicious DNS long query names.
Live Traffic Generation (TXT Records): To simulate the traffic generated by DNS tunneling tools, live TXT record queries were executed directly from the Kali Linux host machine.
Commands Executed: dig -t txt example.com and nslookup -type=txt example.com
To spot the suspicious DNS indicators, the following display filters were applied:
dns: Filtered to view all DNS traffic and observe general volume.
dns.qry.name.len > 40: Applied specifically to the loaded PCAP file to isolate unusually long query names.
dns.qry.type == 16: Applied to the live capture to filter specifically for DNS TXT records, which are frequently abused by attackers to tunnel commands and data (C2).
Task D: Recovering Cleartext Credentials
The final exercise was a stark reminder of why legacy protocols are so dangerous. To generate the necessary traffic, three separate insecure connections were established directly from the Kali Linux host machine:
HTTP Basic Authentication: Executed the command curl -u admin:password http://example.com to send credentials via an unencrypted web request.
FTP Authentication: Connected to a public testing server using the command ftp ftp.dlptest.com and manually entered a test username and password.
Telnet Authentication: Connected to a public telnet server using the command telnet telehack.com.
With the live Wireshark capture running, the following display filters were applied to isolate the specific authentication traffic:
http.authorization: Filtered for HTTP Basic-auth traffic, which transmits credentials as easily decodable base64 strings in the header.
ftp: Filtered to expose the FTP USER and PASS commands, which are transmitted in plaintext.
telnet: Filtered to isolate Telnet traffic, where individual keystrokes are entirely visible.
By simply reading the TCP streams, the usernames and passwords were completely exposed.
Takeaways
This hands-on lab bridged the gap between SOC theory and practical packet analysis. Using filters like tcp.flags.syn==1 && tcp.flags.ack==0 or dns.qry.type == 16 turns a chaotic wall of network packets into a clear, readable story of attacker behavior. As an aspiring L1 analyst, knowing exactly what these attacks look like on the wire is an invaluable foundation