7 SIEM Rules That Actually Catch Lateral Movement (Splunk, Elastic, Sigma)

Last updated: April 26, 2026

Lateral movement is where most ransomware breaches turn from “incident” into “everything is encrypted by Sunday.” Yet most enterprise SOC use-case libraries still rely on Microsoft’s default audit policy events with no contextual tuning. This article gives you seven specific, tunable SIEM rules that catch lateral movement in 2026 — written for Splunk, Elastic, and Sigma. Each comes with the technique it detects, the tuning hint, and the false-positive escape hatch.

Why this matters

Average dwell time before detection in Indian enterprise environments we audit: 14 to 42 days. Most of that time is spent moving laterally — service-to-service, host-to-host, tier-to-tier. The attacker is not new to the environment; they are exploring it. Detection at the lateral-movement stage cuts breach impact by 80% or more compared to detection at the data-exfil stage.

The good news: lateral movement is mechanically distinct from normal user activity. Most users do not run psexec, do not query 200 SPNs in 10 minutes, do not authenticate from a workstation to ten other workstations in sequence. The patterns are detectable.

Rule 1: WMI / WinRM execution from non-admin source

Technique: T1021.006 (Windows Remote Management).

WMI and WinRM are Microsoft’s blessed remote-execution paths. Attackers love them because they look administrative; defenders ignore them because they are administrative. The signal is the source.

Sigma:
title: WMI/WinRM Remote Execution from Non-Admin Source
detection:
  selection:
    EventID: [4688, 1]
    Image|endswith: ['\wmiprvse.exe', '\wsmprovhost.exe']
    ParentImage|endswith: ['\svchost.exe']
  filter:
    User|contains: ['admin', 'sysadmin', 'jenkins-svc']
  condition: selection and not filter

Tuning: carve out your known administrative source workstations and service accounts that legitimately use WinRM (Ansible, Octopus Deploy, Tanium). What remains is suspicious by definition.

Rule 2: Impacket-style PSExec sequence

Technique: T1021.002 (SMB/Windows Admin Shares) via Impacket.

Impacket’s psexec.py writes a unique service-binary filename pattern. The detection is high-fidelity because legitimate services do not name themselves like this.

Splunk:
index=wineventlog (EventCode=4697 OR EventCode=7045)
| regex Service_File_Name="\\\\[A-Z0-9]{8}\\.exe$"
| stats count by Computer, Service_File_Name, Service_Account, _time

Pattern: 8-character random alphanumeric service name. Real services have descriptive names. This rule has near-zero false positives in well-managed environments.

Rule 3: Anomalous SMB write to ADMIN$

Technique: T1021.002 (SMB/Windows Admin Shares).

Most lateral execution writes a payload to \\target\ADMIN$ before invoking it. Workstations writing to ADMIN$ on other workstations is rare; admins doing so from PAWs is normal. The signal is the source-target pair.

Sigma:
title: SMB Write to ADMIN$ from Workstation
detection:
  selection:
    EventID: 5145
    ShareName: '\\*\ADMIN$'
    AccessMask|contains: 'WriteData'
  filter_known_admins:
    SourceWorkstation|startswith: ['PAW-', 'JUMPHOST-', 'SCCM-']
  condition: selection and not filter_known_admins

Tuning: identify your privileged access workstations and management hosts; carve them out. The remaining hits are workstation-to-workstation lateral writes.

Rule 4: Kerberos service-ticket request burst (Kerberoasting)

Technique: T1558.003.

One user requesting many service tickets in a short window is a Kerberoasting fingerprint.

Splunk:
index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17
| bucket _time span=5m
| stats dc(Service_Name) AS unique_spns by Account_Name, _time
| where unique_spns > 10

Tuning: legitimate service ticket activity from build servers and orchestration tools can hit higher counts. Whitelist by Account_Name. Use the encryption-type filter (RC4 = 0x17) to bias toward attacker-tooled requests.

Rule 5: AS-REP Roasting attempts (Event 4768)

Technique: T1558.004.

The AS-REP attack queries TGTs for accounts with DONT_REQ_PREAUTH set. The query is itself a fingerprint — the typical user does not query AS-REP for arbitrary accounts.

Sigma:
title: Multiple AS-REP Requests for DONT_REQ_PREAUTH Accounts
detection:
  selection:
    EventID: 4768
    PreAuthType: 0
  condition: selection
  count by SourceIP: > 5
  timeframe: 5m

Tuning: in healthy environments, the count of PreAuthType=0 events should be near zero. Any volume spike is suspicious.

Rule 6: Credential extraction via LSASS access

Technique: T1003.001 (LSASS Memory).

Sysmon Event 10 logs process access. Mimikatz and equivalents request specific access masks against LSASS that legitimate processes rarely match.

Sigma:
title: Suspicious Process Access to LSASS
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess: ['0x1010', '0x1410', '0x143a', '0x1438', '0x1f0fff', '0x1fffff']
  filter:
    SourceImage|endswith:
      - '\MsMpEng.exe'      # Defender
      - '\NisSrv.exe'       # Defender
      - '\smss.exe'
      - '\wininit.exe'
      - '\csrss.exe'
      - '\services.exe'
      - '\svchost.exe'
  condition: selection and not filter

Tuning: the GrantedAccess masks listed are Mimikatz/Pypykatz signatures. Legitimate AV/EDR processes are filtered. Remaining hits are high-fidelity credential-extraction attempts.

Rule 7: Successful logon from unusual source for the account

Technique: T1078 (Valid Accounts).

Behaviour-based, not signature-based. A user account that always logs in from HR-WS-* suddenly logging in from FINANCE-WS-* is suspicious — even if the password was correct. Build a per-account baseline; alert on outliers.

Splunk:
| tstats count WHERE index=wineventlog EventCode=4624 LogonType IN (3, 10) BY user, ComputerName, _time SPAN=1d
| eventstats count(eval(if(_time < relative_time(now(), "-30d@d"), 1, 0))) AS historical_count BY user, ComputerName
| where historical_count == 0
| where _time >= relative_time(now(), "-1d@d")
| stats count by user, ComputerName, _time

This rule needs a 30-day baseline before it is useful. Tuning: many legitimate cases (new laptops, role changes) generate false positives initially. Tune by aggregating to an organisational unit, not individual host, until your data quality matures.

How to deploy these

1. Validate one rule at a time. Pick the highest-fidelity (Rule 2 — Impacket pattern is best). Tune until false-positive rate is under 1 per week. Then move to the next.
2. Test each rule in a controlled lab. Run the actual attack technique against a target host with the rule deployed. Verify the alert fires. Document the test in a runbook.
3. Tag every alert with MITRE ATT&CK technique IDs. Long-term, this lets you build coverage maps and identify gaps.
4. Build playbooks per rule. When the rule fires at 2am, the on-call engineer needs to know exactly what to check next. Each rule deserves its own one-page response runbook.

How to find your next detection gap

Map your existing SIEM use-cases against the MITRE ATT&CK enterprise matrix. Specifically the Lateral Movement (TA0008) and Credential Access (TA0006) tactics. Where you have zero rules covering a technique, that is a gap. The published purple-team frameworks (Atomic Red Team, Caldera) let you safely run each technique and verify whether your SIEM sees it.

If the SIEM does not alert on a technique, either the data source is missing (Sysmon not deployed, network logs not captured) or the rule does not exist. Both gaps are addressable.

Compliance angle

• SEBI CSCRF explicitly requires MITRE ATT&CK-aligned detection use-cases for Q-RE and MII categories.
• RBI Cyber Framework expects monitoring with documented use-cases and metrics on detection efficacy.
• ISO 27001:2022 A.5.7 (Threat Intelligence) and A.8.16 (Monitoring Activities) are operationalised through these detection rules.

The takeaway

Lateral movement detection is not a vendor problem to solve. It is a use-case engineering problem to solve. The rules above are not novel; they have been published in countless open Sigma repos. The reason most SOCs do not detect lateral movement reliably is that nobody has written the rules into their specific SIEM, tuned them against their specific environment, and validated them against actual attack tooling. The work is operational, not technical. The first rule you deploy and tune well will outperform every product feature your vendor has ever pitched you.