Authentication Detection & Triage
A controlled authentication lab using Splunk and Python.
The corrected search showed 5 of 5 expected findings.
The problem
Two expected findings were missing from a 64-event synthetic matrix. Both cases depended on failed logins exactly ten minutes before a successful login.
What I changed
Compared the missing cases with the source events, then adjusted the time calculation to include the exact 600-second boundary. The revised output was reviewed in a saved Splunk panel.
What I found
The observed result changed from 3 of 5 to 5 of 5 expected findings. That demonstrates the corrected boundary behavior in this training set; a match is a triage lead rather than proof of account compromise.
How I investigated the discrepancy
I compared the first full-matrix result with the five expected findings, then isolated the exact-boundary and interleaved-user cases. The corrected query calculates an inclusive 600-second window rather than relying on a bucket edge. Reusing the same events and expected output made the comparison meaningful.
Analyst disposition
The repaired rule recovers the expected training signals. A real login investigation would still need MFA/session context, account history and related endpoint activity before deciding whether access was compromised. The public result demonstrates detection debugging, not a confirmed intrusion.
Scope
Synthetic authentication events. Indexed ingestion and alert firing were not verified by the October screenshot alone. A separate November 8 synthetic live confirmation later verified 70 indexed rows and one tracked scheduled alert.
Read the full analyst report on GitHub ↗