Blue Team Home Lab: Build a Mini SOC for Free

You cannot learn blue team skills from slides alone. You need logs that you generated yourself, alerts that fired because you broke something, and the freedom to destroy a machine and start again. A blue team home lab gives you all three, and you can build a useful one for free on a single laptop.

This is Part 10 of 30, the last of the beginner stage. We will build a small SOC: a Windows machine that produces logs, a Linux machine that attacks it, and a free SIEM that collects everything. Every later part of the path assumes you have something like this.

Key takeaways

• Four virtual machines are enough: a SIEM, a Windows endpoint, a Linux server and an attacker.
• Keep the lab on an isolated virtual network. Never bridge vulnerable machines to your home network.
• Take a snapshot of every VM once it works, so you can reset in seconds.
• Generate a small, known attack, then confirm you can see it in the SIEM. That loop is the skill.

What you need

The lab runs on a normal computer with virtualisation support enabled in the BIOS. As a planning figure, aim for a host with 16 GB of RAM and a few hundred gigabytes of free disk, because the SIEM is the hungry part. The Wazuh quickstart lists 8 vCPU and 8 GiB RAM for an all-in-one server handling up to 100 agents. A lab with two or three agents can run on less, but expect slower dashboards if you shrink it too far.

• Hypervisor: VirtualBox is free. VMware Workstation and Hyper-V also work.
• Windows endpoint: Microsoft provides time-limited evaluation versions of Windows through its Evaluation Center. Check the current terms and trial length there.
• Linux server: any Ubuntu Server LTS image.
• Attacker: Kali Linux or any distribution with the tools you want to practise with.
• SIEM: Wazuh, which is open source and runs on Ubuntu.

The lab design

Keep it simple. Four virtual machines on one internal network:

1. siem01: Ubuntu Server running Wazuh (server, indexer and dashboard).
2. win01: Windows endpoint with Sysmon and the Wazuh agent.
3. lin01: Ubuntu Server with the Wazuh agent and SSH enabled.
4. kali01: the attacker machine.

Give each VM two network adapters. The first is an internal-only network, such as a VirtualBox “Internal Network” or “Host-only” adapter, where all lab traffic flows. The second is a NAT adapter that you enable only when you need to download updates and tools, then disable again. Do not use a bridged adapter on machines you will attack, because a deliberately weak VM does not belong on your home network.

Use fixed addresses on the internal network so your notes stay valid, for example 10.10.10.10 to 10.10.10.13. Write down the credentials you set in a password manager and keep them out of your notes.

Step 1: build the SIEM

Install Ubuntu Server on siem01 and update it. The Wazuh quickstart offers an assisted installer that deploys all components on one host. At the time of writing the documented command looks like this, but always copy the current version from the documentation:

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

When it finishes, it prints the dashboard address and an admin password. Open the dashboard from a browser on your host or from kali01, and store that password safely. Part 14 is a full Wazuh tutorial, so for now you only need to see the login page and an empty agents list.

Step 2: build and instrument the Windows endpoint

Install the evaluation Windows image on win01. Before you connect it to the SIEM, improve what it logs, because default Windows logging is thin.

• Install Sysmon from Microsoft Sysinternals with a configuration file. Parts 11 and 12 cover configuration and event IDs in depth.
• Enable command-line logging for process creation events so event 4688 records what was run.
• Enable PowerShell script block logging through Group Policy.

Then add the Wazuh agent. The Wazuh dashboard has a guided “Deploy new agent” page that generates the install command for Windows, with the server address filled in. Run the command in an elevated PowerShell session on win01, start the service, and check that the agent shows as active in the dashboard.

Step 3: build the Linux server

Install Ubuntu Server on lin01 with OpenSSH. Add the Wazuh agent the same way, using the dashboard’s generated command for Linux. On this machine, practise reading the logs by hand as well, using Part 5 of this path and the guides on journald and rsyslog and auditd rules.

Step 4: add the attacker

Put Kali on the internal network. It needs no agent. Its job is to generate activity that your sensors should see. Only ever aim it at the machines in your own lab.

Step 5: generate your first alerts

Now close the loop. Here are three safe exercises, each with something to find afterwards.

1. Failed SSH logons. From kali01, try wrong passwords against lin01 a handful of times. Then find them in /var/log/auth.log and in the Wazuh dashboard, using the methods from Part 5.
2. Failed Windows logons. Try to sign in to win01 with a wrong password a few times. Find event 4625 in Event Viewer, as described by Microsoft, and then in the SIEM.
3. A new local user. On win01, create a test account and look for event 4720 on Microsoft’s reference page. That is the technique T1136.001 on the ATT&CK site.

Each exercise answers the same question: did my lab see this, where, and how fast? If the answer is “no”, you have found a logging gap. Fixing it is the learning.

Step 6: capture the network

Run a packet capture on kali01 or on the hypervisor’s virtual network while you repeat an exercise. Open it in Wireshark and find your own traffic, as taught in Part 9. You will be faster at spotting real scans after you have made one yourself.

Snapshots, backups and hygiene

• Snapshot each VM after setup and name it clearly, for example “clean-baseline”. Revert after every destructive test.
• Export your configs (Sysmon file, Wazuh rules, notes) to a Git repository so you can rebuild.
• Keep the lab off your work network. Never practise on systems you do not own or have permission to test.
• Update deliberately. Patch the SIEM and Linux machines on a schedule, and keep the Windows machine’s weaknesses intentional.

Where to go from here

With this lab running, the rest of the path becomes hands-on. You can tune Sysmon in Part 11, write queries in Part 13, practise detections for Kerberos attacks in Part 18 using the Kerberos deep dive, and run controlled attack tests in Part 29. If you want a more offensive way to use the same lab, the Active Directory attacks guide will help.

Keep a lab notebook

A lab becomes a portfolio when you document it. For every exercise, write a short note with five lines: what you did, what you expected to see, what you actually saw, which log source showed it, and what you changed afterwards. Store the notes in a Git repository or a simple folder of Markdown files. After a month you will have a record of real work that you can talk about in an interview, far more convincing than a list of tools you have read about.

Add the ATT&CK technique ID to each note, as we practised in Part 6, and mark whether your lab detected it. That gives you a personal coverage map that grows with each exercise.

A four-week practice plan

1. Week 1: build the four VMs, connect both agents and take snapshots. Success means two active agents in the dashboard.
2. Week 2: add Sysmon on Windows and generate failed logons, new users and a few PowerShell commands. Find each event by hand, then in the SIEM.
3. Week 3: run port scans and a simulated brute force from Kali. Capture traffic, find the scan in Wireshark and the failed logons in auth.log.
4. Week 4: write one custom alert in the SIEM for something you generated, test it, and note how often it fires on normal use.

By the end of the month you will have done the full defender loop at small scale: generate, observe, detect, tune. The intermediate stage of this path repeats that loop with better tools and harder techniques.

Common pitfalls

• Starving the SIEM of memory. A sluggish dashboard usually means too little RAM or CPU.
• Using a bridged network for vulnerable or attacking machines.
• Skipping snapshots. One bad config can cost you a weekend.
• Collecting logs but never testing detections. A lab that only receives logs teaches little.
• Letting the evaluation licence expire without a plan to rebuild the Windows VM from your notes.
• Trying to build everything at once. Get one Windows agent reporting first, then add the rest.

Frequently asked questions