Delay No More

Part 2 - Configuring a Vulnerable Environment

Wed, 13 May 2026 00:00:00 +0000

With the lab fully built, the next step is to deliberately introduce insecure configurations - the kind of misconfigurations and legacy settings that still appear in real enterprise networks more often than expected.

Legacy systems, forgotten infrastructure, rushed deployments, and weak operational practices can all create exploitable attack surfaces inside production environments.

In this part of the series, the goal is to intentionally weaken selected systems inside the Business-in-a-Box homelab while simultaneously configuring Wazuh to monitor and detect the resulting attack activity.

⚠️ Disclaimer: Every configuration change in this section is strictly for the homelab. None of this should be applied to a production environment.

Before starting, ensure all VMs are up and Wazuh has been fully configured with agents deployed to the relevant machines.

What We’re Doing (and Why)

Each misconfiguration below is paired with a detection note explaining how Wazuh catches the resulting activity. This is the blue team layer sitting alongside the red team setup.

1. Enable SSH on project-x-corp-server

We open SSH on the corporate server and deliberately weaken its configuration by enabling password authentication and permitting root login — two settings that are disabled by default for good reason.

Commands run on project-x-corp-server:

1
2
3


sudo apt update && sudo apt install openssh-server -y
sudo systemctl start ssh && sudo systemctl enable ssh
sudo ufw allow 22 && sudo ufw enable

In /etc/ssh/sshd_config, we make two key changes:

PasswordAuthentication yes
PermitRootLogin yes

Then set root’s password and restart SSH:

1
2


sudo passwd root # set to: november
sudo systemctl restart ssh

🔍 Detection Note: project-x-corp-server does not have a Wazuh agent installed. This is intentional — it demonstrates the detection gap that exists when a machine has no endpoint monitoring. An attacker could brute-force this box and no SIEM alert would fire.

2. Enable SSH on project-x-linux-client

The same process is applied to the Linux client machine, with one key difference — this machine does have a Wazuh agent, so failed SSH attempts will be caught.

1
2
3


sudo apt update && sudo apt install openssh-server -y
sudo systemctl start ssh && sudo systemctl enable ssh
sudo ufw allow 22

Enable password authentication in /etc/ssh/sshd_config and restart SSH as above. Also set root’s password to november.

🔍 Detection Note (Wazuh Rule ID: 5760): Wazuh has a built-in rule that fires on sshd: authentication failed events. View it under Server Management -> Rules -> 5760.

Creating a Wazuh Alert for Failed SSH:

In Explore -> Alerting -> Monitors, create a new monitor with the following:

Title: 3 Failed SSH Attempts
Data source index: wazuh-alerts-4.x-*, Time field: @timestamp
Data filters: process.name = sshd and rule.groups = authentication_failed
Trigger condition: count > 2, Severity: Medium (3)

3. Configure the MailHog SMTP Email Connection

MailHog should already be running from the setup phase. Confirm the container is active on project-x-corp-server:

1
2


cd /home/mailhog
sudo docker compose up -d

On project-x-linux-client, start the email poller in the background:

1

cd /home && ./email_poller.sh &

This script polls the MailHog API every 30 seconds and simulates a user checking their inbox — a critical piece for the phishing simulation in Part 3.

🔍 Detection Note: Since project-x-corp-server has no Wazuh agent, email activity originating from it creates a monitoring blind spot — intentionally mirroring real-world scenarios where email infrastructure goes unmonitored.

4. Enable WinRM on project-x-win-client

Windows Remote Management (WinRM) is a legitimate administration protocol, but it’s a commonly abused attack path for lateral movement. We enable it on the Windows client to expose this surface.

Open an Administrator PowerShell session on project-x-win-client and run:

1
2
3
4
5
6


powershell -ep bypass
Enable-PSRemoting -force
winrm quickconfig -transport:https
Set-Item wsman:\localhost\client\trustedhosts *
net localgroup "Remote Management Users" /add administrator
Restart-Service WinRM

🔍 Detection Note (Wazuh Rule ID: 60106): WinRM connections use Kerberos authentication, which generates Windows Event ID 4624 with logonProcessName: Kerberos. Wazuh catches this under rule 60106 (Windows Logon Success).

Creating a Wazuh Alert for WinRM Logon:

Create a monitor titled “WinRM Logon” with:

Data filters: data.win.eventdata.logonProcessName = Kerberos and data.win.system.eventID = 4624
Trigger condition: count > 1, Severity: Medium (3)

5. Enable RDP on project-x-dc (Domain Controller)

Navigate to Settings -> System -> Remote Desktop on the domain controller and toggle it On. This exposes RDP (port 3389) on the DC — the highest-value machine in the network.

🔍 Detection Note (Wazuh Rule ID: 92653): Successful RDP logins generate Event ID 4624 with logonProcessName: User32. Search for it in Wazuh under Explore -> Discover using data.win.eventdata.logonProcessName: User32.

6. Create a Sensitive File on project-x-dc

This simulates the crown jewels of our fictional company. On the domain controller, create:

Path: C:\Users\Administrator\Documents\ProductionFiles\secrets.txt
Content: anything representing sensitive data (the lab uses DEEBOODAH)

Configure Wazuh File Integrity Monitoring (FIM):

In Wazuh, go to Server Management -> Endpoint Groups -> Windows -> Files -> agent.conf and add:

1
2
3
4
5
6


<syscheck>
 <directories check_all="yes" report_changes="yes" realtime="yes">
 C:\Users\Administrator\Documents\ProductionFiles
 </directories>
 <frequency>60</frequency>
</syscheck>

block added at the bottom of the file, monitoring the ProductionFiles path." class="gallery-image" data-flex-basis="741px" data-flex-grow="309" height="362" loading="lazy" sizes="(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px" src="https://lck920.github.io/p/part-2-configuring-a-vulnerable-environment/screenshot9.png" srcset="https://lck920.github.io/p/part-2-configuring-a-vulnerable-environment/screenshot9_hu_c83696022f3341ef.png 800w, https://lck920.github.io/p/part-2-configuring-a-vulnerable-environment/screenshot9.png 1119w" width="1119">

File Integrity Monitoring -> Inventory tab with project-x-dc selected, showing the secrets.txt file path appearing in the monitored file list." class="gallery-image" data-flex-basis="548px" data-flex-grow="228" height="803" loading="lazy" sizes="(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px" src="https://lck920.github.io/p/part-2-configuring-a-vulnerable-environment/screenshot10.png" srcset="https://lck920.github.io/p/part-2-configuring-a-vulnerable-environment/screenshot10_hu_a2a7e52d5c352ea4.png 800w, https://lck920.github.io/p/part-2-configuring-a-vulnerable-environment/screenshot10_hu_14d881b955e79712.png 1600w, https://lck920.github.io/p/part-2-configuring-a-vulnerable-environment/screenshot10.png 1834w" width="1834">

Creating a Custom FIM Alert:

In Server Management -> Rules -> local_rules.xml, add:

1
2
3
4
5
6
7


<group name="syscheck">
 <rule id="100002" level="10">
 <field name="file">secrets.txt</field>
 <match>modified</match>
 <description>File integrity monitoring alert - access to secrets.txt file detected</description>
 </rule>
</group>

Then create a Wazuh monitor titled “File Accessed” with:

Data filters: syscheck.event = modified and full_log contains secrets.txt
Trigger condition: count > 1, Severity: High (2)

7. Prepare the Exfiltration Target on project-x-attacker

Enable SSH on the Kali machine and create a placeholder file for the incoming exfiltrated data:

1
2


sudo systemctl start ssh.service
touch /home/attacker/my_exfil.txt

On project-x-win-client, open gpedit.msc (navigate to C:\Windows\System32\gpedit.msc, right-click, Run as Administrator), then enable:

Computer Configuration -> Administrative Templates -> Network -> Lanman Workstation -> Enable insecure guest logons (set to Enabled)

Then run in PowerShell:

1

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name AllowInsecureGuestAuth -Value 1 -Force

The lab is now intentionally vulnerable and monitored. In Part 3, we run the actual attack — following the full cyber attack lifecycle from reconnaissance all the way to persistence.

Part 1 - Homelab Setup: Building a Business-in-a-Box

Tue, 12 May 2026 00:00:00 +0000

Instead of spinning up a collection of random virtual machines and calling it a homelab, I wanted to build something more meaningful - a small enterprise-like environment that resembles how a real corporate network is structured.

I call this the Business-in-a-Box homelab, inspired by the Project Security E101 course. The goal is to simulate a corporate domain network called Project X, complete with internal services, security monitoring, and an attacker node for running controlled offensive exercises.

Think of it as a self-contained training ground for practising both attack and defence in a realistic but isolated environment.

Lab Architecture

The entire environment runs on Oracle VirtualBox using a private NAT network: 10.0.0.0/24.

This setup keeps the lab isolated from the host machine, allows safe execution of offensive tooling, and still permits controlled outbound internet access for updates.

The architecture includes:

Active Directory infrastructure
Enterprise workstations
Security monitoring platforms
Internal email services
Offensive security systems

Figure 1 - Overall Homelab Architecture

Figure 1 shows the overall structure of the Business-in-a-Box homelab, including the domain controller, enterprise workstations, email server, security server, and monitoring components.

Suggested screenshots to include

VirtualBox VM list showing all homelab machines
VirtualBox NAT network configuration
IP configuration from Windows using ipconfig
IP configuration from Linux using ip a
Successful ping test between hosts

Virtual Machines

Each VM represents a specific role commonly found in a corporate environment.

Hostname	IP Address	Operating System	Role
project-x-dc	10.0.0.5	Windows Server 2025	Domain Controller (AD/DNS/DHCP)
project-x-corp-server	10.0.0.8	Ubuntu Server 22.04	Jumpbox & Email Server
project-x-sec-box	10.0.0.10	Ubuntu Server 22.04	Wazuh SIEM Server
project-x-win-client	10.0.0.100	Windows 11 Enterprise	Domain Workstation
project-x-linux-client	10.0.0.101	Ubuntu Desktop 22.04	Developer Workstation
project-x-sec-work	10.0.0.103	Security Onion	Network Monitoring Workstation
project-x-attacker	10.0.0.50	Kali Linux 2024.4	Attacker Node

The minimum specifications per VM range from 1 CPU / 2 GB RAM for lighter machines, such as the corporate server and attacker node, up to 2 CPU / 4 GB RAM for heavier systems such as the domain controller, Windows client, and security server.

Suggested screenshots to include

VirtualBox VM settings for one Windows host
VirtualBox VM settings for one Linux host
Hostname configuration screen or terminal output
VM resource allocation page

Core Services

The homelab uses several core services to make the environment behave like a small enterprise network.

Active Directory

The domain controller is hosted on project-x-dc and runs Windows Server 2025. It provides:

Active Directory Domain Services (ADDS)
DNS services
DHCP services
Centralised authentication
Domain policy management

All Windows workstations in the lab are joined to the domain corp.project-x-dc.com. This provides centralised authentication and policy management, similar to what would be found in a real enterprise environment.

Suggested screenshots to include

Windows Server Manager dashboard
Active Directory Users and Computers
DNS Manager showing domain records
DHCP configuration screen
Successful Windows domain join screen
Windows login using a domain account

Linux Domain Integration

To support a mixed operating system environment, the Linux workstation is joined to the Active Directory domain using Samba Winbind.

This allows Linux systems to authenticate using domain credentials and helps simulate a realistic environment where Windows and Linux machines coexist.

Useful validation commands include:

1
2
3


realm list
wbinfo -u
id johnd@corp.project-x-dc.com

Suggested screenshots to include

realm list output
wbinfo -u showing domain users
id <domain-user> output
Winbind service status
Linux login using domain credentials

MailHog Email Infrastructure

The email infrastructure is powered by MailHog, a lightweight tool that acts as a fake SMTP server. It runs inside a Docker container on project-x-corp-svr and is central to the phishing simulations later in this series.

MailHog replaces the need for a real external email provider. This means email-based attack simulations can remain fully contained inside the lab.

MailHog ports

Service	Port	Purpose
SMTP	1025	Captures outgoing emails sent by lab scripts or applications
Web Interface	8025	Allows captured emails, headers, and content to be inspected
REST API	N/A	Enables automated interaction for scripted attack scenarios

Figure 2 - MailHog Email Simulation Workflow

Figure 2 shows how MailHog runs inside Docker on project-x-corp-svr and how the Linux client uses an email poller script to simulate inbox activity.

On the project-x-linux-client side, a dedicated Bash script called email_poller.sh runs in the background and periodically polls the MailHog API to simulate a user checking their inbox. When a new email arrives, the script prints an alert to the terminal.

Suggested screenshots to include

MailHog web inbox
Example captured email
Email headers inside MailHog
docker ps showing the MailHog container
Docker Compose file or MailHog startup command
email_poller.sh running in terminal
MailHog API response

Security Stack

The defensive side of the homelab is built around Wazuh and Security Onion. Wazuh provides host-based monitoring, while Security Onion provides network-level visibility.

Figure 3 - Security Monitoring and Defence Architecture

Figure 3 shows how endpoint activity is collected and forwarded into the security server, where it can be used for threat defence, incident response, and defensive analysis.

Wazuh SIEM

Wazuh is the main defensive tool in this homelab. It runs on project-x-sec-box and uses an agent-based model. Lightweight agents are installed on monitored machines and forward telemetry back to the central Wazuh Server.

The three core components are:

Wazuh Agents - installed on project-x-win-client, project-x-linux-client, and project-x-dc. They monitor host-level activity such as system logs, file changes, and rootkit detection.
Wazuh Server - receives all agent data, decodes logs, and runs them against a ruleset library to flag indicators of compromise.
Wazuh Indexer and Dashboard - stores telemetry data and provides a web interface for visualising alerts and performing forensic investigation.

During attack simulations, Wazuh is used to observe the digital footprint left behind at each stage of the attack lifecycle, from initial access to persistence.

Suggested screenshots to include

Wazuh dashboard homepage
Wazuh agent list showing connected hosts
Security events dashboard
Failed login detection alert
File Integrity Monitoring alert
MITRE ATT&CK mapping page
Vulnerability detection results

Security Onion

Security Onion runs on project-x-sec-work and complements Wazuh by providing network-level visibility.

While Wazuh focuses on host-based monitoring, Security Onion handles:

Network Security Monitoring (NSM)
Packet capture
Traffic analysis
Suricata alerts
Zeek logs
Threat hunting

This provides visibility across the lab network, even in situations where host-based telemetry is limited or unavailable.

Suggested screenshots to include

Security Onion dashboard
Packet capture interface
Suricata alert view
Zeek log search
Traffic analysis view
PCAP investigation screen

Offensive Environment

The attacker machine, project-x-attacker, runs Kali Linux 2024.4 and is loaded with the tools used throughout the attack simulation.

Tool	Purpose
Hydra	Brute-force password attacks
NetExec (`nxc`)	Credential spraying and lateral movement
Evil-WinRM	Remote shell access to Windows systems over WinRM
XFreeRDP	Remote Desktop Protocol access
SecLists	Curated wordlists for credential attacks

These tools are used only inside the isolated homelab network for controlled security testing.

Suggested screenshots to include

Kali Linux desktop or terminal
Hydra brute-force output
NetExec credential spraying output
Evil-WinRM shell access
XFreeRDP session to Windows workstation
Wazuh alert generated from offensive activity

Test Credentials

Weak credentials are intentionally configured throughout the lab to make the attack simulation possible. These credentials are for homelab use only.

Important: Do not use these credentials outside the lab. They are intentionally weak and should never be reused in real systems.

Account	Password	Host
`Administrator`	`@Deeboodah1!`	project-x-dc
`johnd@corp.project-x-dc.com`	`@password123!`	project-x-win-client
`jane@linux-client`	`@password123!`	project-x-linux-client
`sec-user@sec-box`	`@password123!`	project-x-sec-box
`attacker`	`attacker`	project-x-attacker

Conclusion

This completes the foundational setup of the Business-in-a-Box cybersecurity homelab. The environment now includes a domain controller, enterprise workstations, internal email infrastructure, security monitoring platforms, and an attacker node.

In Part 2, I will deliberately misconfigure several services across the lab to create a realistically vulnerable environment and connect those activities into Wazuh for detection.