Attack to detection

The three rules we run for this technique all name a tool

technique T1518.001lab capture 2026-09-13ran as NT AUTHORITY\SYSTEM

What we ran, and what the rules saw

5 routes to the same outcome3 rules read as text1 matched

Not alert results. Rule text read against captured telemetry. No connector in that lab: nothing alerted, and nothing could.

Routeran as NT AUTHORITY\SYSTEMRule text · SigmaHQproc_creation_win_findstr_security_keyword_lookupImage ends \find.exe or \findstr.exe and the command line carries a listed keywordRule text · SigmaHQposh_ps_get_process_security_software_discoverya script block carrying a get-process | where pattern, a property test and a listed keywordRule text · SigmaHQproc_creation_win_wmic_recon_product_classImage ends \wmic.exe and the command line carries a listed keyword
01tasklist | findstr /i defendercoveredcmd /c "tasklist | findstr /i defender"matchedBoth selections of the rule are satisfied by this eventno match0 of 52 script-block events in the capture carry the get-process | where pattern the rule needsno eventno wmic.exe process ran in this window (recorded: findstr.exe, tasklist.exe, cmd.exe)
02findstr /i defender <file>gap - endswith anchorcmd /c "tasklist > %TEMP%\\CyRaySOCTest-plist.txt" ; cmd /c "findstr /i defender %TEMP%\\CyRaySOCTest-plist.txt"no matchThe gap is ARGUMENT ORDER: findstr takes the file as a trailing positional argument, so the Sysmon CommandLine 'findstr /i defender "C:\WINDOWS\TEMP\CyRaySOCTest-plist.txt"' ends with the file path, not the keywordno match0 of 52 script-block events in the capture carry the get-process | where pattern the rule needsno eventno wmic.exe process ran in this window (recorded: findstr.exe, cmd.exe, tasklist.exe)
03wmic AntiVirusProductcovered rule, tool removed from OSwmic /Namespace:\\root\\SecurityCenter2 Path AntiVirusProduct Get displayName /Format:Listno eventno process at all was created in this window; find.exe / findstr.exe never ranno match0 of 52 script-block events in the capture carry the get-process | where pattern the rule needsno eventno process at all was created in this window; wmic.exe never ran
04Get-CimInstance SecurityCenter2gap - API routeGet-CimInstance -Namespace 'root/SecurityCenter2' -ClassName 'AntiVirusProduct'no eventno process at all was created in this window; find.exe / findstr.exe never ranno matchscript-block logging was on and recorded it; 0 of 52 script-block events carry the get-process | where pattern the rule needsno eventno process at all was created in this window; wmic.exe never ran
05Get-MpComputerStatusgap - API route (working outcome)Get-MpComputerStatusno eventno process at all was created in this window; find.exe / findstr.exe never ranno matchscript-block logging was on and recorded it; 0 of 52 script-block events carry the get-process | where pattern the rule needsno eventno process at all was created in this window; wmic.exe never ran
matchedthe event exists and satisfies every selection the rule requiresno matchthe event exists; the rule’s selection logic does not match itno eventnothing was recorded for the rule to read

lab capture 2026-09-13 19:33 UTC · a CyRay lab workstation · Sysmon process creation, Security process auditing, PowerShell script-block logging · imported unchanged, sha256 dcb9289f89bc

The lesson

A detection anchored to a tool is a detection of that tool. The behaviour outlives the tool.

Worth doing Monday

Worth doing Monday: run where wmic on your own fleet. Then read your own discovery rules and count how many name a program rather than an act.

How it happened

We watch security software discovery — an intruder asking which security product is on the box — with three rules. They are public Sigma rules and we run them, so this is our coverage missing.

Each of the three names a tool. So we ran the same reconnaissance five ways on a lab machine we own, and read the telemetry against each rule's selection logic.

tasklist | findstr /i defender matched. findstr.exe ran, the command line ends in the keyword, both halves of the rule satisfied.

Same tool, same keyword, same intent: findstr /i defender <file>. The rule matches a command line that ENDS in the keyword. Put the file last, as findstr's syntax invites, and the line ends in a path. No match.

Then the wmic route, which we do have a rule for. This box has no wmic.exe — where wmic answered "Could not find files" on Windows 11 build 10.0.26100, and no process was recorded at all. A rule anchored to a binary the OS is shipping out has nothing left to match.

Then two PowerShell routes, both in-process, both spawning no child process. Get-CimInstance -Namespace root/SecurityCenter2 returned zero rows here — it learned nothing. Get-MpComputerStatus answered the attacker's real question: AMProductVersion : 4.18.23110.3, AntivirusEnabled : True. Two of our rules key on findstr.exe or wmic.exe, so neither had an event. The third is a PowerShell rule, and Script Block Logging was on: three script-block events in that window name SecurityCenter2. It missed anyway, because it looks for a get-process | where shape and neither command is one. The miss is the pattern, not the logging. That distinction decides whether you fix a rule or turn logging on.

No connector is installed in that lab. Nothing alerted and nothing could — this is rule text read against captured telemetry, not a console we watched.

A detection anchored to a tool is a detection of that tool. The behaviour outlives the tool.

Worth doing Monday: run where wmic on your own fleet. Then read your own discovery rules and count how many name a program rather than an act.

Run this against your SOC

The same move, T1518.001, as a safe test you can run on a machine you own - then look at your alerts.