Home SOC Lab Build

If you're on UTM: open it up, click the + button, and walk through the wizard three separate times, once pointed at your Kali Linux ISO, once at your Windows 11 ISO, and once at your Ubuntu Server ISO. Point it at the plain installer ISO each time, not a pre-built or pre-installed VM, Kali does offer ready-made virtual machine images online, but skip those here, this project wants you clicking through the real install yourself so you actually see what gets set up and why. Stop right after each one is created, don't boot into the installer yet, we just want three machines sitting in your VM list, powered off. Seeing all three appear is your proof the hypervisor itself is working before anything real gets built on top of it. Good news if you're on Apple Silicon: virtualization is built in, so there's no BIOS or firmware setting to go dig up the way you might need to on a Windows or Linux PC.

On VMware Workstation Pro or VirtualBox instead, it's the same idea with a different wizard: click New (or Create), walk through the prompts for each ISO, and stop before it actually boots into setup.

Now, rename them. This one's small but saves you real headaches later, once you have three VM windows open at once, you want the title bar to tell you instantly which is which instead of guessing. Right-click each VM in your list and rename it: the Kali Linux one becomes kali-attacker, the Windows 11 one becomes win11-victim, and the Ubuntu Server one becomes ubuntu-siem. That's it, you're officially a VM landlord now.

Do this exact same thing for all three VMs: click the VM, open Settings, click Network on the left, and find the dropdown labeled Network Mode. Change it to Shared Network. Repeat for the other two, and you're done with this stage.

Here's the plain-English version of why that specific setting matters: Shared Network quietly builds a private little internet just for your lab, kind of like a guest Wi-Fi network only your VMs are invited to. They can all see and talk to each other, and they can still reach the real internet through your Mac (so installs and updates keep working), but nothing on your actual home network can see them, and they can't see it either.

Whatever you do, don't pick Bridged. Bridged does the opposite of what we're after: it puts the VM directly onto your real home Wi-Fi, as if it were just another laptop plugged into your router. That kind of exposure is exactly what this stage exists to prevent. You might also spot a mode called Host Only sitting nearby, skip that one too, it locks things down even further by cutting off internet access completely, which would break your installs a few stages from now. Shared Network already gives you the privacy we're after while keeping the internet connection alive.

Same idea as UTM above, just a different menu. With the VM selected (not running), click VM in the menu bar, then Settings, then Network Adapter on the left. Select NAT and click OK. Do this for all three VMs. VMware's NAT mode is the same idea as UTM's Shared Network above, your VMs get a private network together plus a route out to the internet, without ever touching your real Wi-Fi. Skip Bridged (puts the VM on your home network) and skip Host-only (kills internet access).

VirtualBox needs one extra step first, plain NAT in VirtualBox actually keeps each VM separate from the others, so open VirtualBox, go to File → Preferences → Network, click the NAT Networks tab, and click the plus button to create one, the defaults are fine. Then, for each VM, with it powered off, open Settings → Network → Adapter 1, and change Attached to from NAT to NAT Network, picking the one you just created. Do this for all three VMs. This gives you the exact same result as UTM's Shared Network and VMware's NAT above, all three VMs can reach each other and the internet, nothing from your home network can reach them.

Inside the VM, download Sysmon from Microsoft's Sysinternals site (it comes as a zip), and download sysmonconfig-export.xml from SwiftOnSecurity's page, that's a free, widely trusted ruleset that tells Sysmon exactly what to watch for. Unzip Sysmon into your Downloads folder (anywhere works, just remember where), then drop sysmonconfig-export.xml into that exact same folder, sitting right next to Sysmon64.exe and Sysmon64a.exe. They need to be neighbors for the install command below to find the config.

Click Start, type powershell, then right-click Windows PowerShell in the results and choose Run as administrator. Click Yes on the prompt. Running as Administrator matters here specifically because Sysmon installs a background driver, a low-level piece of software, and a regular window isn't allowed to do that.

Move into the folder where you saved Sysmon and the config file:

cd Downloads

cd just means "change directory," and Downloads is wherever you actually saved the files, swap in the real folder name if it's somewhere else.

Now the actual install:

Sysmon64a.exe -accepteula -i sysmonconfig-export.xml

Breaking that down piece by piece: Sysmon64a.exe is the program itself, the ARM64 build (that "a" stands for ARM, use this one if your Windows VM is ARM64, which it will be if you're on an Apple Silicon Mac). -accepteula quietly agrees to Microsoft's license on your behalf, skip it and Sysmon just pops up a license window and waits forever for a click. -i tells Sysmon to install itself, and sysmonconfig-export.xml right after it is the actual file it should install with, the SwiftOnSecurity rules you downloaded. On an Intel or AMD machine, swap in Sysmon64.exe (no "a") everywhere in this command instead. Picking the wrong one fails with "This driver has been blocked from loading," which sounds scary but is really just a CPU mismatch, not a security problem.

Sysmon64.exe -u force

-u tells Sysmon to uninstall itself, and force makes it clean itself out completely even if the earlier install only got halfway. Run the correct install command again right after this.

sudo apt update && sudo apt install -y spice-vdagent

A quick word on Linux commands before we go further, you'll see this shape a lot: sudo means "run this as the administrator." apt is Kali's package manager, the built-in tool that finds and installs software for you. update refreshes its list of what's available, and && just means "then, once that's done, run the next part." install -y spice-vdagent tells it to install the spice-vdagent package specifically, and -y auto-answers "yes" to the "are you sure?" prompt so it doesn't sit there waiting on you. The whole thing enables clipboard sharing between your computer and this VM, not required for the lab to technically work, but you'll be pasting commands into this window constantly, so it's worth the thirty seconds.

ip a

ip a just asks Linux to list every network connection it has and the address each one holds. We're only reading it here, to confirm Kali landed on the same subnet as your other two VMs (look for matching first three numbers, something like 192.168.64.x on all three). If it doesn't match, go back and double-check this VM's network setting from Stage 2.

curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

First line: curl fetches a file straight off the internet, -s keeps it quiet instead of spamming your screen with a progress bar, and the capital O tells it to save the file under its original name instead of dumping its contents at you. Second line: bash runs the script you just downloaded, and -a is the flag that says "install everything, indexer, manager, and dashboard, all in one pass," instead of you wiring each piece together by hand. It finishes by printing an auto-generated admin password, copy that somewhere safe right away, it scrolls off screen and won't be shown to you again.

msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER='<ubuntu-siem IP>'
NET START WazuhSvc

Don't type this one literally, the real version comes from your Wazuh Dashboard itself: open it, go to the Agents screen, click Deploy new agent, and it'll generate this exact command with your manager's real IP address already filled in. For context on what it's doing: msiexec is Windows' own installer program, /i tells it to install the file that follows, /q keeps it quiet with no popup windows, and WAZUH_MANAGER= tells the agent which machine to phone home to, your Ubuntu Server VM. NET START WazuhSvc then actually starts the agent service so it begins running instead of just sitting there installed and idle.

sudo apt update && sudo apt install -y suricata suricata-update

Installs Suricata itself plus suricata-update, the little helper tool that manages its detection rules.

ip a

Find your real network interface name before touching any config, something like enp0s1. Modern Ubuntu doesn't use the old eth0 name anymore, so write down whatever you actually see listed here, you'll need it in the next step.

sudo nano /etc/suricata/suricata.yaml

This opens the config file in nano, a simple text editor that runs right inside your terminal window, no separate app needed. Use your arrow keys to move around like normal. Scroll to find the af-packet: section near the top and change - interface: to the exact name you just read off with ip a, not eth0. When you're done editing, press Ctrl+O (that's the letter O, for "output") to save, hit Enter to confirm the filename, then Ctrl+X to exit back to your terminal. You'll use this exact same save-and-exit combo every time nano shows up later in this guide.

sudo systemctl restart suricata
sudo systemctl status suricata

systemctl is how Linux starts, stops, and restarts background services. The first line restarts Suricata so it picks up the interface change you just made, the second shows its current status. You're looking for a clean "active (running)" with an Engine started line and no repeated restarts scrolling by above it.

curl http://1.1.1.1/

This one's on purpose, we're deliberately triggering an alert so you can prove Suricata is actually watching, not just idling quietly. The specific rule that fires here matches a curl request to a literal IP address like this one, not a domain name, so this exact command is what makes it go off.

sudo grep -c '"event_type":"alert"' /var/log/suricata/eve.json
sudo cat /var/log/suricata/fast.log

grep searches through a file for lines that match something, -c just counts how many matches it finds instead of printing them all. The second line prints Suricata's plain-English alert log so you can actually read what it caught.

sudo nano /etc/suricata/disable.conf

Add these two lines, then save the same way as before (Ctrl+O, Enter, Ctrl+X):

# Routine APT/package-manager traffic, too noisy for a home lab
2013504

sudo suricata-update
sudo systemctl restart suricata

Rebuilds Suricata's active rule set with that one rule now suppressed, then restarts the service to load it.

sudo nano /var/ossec/etc/ossec.conf

Opens Wazuh Manager's main config file in nano. Scroll down and find an existing <localfile> block anywhere in the file (there are already a few), then add a new one right next to it:

<localfile>
  <log_format>json</log_format>
  <location>/var/log/suricata/eve.json</location>
</localfile>

Paste that in, then save with Ctrl+O, Enter, Ctrl+X. This block tells the Wazuh Manager "also read this file," pointing it straight at Suricata's alert log. No separate agent needed for this one, since Suricata and the Wazuh Manager live on the very same VM.

sudo systemctl restart wazuh-manager
sudo systemctl status wazuh-manager

The manager only picks up a config change like this after it's restarted, so this step isn't optional.

sudo grep -i suricata /var/ossec/logs/ossec.log
sudo grep -i suricata /var/ossec/logs/alerts/alerts.log | tail -5

The first line confirms the manager is actually reading eve.json (the -i just means match "suricata" whether it's upper or lowercase). The second shows the last few Suricata alerts as Wazuh decoded them, look for a line mentioning Rule: 86601, Wazuh's built-in decoder made specifically for Suricata alerts.

nc -lvnp 4444

nc is short for netcat, basically a Swiss-army knife for making and listening for network connections. -l means listen, -v means verbose so it actually tells you what's happening instead of staying silent, -n skips trying to look up hostnames, and -p 4444 picks which port to listen on, 4444 is arbitrary, any free port works. Leave this running and watching, don't close the window.

Test-NetConnection -ComputerName <kali-attacker IP> -Port 4444

This has to be PowerShell specifically, not the older Command Prompt (cmd.exe), which doesn't know this command and will just say it's not recognized. Open Start, type powershell, and open Windows PowerShell (the prompt should read PS C:\...>). -ComputerName is who you're trying to reach, your Kali VM's IP address, and -Port is which door you're knocking on, 4444, to match what Kali is listening on. A result of TcpTestSucceeded : True, together with the connection actually landing in your Kali terminal, confirms the two VMs can genuinely reach each other. Curious what happens with a straightforward Nmap scan instead? Check the Troubleshooting section below, it's a real, expected quirk, not a bug in your lab.

Open the Events tab for your Windows 11 agent and confirm you can see the outbound connection you just made sitting right there in the list. Seeing it is the whole point of this stage.

Shut each VM down properly, then right-click it in your hypervisor's VM list and choose Snapshot (or Clone, depending on your hypervisor), while it's sitting in this exact working state. You just gave yourself a free "undo" button for the rest of this course. Nicely done, that's Project 1 complete.