Building a Mini SOC Lab at Home

THE LAB

#

Today we will be building a minimal SOC lab to practice our network defense, endpoint monitoring, and incident response skills.

We will construct the Lab using Virtual Machines, and since I am on linux I will be using using Qemu as my virtualization software but you can use anything else.

Lab Structure

#

Our lab will have different components (VMs), these are the components that we will be using,

• pfSense (Firewall & Router)

• Suricata IDS (pfSense Add-on)

• Wazuh SIEM (Hosted on Ubuntu)

• Windows Endpoint

• Kali

We will be setting up each of these VMs and configure for their communication.

Configuring Virtual Machines

#

We are going to build and configure each VM step-by-step. Follow along, and you should be fine. If you encounter any problems, you are basically on your own but quick internet search will most likely solve your issues.

pfSense VM (Firewall & Router)

#

I assume you have already downloaded the ISO, but if you haven’t go ahead and download it from here. Now, lets create the VM using Qemu (Virt-Manager).

Creation

#

• Select your pfSense ISO
• Select Generic or unknown OS.
• Set Memory: 2048 MiB and vCPUs: 2
• Storage: 20 GiB
• Click the “Customize configuration before install” checkbox
• Finish

Configuration

#

We need to add a second Network Interface Card (NIC). In the setting tab, click Add Hardware -> Network, here select Isolated Network. It should look similar to this,

Now, click the Begin installation button at top right, and boot the machine.

When prompted, choose Install pfSense. Then follow these steps,

• Select Auto (UFS) for disk partitioning.
• Select Entire Disk
• Select MBR DOS Partitions

If everything is correct your partitioning scheme should look like this,

Select Finish and continue, it will install automatically. After it finishes with installation, reboot the VM.

You should see a screen like this after the reboot, listing your NICs with as WAN (em0) and LAN (em1). We will setup LAN interface for our internal lab network.

Follow these steps:

1. Press 2 -> Set interface IP address
2. Select em1 (LAN).
3. Press n -> Configure IPv4 address LAN interface via DHCP
4. Enter new IPv4 address -> 10.10.10.1 (you can change and use your own IP range)
5. Enter subnet mask -> 24
6. For upstream gateway, leave blank (LAN doesn’t need it)
7. Press n -> Configure IPv6 address LAN interface via DHCP6
8. Press Enter for none, we don’t need IPv6
9. Press y -> Enable DHCP server for LAN (this will give your VMs IPs automatically.)
10. Enter start address -> 10.10.10.2 (you can change this)
11. Enter end address -> 10.10.10.100 (you can change this)
12. Press y -> Do you want to revert to HTTP as the webConfigurator protocol

If everything is correct, it should look like this,

now you can use the web configuration page by visiting, http://10.10.10.1 on a VM attached to Isolated Network.

Wazuh SIEM

#

We will be using Ubuntu to host our Wazuh instance, lets create the Ubuntu VM.

Creation

#

• Select your Ubuntu ISO
• Set Memory: 8192 MiB and vCPUs: 4
• Storage: 40 GiB
• Click the “Customize configuration before install” checkbox
• Finish

Configuration

#

Before the installation, change the NIC -> Network Source to Isolated Network. Then, begin installation. I’ve chosen minimal installation but you can choose whatever you like.

After the installation finishes, you can check the IP address of the VM and confirm that it got this IP address from the pfSense DHCP.

It should look like this,

you will notice that you cannot connect to the internet because the VM’s DNS is not configured yet.

To do this, use NetworkManager:

# Find connection name
nmcli connection show 

# Set DNS
sudo nmcli connection modify "Wired connection 1" \
  ipv4.ignore-auto-dns yes \
  ipv4.dns "8.8.8.8 8.8.4.4"

# Restart connection
sudo nmcli connection down "Wired connection 1"
sudo nmcli connection up "Wired connection 1"

You should see your internet connection and have no issues.

Now, that we have fixed the issue and confirmed that our pfSense supplies IP addresses correctly we can continue with the Wazhuh installation.

Follow these steps:

# 1. Update the system
sudo apt update && sudo apt upgrade -y

# 2. Set hostname (optional)
hostnamectl set-hostname wazuh-manager

# 3. Download the Wazuh Install Script and Run it
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

# 4. Verify Services
sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

After the installation, the script will prompt you to a password which you’ll need it to log into the dashboard. You can login to dashboard by visiting http://localhost.

Our SIEM is ready now, we will be adding an Wazuh agent which will be our Windows endpoint. Wazuh agent will forward Windows logs to our Wazuh Manager.

Windows Endpoint

#

We will be creating the Windows VM now, which will be our Wazuh agent.

Creation

#

• Select your Windows ISO
• Set Memory: 4096 MiB and vCPUs: 4
• Storage: 40 GiB
• Click the “Customize configuration before install” checkbox
• Finish

Configuration

#

Again like we did on the Ubuntu VM, before the installation, change the NIC -> Network Source to Isolated Network. Then, begin installation.

You need to setup DNS inside the VM, you can easily change it using the adapter options.

TIP -> you can change the windows vm name to wazuh-agent.

For our Windows endpoint setup, we are going to install Sysmon for detailed log analysis.

Follow these steps:

1. Install Sysmon
   1. Download Sysmon from Microsoft Sysinternals
   2. Download a basic sysmon configuration file using PowerShell (start as admin)
   3. Install Sysmon with the configuration
   4. Verify installation

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

# Install sysmon with config
.\Sysmon64.exe -accepteula -i C:\sysmonconfig.xml

# Verify installation
sysmon64.exe -c

The output should look like this after the verification,

2. Install Wazuh agent
   1. Download the agent msi file from here
   2. Start PowerShell as admin, and nagivate to your downloads folder
   3. Deploy the Wazuh agent
   4. Start the Wazuh agent service

# Deploy the agent
.\wazuh-agent-4.14.1-1.msi /q WAZUH_MANAGER="10.10.10.2"  # your manager ip

# Start the agent service
Start-Service wazuhsvc

Test the connection from Wazuh dashboard, you should see 1 active agent like this,

Now we need to edit the agent configuration file to also include the logs from Sysmon and PowerShell.

Start PowerShell as admin, and navigate to C:\Program Files (x86)\ossec-agent and edit the ossec.conf file.

cd C:\Program Files (x86)\ossec-agent
notepad ossec.conf

Add these 2 config lines after already existing default ones.

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

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

Restart the agent with Restart-Service wazuhsvc, and check on the Wazuh dashboard and verify that Sysmon, and PowerShell logs are being forwarded.

When you expand the related event you should see provider similar to this,

After you verify that logs are being forwarded as expected, we can continue with the Suricata (IDS) setup.

Suricata (IDS)

#

Remember we have configured pfSense before but never visit the pfSense dashboard. We will configure Suricata using this dashboard.

Since it is our first time using the dashboard, pfSense will launch a setup wizard.

Follow these steps:

1. General Information
   • Hostname: e.g., pfsense-lab
   • Domain: e.g., lab.local
   • DNS servers: you can leave empty (it will use WAN default)
2. Time Zone
   • Select your lab’s timezone
3. WAN Interface
   • Should already be configured for DHCP (your WAN is using NAT to your host network)
   • Leave it as is
4. LAN Interface
   • Should match the LAN IP you set earlier (e.g., 10.10.10.1/24)
   • DHCP should already be enabled with the range you configured
5. Admin Password
   • Set a new password for the admin account
6. Finish
   • pfSense will apply settings and reload the web GUI

Now let’s install the Suricata add-on. Go to System -> Package Manager -> Available Packages, search for Suricata and install it.

Verify that Suricata is installed properly:

Configure Suricata

#

Go to Services -> Suricata, add Interface in this case LAN (em1).

Then, edit LAN interface under Actions tab:

We need to enable EVE json logs to forward logs to Wazuh manager.

Make sure that these 2 options are checked:

• EVE JSON log -> enabled

• EVE Output type -> FILE

Other output settings are optional, enable them according to your needs.

I’ve also enabled ETOpen rule set under Global Settings (this is optional). After this, go to Updates tab, and update rules.

Restart the Suricata service for changes to take effect.

There are 2 main ways to forward logs from pfSense/Suricata to Wazuh manager. Using either rsyslog or the wazuh-agent. I’ve setup rsyslog before but I found it unstable and actually harder to troubleshoot therefore I will be demonstrating the second option.

Install wazuh-agent on pfSense

#

We are going to edit some configuration files to be able to use and install FreeBSD packages. You can edit these files by using the built-in vi editor, but I will be using the pfSense dashboard, Diagnostics -> Edit File option for easiness.

• Load and edit file, /usr/local/etc/pkg/repos/pfSense.conf and save it.

  

• Load and edit file, /usr/local/etc/pkg/repos/FreeBSD.conf, and save it.

  

Now that we enabled FreeBSD packages, we can download the wazuh-agent. You can use the shell from the pfSense by pressing 8 or use the pfSense dashboard again, go to Diagnostics -> Command Prompt.

Use these commands to install:

# Update the package cache
pkg update

# Search the package cache for the official agent
pkg search wazuh-agent

# Install the agent
# Replace x.xx.x with your version number
pkg install wazuh-agent-x.xx.x

Configure and enable the wazuh-agent

#

We need to edit the agent configuration file. Use the pfSense dashboard again to edit the file, /var/ossec/etc/ossec.conf.

Add your Wazuh manager IP address, and make sure that you use the correct protocol. I am using TCP here, but if you are not sure check this from Wazuh manager’s ossec.conf file.

To automatically start Wazuh agent at pfSense boot, follow these commands:

sysrc -f /etc/rc.conf.local wazuh_agent_enable="YES"
ln -s /usr/local/etc/rc.d/wazuh-agent /usr/local/etc/rc.d/wazuh-agent.sh
service wazuh-agent start

After setting up Suricata and the Wazuh agent, we need to add the configuration for Wazuh manager to start analyzing FW and Suricata logs.

You can directly edit the /var/ossec/etc/ossec.conf for pfSense agent or as I will do, you can add a new group on the Wazuh manager and add this config for all of the agents under that group.

Go to Agents Management -> Groups and Add new group. Once you create it, click on the group. You will see that its empty. To add an agent for this group, click Manage agents and add your pfSense agent from the listing.

After you add the agent, go back a step and now edit the group configuration.

Add these inside the <agent_config>, once saved the Wazuh manager will apply the changes for every agent under this group.

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

Should look like this,

We are done with the setup. Now, let’s generate some events and analyze it on the Wazuh dashboard.

Simulating Attacks and Analyzing Events

#

For this section, I will be demonstrating 2 scenarios.

• Compromised Windows Endpoint and running tmNIDS
• Compromised Isolated Network and running nmap scans to Windows endpoint from attacker machine (Kali).

tmNIDS framework

#

We can create false positive events and test functionality using tmNIDS framework. This is an interactive script that simulates the interaction with 3rd party websites, and meant to be run on the endpoint. We can technically run this script on the Wazuh manager (Ubuntu), but we are going to run it on the Windows endpoint.

Run this command in git bash:

curl -sSL https://raw.githubusercontent.com/3CORESec/testmynids.org/master/tmNIDS -o tmNIDS && chmod +x tmNIDS && ./tmNIDS

You will see the interactive mode, here you can run any tests that you want. I ran the External IP Address Lookup. Let’s look at the generated events.

I added the filter data.flow.src_ip for my Windows endpoint IP address:

Checking the events, we can see that events have been generated for the External IP Address Lookup test.

When we expand the event we can observe interesting fields like, data.flow.dest_ip, data.http.hostname, data.http.http_user_agent, rule.description, etc. Event details clearly explain the test that we have run, also we can see the Suricata alert and which rule that the test hit.

Kali

#

Create the Kali VM, you can create it from the ISO or use the pre-built VM. I am using the pre-built one for this guide.

VM Specs:

• Memory: 2048 MiB and vCPUs: 2
• Storage: 80 GiB
• NIC: Isolated network

In this case attacker has compromised the isolated network, and can run nmap port scans across the compromised network. This is a bit tricky to investigate in our events because attacker machine and Windows endpoint are on the same L2 network, so traffic never hits pfSense at all.

Therefore, this SOC lab to actually detect internal port scanning, we need to enable firewall logging on the Windows endpoint.

Do this by following these steps:

1. Open Windows Defender Firewall with Advanced Security.
2. Click Properties
3. For each profile tab (Domain, Private, Public) customize logging
   1. Name: %systemroot%\system32\LogFiles\Firewall\pfirewall.log
   2. Size: 16,384
   3. Log dropped packets: Yes
   4. Log successful connections: Yes

      

   5. Click OK
4. Enable Security Auditing for Firewall
   1. Open Local Security Policy
   2. Go to Advanced Audit Policy Configuration -> System Audit Policies -> Object Access
   3. Enable:
      1. Audit Filtering Platform Connection: Success + Failure
      2. Audit Filtering Platform Packet Drop → Success + Failure

         

      3. Apply and close

As the last step, we need to add this log file to the Wazuh agent configuration file to be ingested by the Wazuh manager.

Open PowerShell as admin, and edit the configuration file with this command:

notepad 'C:\Program Files (x86)\ossec-agent\ossec.conf'

At the end of the other <localfile> tags, add this:

<localfile>
  <location>C:\Windows\System32\LogFiles\Firewall\pfirewall.log</location>
  <log_format>syslog</log_format>
</localfile>

and restart the Wazuh agent service, Restart-Service wazuhsvc.

On Wazuh manager, we need to enable logall and logall_json options in the configuration file, but be aware that this will increase the log size.

Edit /var/ossec/etc/ossec.conf and set both option to yes.

Wazuh manager does not index archives by default, so we need to enable it in the filebeat.yml file.

Edit /etc/filebeat/filebeat.yml and set archives: enabled option to true.

Restart filebeat service, sudo systemctl restart filebeat.

We enabled raw logging and enabled archives in filebeat. We should add the wazuh-archives-* index.

Verify that wazuh-archives exists, go to Index Management -> Indexes, you should see an archive named as wazuh-archive-****.

To add this archive as an index, go to Dashboards Management -> Index patterns. Create index pattern, name it wazuh-archives-* and select the time field as @timestamp. After you create the index, we can now select this newly created index and check events under Explore -> Discover tab.

We can finally start an nmap port scan from kali:

nmap -sS -p- -T4 -Pn 10.10.10.14 # Windows IP

We should be able to see the firewall logs on the Windows endpoint and see which connections are allowed or dropped.

After running the scan, we can see from the events that incoming connection from IP 10.10.10.15 (kali) is DROPPED. We can see the full log line and the rule description.

Additionally, we can create more noise on Windows endpoint by running some tests from Atomic Red Team and see incoming logs from Event Viewer and Sysmon. However, I will not demonstrate since we have already verified logs from these resources are indeed ingested by the Wazuh manager.

Useful Reads

#

• https://documentation.wazuh.com/current/index.html
• https://opennix.org/en/docs/pfsense/pfsense-wazuh-integration/
• https://benheater.com/integrating-pfsense-with-wazuh/