1 Install Splunk & Universal Forwarders
Build SPLUNK01 and install Splunk Enterprise for learning purposes using an appropriate current evaluation or free licensing option. Splunk's documentation continues to support on-premises Splunk Enterprise and Universal Forwarders across supported Windows and Linux environments — and notes that indexing can be storage-I/O intensive, worth remembering when Splunk is sharing a host with a dozen other VMs. Learn indexer, search head, forwarder, source, sourcetype, index, and event; in a small lab, one Splunk VM covers all of these roles, no separate servers required.
Install Splunk Universal Forwarder on DC01, WIN11-01, LINUX01 and DB01, and send their logs to SPLUNK01. Now you can search centralised logs from multiple machines in one place — the entire point being that engineers shouldn't need to manually log into 500 servers to investigate 500 individual log files. Centralised logging is what makes correlating events across systems possible at all (Module 14 covers this principle in depth).
2 Splunk Searches
Start simple: index=windows, then narrow to index=windows EventCode=4625 to investigate failed Windows logins, and EventCode=4624 for successful ones. Pull username, hostname, source IP, timestamp and authentication type out of the results, and build simple dashboards for failed authentications, successful authentications, top users, top systems, and authentication trends over time — the exact kind of dashboard a SOC analyst would actually keep open.
3 Microsoft Sentinel & KQL
Gain exposure to a cloud-native SIEM too. Microsoft Sentinel provides security analytics, threat detection, hunting and response within Microsoft's security ecosystem — create an Azure environment using an appropriate learning subscription or sandbox and learn Log Analytics Workspace, Microsoft Sentinel, data connectors, analytics rules, incidents, entities, workbooks, automation, and hunting. Cost management is essential with cloud services: understand pricing, control data ingestion, use budgets, and remove resources after each lab session so nothing expensive keeps running unattended.
Microsoft Sentinel uses Kusto Query Language (KQL). Start with:
SecurityEvent
| where EventID == 4625Then count failed logins by account:
SecurityEvent
| where EventID == 4625
| summarize FailedLogins=count() by AccountFrom there, investigate who, when, from where, how often, and on which machine — this is a natural bridge straight into SOC analyst skills (Module 11 builds on exactly this).
4 Kali Linux & Vulnerable Machines
Build KALI01 inside the isolated security network from Lesson 1 — its job is to give you legitimate exposure to security testing tools in an environment you fully control. Useful tool categories include network discovery, packet analysis, web application testing, DNS investigation, TLS investigation, and vulnerability validation. These tools must only ever be used against systems you own or have explicit authorisation to test.
The lab becomes considerably more useful once it includes deliberately vulnerable targets — purpose-built educational systems such as Metasploitable, OWASP Juice Shop, or DVWA, kept isolated from production, corporate and household networks (KALI01 → SECURITY NETWORK → VULN01). Use VM snapshots so you can reset vulnerable machines frequently.
OWASP Juice Shop is particularly useful because it lets you combine Docker, web technologies, HTTP, authentication, application security, logging, and SIEM in one exercise — run it in Docker, feed its application logs into Splunk, and now application activity is centrally monitored, exactly like a real deployment.
5 Packet Capture & Logging Architecture
Install Wireshark on an appropriate monitoring workstation and capture traffic involving DNS, DHCP, HTTP, TLS, Kerberos, SMB, and LDAP. The goal is recognising protocols, not memorising packet structures — useful display filters include dns, http, kerberos, and tcp.port == 443. Notice how modern TLS protects application payloads while metadata like source and destination addresses stays visible.
By this point your environment produces a real spread of logs — authentication, system, application, firewall, database, web server, and security logs, all flowing from Domain Controller, Windows client, Linux server, database and firewall into the SIEM. This is the same logging architecture Module 14 teaches, now actually running under your own infrastructure instead of as sample data.
6 A Failed Login Investigation
Generate several failed authentication attempts using a lab account, then investigate for real. Windows Event Viewer may show the relevant events directly; Splunk should reveal them under EventCode=4625; Sentinel would query the equivalent Windows security events. Ask: which account failed, which computer generated the request, what time it occurred, how many attempts happened, whether there was a successful login afterwards, and whether the source was expected.
The emphasis throughout is investigation, not knee-jerk alarm — not every failed login is an attack, and jumping straight to "we've been breached" on the first 4625 event is exactly the kind of overreaction Module 17's security-communication guidance warns against.