Building a Tier 1 SOC Dashboard in Splunk
Designing an Operational Monitoring Dashboard for Authentication, Endpoint, Network, and Threat Hunting Visibility
Building a SOC Homelab from Scratch: Active Directory, pfSense, Sysmon and Splunk
Designing an Enterprise-Style Security Monitoring Environment for Blue Team Skill Development
Introduction
One of the most effective ways to develop practical SOC analyst skills is to build and operate a realistic lab environment.
While certifications provide theoretical knowledge, a homelab allows you to work directly with operating systems, network services, logging pipelines, endpoint telemetry, SIEM platforms, and troubleshooting scenarios that closely resemble real-world environments.
To strengthen my defensive security skills, I built a small enterprise-style SOC homelab consisting of:
- pfSense firewall
- Active Directory domain controller
- Windows 11 endpoint
- Sysmon endpoint telemetry
- Windows Event Logging
- Splunk Enterprise SIEM
The objective was not simply to deploy these technologies, but to understand how security-relevant events are generated, transported, collected, and analyzed.
The following diagram shows the final architecture.
Architecture Overview
The lab consists of four virtual machines running inside VirtualBox.
Rather than placing all systems inside a single flat network, I divided the environment into multiple security zones connected through pfSense. This design more closely resembles enterprise environments where infrastructure, user endpoints, and security tooling are separated into dedicated network segments.
The lab uses three internal segments:
Traffic between these segments is controlled through pfSense firewall rules, allowing only the communications required for authentication, DNS resolution, log forwarding, and administration.
Hypervisor Platform: VirtualBox
The entire environment runs inside VirtualBox using isolated internal networks.
This approach provides:
- Network segmentation
- Safe malware testing opportunities in the future
- Snapshot capability
- Easy rollback during troubleshooting
- Minimal hardware requirements
Using virtualization also allows rapid rebuilding of systems and experimentation without impacting production devices.
pfSense Firewall: Network Gateway and Traffic Control
The first component deployed was pfSense, which acts as the security boundary for the environment.
Network Interfaces
WAN Interface: Internet connectivity
SERVERS Interface: 192.168.10.0/24
WORKSTATIONS Interface: 192.168.20.0/24
SECURITY Interface: 192.168.30.0/24
Network Configuration
DNS Design
Rather than allowing clients to perform direct DNS resolution, I implemented a layered DNS architecture:
1. Windows clients send DNS requests to Active Directory.
2. Active Directory resolves internal domain records and forwards unknown queries to pfSense.
3. pfSense uses Unbound as a recursive DNS resolver to resolve external domains.
This design mirrors many enterprise environments where Active Directory serves as the primary DNS authority.
Firewall Rules
To enforce this architecture, I created firewall rules that restrict communication between network segments while allowing the services required for normal operation.
Examples include:
- Allow DNS traffic from workstations to Active Directory.
- Allow Kerberos, LDAP, SMB, and RPC traffic required for domain authentication.
- Allow Splunk Universal Forwarders to send telemetry to the Splunk server.
- Allow Active Directory DNS forwarding to pfSense.
- Block unauthorized traffic between segments by default.
This approach follows the principle of least privilege while generating valuable network telemetry for security monitoring.
Network Segmentation
To more closely resemble a real enterprise environment, I separated the lab into multiple security zones using pfSense interfaces and firewall policies.
Rather than allowing unrestricted communication between networks, access is controlled through explicit firewall rules based on business requirements.
Examples include:
- Workstations can access Active Directory services such as DNS, Kerberos, LDAP, SMB, and RPC.
- Windows systems can forward logs to Splunk on the SECURITY network.
- Active Directory can forward DNS requests to pfSense’s Unbound resolver.
- Unnecessary services such as RDP remain blocked by default.
After implementing segmentation, I validated the configuration by testing both allowed and denied communications. SMB traffic required for domain functionality was successfully permitted, while unauthorized services such as RDP were blocked. These denied connections generate firewall telemetry that can be forwarded to Splunk and used during investigation and detection engineering exercises.
Logging
pfSense forwards the following logs to Splunk via Syslog:
- Firewall events
- DNS Resolver events
- DHCP activity
- System logs
This provides valuable network-level visibility alongside endpoint telemetry.
Active Directory Domain Controller: Identity and Authentication Infrastructure
The next component deployed was a Windows Server 2022 domain controller.
Static Configuration
IP Address: 192.168.10.10
Gateway: 192.168.10.1
DNS: 192.168.10.10
The server hosts:
- Active Directory Domain Services
- DNS services
- Authentication infrastructure
DNS Forwarding
The DNS server was configured to forward unresolved requests to pfSense.
This allows the domain controller to remain authoritative for internal records while maintaining internet name resolution.
Active Directory Population
To generate realistic directory activity, I used the BadBlood PowerShell project to create:
- Users
- Groups
- Organizational Units
- Service accounts
- Delegation scenarios
This creates a more realistic environment for security monitoring and investigation exercises than an empty domain.
Advanced Audit Policy
To improve security visibility, I enabled advanced Windows auditing for key authentication and directory events.
Examples include:
- Logon Success and Failure
- Logoff Events
- Kerberos Authentication Service Events
- Kerberos Service Ticket Events
- Directory Service Access Events
- File Share auditing
These logs generate valuable telemetry for detecting authentication anomalies and account misuse.
Sysmon Deployment
Sysmon was installed using Olaf Hartong’s modular configuration.
This significantly expands endpoint visibility beyond native Windows logging by capturing:
- Process creation
- Network connections
- Registry modifications
- Driver loads
- File creation events
- PowerShell activity
Windows 11 Workstation: User Endpoint Simulation
To simulate a standard enterprise endpoint, I deployed a Windows 11 Pro workstation and joined it to the Active Directory domain.
Static Configuration
IP Address: 192.168.20.10
Gateway: 192.168.20.1
DNS: 192.168.10.10
Endpoint Visibility
The workstation was configured with:
- Sysmon
- PowerShell Logging
- Windows Event Logging
- Splunk Universal Forwarder
This endpoint generates realistic user activity that can be monitored and investigated through Splunk.
Examples include:
- Interactive logons
- PowerShell execution
- Process creation
- DNS queries
- Network connections
- Authentication events
Splunk Enterprise SIEM: Centralized Log Collection and Analysis
The final component deployed was a dedicated Debian 12 server running Splunk Enterprise.
Static Configuration
IP Address: 192.168.30.10
Gateway: 192.168.30.1
DNS: 192.168.10.10
Why Debian?
I chose Debian because it provides:
- Stability
- Long-term support
- Low resource consumption
- Excellent compatibility with Splunk
To minimize resource usage, I installed a headless version without a graphical interface.
Log Sources
Splunk receives telemetry from multiple sources:
Data Flow
The resulting telemetry pipeline is:
Endpoint Activity → Windows Logs / Sysmon → Splunk Forwarders → Splunk
Network Activity → pfSense Syslog → Splunk
This creates a centralized platform for searching, correlating, and investigating security events.
Splunk Universal Forwarders: Endpoint Log Collection
Collecting logs is one of the most important aspects of any SOC environment. To centralize telemetry from the Windows systems, I deployed Splunk Universal Forwarders on both the Active Directory server and the Windows 11 workstation.
The forwarders were configured to send security-relevant event data to the Splunk Enterprise instance running on the Debian server.
Collected Log Sources
The following Windows Event Log channels were configured for collection:
- Security
- System
- Application
- Sysmon Operational
- PowerShell Operational
To achieve this, I configured the appropriate inputs through the inputs.conf file on each endpoint.
Why Collect These Logs?
Each log source contributes a different perspective during investigations:
While native Windows logs provide valuable information, Sysmon significantly expands endpoint visibility and enables more detailed investigations and detections.
Telemetry Flow
The resulting data flow is straightforward:
Windows Endpoint → Splunk Universal Forwarder → Splunk Enterprise
This architecture ensures that endpoint activity is centralized within the SIEM, allowing events from multiple systems to be searched, correlated, and investigated from a single location.
Key Design Decisions
Several design decisions were intentionally made to improve visibility and mimic enterprise environments.
Centralized Authentication
Active Directory serves as the authentication authority for all domain resources.
Controlled DNS Resolution
All DNS traffic is forced through Active Directory and pfSense.
Layered Logging
Both network and endpoint telemetry are collected.
Centralized SIEM
All logs are aggregated into Splunk for correlation and investigation.
Network Segmentation and Least Privilege
Systems are separated into dedicated network zones for servers, workstations, and security tooling. Communication between segments is restricted through pfSense firewall rules that allow only the services required for business functionality.
This design follows the principle of least privilege and creates opportunities to monitor both allowed and denied traffic. Because firewall events are forwarded to Splunk, the environment can be used to investigate blocked connections, validate access controls, and develop detections based on network policy violations.
Realistic Active Directory Environment
BadBlood introduces realistic directory complexity that supports threat hunting and detection exercises.
What This Lab Enables
With the foundation complete, the environment now supports:
- SOC analyst investigations
- Detection engineering exercises
- Threat hunting
- Windows event analysis
- Authentication monitoring
- Active Directory security testing
- Network segmentation monitoring
- Firewall log analysis
- Access control validation
- Splunk dashboard creation
- Incident response simulations
Most importantly, it provides hands-on experience troubleshooting the kinds of issues that frequently appear in real enterprise environments.
Conclusion
Building this SOC homelab provided significantly more practical learning than simply studying technologies in isolation.
Beyond deploying the infrastructure itself, the project required understanding how authentication, DNS resolution, endpoint telemetry, logging pipelines, SIEM platforms, network segmentation, and firewall policy design interact within a security monitoring environment.
The completed lab now serves as a foundation for future projects involving detection engineering, threat hunting, attack simulation, and security monitoring workflows.
In the next article, I will cover the challenges encountered during deployment, including log ingestion problems, Sysmon collection issues, DNS troubleshooting, firewall misconfigurations, network segmentation challenges, and time synchronization issues across the environment.
