ML-Powered Threat Detection in a Cloud-Integrated Home Lab

Why build this at all

Detection engineering has a validation problem. You can write a rule, map it to MITRE ATT&CK, and push it through CI — and still have no idea whether it fires against real attack traffic, or how often it fires against traffic that is perfectly benign. Production telemetry is the wrong place to find out: it is noisy, sensitive, and you rarely get to replay an attack on demand.

So since December 2023 I have been building a lab that closes that loop: a hybrid environment that looks enough like enterprise infrastructure to generate realistic telemetry, instrumented end-to-end so that a detection idea can go from hypothesis to measured result without touching anything I am not allowed to break.

Architecture

The lab is provisioned with Terraform, which matters more than it sounds. Rebuilding from scratch is one command, every experiment starts from a known state, and the infrastructure definition doubles as documentation. The local side simulates a small enterprise segment — victim hosts, a domain of sorts, and a Kali attack box to generate the offensive half of the dataset.

Network visibility comes from two sensors running side by side:

• Zeek for rich protocol metadata — connection logs, DNS, HTTP, TLS — which becomes the feature source for the models.
• Suricata for signature-based alerting, which provides a baseline to compare the ML output against.

Everything is containerised with Docker, so the sensor stack and the analytics pipeline are portable and reproducible. The compute-heavy work — model training and batch analytics over PCAP-derived datasets — is offloaded to Oracle Cloud Infrastructure, which keeps the local footprint small and makes the lab genuinely hybrid: cloud telemetry and cloud IAM are part of the attack surface being studied, not an afterthought.

Threat-intelligence correlation runs through MISP, so detections can be enriched against known IOCs and the models' anomalies can be checked against what the intel side already knows.

The machine-learning layer

Two model families carry the detection work, chosen deliberately for different jobs:

• Random Forest for supervised classification, trained on labelled PCAP datasets — flow-level features like duration, byte and packet distributions, protocol mix, and connection-state patterns derived from Zeek logs.
• Isolation Forest for unsupervised anomaly detection, where the interesting traffic is precisely the traffic nobody has labelled yet.

The honest finding so far: the models are only as good as the feature engineering, and feature engineering is only as good as the telemetry. Most of the project's effort has gone into the unglamorous middle — parsing, normalising, and labelling — rather than the models themselves. That mirrors what I see in production detection work, and it is exactly the lesson a lab is supposed to teach cheaply.

What validation looks like in practice

A detection idea runs through the same cycle every time:

1. Stand up the relevant infrastructure with Terraform.
2. Generate the behaviour — attack traffic from the Kali box, benign background traffic alongside it.
3. Capture through Zeek and Suricata, extract features, run the models.
4. Measure: did it fire, what was the false-positive cost, and would the alert have been actionable for a human analyst?

Step four is the one that changes how you write detections. A model that flags 3% of benign flows sounds precise until you multiply it by enterprise traffic volumes.

Current focus

The lab is an ongoing project. Three threads are active right now: expanding the training datasets beyond the initial PCAP corpora, improving the unsupervised side so anomaly scores come with enough context to be triaged, and integrating cloud-native SIEM pipelines so the validation loop covers ingestion and alerting — not just the model in isolation.

The code and configuration live on GitHub, and I will write up individual components as they stabilise.