Post cover image

November 5, 2026

Purple Team(cyberSecurity ) Home Lab Set-up

VLAN’s,Proxmox & VMware , Wazuh + Suricata , Active Directory , Kali and a Tailscale-remote Access

By Balakrishnanhari

26 min read

This blog is about how i set-up my Home Lab which cover both Attacking and Defensive side of Cybersecurity Set-up. So the that i can perform breaking into systems like a penetration tester and detecting those break like a SOC Analyst. So Rather than two disconnected skill sets , the lab wires them together-every attack from red side is desigent to be visible to the blue side , so exercise closes the loop from action to alert.

List of Hardware and There Roles

None

Architecture Block Diagram

None

I am dividing this lab set-up into Six phase's

Phase 1 : Physical Network

Phase 2 : Host Preparation

Phase 3 : Build The Blue Team Engine

Phase 4 : Build The Target Infrastructure

Phase 5 : Build The Red Team Platform

Phase 6 : Giving My Red Team Platform Remote Access with Tailscale

Lab Scope & Exercise Roadmap

Phase 1 : Physical Network & remote Access

Step 1 : Configuring Switch

Let us start to configure Switch through console port. Here i am using TP-Link TL-SG3210 V3 switch .

  1. Connect the cable : Plug the micro-usb B port into the Console Port ont he switch and the usb end into your Lap/Pc.
  2. Find the COM Port(windows) :

open Device Mnger →Expand Port (COM & LPT) and note your adapter's port number for me it COM3

  1. Open Putty :

Open Putty →Select Serial as the connection Type

Set Serial Line to COM3 →speed(Baud Rate) : 38400 → click Open and Press Enter

Once the switch boots up. log-in with default credentials :

Username: admin , Password: admin

Architecture at a Glance

None

Let create a VLAN and configuing it .

enable
comfigure

#Creating VLAN's
vlan 10
  name Red Team
exit

vlan 20
  name Target Zone
exit

vlan 30
  name SOC
exit

#Configuring Router Uplink(Trunk)
interface gigabitEthernet 1/0/1
  switchport mode trunk
  switchport trunk llowed vlan 10,20,30
exit

#Configuring VLAN 10
interface gigabitEthernet 1/0/2
  switchport mode access
  switchport acces vlan 10
exit

#Configuring VLAN 20
interface gigabitEthernet 1/0/3-4
  switchport mode access
  switchport acces vlan 10
exit

#Configuring VLAN 30
interface gigabitEthernet 1/0/5-8
  switchport mode access
  switchport acces vlan 10
exit

#Save Configuration
copy running-config startup-config

Now we have created a VLAN you can see the vlan by using command

enable
show vlan brief
None

By default, every port on a managed switch belongs to VLAN 1 . So we need to we need to remove port from it

enable

config

#removing port 2
interface gigabitEthernet 1/0/2
no switchport general allowed vlan 1
exit

#removing port 3
interface gigabitEthernet 1/0/3
no switchport general allowed vlan 1
exit

#removing port 4
interface gigabitEthernet 1/0/4
no switchport general allowed vlan 1
exit

#removing port 5
interface gigabitEthernet 1/0/5
no switchport general allowed vlan 1
exit

#removing port 6
interface gigabitEthernet 1/0/6
no switchport general allowed vlan 1
exit

#removing port 7
interface gigabitEthernet 1/0/7
no switchport general allowed vlan 1
exit

#removing port 8
interface gigabitEthernet 1/0/8
no switchport general allowed vlan 1
exit

#saveing the configuration
copy running-config startup-config
None

The Problem : Port 1 was an untagged access port so it can only see VLAN 30 . so that Raspberry Pi(Router) can only see traffic from single zone but here Raspberry Pi(router) need to see traffic from all zone to route traffic between them.

The Solution : Port 1 can be converted into a trunk port To allow the Raspberry Pi(router) to manage multiple subnets over a single physical port, Port 1 was configured as a trunk port carrying tagged frames for all lab VLANs.

SG3210# enable
SG3210# config
SG3210(config)#interface gigabitEthernet 1/0/1
SG3210(config-if)#no switchport general allowed vlan 1
SG3210(config-if)#switchport general allowed vlan 10 tagged
SG3210(config-if)#switchport general allowed vlan 20 tagged
SG3210(config-if)#switchport general allowed vlan 30 untagged
SG3210(config-if)#exit

In above i did not tagged vlan 30 bcz here we are going to create a PVID(Port VLAN ID) was set to 30 meaning any untagged frames arriving from the Pi automatically go to the SOC Zone.

#here we are setting pvid

enable
configure
interface gigabitEthernet 1/0/1
switchport general pvid 30
end
None

So right now we completed our switch configuration . Let Move to router configuration .

Hey Guy's right now i don't have any Router So i had converted my Raspberry-pi 3b+ into a Switch . If you guy's will to go this process you can check here.

So right now we completed our phase 1 .

Phase 2 : Host Preparation

In this phase we are going to prepares two hypervision host's .

  1. Dell Tiny PC →runs Proxmox VE as the always-on Blue Team engine, living on VLAN 30.
  2. Dell Laptop → runs VMware Workstation Pro as the disposable target host, living on VLAN 20.

IP Plan

None

BIOS Configuration

Step 1: BIOS Configuration(do this on both machines) Reboot into BIOS/UEFI by pressing F2 or F12(usually) may vary based on brands and models.

  1. Enable virtualization — look under Virtualization Support or CPU Configuration:
  • Intel VT-x → Enable it
  • Intel VT-d → Enable it if present this can be help later if you want to pass NIC directly to VM
  1. Enable Auto Power-On — usually under Power Management:
  • AC Recovery or Restore AC Power Loss → set to "Power-on" this ensure both machine come back online after any bower-cut without any physical access.

After completeing it save and exit. Now Let us download the resources to complete this phase .

Step 2: Install Hypervisor To install proxmox-ve first we need to create a bootable device, for this i am useing rufus software .

None

In Boot selection field we need to select the proxmox-ve iso file , Then in paatition Scheme select it based on your system. Then click STAT it show a pop-up message

None

Here we need to **select Write in DD Image mode.**Wait for it to complete (progress bar + "READY" status again), Then Boot the Tiny PC from this USB and see if it finds the ISO this time.

Step 3: Static IPs on VLAN 30

During Installation we can set a static-ip(192.168.50.10) for Proxmox . so that we can reache Web UI any time

Step 4: Other Things to Set during installation

Hostname : pve.tinypc.lab.local IP Address : 192.168.50.10/24 Gateway : 192.168.50.1 DNS Server : 192.168.50.1

Step 5 : Accessing proxmox-VE

Now We can Acces the Proxmox Web UI from any devices which is connected on the same network , open a browser and go to → https://192.168.50.10:8006

Log-in with :

User-name : root Password : Set during installation

Step 6: Update the system

apt update && apt full-upgrade -y

Step 7: Verify network connectivity

Conform the Tiny-Pc can reach the Raspberry-pi (gateway) and the internet

ping -c 4 192.168.50.1
ping -c 4 8.8.8.8

Step 8 : Updateing

Now we need to packages to it's lates version

apt update && apt full-upgrade -y

Let now start set-up VM in Dell Laptop

for dell laptop i am choosing VM Workstation Pro . you can dowload it in https://www.vmware.com/products/desktop-hypervisor/workstation-and-fusion

  1. Download VMware Workstation Player and run the installer it show a pop-up menu → press "yes" to continue
None
  1. Now you will see VMware Workstation setup wizard dialog box. Click next to continue.
None

Now it will show End User Licence Agreement dialog box. Check "I accept the terms in the Licence Agreement" box and press next to continue.

None

Select the folder in which you would like to install the application. here i am going to leave in default path.

None

Next you are asked to select "Check for Updates" and "Help improve VMware Workstation Pro". Do as you wish. I normally leave it to defaults that is unchecked.

None

Next step select the place we want the shortcut icons to be placed on our desktop . so select both the options, desktop and start menu and click next.

None

Click install to start the installation process

None

Now it will start to install , so wait untill it complete the installation process . After the it will So a dialog box. In it Click "Finish" and now the installation process is completed .

None

Now you can see VMware Workstation icon on the desktop. Double click on it to launch the application.

None

Now in both Dell Mini-pc and Dell Laptop we installed VM . And i am sorry that i can't add screenshot for proxmox installation process bcz of some technical issues.

Phase 3 : Build The Blue Team Engine

Phase 3 : Build The Blue Team Engine

Now in this phase we are going to Install Wazuh 4.9 SIEM inside ubuntu server and Suricata 7.0.10 inside proxmox host

you can refer to here for install ubuntu server in proxmox host . i am skipping this part due to Fluffness . but make shure you set an static IP 192.168.50.11

Setp 1 : Deploying a Wazuh in ubuntu Server

First Let us donwload the wazuh official installation script by using curl in terminal

curl -curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh

Now let exexute the installation script with -a flag bcz by default it will set up an all-in-one deployment((Wazuh Indexer, Server, and Dashboard all on a single machine)

sudo bash ./wazuh-install.sh -a

One the installation is completed it will show a success message which also contain the Wazuh Dashboard URL , default User-name : "admin" and Password .

Let's verify access now:

sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard --no-pager

All three should show active(running).

Note : Save the credential in some text document . So that use it late while login to Wazuh Web UI through https://192.168.50.11/app/wz-home#/

Step 2 : SPAN Mirror on the Switch

Suricata, an IDS that watches mirrored traffic from the Red Team (VLAN 10) and Target (VLAN 20) zones and sends its alerts into Wazuh.

Note : Instead of Suricata you can also use Snort IDS.

Before installing anything, I had to solve a hardware problem.

The Problem: One NIC, Two Jobs An IDS fed by a SPAN (port mirror) session needs a network interface dedicated to receiving the copied traffic. My Dell Tiny PC (the Proxmox host) has only one Ethernet port, 'nic0', and it already carries Proxmox management traffic and all VM traffic through 'vmbr0'.

Mirroring onto that same NIC can work in some setups, but it's a bad idea. It mixes control traffic with monitored traffic and can disrupt Proxmox's own connectivity.

The Workaround: Borrowing the USB Adapter

The TP-Link switch supports port mirroring, and I'd already planned a destination port, Gi1/0/8. What I needed was a second NIC.

The resulting design: nic0 (onboard): management and VM traffic on vmbr0

UE300 (USB): dedicated monitoring NIC, no IP address, not attached to any bridge, just in promiscuous mode so Suricata can read raw packets

I configured a SPAN (port mirror) session on the TP-Link SG3210. It copies traffic from the Red Team port (Gi1/0/2) and the Target Zone ports (Gi1/0/3–4) to the monitoring port (Gi1/0/8). Here i am also adding

Using putty we can do it in swicth . I already mention early how to access switch CLI .

enable
configure
monitor session 1 source interface gigabitEthernet 1/0/2,1/0/3,1/0/4 both
monitor session 1 destination interface gigabitEthernet 1/0/8
end

#saveing the changes
copy running-config startup-config

Why Mirror the Attacker Zone Too?

My SPAN session copies traffic from the Red Team port (Gi1/0/2) as well as the Target Zone ports (Gi1/0/3–4). Mirroring only the targets would capture attacks that arrive, but miss everything that doesn't:

  • Scans of hosts that don't exist or get blocked
  • Attempts against the SOC VLAN or the router
  • Outbound DNS and internet traffic from the attacker

Seeing both sides gives me ground truth: what the attacker actually sent versus what each detection layer saw. The trade-off is that traffic between zones is captured twice (once leaving the attacker, once arriving at the target after routing), which can produce duplicate alerts and skew threshold-based rules.

Prepare the Capture NIC:

I am going to deploy Suricata directly into a Proxmox host bcz it need raw access to the physical mirror interface

Before we start installing first we need to find the interface name we can find it by

ip a

After finding the interface name, We need to the NIC up and connect patch cable to the switch SPAN destination port (Gi1/0/8), then run

sudo ip link set enx00e06xxxxxxx up

Then we can check the interface status by running

ip a show enx00e04xxxxxxx

Install Suricata :

sudo apt update
sudo apt install suricata -y

Configure Suricata to listen on that interface:

Edit 'suricata.yaml' . In it we need make two change

sudo nano /etc/suricata/suricata.yaml
  1. Point 'af-packet' at the monitoring NIC.

Find the 'af-packet' section and replace the default interface (usually eth0) with the SPAN port connectedd NIC

af-packet:
  - interface: enx00e04xxxxxxxxx
  1. Set 'HOME_NET'

Under 'vars: address-groups:', define which networks count as "inside" for detection rules. At this point I only had the VLANs being mirrored:

HOME_NET: "[192.168.10.0/24,192.168.20.0/24]"

Now save and exit

Suricata has a test mode that validates the configuration without starting the engine. Run it first, because it's much easier to debug than a service that silently fails.

sudo suricata -T -c /etc/suricata/suricata.yaml -i enx00e04cxxxxxxxx

My output :

i: suricata: This is Suricata version 7.0.10 RELEASE running in SYSTEM mode
W: detect: No rule files match the pattern /var/lib/suricata/rules/suricata.rules

It showing a warning that suricata load fine but it found no rules bcz fresh install ships without a ruleset. So now it can watch traffic and never alter on anything.

Download the Rules :

suricata-update fetches the free "Emerging Threats Open" ruleset and puts it exactly where Suricata expects it:

sudo suricata-update

after update complete you can find the file in /var/lib/suricata/rules/suricata.rules now Re-run the Test , This time the rule load and end-up clearly.

Run It as a Service :

I am going to set it to start on boot insted of launching it manualy by editing /etc/default/suricata → in it change the interface line :

IFACE=enx00e04cxxxxxxxxx

after changeing it save and then enable and start the service

sudo systemctl enable suricata
sudo systemctl start suricata
sudo systemctl status suricata --no-pager

Suricata is now running and writing alerts to '/var/log/suricata/eve.json'.

Now let's connect Suricata's alerts into Wazuh, so everything shows up in one dashboard instead of two separate logs. for this we need to install light weight wazuh Agent on proxmox host .

  • The Wazuh Agent runs directly on Proxmox, reads Suricata's local eve.json, and forwards those events to the Wazuh Manager at 192.168.50.11
  • This is the standard Wazuh pattern — treats Proxmox host as a monitored endpoint

Step 1: Add the Wazuh repository and install the agent on Proxmox host

curl -o wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.2-1_amd64.deb

Step 2: Install with the Manager IP pre-configured

WAZUH_MANAGER='192.168.50.11' dpkg -i ./wazuh-agent.deb

Step 3: Enable and start the agent

systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
systemctl status wazuh-agent --no-pager

This show the result active(running)

Step 4: Configure the agent to monitor Suricata's eve.json

For this we need to edit the agent config → nano /var/ossec/etc/ossec.conf

In Ossec.conf file find the <ossec_config> and add a new block as showen below

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

Now Save and restart the agent to apply changes .

systemctl restart wazuh-agent

Step 5 : verify the agent on the Wazuh Manager side

Now just log into the Wazuh Dashboard (https://192.168.50.11) → Agents section→ now we can see a new agent named pve-tinypc listed as Active.

Phase 3 is genuinely, fully complete. Here's the final state:

  • Wazuh SIEM (Indexer + Manager + Dashboard) — stable, disk issue resolved, vulnerability detection disabled to prevent recurrence
  • Suricata IDS on Proxmox host, listening on SPAN-mirrored VLAN 10/20 traffic via persistent USB NIC config
  • Full Emerging Threats Open ruleset (52,806 rules) properly synced via suricata-update
  • Proxmox host enrolled as a Wazuh agent, forwarding Suricata's eve.json alerts

Phase 4 : Build The Target Infrastructure

Phase 4 is the target infrastructure: the machines that get attacked and monitored. The first one is a Windows Server 2025 Domain Controller running Active Directory for a domain called 'lab.local'. It's the most valuable target in any Windows network, so it's also the most important one to monitor.

All of this runs in VMware Workstation Pro on the Dell laptop (VLAN 20, 192.168.20.10), bridged to the physical NIC so each VM gets its own address in the Target Zone.

The best way to learn about Active Directory environments is to build one. In this guide, I walk through the process I used to:

  • Build a Domain Controller (Windows Server 2025).
  • Create two Windows 11 client machines.
  • Join those client machines to the AD Domain.
  • Create and test user accounts (both local and AD accounts).
  • Configure AD services like DNS, Group Policy, and User Management.

Part 1 : Building the Domain Controller (AD-DC01)

Step 1 : Download the recourses

Windows Server 2025: https://www.microsoft.com/en-us/evalcenter/download-windows-server-2025

Step 2: Creating the Virtual Machines

Create a new VM: Name : AD-DC01 Processors :1 processor, 2 cores RAM : 4gb UEFI as Firmware Network : Bridged Disk Space : 70gb , stored as a single file

Before clicking "Finish" , Open Customize Hardware → select New CD/DVD → choose use ISO image file and point it as Windows Server 2025 evaluation ISO.

Step 3: Install Windows Server 2025

power on the machine and boot straight into Setup . choose

  • Product key: I don't have a product key
  • Edition: Windows Server 2025 Standard Evaluation
  • Install type: Custom (advanced), installing to the 70 GB unallocated disk

The installation process take some time (around 20min) with some automatic reboot . At the end we need to set Administrator Password .

Step 4: Set a Static IP

DC need a stable network identity. Let set it

open settings → Network & Interface → Ethernet → Edit :

  • IP address : 192.168.20.11
  • Subnet mask : 255.255.255.0
  • Gateway : 192.168.20.1
  • Preferred DNS : 127.0.0.1
  • Alternate DNS : 1.1.1.1

click save .

Now we should Verify connectivity for this open power-shell as Administrator and run :

ipconfig
ping 192.168.20.1
ping 8.8.8.8

Confirm the IP shows correctly and both pings succeed

step 5 : Domain Controller Configuration

i) Install the AD DS role

  • Click Manage →Add Roles and Features
  • Installation Type →select Role-based or feature-based installation → Click Next
  • Server Selection → you server (AD-DC01) → Click Next
  • Server Roles → check Active Directory Domain Services -> Click Nex for all other opetion until you see Install

ii) Promote to Domain Controller

  • Select "Add a new forest"
  • Domain Name : lab.local
  • Click Next

iii) Deployment Configuration

  • Forest functional level / Domain functional level: leave at default
  • Checke DNS Server
  • Set the DSRM password
  • click Next

iv) Additional Options

  • NetBIOS name should auto-populate as LAB — leave as is
  • Click Next

v) Paths

  • Leave default paths for AD DS database, log files, SYSVOL
  • Click Next

vi) Review Options

  • Review the summary
  • Next

vii) Prerequisites Check

  • Windows will run a check
  • click Install

Now the server will Install and Reboot automaticaly → once completed now we login as Lab\Administrator instead of local Administrator.

Confirm you're now logged in as a domain account

whoami

Should show "lab\administrator"

Verify AD DS and DNS are running correctly

Get-Service -Name NTDS, DNS, Netlogon

All three should show Running.

check network connectivity still works

ping 192.168.20.1
ping 8.8.8.8

Install Sysmon + Wazuh Agent on AD-DC01

i)Download Sysmon and the SwiftOnSecurity config

Flow the below process to download Sysmon and SwiftOnSecurity config file by using power-shell inside the VM.

mkdir C:\Sysmon\
cd C:\Sysmon\

#download Sysmon
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" -OutFile "Sysmon.zip"
Expand-Archive -Path "Sysmon.zip" -DestinationPath "C:\Sysmon"

#download SwiftOnSecurity config file
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" -OutFile "C:\Sysmon\sysmonconfig-export.xml"

ii) Install Sysmon with the SwiftOnSecurity config

cd C:\Sysmon\

.\Sysmon64.exe -accepteula -i sysmonconfig-export.xml

Now confrim Sysmon is installed as service

Get-Service Sysmon64

iii) Download and install the Wazuh Agent

#downloadin wazuh agent
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.2-1.msi" -OutFile "$env:tmp\wazuh-agent.msi"

#instaling wazuh agent
msiexec.exe /i "$env:tmp\wazuh-agent.msi" /q WAZUH_MANAGER="192.168.50.11"

#starting wazug agent
NET START WazuhSvc

iv) Configure Sysmon log collection in the agent config

wazuh config file are at C:\Program Files (x86)\ossec-agent\ossec.conf path open it with notepad → add below content inside the <ossec_config>

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

now save it -> restart the wazuh agent

NET STOP WazuhSvc
NET START WazuhSvc

Now check wazuh agent is running

Get-Service WazuhSvc

Part 2: Building the Windows 11 Workstation (WIN11-WKS01)

I am adding windows workstaion bcz Domain controler alone make a much target . Real attacks usually start from workstation and escalate to DC . So Let add Windows 11 workstion (win11-wks01)to lab.local

Step 1 : Download resource

Let download Windows 11 Enterpricer from https://www.microsoft.com/en-us/evalcenter/download-windows-11-enterprise it has 90 day's free trail . or you can also use Windows 11 pro.

Step 2 :Create new vm for windows 11

This follow same step as we used in DC

Name : win11-wks01 Processor : 1 socket , 2 cores Memory : 4gb Network : Use bridged network Disk-Size : 70gb

Step 2: Skip the Microsoft Account Prompt

During first time set-up windows required to sign-n with microsoft account but for lab machine we want local account . So we can skip this process by pressing "shift + F10" in network screen which will open command prompt .

oobe\bypassnro

Now the VM will reboot and now set-up offer "I don't have internet" . So now you can create a local account.

After completeing all now VM will reboot →

Step 3: Static IP and DNS

open settings → Network & Interface → Ethernet → Edit IP assigment manual → Toggel IPV4 on then

IP address : 192.168.20.12 Subnet mask : 255.255.255.0 Gateway : 192.168.20.1 Preferred DNS :192.168.20.11

save it and verify the connectivity to the DC by

ping 192.168.20.11

nslookup lab.local

step 4 : Rename the computer

Rename-Computer -NewName "WIN11-WKS01" -Restart

Step 5 : Join to the domain

open powershell

Add-Computer -DomainName lab.local -Credential LAB\Administrator -Restart

Step 6: The Login Problem

Now restart the system and I tried to login in with "administrator" and got a message account is disabled. This happen bcz without domain specific windows checked it's own Administrator account first . This account is disabled by default on windows 11 .

So be try to include domain on login. It can be done by Click "Other User" in login page "administrator@lab.local"

Step 7 : Verify the Join

Now verify Workstation is the correct role for a domain-joined client. To check this open powershell

Get-ComputerInfo | Select CsDomain, CsDomainRole

Output must show :

CsDomain : lab.local CsDomainRole : MemberWorkstation

Install Sysmon + Wazuh Agent on WIN11-WKS01

For this follow the exact same method done in Domain Controler .

Part 3: Building the Ubuntu Server VM for the vulnerable Linux target.

Here I am adding Linux target bcz the Domain Controller and the Windows workstation cover the Active Directory side. The third target covers a different attack surface: a Linux server running "intentionally vulnerable web applications". It gives the lab something to hit with web scans and brute-force tools, and a different kind of telemetry to detect.

List of components i am going to use here are :

  • Ubuntu Server 24.04 → The host OS
  • Docker → Runs the vulnerable apps in containers
  • OWASP Juice Shop (on port 3000) → A modern vulnerable web app (SQLi, XSS, broken auth, etc..)
  • DVWA (on port 8080) → A classic vulnerable PHP app with adjustable difficulty Levels
  • Wazuh agent → Ships the logs to the SIEM
  • Auditd → Kernel-level logging of commands and sensitive file access

Step 1: Create the VM and Install Ubuntu

Create a new vm with below specification

Name : LINUX-TARGET01

Processors: 1 socket, 2 cores → Next

Memory: 2 GB RAM

Network: Use bridged networking

Disk size: 30 GB

Now power on and start the installation process as we done early for Wazuh VM .

network config for this Ubuntu installer screen:

Subnet: 192.168.20.0/24 Address: 192.168.20.13 Gateway: 192.168.20.1 Name servers: 1.1.1.1

Once installation completed Vm will automatically reboot.

Step 2: Verify network connectivity

ip a
ping -c 4 192.168.20.1
ping -c 4 8.8.8.8

Step 3 : Update the system

sudo apt update && sudo apt upgrade -y

Step 4 : Install Docker

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER

Step 5: Deploy OWASP Juice Shop

docker run -d - name juice-shop -p 3000:3000 - restart unless-stopped bkimminich/juice-shop

Step 6: Deploy DVWA

docker run -d --name dvwa -p 8080:80 --restart unless-stopped vulnerables/web-dvwa

Verify both(Juice shop and DVWA) are running:

docker ps

Step 7 : Auditd for Command and File Logging

Web attacks are visible on the network, but what an attacker does after getting in is only visible on the host. 'auditd' records that at the kernel level.

sudo apt install auditd audispd-plugins -y
sudo systemctl enable auditd
sudo systemctl start auditd
sudo systemctl status auditd --no-pager

you can add you own rule in "/etc/audit/rules.d/lab.rules" , for example right now i am going rule , which will log every program execution

-a always,exit -F arch=b64 -S execve -k exec_log
-a always,exit -F arch=b32 -S execve -k exec_log

Step 8 : Install the Wazuh Agent

curl -o wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.2-1_amd64.deb
sudo apt install lsb-release -y
sudo WAZUH_MANAGER='192.168.50.11' dpkg -i ./wazuh-agent.deb

Forward the Audit Log to Wazuh by adding below content inside <ossec_config> in "/var/ossec/etc/ossec.conf"

<localfile>
  <log_format>audit</log_format>
  <location>/var/log/audit/audit.log</location>
</localfile>

then save and restart it .

sudo systemctl restart wazuh-agent

Verify it on wazuh manager

sudo /var/ossec/bin/manage_agents -l

now it should list linux-target01

The targets are built and every one of them reports to Wazuh.

Phase 5: Building the Red Team Platform (Kali on the Asus Laptop)

Now our lab need an attacker. So let put Kali Linux machine on the Red Team VLAN (VLAN 10, "192.168.10.0/24"), so attacks cross the router and the SPAN mirror and leave evidence for the Blue Team side to find.

My Asus Laptop run windows and has no linux on it . First i planned to install kali linux natively but i choose VM on top of Windows 11 .

Resoun 1 : snapshot → I can roll back after a failed exploit attampt and take clean "before" states for blog write-ups and proofs of concep.

Resoun 2 : Keep the laptop usable . Windows stays intact for everythings else.

I deliberately kept Kali minimal at the start:

  • No auditd or Wazuh agent on Kali.As a beginner, I wanted to learn to read the victim-side detections (Suricata, Sysmon, Wazuh) before also watching attacker-side logs. Seeing both at once would have been noise while I was still learning what each alert means.
  • No Tailscale yet. Traffic through the Tailscale tunnel doesn't cross the mirrored switch ports, so Suricata can't inspect it. I wanted my first attacks on the plain wired VLAN 10 path, where every packet is visible to the sensor. Tailscale was added later, once I was ready to test remote access. but in this blog we also covered it .

Step 1 : Download the resources

Here i am going to use pre-built Kali VMware image from kali official download page → https://www.kali.org/get-kali/#kali-virtual-machines

before using the resource check the SHA256sum → f7a008dfc78de660f8e98b8cbbf94c36688e5441bf53d6c32643f0573177a096

Step 2: Import into VMware Workstation

i) Extract the download archive file

ii) Now open VM → File → open browse to extrcted folder → select the .vmx file .

Step 3: Resource allocation

Befoor booting the VM , edit the VM Setting

  • Processors: 2 cores
  • Memory: 3GB
  • Hard disk: 40GB

Step 4: Switch to XFCE

Kali linux default desktop is GNOME , which is heavier. So once booted change it to XFCE

sudo apt install -y kali-desktop-xfce

at login screen , select Xfce Session before logging in.

Step 5: Set networking to Bridged

Now shutdown the kali Linux ,

Physically connect the Asus's Ethernet port to switch port Gi1/0/2 and go to VM Settings → Network Adapter →Bridge under Configure Adapters make sure it bridge to your Physical NIC on the ASUS

Step 6: Verify network placement

ip a
ip route

If the wired interface doesn't show "192.168.10.50/24", set it:

nmcli connection modify "Wired connection 1" ipv4.addresses 192.168.10.50/24 ipv4.gateway 192.168.10.1 ipv4.method manual
nmcli connection up "Wired connection 1"

Then verify:

ip a                        # should show 192.168.10.50/24
ip route                    # default route via 192.168.10.1
ping -c 5 192.168.10.1      # gateway (Pi)
ping -c 5 192.168.20.113    # target VLAN, through inter-VLAN routing
ping -c 5 8.8.8.8           # internet

Step 7 : Tools

In this lab we used pre-built Kali image which include all core tools which is needed for this lab . So right now we need to verify them and update the system.

which nmap hydra nikto sqlmap msfconsole
sudo apt update && sudo apt full-upgrade -y

we can install specific tools later when needed.

Step 8 : Baseline snapshot

once everything in the above is confirmed working , Shutdown the VM properly and open VM menu → snapshot → Take snapshot , now you will get two fields

Name: snapshot 1

Description : Fresh Kali install, XFCE desktop, fully updated, bridged networking confirmed to VLAN 10/20, no Tailscale/auditd yet

None

I am useing it bcz if an exploit breaks something or if i want to repeat an experiment from the same starting point, I can roll back in seconds . This is one reason I chose a VM over a native install .

Note: A snapshot is a rollback point, not a backup. It sits beside the VM's own disk files.

Phase 6 : Giving Red Team Platform Remote Access with Tailscale

Part 1 : Creating Remote Access.

Up to this point we had connected attack system (Kali VM) directly to the Red_Team VLAN, but real attackers will be coming from external networks. We would need to detect and attribute any traffic from attackers in our SOC anyway. In this phase I made my Kali machine available to the lab from anywhere without exposing any ports to the Internet.

Why Tailscale?

Tailscale uses Wireguard to create a private mesh vpn. Each device registered will have a static IP address in the range 100.x.x.x and will communicate securely via a tunnel to the other devices.

Now we only need to install tailscale on two device

  1. **The Raspberry Pi :**as a subnet router. It already routes all three VLANs, so it can advertise them to the tailnet.
  2. The Kali VM, as the client.

Work Flow will be

kali → Tailscale tunnel → Pi(router) → Vlan 10/20/30

Step 1: Installing Tailscale on Pi

Install Tailscale:

curl -fsSL https://tailscale.com/install.sh | sh

Authenticate and advertise the three VLAN subnets:

sudo tailscale up --advertise-routes=192.168.10.0/24,192.168.20.0/24,192.168.50.0/24 --accept-dns=false

Linux won't forward packets between interfaces by default, so I enabled IP forwarding and made it persistent

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Now we need to approve them in Tailscale admin console for this follow the below steps

Go to https://login.tailscale.com/admin/machines → you can find the pi in below → click the 3 dots menu which is placed near pi entry → Edit route setting → Approve all three subnets

Now Verify it in Pi terminal

tailscale status

it should show the pi as online with it's tailnet IP 100.XX.XX.X .

step 2 : Installing Tailscale on Kali (attacker client)

Install Tailscal

curl -fsSL https://tailscale.com/install.sh | sh

Authenticate and accept routes

sudo tailscale up --accept-routes

Now Open the printed login URL, authenticate with the same account.

tailscale status

You should see pi and any other tailnet devices listed.

Test reachability through the Pi's subnet routes

ping 192.168.10.1        # Pi's VLAN 10 gateway
ping 192.168.20.113      # linux-target01
ping 192.168.50.11       # Wazuh
None

Remote Power Control for a Home SOC Lab: Wake-on-LAN Over Tailscale

I don't want to run my lab 24/7 . So i wan't to trun on/off from anywhere This isn't limited to just when I'm sitting at the switch. So let us set up remote power on/off for both my Dell laptop and Proxmox Tiny PC using only tools from Kali and Tailscale.

Wake-on-LAN (WoL) magic packets are Layer 2 broadcasts, and Tailscale only carries Layer 3 traffic, So when we send packet from kali to target it will never reach it . We need a device that sit on the same vlan as the targets . It can only done by Pi(router) bcz it will run 24/7 and it has leg on both VLan 20 and 30. Shutting down is simpler. It's ordinary SSH over the tunnel.

None

Step 1 : Configure the Dell Lap & Pc BIOS / UEFI

  • Restart your Dell PC or laptop and tap the F2 key repeatedly when the Dell logo appears to enter the BIOS.
  • BIOS Menu → Power Management → Locate Wake on LAN (WoL) → Turn it on .
  • Disable Deep Sleep if present in Power Management
  • Click Apply / Save and exit from BIOS

Step 2 : Set the OS to listen for magic packets(Tiny PC)

  • Install ethtool on proxmox VM by running
apt install ethtool
  • Find your network interface name by running
ip a
  • Enable WoL by running
sudo ethtool -s eth0 wol g
  • This setting lives in the network card, and it resets on every reboot, so you need to make it permanent by adding it in /etc/network/interfaces
nano /etc/network/interfaces

now add "post-up /sbin/ethtool -s nic0 wol g" inside the iface vmbr0 inet static block .

  • We should know the MAC address to wake up the Machine using Magick packet.
ip link show nic0

Step 3: Set the OS to listen for magic packets(Laptop)

  • In windows Device Manager → Network adapters → Intel Ethernet → Properties in it navigate to Advanced tab → set Wake on Magic Packet on Enable .
  • Disable Fast Startup Control Panel → Power Options →Choose what the power buttons do →click Change settings that are currently unavailable → untick Turn on fast startup.
  • We should know the MAC address to wake up the Machine using Magick packet. To find it open PowerShell
ipconfig /all
  • Enable OpenSSH Server so you can shut the laptop down remotely Settings → System → Optional features → add OpenSSH Server . Now open PowerShell as Administrator
   Start-Service sshd
   Set-Service -Name sshd -StartupType Automatic
  • We can set VM auto-start which is now available VM Ware 25H2

open VM → File → Now it will list all vm you can select them you need → click ok

None

Step 4 : Setting the Pi.

Install the tool that sends the magic packet in Rpi

sudo apt install etherwake -y

Now make sure Tailscale is up on kali

sudo tailscale up --accept-routes

Then SSH to the Pi through its Tailnet IP.

ssh router@100.1X,XX,XX

Power ON Tiny Pc using Magic Packet

sudo etherwake -i eth0 1x:xx:xx:xx:XX:XX

Power ON Laptop using Magic Packet

sudo etherwake -i eth0.20 5x:xx:xx:XX:XX:XX

Power off — Tiny Pc

Before shuting down the Host (Tiny PC) . We shutdown the Wazuh VM first

ssh -J router@100.x.xx.xx root@192.168.50.10
qm shutdown 100 #shuting down the WAZUH VM
shutdown -h now #shuting down the host(proxmox)

Power off — Dell Laptop

First we need to stop the VM's first so they don't get hard-killed . In admin PowerShell on the laptop, either over SSH or via VMware's GUI

& "C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe" list
& "C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe" stop "<path-to.vmx>" soft

Run 'vmrun stop … soft' for every VM's, then shut down the host.

ssh -J router@<pi-tailscale-ip> <windows-user>@192.168.20.10
shutdown /s /t 0

Lab Scope & Exercise Roadmap

What This Lab Allows Me To Practice

While a home lab is a great learning tool, it does not offer the same scale as an enterprise environment or an actual opponent. I'll be honest and outline what this environment can and cannot help me practice.

What I Can Practice

  1. Reconnaissance & Scanning
  • Network discovery : nmap, netdiscover, ARP scan
  • Service enumeration against AD-DC01, WIN11-WKS01, linux-target01 .
  • Web app recon
  • Vulnerability scanning with OpenVAS/Nessus-style tools

2. Web Application Attacks

  • SQL injection
  • XSS
  • CSRF
  • Broken access control
  • IDOR
  • Authentication bypass
  • Broken session management
  • Command injection
  • File upload vulnerabilities
  • Path traversal
  • API testing with Burp Suite/ZAP

3. Active Directory Attacks

  • Enumeration: BloodHound
  • Kerberoasting
  • AS-REP roasting
  • Password spraying / credential stuffing against domain accounts
  • Pass-the-hash, pass-the-ticket
  • SMB relay / NTLM relay attacks
  • Lateral movement
  • Privilege escalation via misconfigurations

4. Host/Endpoint Exploitation

  • Metasploit to exploit known CVE's that haven't been patched on WIN11-WKS01 or linux-target01
  • Post-exploitation: Mimikatz , persistence techniques (registry run keys, scheduled tasks, services)
  • Privilege escalation on Linux and windows

5. C2 and Tooling Practice

  • Basic C2 configuration
  • Living-off-the-land techniques to see what Sysmon/Wazuh actually catch

6. Blue Team / SOC Side

  • Writing and tuning custom Suricata signatures
  • Building Wazuh detection rules/decoders for Sysmon events
  • Mapping MITRE ATT&CK techniques. Pick a technique, perform it from Kali and ensure that there is a corresponding Wazuh alert. Record what data sources are covered.
  • Incident response : Using alerts to navigate to the wazuh dashboard to view historic events on that host and build the attack timeline.
  • Threat hunting
  • Using pro-active queries within Wazuh/Suricata to search for IOC.
  • SIEM dashboard/visualization building in Wazuh for specific attack categories

7. Network-Layer Exercises

  • MITM practice
  • SPAN/mirror-based packet capture analysis in Wireshar

What I Can't do in this lab

  • No internet-facing attack surface
  • No enterprise-scale AD
  • No real EDR/antivirus product in play.
  • Cloud security testing (AWS/Azure/GCP misconfig, IAM abuse)
  • Mobile app pentesting

What's Next ?

This page shows what I want to do. The next few posts will go through each item on the list above, using Kali to attack and seeing what Suricata and Wazuh detect (or fail to detect). Then I can tune my detection rules and note any changes.

I'll start with reconnaissance and the web app attacks such as Juice Shop and DVWA. These are the most lenient to help me learn. Once I feel confident with reading the Blue Team side of things I'll move on to Active Directory attacks. Each post will also update the status on this page.

If you're building something similar, the next posts are where the real lessons will show up — not in what I planned to do, but in what broke, what got caught, and what didn't.