[ProjectX] E101: Vulnerable Environment Setup & Wazuh Monitoring

This homelab project is included in the ProjectX course by Grant Collins.

This is S01 E01 of ProjectX, my homelab series for testing blue team tooling end to end. The goal of this episode: build a small Active Directory environment with deliberate weaknesses, deploy Wazuh on the agent-monitored hosts, and confirm detection coverage across five attacker scenarios. The thesis: what you don't monitor is what attackers exploit.

What You'll Build

Detection Coverage Validated

---

Network Topology & Attack Scenario

VM System

In the course, virtual machines (VMs) are used, but I prefer using Proxmox VE to save resources.

Overall Purpose of the Homelab

• Comparison of detection integration: corp-svr (without EDR) vs. linux-client (with Wazuh agent)
• The blind-spot story is the lesson. Anything happening on the unmonitored host is invisible to a SOC.

Configure a Vulnerability

Open SSH [T1110.001 Brute Force: Password Guessing]

• PasswordAuthentication yes: allows users to log in with a standard password rather than an SSH key.

  • Why insecure: vulnerable to brute-force attacks.

    

• PermitRootLogin yes: allows the root account to log in directly via SSH.

  • Why insecure: attackers only need to guess one password to gain full control of the machine.

    

• Weak password: set the root password to november using sudo passwd root.

Create Detection Alert for SSH in Wazuh

• To create a detection alert, use an SSH authentication failure sample. From the screenshot, you can extract the decoder name and rule groups.

  

• Using the sample, build the detection query.

Enable WinRM on win-client [T1021.006 Remote Services: WinRM]

• What is WinRM: allows administrators to remotely manage Windows systems, similar to how SSH works for Linux.

• Enable WinRM via PowerShell:

    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
  

How to Detect WinRM Activation

• Event ID 4624 with a logonProcessName of Kerberos
• Wazuh Rule ID: 60106
• Description: Windows Logon Success

• From the sample, create a data filter for the alert.

  

Configure SMTP Email Inbox Connection

[project-x-corp-svr] → [project-x-linux-client]

• Docker is used to host and orchestrate MailHog, which acts as the SMTP server for the lab environment.

• The email_poller.sh script runs on the client machine ([project-x-linux-client]) to interact with the MailHog server.

  

• [project-x-corp-svr] is intentionally unmanaged to demonstrate the security 'blind spot' that occurs when monitoring tools are absent. This is the central lesson of the lab.

Enable RDP on [project-x-dc] [T1021.001 Remote Services: RDP]

How to Detect RDP Connection in Wazuh

• Default Wazuh rule for RDP: 92653

  

• Or query: data.win.system.eventID: 4624 AND data.win.eventdata.logonProcessName: User32

  • Successful authentication (Windows Security Event ID): 4624
  • Unsuccessful authentication (Windows Security Event ID): 4625
  • The value User32 in the logonProcessName field indicates the use of the User32.dll library, which handles RDP logins.

Setup "Sensitive File" in [project-x-dc] [T1565 Data Manipulation, T1083 File Discovery]

Create a secrets.txt file under Administrator > Documents > ProductionFiles.

Detect File Modifications in Wazuh

• Under Server management > Endpoint Groups > Windows > agent.conf
• Add the syscheck block to enable file monitoring:

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

• check_all="yes": check multiple file properties including the file's hash (MD5, SHA1, SHA256), permissions, owner, group, and size.
• report_changes="yes": when a text file is modified, Wazuh sends an alert with the diff.

Under File Integration Monitoring > Inventory, you can see all monitored files including secrets.txt.

Create Detection Alert for File Modification

Under the rules tab, find local_rules.xml and add this rule:

<group name="syscheck">
  <rule id="100002" level="10">
    <field name="file">secrets.txt</field>
    <match>modified</match>
    <description>File integrity monitoring alert: modification detected on sensitive file</description>
  </rule>
</group>

• Save and restart the Wazuh manager.
• Under Alerting > Monitors > Create Monitor, configure:

• full_log contains secrets.txt: ensures we look at events specifically related to secrets.txt.
• syscheck.event is modified: when a file change is detected, Wazuh categorizes the type of action that occurred.

Configure the Trigger Condition so the monitor fires on every match.

Exfiltration Setup on Attacker Machine [T1048 Exfiltration Over Alternative Protocol]

scp is the canonical Linux file copy tool over SSH. It uses the same auth as SSH, which means once an attacker has credentials (or a key), exfiltration is one command away.

• Create a destination folder on the attacker host where secrets.txt content will land.
• Wazuh detects this only if the destination is monitored. Outbound SCP from a non-agent host (corp-svr) is invisible at the network edge unless we add a separate firewall or log source. The blind spot strikes again.

Enable Insecure Guest Logons for [project-x-win-client] [T1078 Valid Accounts]

• Under File Explorer > C:\Windows\System32 > gpedit (Run as Administrator) > Computer Configuration > Administrative Templates > Network > Lanman Workstation > "Enable insecure guest logons" > "Enabled".
• Effect: allows the workstation to connect to shared network resources (e.g., an SMB share) using a guest account with zero authentication required.

• Equivalent command-line registry edit (alternative to GPO).

---

What I Asked Myself While Building This

The harder part of analyst work is asking better questions, not running more tools. Building this lab forced me to externalize the questions I'd otherwise glaze past:

• "What am I missing?": when corp-svr got no agent on purpose, the question became: if I were an analyst on a real SOC and this host went silent for a week, would I notice? Probably not. The lab's whole point is to make that gap visceral.

• "Why this rule, and not five others?": Wazuh ships with thousands of default rules. Picking 92653 for RDP and writing custom 100002 for FIM forced a justification: this rule fires on the actual attacker action, not on incidental noise around it.

• "What happened before this?": when the SSH brute-force alert fires, the alert itself is uninteresting. What's interesting is the host's auth log 30 minutes earlier (recon? credential spraying from a different IP?). The lab teaches you to look at the alert AND the context window around it.

• "Why now? Why this host?": corp-svr runs MailHog. Why is it the host without an agent? Because in a real org, "the SMTP test box" or "the legacy server nobody owns" is exactly the kind of host that gets skipped during agent rollout. This lab is a small version of that organizational pattern.

What This Episode Validated

• Wazuh agent-side telemetry catches: SSH auth failures, WinRM activation, RDP logins, FIM events on monitored hosts.
• Custom rules + alerts work end to end: syscheck > local_rules.xml > Monitor > Trigger. The chain holds.
• The agent-LESS host (corp-svr) is the blind spot. Anything happening on it goes unobserved by the SOC. Outbound SCP from this host disappears once it leaves the box. That is the lesson.
• Compromised vs. monitored is the wrong framing. The right framing is monitored vs. unmonitored. An unmonitored host doesn't care whether it's compromised because we wouldn't know either way.

What's Next

E02 picks up where this leaves off. We simulate the actual attack chain across these hosts, watch what the Wazuh dashboard surfaces, and identify what slips through. The blind spot becomes the entry point.