Overview

Requirements

• Disk space: 110 GB
• RAM: 8 GB
• Bandwidth: Oodles
• Time: 3 hours
• Additional Software:
  • Magnet DumpIt for Windows
  • XAMPP
  • Damn Vulnerable Web App
  • the Non-Sucking Service Manager (for Snort as a Service)

Recommended for Windows: 7zip, Wireshark and Notepad++.

I used WinMerge for diff tables.

1. Setup Virtual Machines and Operating Systems

Hardware, operating system, network interface and time protocol for each VM.

1.1. Ubuntu Desktop (SIEM) Setup

Download ubuntu-22.04.5-desktop-amd64.iso from https://www.releases.ubuntu.com/22.04/.

Create VM

Run VMWare New Virtual Machine Wizard and choose:

• “I will install the operating system later”
• Guest Operating System: Linux / Ubuntu
• 2 single-core processors
• 4 GB RAM
• Network type: NAT
• 50 GB Disk
• Add Network Adapter 2 and assign to Custom VMnet
• Connect the VM CD drive to the ISO

Install Ubuntu Linux

Boot the VM and choose:

• Try or Install Ubuntu
• Install Ubuntu
• Normal installation Minimal installation
• Timezone: Eastern Standard Time (UTC-04:00)
• Username: cir-siem
• Password: password

When prompted to remove installation media, disconnect the CD Drive and reboot the machine again:

Install security updates when prompted.

Configure Ubuntu Linux

To set a static IP address ^[1], open a Terminal and enter:

sudo su

apt install net-tools

ifconfig #Note the second interface name

ls /etc/netplan #Note the file name

# Edit /etc/netplan/01-network-manager-all.yaml to add the following lines:

echo -e "  ethernets:\n    ens34:\n      dhcp4: no\n      addresses: [10.10.1.10/24]" >> /etc/netplan/01-network-manager-all.yaml

netplan apply

# To setup NTP server:

apt install ntp -y

echo “server 10.10.1.10” >> /etc/ntp.conf

systemctl restart ntp

# Verify the NTP server is listed:

ntpq -p

1.2. Windows Server Setup

Download Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO from https://www.microsoft.com/en-us/evalcenter/download-windows-server-2016.

Create VM

Run VMWare New Virtual Machine Wizard and choose:

• “I will install the operating system later”
• Guest Operating System: Microsoft Windows / Windows Server 2016
• 2 single-core processors
• 2 GB RAM
• Network type: NAT
• 40 GB Disk
• Add Network Adapter 2 and assign to Custom VMnet
• Connect the VM CD drive to the ISO

Install Windows Server

Boot the VM, install windows and choose:

• Windows Server 2016 Datacenter Evaluation (Desktop Experience)
• Custom: Install Windows Only (advanced)
• Username: Administrator
• Password: Pa$$w0rd

Log in to the Windows desktop and then disconnect the ISO from the VM CD drive. Allow PC to be discoverable when prompted.

Configure Windows Server

To set the IPv4 method ^[2], firewall rules ^[3] and NTP ^[4] for the SIEM subnet, open PowerShell and run:

ipconfig

Get-NetAdapter #Note the ifIndex number

New-NetIPAddress -InterfaceIndex 2 -IPAddress 10.10.1.20 -PrefixLength 24

# Create firewall rules for inbound and outbound connections on SIEM subnet:

New-NetFirewallRule -DisplayName “SIEM In” -Direction Inbound -Action Allow -RemoteAddress 10.10.1.0/24 -Enabled True

New-NetFirewallRule -DisplayName “SIEM Out” -Direction Outbound -Action Allow -RemoteAddress 10.10.1.0/24 -Enabled True

# Configure NTP to use Ubuntu SIEM as server:

w32tm /config /syncfromflags:manual /manualpeerlist:”10.10.1.10” /reliable:YES /update

Restart-Service w32time

Set-TimeZone -Name “Eastern Standard Time”

# Verify the NTP source is 10.10.1.10:

w32tm /query /status

1.3. Kali Attack Box Setup

Download kali-linux-2025.2-installer-amd64.iso from https://www.kali.org/get-kali/#kali-installer-images.

Create VM

Run VMWare New Virtual Machine Wizard and choose:

• “I will install the operating system later”
• Guest Operating System: Linux / Other Linux 6.x kernel 64-bit
• 2 single-core processors
• 2 GB RAM
• Network type: NAT
• 20 GB Disk
• Add Network Adapter 2 and assign to Custom VMnet
• Connect the VM CD drive to the ISO

Install Kali Linux

Boot the VM and choose:

• Graphical Install
• Timezone: Eastern Standard Time (UTC-04:00)
• Username: kali
• Password: kali
• Primary drive: /dev/sda

When prompted to remove installation media after rebooting, disconnect the CD Drive and reboot the machine again.

Configure Kali Linux

Open a Terminal,

# Configure network interfaces:

sudo su

ip addr show #Note the interface names

# Edit /etc/network/interfaces to add these lines:

echo -e "\nauto eth0\niface eth0 inet dhcp\n\nauto eth1\niface eth1 inet static\n\taddress 10.10.1.30\n\tnetmask 255.255.255.0\n" >> /etc/network/interfaces

systemctl restart networking

# Configure NTP to use Ubuntu-SIEM as server in /etc/systemd/timesyncd.conf:

sed -i 's/#NTP=/NTP=10.10.1.10/g' /etc/systemd/timesyncd.conf

# Verify the NTP server is 10.10.1.10:

timedatectl timesync-status

After installing Kali, disconnect the NAT interface to prevent accidentally attacking the wrong network. Verify that all VMs now have synchronized time and can ping each other.

2. Setup Applications

Installing, configuring and testing apps.

2.1. FTP with IIS on Windows Server

On Windows Server, run PowerShell to install and configure FTP ^[5].

Run inetmgr to verify (or make) these changes. Ensure that FTP to 10.10.1.20 as Administrator / Pa$$w0rd works from Kali and Ubuntu:

Default location for IIS logs:

• C:\inetpub\logs\LogFiles\

2.2. Vulnerable Web App with XAMPP

On Windows Server, download and run xampp-windows-x64-8.2.12-0-VS16-installer.exe from https://www.apachefriends.org/download.html. After installing, run the XAMPP Control Panel at C:\xampp\xampp-control.exe and start Apache, MySQL.

Default locations for XAMPP logs:

• C:\xampp\mysql\data\mysql_error.log
• C:\xampp\apache\logs\
• C:\xampp\php\logs\

Download/clone DVWA-master from https://github.com/digininja/DVWA ^[6]. Extract to C:\xampp\htdocs and rename folder to dvwa. Rename C:\xampp\htdocs\dvwa\config\config.inc.php.dist to config.inc.php and edit to set db username and password to root / ’’ :

Browse to http://localhost/phpmyadmin/ and create a new database called dvwa.

Browse to http://localhost/dvwa/setup.php and click Create/Reset Database at the page bottom. Log in to DVWA with admin / password, find DVWA Security in the nav panel and set the security level to Low. This is important for simple web app attacks.

Now http://10.10.1.20/dvwa/ can be visited (and attacked) from Kali.

2.3. Wazuh SIEM on Ubuntu Desktop

On Ubuntu SIEM, open a Terminal and install Wazuh ^[7] :

sudo su

apt install curl

curl -sO https://packages.wazuh.com/4.12/wazuh-install.sh && bash ./wazuh-install.sh -a

# When the installation finishes, note the admin credentials:

# Disable automatic updates for Wazuh (to prevent anything from breaking):

sed -i "s/^deb /#deb /" /etc/apt/sources.list.d/wazuh.list

apt update

# Check the status of Wazuh processes:

systemctl status wazuh-indexer

systemctl status wazuh-dashboard

Browse to https://10.10.1.10 and log in to the Wazuh Web Interface.

2.4. Wazuh Agent on Ubuntu and Windows

On Ubuntu SIEM, browse to https://10.10.1.10 and log in with Wazuh credentials. From the Wazuh overview, click “Deploy new agent”:

Enter the IP of Ubuntu SIEM and copy the command it provides…

On Windows Server,

On Ubuntu SIEM, in the Wazuh Web Interface, optionally create a new group and add the agent ^[8], then edit the group configuration:

Add this code to agent.conf ^{[9][10][11][12][13]} :

<!-- Reduce alert flooding from the agent: -->
<client_buffer>
  <disabled>no</disabled>
  <queue_size>100</queue_size>
  <events_per_second>10</events_per_second>
</client_buffer>

<!-- File Integrity Monitoring for XAMPP and select registries: -->
<syscheck>
  <frequency>300</frequency>
  <directories realtime=”yes”>C:\xampp\htdocs\dvwa</directories>
  <ignore>C:\xampp\htdocs\dvwa\database</ignore>
  <windows_registry report_changes=”yes”>HKEY_LOCAL_MACHINE\SYSTEM\Setup</windows_registry>
  <windows_registry report_changes=”yes”>HKEY_USERS\*</windows_registry>
  <registry_ignore>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services</registry_ignore>
</syscheck>

<!-- Collect Snort IDS alerts: -->
<localfile>
  <frequency>30</frequency>
  <log_format>snort-fast</log_format>
  <location>C:\Snort\log\alert.ids</location>
</localfile>

<!-- Apache and MySQL logs: -->
<localfile>
  <frequency>30</frequency>
  <location>C:\xampp\apache\logs\*.log</location>
  <log_format>apache</log_format>
</localfile>
<localfile>
  <frequency>30</frequency>
  <location>C:\xampp\mysql\data\mysql_error.log</location>
  <log_format>mysql_log</log_format>
</localfile>

<!-- IIS logs: -->
<localfile>
  <frequency>30</frequency>
  <location>C:\inetpub\logs\LogFiles\FTPSVC2\*.log</location>
  <log_format>iis</log_format>
</localfile>
<localfile>
  <frequency>30</frequency>
  <location>C:\inetpub\logs\LogFiles\W3SVC1\*.log</location>
  <log_format>iis</log_format>
</localfile>

Optionally, add <only-future-events>no</only-future-events> inside any <localfile> tags to always scan old logs. Thus, it will be unnecessary to generate new events for debugging. When the corresponding alerts appear in the SIEM, return here and set to yes.

On Ubuntu SIEM, configure a higher severity rule to stand out on the main dashboard, based on repeated failed logons. In the Wazuh Web Interface, find Server management > Rules in the left nav panel. Type local_rules into the search and click on the filename:

Add this code inside the tags ^[14][15] :

<rule id="100300" level="12" frequency="10" timeframe="60" ignore="300">
  <if_matched_sid>60122</if_matched_sid>
  <description>10 logon failures (rule 60122) within 60 seconds</description>
  <group>authentication_failed,brute_force_delay</group>
</rule>

By default, Wazuh-Manager monitors the operating system it is running on and will have already generated some alerts under agent.name:cirsiem-virtual-machine. Disable these scanners (and enable json log retention on line 11) with the following edit to /var/ossec/etc/ossec.conf:

Apply the configuration:

systemctl restart wazuh-manager

On Windows Server, the Wazuh Agent seems to restart automagically, but it can be done with PowerShell to pull the new configuration manually:

Restart-Service -Name wazuh

Jump to testing3.1. Wazuh Config and verify this all works.

2.5. Snort NIDS on Windows Server

Download and run npcap-1.83.exe from https://npcap.com. Snort may require Visual C++ Redistributables to run. Anyways I did install them ^[18]. Download and run Snort_2_9_20_Installer.x64.exe from https://snort.org/downloads. Download and extract snortrules-snapshot-29200.tar.gz with a free account. Unzip to C:\Snort, overwrite everything when prompted ^[17].

Before configuring, jump to testing 3.2. Snort in Sniffer Mode.

2.5.1. Configure Snort

Create folder C:\Snort\lib\snort_dynamicrules and copy files from C:\Snort\so_rules\precompiled\FC-36\x86-64\2.9.20.0. Modify C:\Snort\etc\snort.conf to run in Windows ^[19], as below:

XSS code is typically injected in HTTP POST data and so won’t appear in the Apache access logs. Fortunately, the web-attacks.rules file in Snort’s snapshot archive is empty, so I got to write one!

On Windows Server, Capture an XSS attack with Wireshark to characterize the packets:

I just want to match the HTTP POST method (byte 66-69) and </script in the content. So, rules to add in C:\Snort\rules\local.rules could be ^[20][21][26] :

Jump to testing 3.3. Snort in IDS mode.

2.5.2. Snort as a Service

Snort doesn’t signal to the Windows Service Control Manager when it starts successfully and so is eventually terminated, although it functions fine. A common solution is to use Non-Sucking Service Manager (NSSM). Download NSSM from https://nssm.cc/download, extract contents to C:\Program Files\, and run in PowerShell:

cd ‘C:\Program Files\nssm-2.24\win64’

./nssm.exe install Snort

The NSSM GUI will appear, populate the fields:

Make sure Startup Type is set to Automatic. Verify the service details by running services.msc and inspecting “Snort”. Restart the Windows operating system and verify that Wazuh is still getting IDS alerts. Notice that Wazuh noticed that:

2.6. Volatility on Ubuntu

On Ubuntu SIEM,

Jump to testing 3.4. Volatility Memory Analysis.

3. Testing

3.1. Wazuh Config

The Wazuh discover tab should be populating with events, otherwise the SIEM is borken:

Some of the alert categories generated by the Windows agent, in wazuh-alerts-* index:

Absence of these alerts indicates a problem in agent.conf or with the Wazuh Agent.

Query the Discover tab with these group names, for instance ^[16] :

Realtime file integrity:

agent.ip: 10.10.1.20 and syscheck.mode: realtime

General file integrity:

agent.ip: 10.10.1.20 and rule.groups: syscheck

Snort IDS alerts (once Snort is running):

agent.ip: 10.10.1.20 and rule.groups: ids

Just the XMAS scans:

full_log:*xmas*

Wazuh will also alert when log files are tampered with:

Wazuh can already alert for SQL injections, based on the Apache access logs:

3.1.1. SQL Injection

On Windows Server, make sure Apache and MySQL are running in XAMPP.

On Kali Attack Box, browse to http://10.10.1.20/dvwa/vulnerabilities/sqli/ (log in with admin / password). In the User ID field, enter ‘ or 1=1 -- -

On Ubuntu SIEM, check the discover tab for an SQL injection alert.

If an alert does not appear, troubleshoot to identify the problem:

On Windows Server, the file C:\xampp\apache\logs\access.log should contain the SQLi pattern, otherwise there is a problem with Apache.

Files in C:\Program Files (x86)\ossec-agent\logs should reference the Apache access log, otherwise there is a problem with the Wazuh Agent (likely agent.conf).

On Ubuntu SIEM, the file /var/ossec/logs/archives/archives.json should also contain the SQLi pattern, otherwise there is a problem with Wazuh-Manager (likely ossec.conf) ^[25].

3.1.2. Brute Force Attack

On Kali attack box, perform an FTP brute force attack against Windows Server with Hydra:

hydra -l administrator -P /usr/share/wordlists/dirb/common.txt ftp://10.10.1.20

Let Hydra run for a few seconds, then terminate (Ctrl+C).

On Ubuntu SIEM, there should be a bunch of low-severity “Logon Failure” alerts and one new high-severity alert based on the rule added to local_rules.xml:

Otherwise, On Windows Server, check that FTP is working, capture the attack with Wireshark, use Event Viewer to verify the security logs. The ossec-agent logs should contain:

On Ubuntu SIEM, /var/ossec/logs/archives/archives.json should be full of “Logon Failure”.

Return to 2.5. Snort NIDS.

3.2. Snort in Sniffer Mode

On Windows Server, run Snort showing only IP and TCP/UDP/ICMP headers with PowerShell:

cd C:\Snort\bin

./snort -W #Note the interface index number

./snort -vd -i 2

On Kali attack box, ping Windows Server.

On Windows Server, observe Snort output showing the ping:

Return to 2.5.1. Configure Snort.

3.3. Snort in IDS mode

On Windows Server, activate Snort in IDS mode:

cd C:\Snort\bin

./snort -W #Note the interface index number

./snort -i 2 -l ..\log -c ..\etc\snort.conf

# After a slew of warnings, it should say “Commencing packet processing”:

On Kali attack box, scan the Windows VM:

nmap -sX -p 22-180 10.10.1.20

nmap -sN -p 22-180 10.10.1.20

nmap -sS -p 22-180 10.10.1.20

nmap -sU -p 22-180 10.10.1.20

Check the Wazuh Discover tab for alerts.

If these IDS events are missing from the SIEM, troubleshooting SNORT:

On Windows Server, check C:\Snort\log\alert.ids:

Check the latest files in C:\Program Files(x86)\ossec-agent\logs\ to see what files are being analyzed by the agent ^[22]. Look for something like:

On Ubuntu SIEM, search /var/ossec/logs/archives.json for the Snort alerts:

3.3.1. Generate XSS Alerts

On Windows Server, make sure Apache and MySQL are running in XAMPP.

On Kali attack box, browse to http://10.10.1.20/dvwa/vulnerabilities/xss_s/ (log in with admin / password). Populate the form with any name and some javascript in the message:

Of course it shows up in the SIEM:

But in case it doesn’t, follow the same chain of logs as with previous Snort troubleshooting. There should be an alert in C:\Snort\log\alert.ids, otherwise Snort is faulty. The Wazuh Agent should log that it’s analyzing alert.ids in C:\Program Files(x86)\ossec-agent\logs\. On Ubuntu, /var/ossec/logs/archives.json should contain the alert if ossec.conf is working correctly:

Return to 2.5.2. Snort as a Service.

3.4. Volatility Memory Analysis

On Windows Server, download Comae-Toolkit-v20230117.zip (DumpIt) from https://www.magnetforensics.com/resources/magnet-dumpit-for-windows/ and extract to C:\DumpIt\. Generate a memory dump in PowerShell, output to IIS FTP root:

C:\DumpIt\x64\DumpIt.exe /O C:\inetpub\ftproot\WIN.dmp

Restart the FTP site before switching VMs, otherwise it will probably botch the next step:

Restart-WebItem “IIS:\Sites\IIS-FTP”

On Ubuntu SIEM, Download the DMP file ^[23][24] :

cd /home/cir-siem/volatility3

wget --user=administrator --password=’Pa$$w0rd’ ftp://10.10.1.20/WIN.dmp -O WIN.dmp

# Compute hash:

sha256sum WIN.dmp

# Extract artifacts:

python3 -m venv venv && . venv/bin/activate

vol -f WIN.dmp windows.info #Image info

The first time Volatility runs, it needs to build caches, can take a few minutes. More useful commands:

vol -f WIN.dmp windows #List available modules

vol -f WIN.dmp windows.pslist #Running processes

vol -f WIN.dmp windows.cmdline #Command line arguments

vol -f WIN.dmp windows.netscan #Active ports

vol -f WIN.dmp windows.shimcachemem #ShimCache

vol -f WIN.dmp windows.hivelist #List registry hives

Show registry keys:

vol -f WIN.dmp windows.registry.printkey

Use -h to get help with a specific module:

vol -f WIN.dmp windows.registry.printkey -h

Tells us there is a --recurse option:

vol -f WIN.dmp windows.registry.printkey --recurse

Okay that one never stops. :p Here’s a better one. First get the PID of Windows Defender:

vol -f WIN.dmp windows.pslist | grep msmpeng -i

Then, list DLLs used by that PID only:

vol -f WIN.dmp windows.dlllist --pid 2008

P.S. For encrypted FTP traffic, do this: https://learn.microsoft.com/en-us/iis/manage/configuring-security/how-to-set-up-ssl-on-iis.

Appendix A. Credentials

References