Digital Twin for Network Security: Building a Virtual Lab to Simulate and Detect Attacks

The challenge with network security education is that you can't practice on real production networks. But simulated environments often feel too sanitized — they don't replicate the complexity and noise of actual enterprise traffic. My solution was to build a digital twin of a small enterprise network: a virtual replica that generates realistic traffic patterns, can be subjected to simulated attacks, and lets me test monitoring workflows in a controlled but realistic setting.

This project became one of the most educational experiences of my time at BU.

What Is a Digital Twin in Network Security?

In industrial and engineering contexts, a digital twin is a virtual replica of a physical system — used to simulate behavior, test scenarios, and optimize without touching the real thing. The concept applies directly to network security: a digital twin network mirrors a real network's topology, services, and traffic patterns, allowing security teams to test defenses, validate detection rules, and train analysts without risk.

For my academic project, I scoped this down to a small enterprise network: a few servers, a firewall, internal clients, and an internet-facing segment. The goal was to generate traffic that looked realistic enough to be worth analyzing, simulate attack scenarios, and validate whether my monitoring stack could detect the attacks.

Lab Architecture

I built the entire lab in VirtualBox using host-only and internal networking to isolate traffic:

Network Segments:

• 192.168.10.0/24 — Internal corporate network (clients, file server, internal web apps)
• 192.168.20.0/24 — DMZ (web server, email server, DNS)
• 10.0.0.0/24 — Management network (SIEM, monitoring tools)

Virtual Machines:

• pfSense Firewall — Gateway and traffic inspection. Separates all segments and provides NAT.
• Ubuntu File Server — Simulates an internal NFS/Samba file server
• Ubuntu Web Server (DVWA) — Deliberately Vulnerable Web Application for attack simulation
• Windows 10 Client — Simulates a corporate endpoint
• Kali Linux Attacker — The offensive machine, isolated from the management segment
• Ubuntu SIEM Node — Running Splunk + Zeek for traffic analysis

Generating Realistic Traffic

A digital twin only works if the baseline traffic looks realistic. I used several approaches to generate normal traffic patterns:

Scripted user behavior: Python scripts running on the Windows client simulate typical user activity — web browsing (curl requests to external sites), file server access (SMB reads/writes), internal web app usage. These run on randomized intervals throughout the day.

Background services: The servers run actual services — Apache for web, Samba for file sharing, Postfix for email relay — so service-to-service traffic (heartbeats, DNS queries, NTP syncs) flows naturally.

Zeek for traffic logging: Zeek (formerly Bro) sits on a monitoring span port and logs all network activity as structured connection logs, HTTP logs, DNS logs, and more. These feed into Splunk for analysis.

Simulated Attack Scenarios

With realistic baseline traffic established, I ran four attack scenarios and evaluated whether my monitoring stack detected each one.

Scenario 1: Network Reconnaissance (Nmap Scan)

From Kali, I ran a standard discovery scan against the internal network:

nmap -sV -T4 192.168.10.0/24

What the SIEM saw: Zeek's connection logs showed a single source IP making TCP connections to hundreds of unique destination ports across multiple hosts in a three-minute window. Splunk alert triggered: "Port Scan Detected — more than 50 unique ports accessed by single host in 5 minutes."

Result: Detected ✅

Scenario 2: Brute Force SSH

I used Hydra to brute-force SSH credentials on the file server:

hydra -l admin -P /usr/share/wordlists/rockyou.txt 192.168.10.5 ssh

What the SIEM saw: Auth logs on the file server showed hundreds of failed authentication events in rapid succession, all from the same source. Splunk alert triggered: "Brute Force — more than 20 failed SSH logins in 2 minutes from single IP."

Result: Detected ✅

Scenario 3: SQL Injection via DVWA

I used SQLMap against the vulnerable web application:

sqlmap -u "http://192.168.20.10/dvwa/vulnerabilities/sqli/?id=1" --cookie="..."

What the SIEM saw: This one was harder. HTTP logs showed unusual request patterns — long query strings with SQL keywords, many requests returning error codes. Without a WAF in the path, raw HTTP logs required a custom Splunk search to surface this pattern.

I built a detection rule: requests containing SQL keywords (UNION, SELECT, DROP, OR 1=1) in query parameters, triggering an alert for "Potential SQL Injection Activity."

Result: Detected with custom rule ✅ (missed by default rules)

Scenario 4: Lateral Movement (Pass-the-Hash)

Using Impacket's psexec.py, I simulated lateral movement from a compromised Windows client to the file server using a captured NTLM hash.

What the SIEM saw: Windows event logs showed a remote service creation (Event ID 7045) followed by an unusual process launch. Splunk detected the event but required correlation with the preceding authentication events to understand the full picture.

Result: Partially detected — required manual correlation ⚠️

Key Findings

The experiment surfaced some important insights:

Detection coverage is uneven: Noisy, volumetric attacks (port scans, brute force) are easy to detect. Subtle, sophisticated attacks (lateral movement, slow-and-low data exfiltration) require highly tuned correlation rules and behavioral baselines.

Context is everything: An individual alert means little without context. Connecting the brute force attempt, successful login, lateral movement, and file access into a single incident timeline requires correlation — which is the hardest part of SIEM work.

Zeek adds enormous value: Raw firewall logs are useful. Zeek's structured application-layer logs (HTTP metadata, DNS queries, SSL certificates) add a layer of context that makes detection dramatically easier.

Baselining takes time: You can't detect anomalies without knowing what normal looks like. I ran the lab for a week with only legitimate traffic before introducing attacks, which gave me a meaningful baseline.

Documentation and Repeatability

I documented the full setup in a technical report, including all VM configurations, network diagrams, Splunk search queries, and detection results. The lab is fully reproducible — everything is scripted so I can tear it down and rebuild it from scratch in about an hour.

This repeatability matters. Security labs that can't be reliably recreated can't be used for training or testing new detection rules.

Takeaways for Anyone Building a Similar Lab

• Start small — one attacker VM, one victim VM, one SIEM is enough to learn a lot
• Focus on log quality over log volume — better data beats more data
• Build scenarios first, then build detections — know what you're trying to find before you write rules
• Document everything — your future self will thank you

Network security isn't something you learn by reading about it. You learn it by watching packets flow, watching attacks unfold, and understanding why your detections worked or didn't. That's exactly what this project gave me.