CSA (312-39) SOC Simulation Lab
Scenario Context
During a proactive threat hunt, your L3 team discovers an active C2 (Command and Control) beacon originating from the workstation of a senior finance executive. Reviewing the SIEM logs, you realize the initial compromise occurred two weeks ago via a compromised Active Directory account.
The SOC relies on a static correlation rule: Detect >= 10 Failed Logons (EventID 4625) within 5 minutes. The threat actor deliberately throttled their brute-force attempts, successfully guessing the password on the 9th attempt. Because the threshold was not breached, the SIEM generated no alerts, and the L1 team was completely blind to the intrusion.
Security Environment
Review the retrospective Splunk query executed during the incident response phase that uncovered the attacker's methodology:
Context: The attacker carefully profiled the standard SOC defenses. Tools like Hydra or TrevorSpray allow attackers to define deliberate delays (jitter) or stop exactly at account lockout/alert thresholds to maintain stealth.
Question
An attacker attempts to gain unauthorized access to a secure network by repeatedly guessing login credentials. The SIEM is configured to generate an alert after detecting 10 consecutive failed login attempts within a short timeframe. However, the attacker successfully logs in on the 9th attempt, just before the threshold is reached, bypassing the alert mechanism. Security teams only become aware of the incident after detecting suspicious activity post-login, highlighting a gap in the SIEM's detection rules. What type of alert classification does this represent?
Expert Insight
1. What is happening
The SOC is facing a detection failure caused by rigid, static threshold rules. Attackers know that most SIEMs are configured with out-of-the-box alerting thresholds (e.g., 5, 10, or 20 failed logins). By slowing down their brute force or password spray attacks ("low and slow"), they avoid triggering the SIEM while still eventually cracking the credential.
2. Why the correct answer is correct
D. False Negative is correct. A False Negative occurs when a malicious event actually takes place, but the security control (the SIEM) fails to detect or alert on it. In this scenario, the attack was real, but the SIEM remained silent (a negative alert state). That silence was incorrect (false).
3. Why the other options are wrong
- True Positive (A): An attack happened, and the SIEM correctly fired an alert. (Did not happen here).
- True Negative (B): Normal user activity occurred, and the SIEM correctly stayed quiet. (The activity was not normal).
- False Positive (C): Normal user activity occurred, but the SIEM wrongly fired an alert (e.g., a user forgot their password and triggered the brute force alert). Alert fatigue is caused by high volumes of False Positives.
MINI LESSON: Evolving Beyond Static Thresholds
As a senior analyst, your job is to fix the gap that allowed this False Negative. Relying solely on `count > X` is a legacy approach. Modern SOCs upgrade to Behavioral Analytics (UEBA) and stateful correlation:
- Success After Failure: Instead of alerting on *just* 10 failures, write a rule that alerts on `N` failures followed immediately by a successful login (`EventID 4624`) from the same IP or ASN.
- First-Time Seen: Correlate the successful login against a baseline. Is this the first time this user has logged in from this geolocation or ISP?
- Impossible Travel: Detect if the successful login originates from an IP address that physically contradicts the user's last known location (e.g., VPN login from Russia 30 minutes after an office badge-in in New York).
Ready to master more real-world SOC concepts?
Explore more CSA simulations