Skip to content

Latest commit

 

History

History
1259 lines (971 loc) · 50.8 KB

File metadata and controls

1259 lines (971 loc) · 50.8 KB

Windows Security Operations Lab (Blue Team / SOC)

This document describes a Windows-focused virtual lab for blue team and Security Operations Center (SOC) training.
The lab is built entirely from defensive components:

  • Windows Active Directory domain
  • Multiple Windows clients and servers
  • pfSense virtual firewall/router
  • Central logging and monitoring (SIEM-style)
  • Optional SOAR-style automation and deception/honeypot hosts

There are no dedicated attacker machines in this design. It is intended to:

  • Generate realistic Windows security telemetry
  • Practice log collection, correlation, and alerting
  • Exercise incident triage and response playbooks
  • Integrate later with a separate offensive lab if desired

1. Tool Selection and Justification

This section explains why each tool was chosen for this Windows Security Operations Lab, how it compares to alternatives, and its viability in 2026 and beyond.

1.1. Virtualization Platform: QEMU/KVM

Why QEMU/KVM?

  • Open-source and actively maintained: QEMU/KVM is the standard Linux virtualization solution, with continuous development and security updates as of 2026.
  • Performance: Near-native performance with hardware acceleration (Intel VT-x/AMD-V), essential for running multiple Windows VMs simultaneously.
  • Cost: Free and open-source, unlike VMware vSphere or Hyper-V Server (which requires Windows Server licensing).
  • Integration: Native integration with Linux hosts, perfect for security professionals already using Linux.

Alternatives Considered:

  • VMware Workstation: Commercial, requires licensing. Better GUI but QEMU/KVM + virt-manager provides equivalent functionality for free.
  • VirtualBox: Free but lower performance, especially for Windows Server workloads. QEMU/KVM offers better I/O performance.
  • Hyper-V: Windows-only, requires Windows Server host. QEMU/KVM works on any Linux distribution.

2026+ Viability: ✅ Excellent - QEMU 8.0+ and KVM are actively developed, support latest Windows Server 2022 and Windows 11, and receive regular security patches.

1.2. VM Management: libvirt + virt-manager

Why libvirt/virt-manager?

  • Standard tooling: libvirt is the de-facto standard for Linux VM management, used by major cloud providers and enterprise environments.
  • CLI and GUI: virsh (CLI) and virt-manager (GUI) provide flexibility for both automation and manual management.
  • Network management: Built-in network creation and management (virsh net-* commands) simplifies lab networking.
  • Compatibility: Works seamlessly with QEMU/KVM, no additional licensing.

Alternatives Considered:

  • Cockpit: Web-based management, good for remote access but virt-manager provides better local VM console experience.
  • Proxmox: Full hypervisor platform, overkill for a lab environment. libvirt is lighter and more flexible.

2026+ Viability: ✅ Excellent - libvirt 10.0+ actively maintained, virt-manager receives regular updates, full Windows 11/Server 2022 support.

1.3. Firewall/Router: pfSense CE

Why pfSense?

  • Enterprise-grade: pfSense is based on FreeBSD and used in production environments worldwide, providing realistic firewall experience.
  • Feature-rich: Includes stateful firewall, NAT, VPN, IDS/IPS capabilities, traffic shaping, and extensive logging.
  • Free: Community Edition (CE) is free and fully functional for lab use.
  • Windows integration: Works seamlessly with Windows Event Log forwarding and can integrate with Windows SIEM solutions.

Alternatives Considered:

  • OPNsense: pfSense fork with modern UI, but pfSense has larger community and more documentation.
  • VyOS: CLI-only, steeper learning curve. pfSense web UI is more accessible for lab learning.
  • iptables/netfilter: Native Linux but requires extensive configuration. pfSense provides GUI and better Windows integration.

2026+ Viability: ✅ Excellent - pfSense CE 2.7+ actively maintained, regular security updates, supports modern protocols (TLS 1.3, IPv6, etc.).

1.4. Directory Services: Windows Active Directory

Why Windows AD?

  • Industry standard: Active Directory is the dominant directory service in enterprise Windows environments (estimated 90%+ market share).
  • Real-world relevance: Learning AD is essential for Windows security professionals, as most Windows attacks target AD.
  • Rich telemetry: AD generates extensive security logs (logon events, privilege changes, object access) perfect for SOC training.
  • Integration: Native integration with Windows Event Forwarding, Group Policy, and Windows security tools.

Alternatives Considered:

  • Samba AD: Open-source AD implementation, but lacks some advanced features and has compatibility issues with some Windows tools.
  • FreeIPA: Linux-focused, doesn't provide Windows AD experience needed for blue team training.

2026+ Viability: ✅ Excellent - Windows Server 2022 AD DS is current, Microsoft continues active development, AD remains core to Windows security.

1.5. Log Collection: Windows Event Collector (WEC)

Why WEC?

  • Native Windows solution: Built into Windows Server, no additional licensing or installation required.
  • Efficient: Uses Windows Remote Management (WinRM) for secure, efficient log forwarding.
  • Standard protocol: Uses standard Windows Event Log format, compatible with all Windows SIEM solutions.
  • Group Policy integration: Can be deployed and configured via Group Policy across entire domain.

Alternatives Considered:

  • NXLog: Third-party log forwarder, requires licensing for advanced features. WEC is free and native.
  • Winlogbeat: Part of Elastic Stack, good for ELK but WEC is more universal and works with any SIEM.

2026+ Viability: ✅ Excellent - WEC is core Windows functionality, fully supported in Windows Server 2022 and Windows 11.

1.6. Process Monitoring: Sysmon

Why Sysmon?

  • Microsoft tool: Free, officially supported by Microsoft, regularly updated with new detection capabilities.
  • Comprehensive: Tracks process creation, file creation, network connections, registry changes, and more.
  • Industry standard: Used by security teams worldwide, extensive community configurations available (SwiftOnSecurity, etc.).
  • SIEM integration: Generates Windows Event Logs that integrate seamlessly with WEC and SIEM platforms.

Alternatives Considered:

  • Process Monitor (ProcMon): GUI tool, not suitable for continuous monitoring and SIEM integration.
  • ETW (Event Tracing for Windows): Lower-level, requires more configuration. Sysmon provides higher-level, security-focused events.

2026+ Viability: ✅ Excellent - Sysmon 15.0+ actively maintained by Microsoft, latest version supports Windows 11 and Server 2022, regular updates with new detection capabilities.

1.7. SIEM Platforms: Wazuh, Splunk, Graylog

Why Multiple Options? Different SIEMs serve different use cases and learning objectives:

Wazuh:

  • Open-source: Free, no licensing restrictions, perfect for learning.
  • Comprehensive: Includes HIDS, log analysis, vulnerability detection, and compliance monitoring.
  • Active development: Regularly updated, active community, good documentation.
  • Windows integration: Native Windows agent, excellent Sysmon integration.

Splunk Enterprise:

  • Industry leader: Most widely used SIEM in enterprise environments (Fortune 500 companies).
  • Powerful: Advanced search, correlation, and visualization capabilities.
  • Evaluation available: 60-day free evaluation, perfect for lab learning.
  • Career relevance: Learning Splunk is valuable for SOC analyst careers.

Graylog:

  • Open-source core: Free open-source version available.
  • Modern interface: Clean web UI, good for learning log analysis concepts.
  • Elasticsearch backend: Uses Elasticsearch for storage, good performance.

2026+ Viability:

  • Wazuh: ✅ Excellent - Version 4.7+ actively maintained, regular releases, strong Windows support.
  • Splunk: ✅ Excellent - Industry standard, continuous development, latest version supports modern Windows.
  • Graylog: ✅ Good - Active development continues, though smaller community than Wazuh/Splunk.

Recommendation: Start with Wazuh for free, comprehensive learning. Use Splunk evaluation if you want enterprise experience.

1.8. Automation: PowerShell

Why PowerShell?

  • Native Windows: Built into Windows Server and Windows 10/11, no additional installation required.
  • Powerful: Can manage AD, Windows services, event logs, registry, and more.
  • Industry standard: Used by Windows administrators and security professionals worldwide.
  • SOAR integration: Most Windows SOAR platforms use PowerShell for automation.

Alternatives Considered:

  • Python: Cross-platform but requires installation, less native Windows integration.
  • Bash: Not native to Windows, requires WSL or additional tools.

2026+ Viability: ✅ Excellent - PowerShell 7+ (cross-platform) and Windows PowerShell 5.1 actively maintained, core to Windows administration.

1.9. Operating Systems: Windows Server 2019/2022 and Windows 10/11

Why These Versions?

  • Windows Server 2022: Latest stable release as of 2026, includes latest security features and AD improvements.
  • Windows Server 2019: Still widely deployed in enterprises, learning both versions provides broader experience.
  • Windows 11: Current client OS, represents modern Windows security features.
  • Windows 10: Still common in enterprises, provides compatibility testing.

2026+ Viability: ✅ Excellent - All versions receive security updates, Windows Server 2022 supported until 2031, Windows 11 is current.


2. Host System Requirements

The tables below assume all VMs for a given lab profile are powered on simultaneously.

1.1. Recommended Host Hardware by Lab Size

Lab Profile Intended Use Minimum Host CPU Recommended Host CPU Minimum Host RAM Recommended Host RAM Minimum Free Disk Recommended Free Disk
Profile A – Core AD + Logging Single DC, 1 SIEM/server, 1–2 clients 4 cores 6–8 cores 16 GB 24 GB 300 GB 400 GB
Profile B – SOC Monitoring Lab DC, file server, SIEM server, 2–3 clients 6 cores 8–12 cores 24 GB 32 GB 450 GB 600 GB
Profile C – SOC + Deception Lab Redundant DCs, SIEM, honeypot, 3–4 clients 8 cores 12–16 cores 32 GB 48 GB 600 GB 800 GB+

Notes

  • Use thin-provisioned virtual disks (e.g., qcow2) wherever possible.
  • If resources are tight, power off non-essential clients while focusing on server configuration.

2. Common Network and Services Design

All lab profiles share a similar high-level design:

  • A single routed internal network (for example, 10.10.0.0/24)
  • A pfSense VM acting as:
    • Default gateway
    • Firewall between the lab and any external network
    • Optional DHCP server for the internal segment
    • Optional DNS forwarder
  • One or more Windows Server hosts providing:
    • Active Directory Domain Services (AD DS)
    • DNS for the Windows domain
    • Additional roles such as file services, logging collectors, and security tooling
  • Multiple Windows 10/11 clients joined to the domain

Example internal addressing (you may adjust the exact ranges):

  • pfSense LAN: 10.10.0.1/24
  • Domain Controller(s): 10.10.0.10–11
  • Member servers (file, SIEM, automation, honeypot): 10.10.0.20–39
  • Clients: 10.10.0.100–150

3. Profile A – Core AD + Centralized Logging Lab

Goal: A compact Windows domain with centralized logging suitable for:

  • Practicing Active Directory administration
  • Enabling Windows Event Forwarding (WEF/WEC)
  • Sending events to a local SIEM-style instance on a Windows server

3.1. Topology

graph TB
    subgraph Edge["pfSense Firewall / Router"]
        PFS["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 10.10.0.1/24"]
    end

    subgraph Domain["Windows Domain: corp.local (10.10.0.0/24)"]
        DC1["DC1 - Windows Server 2019/2022<br/>Domain Controller + DNS<br/>10.10.0.10"]
        SOC1["SOC-SRV - Windows Server 2019/2022<br/>Event Collector + SIEM-style Server<br/>10.10.0.20"]
        WIN1["WIN10-1 - Windows 10/11 Pro<br/>Domain-Joined Client<br/>10.10.0.101"]
        WIN2["WIN10-2 - Windows 10/11 Pro (optional)<br/>Domain-Joined Client<br/>10.10.0.102"]
    end

    PFS --- DC1
    PFS --- SOC1
    PFS --- WIN1
    PFS --- WIN2

    DC1 --- SOC1
    WIN1 --- SOC1
    WIN2 --- SOC1
Loading

3.2. VM Inventory and Specifications

VM Name / Role OS vCPU (Min / Rec) RAM (Min / Rec) Disk (Min / Rec) NICs Primary Purpose
PFS (pfSense) pfSense CE 1 / 2 cores 1 GB / 2 GB 16 GB / 20 GB 2 (WAN, LAN) Gateway, firewall, DHCP/DNS forwarder
DC1 (Domain Controller) Windows Server 2019/2022 2 / 4 cores 4 GB / 8 GB 60 GB / 80 GB 1 (LAN) AD DS, DNS for corp.local, optional DHCP
SOC-SRV (Logging / SIEM-style) Windows Server 2019/2022 2 / 4 cores 6 GB / 8–12 GB 100 GB / 150 GB 1 (LAN) Windows Event Collector (WEC), Sysmon logs, SIEM-style dashboarding
WIN10-1 (Client) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 (LAN) Standard domain workstation for user activity
WIN10-2 (Optional Client) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 (LAN) Additional workstation for testing policies and multiple users

3.3. Blue Team Focus

Recommended defensive configuration in this profile:

  • On DC1

    • Install and configure Active Directory Domain Services and DNS.
    • Enable advanced auditing (account logon, object access, policy changes, etc.).
    • Configure Group Policy to:
      • Deploy Sysmon configuration to clients and servers.
      • Enable Windows Event Forwarding to SOC-SRV.
  • On SOC-SRV

    • Configure Windows Event Collector (WEC) subscriptions to receive logs from:
      • Domain Controller (DC1)
      • All domain-joined clients (WIN10-*)
    • Install a SIEM-style solution on Windows Server (for example, an evaluation or free tier) to:
      • Ingest Windows Security, Sysmon, and Application logs.
      • Build simple dashboards (logon failures, new logon types, service installations).
      • Configure baseline alerts (e.g., repeated failed logons, new service creation).
  • On Clients

    • Join each client to the corp.local domain.
    • Apply Group Policies for:
      • Sysmon installation and configuration.
      • Forwarding of key event channels to SOC-SRV.

4. Profile B – SOC Monitoring Lab

Goal: Expand the environment into a small SOC lab with:

  • A dedicated file/utility server
  • A more capable SIEM server
  • 2–3 domain-joined clients

4.1. Topology

graph TB
    subgraph Edge["pfSense Firewall / Router"]
        PFSB["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 10.20.0.1/24"]
    end

    subgraph DomainB["Windows Domain: blue.local (10.20.0.0/24)"]
        DCB["DC1 - Windows Server 2019/2022<br/>Domain Controller + DNS<br/>10.20.0.10"]
        FILEB["FILE-SRV - Windows Server 2019/2022<br/>File / Utility Server<br/>10.20.0.20"]
        SIEMB["SIEM-SRV - Windows Server 2019/2022<br/>Central SIEM-Style Platform<br/>10.20.0.30"]
        MGMTB["SEC-MGMT - Windows 10/11 Pro<br/>Analyst / Admin Workstation<br/>10.20.0.40"]
        C1B["WIN10-1 - Client 1<br/>10.20.0.101"]
        C2B["WIN10-2 - Client 2<br/>10.20.0.102"]
        C3B["WIN10-3 - Client 3 (optional)<br/>10.20.0.103"]
    end

    PFSB --- DCB
    PFSB --- FILEB
    PFSB --- SIEMB
    PFSB --- MGMTB
    PFSB --- C1B
    PFSB --- C2B
    PFSB --- C3B

    DCB --- SIEMB
    FILEB --- SIEMB
    C1B --- SIEMB
    C2B --- SIEMB
    C3B --- SIEMB
    MGMTB --- SIEMB
Loading

4.2. VM Inventory and Specifications

VM Name / Role OS vCPU (Min / Rec) RAM (Min / Rec) Disk (Min / Rec) NICs Primary Purpose
pfSense (PFSB) pfSense CE 2 / 2 cores 2 GB / 2–4 GB 20 GB / 30 GB 2 Gateway, firewall, DHCP/DNS relay or forwarder
DC1 (DCB) Windows Server 2019/2022 2 / 4 cores 4 GB / 8 GB 60 GB / 80 GB 1 Domain Controller, DNS for blue.local
FILE-SRV (FILEB) Windows Server 2019/2022 2 / 4 cores 4 GB / 8 GB 80 GB / 120 GB 1 File shares, script storage, log archive share
SIEM-SRV (SIEMB) Windows Server 2019/2022 3 / 4–6 cores 8 GB / 12–16 GB 150 GB / 200–300 GB 1 SIEM platform, event collector, correlation and alerting
SEC-MGMT (MGMTB) Windows 10/11 Pro 2 / 2 cores 4 GB / 8 GB 60 GB / 80 GB 1 Security analyst workstation with consoles, dashboards, and tools
WIN10-1 (C1B) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 Standard user workstation
WIN10-2 (C2B) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 Standard user workstation
WIN10-3 (C3B, Optional) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 Additional client for load and policy testing

4.3. Blue Team / SOC Capabilities

In this profile, you can practice:

  • Centralized logging

    • Configure SIEM-SRV to ingest:
      • Windows Security and Sysmon logs from all servers and clients
      • File access logs from FILE-SRV
    • Use subscriptions and agents appropriate to your chosen platform.
  • SOC workflows

    • Use SEC-MGMT as the analyst console:
      • SIEM web interface
      • Remote Event Viewer and PowerShell remoting
      • Documentation and runbooks
  • File server monitoring

    • On FILE-SRV, enable advanced auditing for:
      • File read/write/delete on specific shares
      • Permission changes and ownership changes
    • Forward these events into SIEM-SRV for correlation.

5. Profile C – SOC + Deception / Honeypot Lab

Goal: Extend the SOC lab with deception techniques by adding a highly monitored honeypot server in the Windows environment.

5.1. Topology

graph TB
    subgraph Edge["pfSense Firewall / Router"]
        PFSC["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 10.30.0.1/24"]
    end

    subgraph DomainC["Windows Domain: sec.lab (10.30.0.0/24)"]
        DC1C["DC1 - Windows Server 2019/2022<br/>Primary DC + DNS<br/>10.30.0.10"]
        DC2C["DC2 - Windows Server 2019/2022<br/>Secondary DC + DNS<br/>10.30.0.11"]
        SIEMC["SIEM-SRV - Windows Server 2019/2022<br/>Central SIEM-style Platform<br/>10.30.0.30"]
        HONEYC["HONEY-SRV - Windows Server 2019/2022<br/>Deception / Honeypot Server<br/>10.30.0.40"]
        MGMT2C["SEC-MGMT - Windows 10/11 Pro<br/>Analyst Workstation<br/>10.30.0.50"]
        C1C["WIN10-1 - Client 1<br/>10.30.0.101"]
        C2C["WIN10-2 - Client 2<br/>10.30.0.102"]
        C3C["WIN10-3 - Client 3 (optional)<br/>10.30.0.103"]
    end

    PFSC --- DC1C
    PFSC --- DC2C
    PFSC --- SIEMC
    PFSC --- HONEYC
    PFSC --- MGMT2C
    PFSC --- C1C
    PFSC --- C2C
    PFSC --- C3C

    DC1C --- SIEMC
    DC2C --- SIEMC
    HONEYC --- SIEMC
    C1C --- SIEMC
    C2C --- SIEMC
    C3C --- SIEMC
Loading

5.2. VM Inventory and Specifications

VM Name / Role OS vCPU (Min / Rec) RAM (Min / Rec) Disk (Min / Rec) NICs Primary Purpose
pfSense (PFSC) pfSense CE 2 / 3–4 cores 2 GB / 4 GB 20 GB / 30 GB 2 Gateway, firewall, optional additional interfaces if you split subnets later
DC1 (DC1C) Windows Server 2019/2022 2 / 4 cores 4 GB / 8 GB 60 GB / 80 GB 1 Primary DC, holds FSMO roles, DNS for sec.lab
DC2 (DC2C) Windows Server 2019/2022 2 / 4 cores 4 GB / 8 GB 60 GB / 80 GB 1 Secondary DC for redundancy and replication testing
SIEM-SRV (SIEMC) Windows Server 2019/2022 3 / 4–6 cores 8 GB / 12–16 GB 200 GB / 300 GB+ 1 Central log storage, correlation, dashboards, and alerting
HONEY-SRV (HONEYC) Windows Server 2019/2022 2 / 4 cores 4 GB / 8 GB 80 GB / 120 GB 1 Deception host with deliberately exposed but closely monitored services
SEC-MGMT (MGMT2C) Windows 10/11 Pro 2 / 2 cores 4 GB / 8 GB 60 GB / 80 GB 1 SOC analyst workstation, remote admin of all servers
WIN10-1 (C1C) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 User workstation
WIN10-2 (C2C) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 User workstation
WIN10-3 (C3C, Optional) Windows 10/11 Pro 2 / 2 cores 4 GB / 6 GB 50 GB / 60 GB 1 Optional additional client

5.3. Deception and SOC Configuration

Key defensive patterns to implement:

  • Directory Services and Redundancy

    • Configure AD replication between DC1C and DC2C.
    • Test failover: simulate DC outages and validate client logon behavior.
  • SIEM Integration

    • Forward Security, Sysmon, and key Application logs from:
      • Both domain controllers
      • All clients
      • HONEY-SRV (critical)
    • Build correlation rules for:
      • Logon anomalies
      • New service creation
      • Process executions from unusual paths on the honeypot
  • Honeypot Design (HONEY-SRV)

    • Join to domain with restricted rights.
    • Expose commonly targeted services (for lab use only), such as:
      • RDP listener with strong passwords but extensive logging
      • SMB shares with decoy folders and honey files
    • Enable:
      • Detailed object access auditing on decoy shares
      • Additional Sysmon rules focused on suspicious tools and processes
    • Ensure all activity on HONEY-SRV is forwarded and clearly labeled in the SIEM.

6. SOAR-Style Automation (Optional)

If resources permit, you can implement automation workflows that react to SIEM alerts:

  • Use scripts and tools on SIEM-SRV or SEC-MGMT to:
    • Automatically disable suspicious user accounts
    • Move machines into quarantine Organizational Units
    • Collect additional data via remote PowerShell or WMI queries
  • Store automation scripts on FILE-SRV or INFRA-style servers (depending on profile) and document:
    • Trigger conditions (for example, a high-severity SIEM alert)
    • Required approvals (manual step in training scenarios)
    • Exact actions taken by each script

This provides SOAR-like behavior using built-in Windows and scripting capabilities without additional products.


7. General Build Order and Best Practices

  1. Create pfSense VM

    • Configure one WAN interface (NAT from host) and one LAN interface for the lab.
    • Confirm lab clients can reach 10.10.0.1 / 10.20.0.1 / 10.30.0.1 according to the chosen profile.
  2. Deploy Domain Controller(s)

    • Install Windows Server, set static IPs, and configure DNS.
    • Promote to Domain Controller and create your lab domain.
  3. Deploy Member Servers (File / SIEM / Honeypot)

    • Join each server to the domain.
    • Install relevant roles and features (file services, event collector, SIEM platform).
    • Configure log forwarding and retention policies.
  4. Deploy Clients

    • Install Windows 10/11 Pro, assign IPs via DHCP or statically, and join the domain.
    • Apply Group Policies for security baselines, logging, and monitoring.
  5. Harden and Instrument

    • Enable advanced auditing and Sysmon on all endpoints.
    • Confirm events flow end-to-end from endpoints into the SIEM dashboards.
  6. Document Use Cases

    • Define specific scenarios (suspicious logons, file access anomalies, service modifications).
    • Practice triage, escalation, and reporting using the SOC workstation.

This Windows Security Operations Lab provides a flexible foundation for defensive training and can be integrated with a separate offensive lab by carefully adjusting pfSense rules to allow controlled traffic between environments.


8. Host Configuration and Virtualization Setup (QEMU/KVM)

The Windows Security Operations Lab is intended to run on a Linux host using QEMU/KVM and libvirt/virt-manager, in the same way as described in README.md.

8.1. Verify Hardware Virtualization Support

# Check CPU virtualization support (Intel VT-x or AMD-V)
egrep -c '(vmx|svm)' /proc/cpuinfo

# Alternative: show a line with virtualization flags
grep -E '(vmx|svm)' /proc/cpuinfo | head -1
  • Expected: A value greater than 0 and virtualization flags (vmx or svm) present.
  • If 0, enable virtualization in BIOS/UEFI and reboot.

8.2. Install QEMU/KVM and Management Tools

Arch Linux

# Update package database
sudo pacman -Sy

# Install QEMU/KVM, libvirt and related tools
sudo pacman -S --needed qemu virt-manager virt-viewer dnsmasq vde2 bridge-utils openbsd-netcat ebtables iptables

# Verify binaries
which qemu-system-x86_64
which virt-manager
which virsh

Ubuntu / Debian

# Update package lists
sudo apt update

# Install QEMU/KVM and virtualization tools
sudo apt install -y qemu-kvm qemu-utils libvirt-daemon-system libvirt-clients bridge-utils virt-manager virt-viewer dnsmasq

# Verify binaries
which qemu-system-x86_64
which virt-manager
which virsh

8.3. Enable and Start libvirtd

sudo systemctl enable libvirtd
sudo systemctl start libvirtd

# Check status
sudo systemctl status libvirtd

Add your user to the libvirt or kvm groups if required by your distribution, then log out and back in.

8.4. Create a Directory for Windows Lab VMs

mkdir -p "${HOME}/VMs/windows-soc-lab"
ls -ld "${HOME}/VMs/windows-soc-lab"

9. Network Creation for Windows Security Lab

This section creates a single isolated libvirt network for the Windows SOC lab. pfSense will provide routing and (optionally) NAT to the internet from within that network.

9.1. Define the win-soc Network

tee /tmp/win-soc.xml <<'EOF'
<network>
  <name>win-soc</name>
  <bridge name="br-win-soc"/>
  <forward mode='isolated'/>
  <ip address='10.30.0.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='10.30.0.100' end='10.30.0.200'/>
    </dhcp>
  </ip>
</network>
EOF

# Define and start the network
virsh net-define /tmp/win-soc.xml
virsh net-start win-soc
virsh net-autostart win-soc

# Verify network
virsh net-list --all

9.2. Network Usage

  • Attach all Windows lab VMs (pfSense, domain controllers, SIEM, honeypot, clients) to the win-soc network.
  • pfSense LAN interface will use a static IP, for example 10.30.0.1 or 10.30.0.254 depending on your preference.
  • pfSense WAN interface should use the default virbr0 or another NAT network to reach the internet for updates.

10. VM Creation Commands (pfSense, Windows Servers, Clients)

The commands below provide scriptable examples for creating the main Windows Security Operations Lab VMs with QEMU/KVM. You may also perform these steps through virt-manager if you prefer a graphical workflow.

10.1. Download pfSense ISO

mkdir -p "${HOME}/Downloads/pfsense"

# Check https://www.pfsense.org/download/ for latest version
PFS_VERSION="2.7.2"
PFS_ISO="pfSense-CE-${PFS_VERSION}-RELEASE-amd64.iso"
PFS_URL="https://atxfiles.pfsense.org/mirror/downloads/${PFS_ISO}"

echo "Downloading pfSense ISO..."
curl -L --progress-bar -o "${HOME}/Downloads/pfsense/${PFS_ISO}" "${PFS_URL}"

# Verify file exists
ls -lh "${HOME}/Downloads/pfsense/${PFS_ISO}"

10.2. Create pfSense VM

# Parameters
VM_NAME="pfsense-win-soc"
VM_RAM="2048"        # 2 GiB
VM_CPUS="2"
VM_DISK_SIZE="20"    # 20 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/pfsense/${PFS_ISO}"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=win-soc,model=virtio \
  --graphics vnc,listen=0.0.0.0 \
  --noautoconsole \
  --os-type generic \
  --os-variant generic

After installation, configure:

  • WAN interface: attach to the default NAT network (virbr0) in virt-manager or via virsh attach-interface.
  • LAN interface: attach to win-soc and set IP (for example, 10.30.0.1).

10.3. Create Windows Server VM (Domain Controller Example)

Obtain a Windows Server evaluation ISO from the official source:

  • https://www.microsoft.com/en-us/evalcenter/ (Windows Server Evaluation Center)

Assuming a Windows Server ISO at ${HOME}/Downloads/ISOs/WinServer2019.iso:

VM_NAME="win-dc1"
VM_RAM="8192"        # 8 GiB
VM_CPUS="4"
VM_DISK_SIZE="80"    # 80 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/WinServer2019.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=win-soc,model=virtio \
  --graphics spice \
  --video qxl \
  --os-type windows \
  --os-variant win2k19

After installation:

  • Set a static IP (for example, 10.30.0.10).
  • Configure DNS to point to itself.
  • Install Active Directory Domain Services and promote the server to a Domain Controller for your chosen domain (corp.local, blue.local, or sec.lab).

10.4. Create Additional Windows Servers (SIEM, File, Honeypot)

Repeat the previous process with adjusted VM names, resources, and static IPs:

# Example for SIEM server
VM_NAME="win-siem"
VM_RAM="12288"       # 12 GiB
VM_CPUS="4"
VM_DISK_SIZE="200"   # 200 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/WinServer2019.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=win-soc,model=virtio \
  --graphics spice \
  --video qxl \
  --os-type windows \
  --os-variant win2k19

Assign static IPs such as:

  • 10.30.0.30 for win-siem
  • 10.30.0.40 for a honeypot server
  • 10.30.0.20 for a file or utility server

Join each server to the domain, then install the appropriate roles (file services, event collector, SIEM platform, honeypot applications).

10.5. Create Windows 10/11 Client VMs

Obtain official Windows 10/11 installation media (for example, from the Microsoft Software Download pages) and then:

VM_NAME="win10-1"
VM_RAM="6144"        # 6 GiB
VM_CPUS="2"
VM_DISK_SIZE="60"    # 60 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/Win10.iso"

mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"

virt-install \
  --name "${VM_NAME}" \
  --ram "${VM_RAM}" \
  --vcpus "${VM_CPUS}" \
  --disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
  --cdrom "${ISO_PATH}" \
  --network network=win-soc,model=virtio \
  --graphics spice \
  --video qxl \
  --os-type windows \
  --os-variant win10

After installation:

  • Configure either DHCP (from pfSense) or a static IP within the 10.30.0.0/24 range.
  • Join the machine to your Windows domain.
  • Ensure that logging and monitoring agents or policies described earlier are applied.

11. Post-Installation Configuration: Windows Active Directory

After creating your Windows Server VM, follow these steps to configure Active Directory Domain Services.

11.1. Install VirtIO Drivers

On Host:

# Download virtio-win.iso
DOWNLOAD_DIR="${HOME}/Downloads"
mkdir -p "$DOWNLOAD_DIR"

VIRTIO_URL="https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso"
VIRTIO_FILE="${DOWNLOAD_DIR}/virtio-win.iso"

echo "Downloading virtio-win.iso..."
if curl -L --progress-bar -o "$VIRTIO_FILE" "$VIRTIO_URL"; then
    echo "✓ Download complete: $VIRTIO_FILE"
    ls -lh "$VIRTIO_FILE"
else
    echo "✗ Download failed. Check internet connection."
    exit 1
fi

In virt-manager:

  • Shut down Windows Server VM (if running)
  • Open VM details → Add HardwareStorage
  • Select Select or create custom storage → Browse to $HOME/Downloads/virtio-win.iso
  • Device type: CDROM → Click Finish

In Windows Server VM:

  • Start the VM
  • Open File ExplorerThis PC → Open CD drive (virtio-win)
  • Run virtio-win-gt-x64.msi
  • Follow installation wizard → Reboot VM

11.2. Configure Static IP Address

In Windows Server VM:

  • Open SettingsNetwork & InternetEthernet
  • Click on the network adapter → Edit under IP settings
  • Select Manual
  • Configure:
    • IP address: 10.30.0.10 (for DC1, adjust per profile)
    • Subnet mask: 255.255.255.0
    • Gateway: 10.30.0.1 (pfSense LAN)
    • DNS: 127.0.0.1 (will change after AD install)
  • Click Save

11.3. Install Active Directory Domain Services

In Windows Server VM:

  • Open Server Manager
  • Click Add Roles and Features
  • Wizard steps:
    • Select Role-based or feature-based installation
    • Select current server
    • Check:
      • Active Directory Domain Services
      • DNS Server
      • DHCP Server (optional)
    • Click Next through remaining steps → Install
  • Wait for installation to complete

11.4. Promote Server to Domain Controller

In Windows Server VM:

  • In Server Manager, click notification flag (yellow triangle)
  • Click Promote this server to a domain controller
  • Deployment Configuration:
    • Select Add a new forest
    • Enter Root domain name: corp.local (or blue.local, sec.lab per profile)
  • Domain Controller Options:
    • Set Directory Services Restore Mode (DSRM) password (remember this!)
    • Leave other options as default
  • Complete wizard → Click Promote
  • Server will automatically reboot

11.5. Post-Promotion Configuration

After reboot, log in as domain administrator:

  • Open Network Settings → Change DNS to 127.0.0.1 or 10.30.0.10
  • Open Active Directory Users and Computers (dsa.msc)
  • Navigate to corp.localUsers
  • Create test users:
    • john.doe (regular user)
    • jane.smith (regular user)
    • svc_siem (service account for SIEM)
    • admin_user (administrative user)

11.6. Enable Advanced Auditing

On Domain Controller:

  • Open Group Policy Management (gpmc.msc)
  • Right-click Default Domain PolicyEdit
  • Navigate to: Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAdvanced Audit Policy ConfigurationAudit Policies
  • Enable:
    • Account LogonAudit Account Logon Events: Success and Failure
    • Account ManagementAudit Account Management: Success and Failure
    • Logon/LogoffAudit Logon: Success and Failure
    • Object AccessAudit File System: Success and Failure
    • Policy ChangeAudit Policy Change: Success and Failure
  • Close Group Policy Editor
  • Force policy update: gpupdate /force

12. Post-Installation Configuration: Windows Event Collector (WEC) and SIEM

Configure centralized logging and SIEM-style analytics on your Windows SOC server.

12.1. Configure Windows Event Collector Service

On SIEM Server (SOC-SRV or SIEM-SRV):

  1. Enable Windows Event Collector Service:

    # Open PowerShell as Administrator
    wecutil qc
    • When prompted, type Y to enable the service
    • Service will start automatically
  2. Configure Firewall Rule:

    # Allow Event Collector traffic
    New-NetFirewallRule -DisplayName "Windows Event Collector" -Direction Inbound -LocalPort 5985,5986 -Protocol TCP -Action Allow

12.2. Create Event Subscription (Collector-Initiated)

On SIEM Server:

# Create subscription to collect from Domain Controller
$SubscriptionName = "Domain-Controller-Logs"
$DCName = "DC1.corp.local"
$Logs = @("Security", "System", "Application")

wecutil cs $SubscriptionName.xml

# Edit subscription XML (or create manually)
$SubscriptionXML = @"
<Subscription>
  <SubscriptionId>$SubscriptionName</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Collect Security, System, Application logs from DC</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Custom</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxItems>100</MaxItems>
      <MaxLatencyTime>1000</MaxLatencyTime>
    </Batching>
  </Delivery>
  <QueryList>
    <Query Id="0" Path="Security">
      <Select>*</Select>
    </Query>
    <Query Id="1" Path="System">
      <Select>*</Select>
    </Query>
    <Query Id="2" Path="Application">
      <Select>*</Select>
    </Query>
  </QueryList>
</Subscription>
"@

$SubscriptionXML | Out-File -FilePath "$SubscriptionName.xml" -Encoding UTF8
wecutil cs "$SubscriptionName.xml"

On Source Machines (DC, Clients):

# Configure source machines to forward events
# Run on each Windows machine that will forward logs

# Add SIEM server to Event Log Readers group
$SIEMServer = "SIEM-SRV.corp.local"
$Group = [ADSI]"WinNT://./Event Log Readers,group"
$Group.Add("WinNT://$SIEMServer/Administrator")

# Or use Group Policy:
# Computer Configuration → Policies → Administrative Templates → Windows Components → Event Forwarding
# Enable "Configure target Subscription Manager"

12.3. Install and Configure Sysmon

Download Sysmon:

  • Visit: https://learn.microsoft.com/sysinternals/downloads/sysmon
  • Download Sysmon64.exe to SIEM server and all endpoints

Create Sysmon Configuration:

<!-- Save as sysmonconfig.xml -->
<Sysmon schemaversion="4.90">
  <HashAlgorithms>SHA256</HashAlgorithms>
  <EventFiltering>
    <ProcessCreate onmatch="exclude">
      <Image condition="end with">\chrome.exe</Image>
      <Image condition="end with">\firefox.exe</Image>
    </ProcessCreate>
    <FileCreateTime onmatch="exclude">
      <Image condition="end with">\chrome.exe</Image>
    </FileCreateTime>
    <NetworkConnect onmatch="exclude">
      <Image condition="end with">\chrome.exe</Image>
      <Image condition="end with">\firefox.exe</Image>
      <DestinationPort>80</DestinationPort>
      <DestinationPort>443</DestinationPort>
    </NetworkConnect>
    <ProcessTerminate onmatch="include"/>
    <ImageLoad onmatch="include">
      <Signed condition="is">false</Signed>
    </ImageLoad>
  </EventFiltering>
</Sysmon>

Install Sysmon on All Machines:

# Run on each Windows machine
.\Sysmon64.exe -i sysmonconfig.xml -accepteula

# Verify installation
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Select-Object -First 5

12.4. Install SIEM Platform (Example: Wazuh Agent on Windows)

On SIEM Server (Linux-based Wazuh server, or use Windows-compatible SIEM):

Option A: Wazuh (if SIEM server is Linux):

  • Install Wazuh server on Linux VM (see LINUX-LAB.md section on SIEM)
  • Install Wazuh agent on Windows machines:
    # Download Wazuh agent for Windows
    # Install agent and configure manager IP to point to SIEM server

Option B: Windows-Compatible SIEM (Splunk, Graylog, etc.):

  • Download evaluation version of Splunk Enterprise or Graylog
  • Install on Windows Server SIEM VM
  • Configure inputs to read Windows Event Logs:
    # Splunk Universal Forwarder installation
    # Configure inputs.conf to monitor:
    # [WinEventLog://Security]
    # [WinEventLog://System]
    # [WinEventLog://Application]
    # [WinEventLog://Microsoft-Windows-Sysmon/Operational]

12.5. Configure Event Forwarding via Group Policy

On Domain Controller:

  1. Open Group Policy Management (gpmc.msc)
  2. Create new GPO: "SIEM Event Forwarding"
  3. Edit GPO:
    • Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsEvent Forwarding
    • Enable "Configure target Subscription Manager"
    • Enter: Server=http://SIEM-SRV.corp.local:5985/wsman/SubscriptionManager/WEC,Refresh=60
  4. Link GPO to Domain Controllers OU and Domain Computers OU
  5. Run gpupdate /force on all machines

13. Post-Installation Configuration: Windows Honeypot Server

Configure a Windows Server as a deception/honeypot host.

13.1. Basic Honeypot Setup

On HONEY-SRV:

  1. Join to Domain:

    • Configure static IP: 10.30.0.40
    • Join to corp.local domain
    • Use domain admin credentials
  2. Create Decoy Shares:

    # Create decoy folders
    New-Item -Path "C:\Shares\Confidential" -ItemType Directory
    New-Item -Path "C:\Shares\Financial" -ItemType Directory
    New-Item -Path "C:\Shares\HR" -ItemType Directory
    
    # Create honey files
    "Fake confidential data - DO NOT ACCESS" | Out-File "C:\Shares\Confidential\secret.txt"
    "Fake financial data" | Out-File "C:\Shares\Financial\budget.xlsx"
    
    # Share folders
    New-SmbShare -Name "Confidential" -Path "C:\Shares\Confidential" -FullAccess "Everyone"
    New-SmbShare -Name "Financial" -Path "C:\Shares\Financial" -FullAccess "Everyone"
  3. Enable Detailed Auditing on Decoy Shares:

    # Enable object access auditing
    auditpol /set /category:"Object Access" /success:enable /failure:enable
    
    # Configure auditing on folders
    $Acl = Get-Acl "C:\Shares\Confidential"
    $AuditRule = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone","FullControl","ContainerInherit,ObjectInherit","None","Success,Failure")
    $Acl.SetAuditRule($AuditRule)
    Set-Acl "C:\Shares\Confidential" $Acl
  4. Enable RDP with Extensive Logging:

    # Enable RDP
    Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 0
    Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
    
    # Enable detailed RDP logging
    Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "LogonUserName" -Value 1
  5. Install and Configure Sysmon (use aggressive configuration):

    # Use Sysmon configuration focused on detecting suspicious activity
    .\Sysmon64.exe -i honeypot-sysmonconfig.xml -accepteula
  6. Forward All Logs to SIEM:

    • Configure Windows Event Forwarding to SIEM-SRV
    • Ensure all Security, Sysmon, and Application logs are forwarded

14. Post-Installation Configuration: SOAR-Style Automation

Implement automated response workflows using PowerShell and Windows built-in tools.

14.1. Create Automation Scripts Directory

On SIEM-SRV or FILE-SRV:

New-Item -Path "C:\SOAR\Scripts" -ItemType Directory
New-Item -Path "C:\SOAR\Logs" -ItemType Directory

14.2. Example: Auto-Disable User Account Script

Create Disable-SuspiciousUser.ps1:

# C:\SOAR\Scripts\Disable-SuspiciousUser.ps1
param(
    [Parameter(Mandatory=$true)]
    [string]$Username,
    
    [Parameter(Mandatory=$true)]
    [string]$Reason
)

$LogFile = "C:\SOAR\Logs\automation.log"
$Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

# Log action
"[$Timestamp] Disabling user: $Username - Reason: $Reason" | Out-File -FilePath $LogFile -Append

try {
    Disable-ADAccount -Identity $Username
    "[$Timestamp] Successfully disabled user: $Username" | Out-File -FilePath $LogFile -Append
    
    # Send notification (example)
    # Send-MailMessage -To "admin@corp.local" -Subject "User Disabled" -Body "User $Username disabled: $Reason"
    
    Write-Host "User $Username disabled successfully"
} catch {
    "[$Timestamp] ERROR disabling user $Username : $_" | Out-File -FilePath $LogFile -Append
    Write-Error "Failed to disable user: $_"
}

14.3. Example: Quarantine Machine Script

Create Move-MachineToQuarantine.ps1:

# C:\SOAR\Scripts\Move-MachineToQuarantine.ps1
param(
    [Parameter(Mandatory=$true)]
    [string]$ComputerName
)

$LogFile = "C:\SOAR\Logs\automation.log"
$Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

# Create Quarantine OU if it doesn't exist
$DomainDN = (Get-ADDomain).DistinguishedName
$QuarantineOU = "OU=Quarantine,$DomainDN"

if (-not (Get-ADOrganizationalUnit -Filter "DistinguishedName -eq '$QuarantineOU'" -ErrorAction SilentlyContinue)) {
    New-ADOrganizationalUnit -Name "Quarantine" -Path $DomainDN
}

# Move computer to Quarantine OU
try {
    $Computer = Get-ADComputer -Identity $ComputerName
    Move-ADObject -Identity $Computer.DistinguishedName -TargetPath $QuarantineOU
    
    "[$Timestamp] Moved $ComputerName to Quarantine OU" | Out-File -FilePath $LogFile -Append
    
    # Apply restrictive GPO to Quarantine OU
    # (Create GPO that blocks network access, etc.)
    
    Write-Host "Computer $ComputerName moved to quarantine"
} catch {
    "[$Timestamp] ERROR moving $ComputerName : $_" | Out-File -FilePath $LogFile -Append
    Write-Error "Failed to move computer: $_"
}

14.4. Create Scheduled Task to Monitor SIEM Alerts

Create Monitor-SIEMAlerts.ps1:

# C:\SOAR\Scripts\Monitor-SIEMAlerts.ps1
# This script would query your SIEM API or log files for high-severity alerts
# Example: Query Wazuh API, Splunk API, or read from event logs

$SIEMLogPath = "C:\SIEM\Alerts\high-severity.json"  # Example path
$Threshold = 5  # Number of failed logons before action

# Query for repeated failed logons
$FailedLogons = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
    StartTime = (Get-Date).AddMinutes(-10)
} | Group-Object -Property @{Expression={$_.Properties[5].Value}} | Where-Object {$_.Count -ge $Threshold}

foreach ($User in $FailedLogons) {
    $Username = $User.Name
    Write-Host "Detected $($User.Count) failed logons for $Username"
    
    # Trigger automation
    & "C:\SOAR\Scripts\Disable-SuspiciousUser.ps1" -Username $Username -Reason "Repeated failed logon attempts"
}

Create Scheduled Task:

$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-File C:\SOAR\Scripts\Monitor-SIEMAlerts.ps1"
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration (New-TimeSpan -Hours 24)
Register-ScheduledTask -TaskName "SOAR-MonitorAlerts" -Action $Action -Trigger $Trigger -RunLevel Highest

15. Additional References

Virtualization and Management

  • QEMU/KVM Documentation: https://www.qemu.org/documentation/ - Official QEMU documentation
  • KVM Virtualization: https://www.linux-kvm.org/page/Main_Page - KVM project homepage
  • libvirt Documentation: https://libvirt.org/docs.html - Complete libvirt API and tool documentation
  • virt-manager: https://virt-manager.org/ - GUI for managing virtual machines
  • virsh Command Reference: https://libvirt.org/manpages/virsh.html - Command-line tool documentation

Networking and Firewall

  • pfSense CE: https://www.pfsense.org/ - Official pfSense website and downloads
  • pfSense Documentation: https://docs.netgate.com/pfsense/ - Complete pfSense documentation
  • pfSense Community Forum: https://forum.netgate.com/ - Community support and discussions

Windows Operating Systems

  • Windows Server Evaluations: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2022 - Download Windows Server 2022 evaluation
  • Windows Server 2019 Evaluation: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2019 - Download Windows Server 2019 evaluation
  • Windows 10/11 Enterprise Evaluation: https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise - Download Windows 10/11 evaluation
  • VirtIO Drivers for Windows: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/ - Download virtio-win.iso

Windows Security Tools

  • Windows Sysinternals / Sysmon: https://learn.microsoft.com/sysinternals/downloads/sysmon - Download and documentation
  • Sysmon Configuration Examples: https://github.com/SwiftOnSecurity/sysmon-config - Community-maintained Sysmon configurations
  • Windows Event Forwarding (WEC): https://learn.microsoft.com/windows-server/administration/windows-commands/wecutil - WEC command reference
  • Windows Event Forwarding Guide: https://learn.microsoft.com/windows-server/identity/ad-ds/manage/component-updates/command-line-procedures/event-forwarding - Complete WEC setup guide

Active Directory

  • Active Directory PowerShell Module: https://learn.microsoft.com/powershell/module/activedirectory/ - AD PowerShell cmdlet reference
  • Group Policy Management: https://learn.microsoft.com/windows-server/identity/ad-ds/getting-started/windows-server-2012-r2-and-2012/active-directory-group-policy - GPO documentation
  • Active Directory Domain Services: https://learn.microsoft.com/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview - AD DS overview and setup

SIEM Platforms

  • Wazuh Documentation: https://documentation.wazuh.com/current/index.html - Complete Wazuh documentation
  • Wazuh Windows Agent: https://documentation.wazuh.com/current/user-manual/agent/agent-installation/windows/windows-agent-package.html - Windows agent installation guide
  • Splunk Enterprise: https://www.splunk.com/en_us/download/splunk-enterprise.html - Download Splunk Enterprise (60-day evaluation)
  • Splunk Universal Forwarder: https://www.splunk.com/en_us/download/universal-forwarder.html - Download Splunk Universal Forwarder
  • Splunk Documentation: https://docs.splunk.com/Documentation/Splunk - Splunk product documentation
  • Graylog Documentation: https://go2docs.graylog.org/ - Graylog official documentation
  • Graylog Installation Guide: https://go2docs.graylog.org/5-2/installing-graylog/install-graylog-on-microsoft-windows.html - Windows installation guide

PowerShell and Automation

  • PowerShell Documentation: https://learn.microsoft.com/powershell/ - Complete PowerShell documentation
  • PowerShell Scripting Guide: https://learn.microsoft.com/powershell/scripting/overview - PowerShell scripting reference
  • Active Directory PowerShell Cmdlets: https://learn.microsoft.com/powershell/module/activedirectory/ - AD management cmdlets