[{"content":"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.\nLegacy systems, forgotten infrastructure, rushed deployments, and weak operational practices can all create exploitable attack surfaces inside production environments.\nIn 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.\n⚠️ Disclaimer: Every configuration change in this section is strictly for the homelab. None of this should be applied to a production environment.\nBefore starting, ensure all VMs are up and Wazuh has been fully configured with agents deployed to the relevant machines.\nWhat We\u0026rsquo;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.\n1. 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.\nCommands run on project-x-corp-server:\n1 2 3 sudo apt update \u0026amp;\u0026amp; sudo apt install openssh-server -y sudo systemctl start ssh \u0026amp;\u0026amp; sudo systemctl enable ssh sudo ufw allow 22 \u0026amp;\u0026amp; sudo ufw enable In /etc/ssh/sshd_config, we make two key changes:\nPasswordAuthentication yes PermitRootLogin yes Then set root\u0026rsquo;s password and restart SSH:\n1 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.\n2. 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.\n1 2 3 sudo apt update \u0026amp;\u0026amp; sudo apt install openssh-server -y sudo systemctl start ssh \u0026amp;\u0026amp; sudo systemctl enable ssh sudo ufw allow 22 Enable password authentication in /etc/ssh/sshd_config and restart SSH as above. Also set root\u0026rsquo;s password to november.\n🔍 Detection Note (Wazuh Rule ID: 5760): Wazuh has a built-in rule that fires on sshd: authentication failed events. View it under Server Management -\u0026gt; Rules -\u0026gt; 5760.\nCreating a Wazuh Alert for Failed SSH:\nIn Explore -\u0026gt; Alerting -\u0026gt; Monitors, create a new monitor with the following:\nTitle: 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 \u0026gt; 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:\n1 2 cd /home/mailhog sudo docker compose up -d On project-x-linux-client, start the email poller in the background:\n1 cd /home \u0026amp;\u0026amp; ./email_poller.sh \u0026amp; 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.\n🔍 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.\n4. Enable WinRM on project-x-win-client Windows Remote Management (WinRM) is a legitimate administration protocol, but it\u0026rsquo;s a commonly abused attack path for lateral movement. We enable it on the Windows client to expose this surface.\nOpen an Administrator PowerShell session on project-x-win-client and run:\n1 2 3 4 5 6 powershell -ep bypass Enable-PSRemoting -force winrm quickconfig -transport:https Set-Item wsman:\\localhost\\client\\trustedhosts * net localgroup \u0026#34;Remote Management Users\u0026#34; /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).\nCreating a Wazuh Alert for WinRM Logon:\nCreate a monitor titled \u0026ldquo;WinRM Logon\u0026rdquo; with:\nData filters: data.win.eventdata.logonProcessName = Kerberos and data.win.system.eventID = 4624 Trigger condition: count \u0026gt; 1, Severity: Medium (3) 5. Enable RDP on project-x-dc (Domain Controller) Navigate to Settings -\u0026gt; System -\u0026gt; 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.\n🔍 Detection Note (Wazuh Rule ID: 92653): Successful RDP logins generate Event ID 4624 with logonProcessName: User32. Search for it in Wazuh under Explore -\u0026gt; Discover using data.win.eventdata.logonProcessName: User32.\n6. Create a Sensitive File on project-x-dc This simulates the crown jewels of our fictional company. On the domain controller, create:\nPath: C:\\Users\\Administrator\\Documents\\ProductionFiles\\secrets.txt Content: anything representing sensitive data (the lab uses DEEBOODAH) Configure Wazuh File Integrity Monitoring (FIM):\nIn Wazuh, go to Server Management -\u0026gt; Endpoint Groups -\u0026gt; Windows -\u0026gt; Files -\u0026gt; agent.conf and add:\n1 2 3 4 5 6 \u0026lt;syscheck\u0026gt; \u0026lt;directories check_all=\u0026#34;yes\u0026#34; report_changes=\u0026#34;yes\u0026#34; realtime=\u0026#34;yes\u0026#34;\u0026gt; C:\\Users\\Administrator\\Documents\\ProductionFiles \u0026lt;/directories\u0026gt; \u0026lt;frequency\u0026gt;60\u0026lt;/frequency\u0026gt; \u0026lt;/syscheck\u0026gt; Creating a Custom FIM Alert:\nIn Server Management -\u0026gt; Rules -\u0026gt; local_rules.xml, add:\n1 2 3 4 5 6 7 \u0026lt;group name=\u0026#34;syscheck\u0026#34;\u0026gt; \u0026lt;rule id=\u0026#34;100002\u0026#34; level=\u0026#34;10\u0026#34;\u0026gt; \u0026lt;field name=\u0026#34;file\u0026#34;\u0026gt;secrets.txt\u0026lt;/field\u0026gt; \u0026lt;match\u0026gt;modified\u0026lt;/match\u0026gt; \u0026lt;description\u0026gt;File integrity monitoring alert - access to secrets.txt file detected\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;/group\u0026gt; Then create a Wazuh monitor titled \u0026ldquo;File Accessed\u0026rdquo; with:\nData filters: syscheck.event = modified and full_log contains secrets.txt Trigger condition: count \u0026gt; 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:\n1 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:\nComputer Configuration -\u0026gt; Administrative Templates -\u0026gt; Network -\u0026gt; Lanman Workstation -\u0026gt; Enable insecure guest logons (set to Enabled)\nThen run in PowerShell:\n1 Set-ItemProperty -Path \u0026#34;HKLM:\\SYSTEM\\CurrentControlSet\\Services\\LanmanWorkstation\\Parameters\u0026#34; -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.\n","date":"2026-05-13T00:00:00Z","permalink":"/p/part-2-configuring-a-vulnerable-environment/","title":"Part 2 - Configuring a Vulnerable Environment"},{"content":"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.\nI 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.\nThink of it as a self-contained training ground for practising both attack and defence in a realistic but isolated environment.\nLab Architecture The entire environment runs on Oracle VirtualBox using a private NAT network: 10.0.0.0/24.\nThis setup keeps the lab isolated from the host machine, allows safe execution of offensive tooling, and still permits controlled outbound internet access for updates.\nThe architecture includes:\nActive 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.\nSuggested 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.\nHostname 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 \u0026amp; 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.\nSuggested 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.\nActive Directory The domain controller is hosted on project-x-dc and runs Windows Server 2025. It provides:\nActive 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.\nSuggested 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.\nThis allows Linux systems to authenticate using domain credentials and helps simulate a realistic environment where Windows and Linux machines coexist.\nUseful validation commands include:\n1 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 \u0026lt;domain-user\u0026gt; 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.\nMailHog replaces the need for a real external email provider. This means email-based attack simulations can remain fully contained inside the lab.\nMailHog 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.\nOn 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.\nSuggested 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.\nFigure 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.\nWazuh 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.\nThe three core components are:\nWazuh 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.\nSuggested 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\u0026amp;CK mapping page Vulnerability detection results Security Onion Security Onion runs on project-x-sec-work and complements Wazuh by providing network-level visibility.\nWhile Wazuh focuses on host-based monitoring, Security Onion handles:\nNetwork 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.\nSuggested 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.\nTool 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.\nSuggested 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.\nImportant: Do not use these credentials outside the lab. They are intentionally weak and should never be reused in real systems.\nAccount 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.\nIn 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.\n","date":"2026-05-12T00:00:00Z","permalink":"/p/part-1-homelab-setup-building-a-business-in-a-box/","title":"Part 1 - Homelab Setup: Building a Business-in-a-Box"}]