Writing Your First SIEM Detection Rules: Brute Force and Lateral Movement

A SIEM with no custom detection rules is a very expensive log archive. Vendor-supplied analytics help, but they do not know your environment — which accounts are service accounts, which subnets are management networks, what "normal" looks like on a Tuesday. The fastest way to make a SIEM earn its license is to build a small set of well-tuned rules against the two attack patterns present in nearly every intrusion: password attacks and lateral movement. Both are detectable with the events from the critical Event ID collection baseline, and both teach the tuning discipline every later rule will need.

Rule design fundamentals

• Write detections as hypotheses, not signatures: "an attacker guessing passwords produces many failures from one source in a short window" is a durable behavior; a specific tool hash is not.
• Express logic portably where possible — Sigma is the vendor-neutral rule format, convertible to Sentinel KQL, Splunk SPL, and Elastic queries. Even if you write natively, Sigma's structure (log source, detection condition, false-positive notes, ATT&CK mapping) is the right documentation template.
• Map every rule to a MITRE ATT&CK technique (brute force: T1110; lateral movement tactic: TA0008). This turns a rule pile into a coverage map with visible gaps.
• Every rule ships with three things: a threshold justification, a known false-positive list, and a response playbook line ("who does what when this fires"). A rule without a response plan is decoration.

Brute force and password spray

• Classic brute force: N failed logons (4625) against one account from one source within M minutes — start around 10 failures in 5 minutes and tune. Include Kerberos pre-auth failures (4771) or your DC coverage misses domain authentication entirely.
• Password spray — the attack MFA-less environments actually get hit with: one source generating failures against many distinct accounts with few attempts each. Detect on distinct-account count (e.g., failures against 15+ accounts from one source in 30 minutes). Spraying is specifically designed to stay under per-account lockout thresholds, so per-account rules never see it.
• Success-after-failure: a 4624 from a source that just generated a failure burst is the highest-priority variant — the guess worked. This correlation should page, not queue.
• Cloud identities need the same coverage: replicate all three patterns against Entra ID sign-in logs, and alert on legacy-authentication successes anywhere — which should be impossible once the legacy auth block is enforced, making any hit either policy drift or an attack.
• Tuning reality: the top false-positive sources are service accounts with stale credentials, NAT gateways concentrating many users behind one IP, and vulnerability scanners performing authenticated scans. Allowlist scanner IPs explicitly; investigate (do not blanket-exclude) misbehaving service accounts — a "noisy service account" is also what a compromised one looks like.

Lateral movement

• Workstation-to-workstation logons: network logons (4624 type 3) or RDP (type 10 / 1149) between client subnets. In a well-run environment this is rare enough to alert on directly — and if your segmentation blocks it at the network layer, the firewall deny logs become a parallel detection source for the same behavior.
• One-to-many fan-out: a single source authenticating to many distinct hosts in a short window (10+ hosts in 10 minutes) — the signature of automated propagation, credential-stuffing tools, and ransomware staging. Exclude your management, patching, and backup servers by name, not by pattern.
• Tiering violations as detections: a 4672 privileged logon on any machine outside the appropriate tier's OU converts your tiering model from policy into a live tripwire. Same logic: Tier 0 account names appearing in 4624 events on workstations should effectively never happen.
• Remote execution artifacts: service installs (7045/4697) and scheduled task creation (4698) on a host shortly after a network logon from another internal host — the PsExec/WMI/schtasks execution pattern. Correlating "logon then persistence artifact within 5 minutes" is a beginner-friendly join with strong signal.
• Credential theft preconditions: these rules assume stolen credentials work broadly — which is why they pair with LAPS (unique local admin passwords kill reuse-based movement) and LSA Protection/Credential Guard (less to steal in the first place). Detection and prevention are the same project viewed from two sides.

The tuning cycle

• Deploy every new rule in audit/silent mode for one to two weeks, review what it would have fired on, tune thresholds and exclusions, then promote to alerting. Never ship a rule straight to paging.
• Track two metrics per rule: fire rate (a rule firing 50 times daily is a dashboard, not an alert) and true-positive rate from analyst dispositions. Prune or fix anything below a defensible signal ratio — alert fatigue is how real intrusions get closed as duplicates.
• Test detections deliberately: generate the behavior yourself (a scripted failed-logon burst, a test PsExec run in a lab OU) and confirm the alert fires end-to-end. Purple-team tooling automates this later; a PowerShell one-liner is enough to start.
• Version-control the rules like code — Sigma files in a repo with review — so tuning history survives analyst turnover.

Six to ten well-tuned rules covering these two behaviors will catch more real intrusions than a hundred untuned vendor analytics — and the threshold-correlation-tuning discipline they teach transfers directly to every detection you build afterward.