Network threat monitoring and forensics lab

I built a repeatable environment for moving from an alert or unusual connection to packet, protocol, flow, endpoint, honeypot, and threat-intelligence evidence.

Context

The lab combines Security Onion, Zeek, Elastic, DShield honeypot data, SiLK, Wireshark, IDS telemetry, Linux analysis systems, and PCAP-based exercises.

My role

I deployed the monitoring components, built analysis workflows, and practiced correlation across evidence sources.

Result

I created a reusable investigation environment for understanding traffic, testing analysis methods, and separating false positives from activity that deserves deeper attention.

Safe working sequence

How I reduced risk

Collect
Correlate
Enrich
Validate
Document

Conceptual workflow only. No live topology, identifiers, or operational data are shown.

The problem

Why the work needed more than one tool

A single alert rarely explains what happened. Useful investigation requires timestamps, sessions, protocol metadata, packet context, flow relationships, endpoint activity, attacker history, and the vulnerable service to agree.

What could go wrong

Treating an IDS signature as a complete conclusion
Losing context when moving between packet, flow, and log data
Confusing scanning noise with meaningful exploitation
Publishing attacker data without enough evidence or context
Allowing analysis tooling to create unnecessary exposure

What I did

The working sequence

Built a Security Onion environment for packet capture, IDS alerts, Zeek logs, and Elastic investigation
Deployed and analyzed DShield honeypot telemetry
Used Zeek connection, DNS, HTTP, TLS, and file logs for protocol analysis
Used zeek-cut and SiLK tools to filter relationships, ports, traffic volume, and unusual connections
Correlated IDS alerts with packet captures, network flows, endpoint context, and threat intelligence
Mapped observed exploit attempts to CVEs, affected services, and likely objectives
Built repeatable Linux and PCAP practice environments for protocol analysis
Planned a CAPEv2 malware-analysis VM for later integration with the broader investigation stack

How I validated it

Evidence before completion

Followed the same event across multiple independent data sources
Checked whether network behavior matched the alert description
Used packet and protocol evidence to confirm or reject assumptions
Compared attacker history and CVE context with the observed target and payload behavior
Kept planned malware execution isolated from the monitoring and management planes

What this demonstrates

The skill behind the tools

The lab demonstrates evidence-led security analysis rather than alert counting. It also gives me a controlled place to evaluate how AI can assist correlation without becoming the authority.

Production details are intentionally anonymized. I do not publish organization names, internal addresses, credentials, private topology, or sensitive recovery information.

Platforms and tools

Security Onion Zeek Elastic DShield SiLK Wireshark IDS PCAP Linux CVE research

Continue through the project inventory

All projects Experience