Detect by invariants, not tool names: what attackers cannot change
The scenario is fictional. Sysmon details come from the book. The Sigma rule was validated for syntax only (YAML, required keys, condition references). Many rules read "alert if the process is named (famous attack tool
The scenario is fictional. Sysmon details come from the book. The Sigma rule was validated for syntax only (YAML, required keys, condition references).
Many rules read "alert if the process is named (famous attack tool).exe". The attacker renames the file and the rule is dead.
What you'll learn
- Brittle IOCs vs. robust TTPs
- The question that finds the choke point
- Invariants for lsass, WMI, pass-the-hash, Linux SUID
- A Sigma rule and its validation
The story at a glance
In part 7, svc_update.exe read lsass. A rule keyed to that name catches it once; next time it's winhelper.exe.
The question
What would the attacker have to change to evade this?
If the answer is "rename the file", it's brittle. If it's "change the whole technique", it's robust.
Invariants
-
lsass: target
lsass.exe+ GrantedAccess includingPROCESS_VM_READ(0x1010,0x1410) + source not a known legitimate accessor. -
WMI lateral movement: parent is
WmiPrvSE.exeand child is cmd/powershell. - Pass-the-hash: 4624 type 3 + NTLM + privileged target in a Kerberos-standard environment.
-
Linux SUID: auditd
uid != euidandeuid = 0.
Sigma
title: LSASS access with memory-read rights (non-legitimate source)
id: 6e1b7a52-0000-4c00-9000-lsass-vmread
status: experimental
logsource:
product: windows
category: process_access
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010'
- '0x1410'
- '0x143a'
filter_legit:
SourceImage|startswith: 'C:\Windows\System32\'
condition: selection and not filter_legit
falsepositives:
- EDR / security products (exclude by SourceImage and signature)
level: high
tags:
- attack.credential_access
- attack.t1003.001
Validated: required keys present and every name in condition exists under detection (2/2). This does not prove it catches the event; convert it and test with real data. Keep exclusions narrow (path and signature).
Lifecycle
Check the data source, write one detection, correlate, baseline and suppress, test with attack replays, track ATT&CK coverage, retire stale rules.
Next: why even great rules produce 99% false positives.
Adapted from chapter 31 of my Japanese book on server defense.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.