Detection Engineering & Rule Development
Build detections that explain the behavior they match—and the benign activity they can confuse.
Public authentication validation: 64 events · nine scenarios · five expected findings. Corrected Splunk output matches all five.
The investigation problem
A rule that matches a suspicious command or a login burst is a starting point. Its value depends on the behavior it is intended to detect, the data it needs and the legitimate activity that can produce the same pattern.
What I validated
I investigated why an authentication search returned three of five expected findings on a frozen 64-event training matrix. Both misses depended on the exact ten-minute boundary. I replaced the window assumption with an explicit inclusive 600-second comparison; the corrected query and saved Splunk panel displayed all five expected findings.
The result measures agreement with this fixture’s expected findings. It is not a false-positive reduction, a precision/recall estimate or evidence of production detection performance. The source events, expected results and observed-result record ↗ are available for inspection.
Inspect the rule. Challenge the window.
A replay of the committed public authentication fixture. JavaScript evaluates these events locally; Splunk does not run in this page.
Five preceding failures in the same account/IP stream qualify at the exact ten-minute boundary.
Boundary decision
0 ≤ success_time − failure_time ≤ 600 seconds. At least five qualifying failures are required.
Five qualifying failures → investigate. Compromise is not established.
Inspect the actual SPL and validation
64 source events · nine scenarios · five expected findings.
| eval eligible_ages=mvfilter(isnotnull(age_seconds) AND age_seconds>=0 AND age_seconds<=600)
| where event_type="login_success" AND recent_failures>=5Compare the Python implementation
See the linked Python source for the inclusive-window reference implementation.The original saved result returned 3/5 expected findings; the corrected search returned 5/5 on the same training set. The browser replay above is a separate local evaluation, not a new Splunk observation.
Canonical CSV SHA-256: 84ca7b35537c724c06dd8c8dc67dfafa0bd13a6e4079b216f7e71c4fd8568a03
The telemetry contract
The rule needs a valid UTC timestamp, username, source IP, host context, and a failure/success event type. It groups by username and source IP; the host is displayed as context. Every success closes that stream’s failure streak, even if no finding is produced. Events are ordered by timestamp, preserving source order on ties in this public fixture.
The browser rejects missing required fields and malformed times. In an operational pipeline, parser coverage, clock skew, duplicates, late arrival, and retention would need their own verification. A correct query cannot recover telemetry that was never collected.
Why the correction matters
A bucket edge can split related events. The corrected SPL calculates each preceding failure’s age at a successful login and explicitly includes the 600-second boundary. Interleaved accounts remain separate; failures from a different source IP cannot complete another stream’s threshold.
The minimum count is a triage heuristic. Raising it can reduce noise while missing slower attempts. A successful login after repeated failures can also be a legitimate user recovering access. MFA outcome, session history, account sensitivity, and related endpoint events determine the next investigation step.
Beyond authentication
Investigate recorded Active Directory telemetry ↗: my independent analysis adds tested distinct-account, RC4-ticket and remote-process candidates with exact source references, host/logon/GUID joins and packet corroboration.
Encoded PowerShell and Windows triage ↗: inspect command lines, process context, and competing administration explanations. Encoding alone does not establish malicious execution. Packet analysis ↗ adds DNS and HTTP observations with explicit evidence limits.
The AD Python analysis is executed and source-linked. Its SPL and Sigma translations are unexecuted candidates; they are not equivalent to the complete host/session/network correlation.
Inspect the existing rules and controls
- Authentication correlation
- At least five preceding failures in the same account/IP stream, with ages from zero through 600 seconds. Every success resets the streak. Corrected SPL · Python boundary and isolation tests ↗
- Windows command candidates
- PowerShell encoded-command flags and certutil URL-cache/force flags are separate review predicates, not malware verdicts. Rule source ↗ · Benign and flag-boundary controls ↗
- Recorded AD correlation
- Distinct-account failures, RC4 service tickets and remote PowerShell retain exact source references and alternative explanations. Conditions and evidence joins ↗ · Isolation and missing-corroboration tests ↗
Open the rule-to-evidence matrix ↗ for input, implementation, verification and remaining gaps.
Earlier résumé lab work and its supporting evidence
My résumé reports more than five SPL/Sigma rules for brute force, encoded PowerShell and lateral movement, and approximately 30% fewer false positives during lab validation. The original rule collection and before/after event sets are not published here. Reproducing that result requires the original rules, labeled inputs, false-positive counts and denominators, matching criteria and tuning procedure. The public authentication and AD examples have their own inputs and results; they do not substantiate that earlier percentage.
Academic foundation
Completed coursework: IST 4210 Advanced Networking & Security and IST 5250 Incident Handling & Cyber Investigation (Fall 2024).
Scope and evidence
The authentication case uses synthetic inputs and a genuine screenshot-reviewed Splunk result. The AD case separately analyzes OTRF recorded emulation in Python. Earlier résumé lab claims retain their original scope in the note above. Indexed ingestion, scheduled alert firing and production detection efficacy remain unverified.
Background reference
MITRE ATT&CK: brute-force behavior ↗. This reference informs the investigation approach; it does not verify my lab results.