CSA (312-39) SOC Simulation Lab
In this scenario, you will investigate a logging visibility gap on a newly provisioned Windows Server. Learn how to verify and configure endpoint telemetry before escalating to network or SIEM engineering teams.
Scenario Context
You are a Tier 2 SOC Analyst responding to an onboarding ticket. A new critical financial application server (SRV-FIN-PRD-01, Windows Server 2022) was deployed in the DMZ yesterday. The Splunk Universal Forwarder is installed and running.
However, when hunting for baseline authentication activity, you notice a complete absence of Windows Event ID 4624 (Successful Logon) and 4625 (Failed Logon) for this specific host in your SIEM.
Security Environment
You pull a quick Splunk search to verify the forwarder's health. The agent is sending logs, but only system-level events (like Service Control Manager events), not security events.
[14:02:11] index=windows host=SRV-FIN-PRD-01 source="WinEventLog:System" | stats count by EventCode
EventCode count
--------- -----
7036 142
7040 12
[14:02:45] index=windows host=SRV-FIN-PRD-01 source="WinEventLog:Security" EventCode IN (4624, 4625)
No results found.
You realize the issue isn't the SIEM agent—the Windows OS itself isn't generating the logs locally.
Question
Expert Insight
1. What is happening?
As a SOC analyst, encountering "missing logs" is a daily occurrence. When an agent is installed but specific event IDs (like 4624/4625) are missing, the most common root cause is that the endpoint's OS has not been instructed to record them. By default, Windows does not log all security events to save disk space and CPU cycles. We must explicitly enable Audit Policies.
2. Why C is correct
The Local Group Policy Editor (gpedit.msc) or the Local Security Policy snap-in (secpol.msc) is the exact feature used to configure Audit Policies on a standalone Windows machine. In an Active Directory environment, this is done via domain-wide Group Policy Objects (GPOs). Here, you define what the OS should audit (e.g., Logon events, Object Access, Privilege Use) and whether to log Successes, Failures, or both.
3. Why the others are wrong
- A. Bitlocker: This is Microsoft's full volume encryption feature. It protects data at rest but has absolutely nothing to do with event log generation.
- B. Windows Firewall: Controls inbound and outbound network traffic. While it can drop packets, it does not dictate the OS's Security Audit settings for things like user logons or process creation.
- D. Windows Defender: This is the native Antivirus/EDR solution. It generates its own alerts (Event ID 1116, etc.) but does not govern the base Windows Security Audit Policy.
4. Real-world SOC Application
Before opening a ticket with the network team regarding firewall rules blocking Splunk traffic, a senior analyst always isolates the fault domain. If you RDP into SRV-FIN-PRD-01, open Event Viewer, and the Security log is empty of 4625s, you immediately know the fix requires a Systems Administrator to update the GPO or Local Security Policy. You save hours of troubleshooting by validating the source first.
MINI LESSON: Validating Audit Policy via CLI
If you are connected to a Windows host via an EDR live terminal or PowerShell remoting, you don't need the GUI Group Policy Editor. You can query the effective audit policy instantly using the built-in auditpol command.
Command to run:
If the output shows "No Auditing" for Logon events, you've found your culprit. You can then request the infrastructure team to push a GPO update to enable "Success and Failure" auditing for that category.
Pro-Tip for ExamRange users: Always ensure "Advanced Audit Policy Configuration" is used rather than legacy policies to prevent policy conflicts on modern Windows servers.
Ready for the next incident?
Enhance your detection engineering and incident response skills.
Explore more CSA simulations