ACADEMIC PROJECT / NETWORK SECURITY

IDS Traffic
Analysis Project

Used Wireshark to establish a normal traffic baseline, investigate an external attack dataset, and propose detection logic for suspicious network behavior.

WiresharkPCAP analysisIDS conceptsDetection designFalse-positive analysis

Normal capture packets: 2,565
External dataset packets: 5,091
Reported capture drops: 0%
Proposed detection strategies: 6

01 / OBJECTIVE

Understand the baseline before investigating anomalies.

I compared a live workstation capture with an external traffic-analysis exercise to identify behavior that deserved investigation. The analysis covered protocol distribution, conversations, DNS requests, and visible HTTP traffic.

This was a packet-analysis and IDS design exercise. Wireshark supported manual investigation; the project did not implement a continuously running IDS sensor or automated alert pipeline.

02 / METHOD & EVIDENCE

Two captures, different patterns.

Evidence documented in the final technical report
Dataset	Work completed	Finding
Normal workstation capture	Captured 2,565 packets with no reported dropped packets; reviewed protocol hierarchy, conversations, and DNS.	Observed routine encrypted web traffic and local network protocols. No malicious activity was confirmed in this capture.
External attack dataset	Analyzed 5,091 packets from the 2024-09-04 traffic-analysis exercise using host and HTTP filters.	Identified repeated HTTP POST requests from one internal host to one external destination as the strongest suspicious pattern.
Local scan capture	Attempted to run Nmap, but the command was unavailable.	No completed scan capture or validated scan-detection result is claimed.

PACKET ANALYSIS / ORIGINAL REPORT SCREENSHOTS

See the investigation evidence

Screenshots from my analysis of the external traffic-analysis exercise. The addresses shown belong to that dataset. Select an image to inspect it at full size.

Wireshark HTTP request list showing repeated POST requests in the external dataset — **Repeated HTTP requests**
The HTTP request list shows repeated POST requests from 172.17.0.99 to 79.124.78.197, including /foots.php. These rows prompted further investigation. The lower packet-details pane displays the selected connectivity-test GET request, not a POST payload.
Source: IDS final technical report · External PCAP analysis

Wireshark protocol hierarchy for the external dataset showing 5,091 frames — **Protocol distribution**
The external dataset contains 5,091 packets. Its protocol hierarchy provides context for the investigation; protocol proportions alone do not establish malicious activity.
Source: IDS final technical report · External PCAP analysis

Wireshark IPv4 conversations showing the dataset host and its network peers — **Host conversation review**
The Conversations view shows 172.17.0.99 communicating with multiple destinations. I used this view to identify traffic to examine more closely.
Source: IDS final technical report · External PCAP analysis

03 / INVESTIGATION

Follow the traffic, then test the explanation.

I used Protocol Hierarchy and Conversations views to identify common protocols and hosts of interest. In the external dataset, repeated HTTP POST requests to the same destination, including /foots.php and /index.php, prompted further investigation.

Those requests were suspicious indicators consistent with possible command-and-control communication. The request method or path alone does not prove compromise.

The baseline also provided false-positive examples. WPAD-related NXDOMAIN responses and multicast discovery can reflect normal workstation behavior. Encrypted traffic, including DNS-over-HTTPS, limits what packet inspection can reveal.

04 / PROPOSED DETECTION LOGIC

Turn observations into testable hypotheses.

The report proposed six detection strategies. These are candidates for lab validation, not deployed rules or measured detection results. Thresholds would need tuning against representative traffic.

Detection ideas and the context required to evaluate them
Strategy	Signal to investigate	Validation consideration
Port scanning	One source contacting many destination ports in a short interval	Complete a controlled scan capture and distinguish scanning from expected services.
Repeated HTTP POST	Repeated requests to an unusual external destination	Review application purpose, timing, and visible request content.
DNS anomalies	Error bursts or unusual query names	Account for normal discovery behavior and encrypted DNS visibility gaps.
Known indicators	Traffic matching a threat-intelligence indicator	Check the source, age, and context of the indicator.
Beaconing	Regular communication intervals to a destination	Separate possible beaconing from legitimate periodic application activity.
Large transfers	A conversation with unusually high outbound volume	Compare with expected uploads, backups, and capture duration.

05 / LIMITATIONS & NEXT STEPS

Keep findings separate from assumptions.

The analysis demonstrated traffic baselining, packet investigation, detection design, and false-positive reasoning. It did not measure detection accuracy or establish confirmed DDoS activity.

The local Nmap capture remains incomplete. A next iteration would collect that evidence in an authorized lab and test the proposed analytics against both suspicious and benign samples, documenting false positives and missed activity.

The report contains differing protocol and DNS counts across some sections. This case study uses the consistent total packet counts and qualitative findings rather than publishing those conflicting breakdowns.

Source: Aung Mhn, IDS Final Project: Network Traffic Analysis Using Wireshark, May 8, 2026. External dataset identified in the report: 2024-09-04-traffic-analysis-exercise.pcap.