Test your SOC · about a minute

Can your SOC see someone checking what is watching them?

One real attacker move, a safe way to run it on a machine you own, and the detection that closes the gap — in that order, so you leave with better coverage than you arrived with.

technique T1518.001 · Security Software Discoveryseen in MuddyWaterwhere any Windows box

What our lab saw →

What this is about

Can your SOC see an attacker looking for your security agent?

Before an intruder does anything noisy, they check who is watching. The cheapest way is to list the running processes and filter that list for the names of security products. If the filter comes back empty, the next steps get bolder; if it finds an agent, the plan changes.

The detection is the neat part: it does not care about the process list, it cares about the keyword. Filtering anything for the name of a security vendor is a question almost nobody legitimate asks at a command line, which makes it a rare and high-quality signal.

The detection watches one thing: a process list being filtered for the name of a security product.

This is not hypothetical

The group tracked as MuddyWater is documented performing security software discovery on the machines it reaches. It is the reconnaissance step that decides whether the intrusion stays quiet or gets aggressive, and it happens before anything worth alerting on has been attempted.

One built-in listing, one built-in filter, no admin rights. The same line you are about to run — the only question is whether looking for the guard is itself noticed.

The actor above is named in MITRE ATT&CK’s own Procedure Examples for this technique; the link is where you can read it. Nothing on this page discloses a move an attacker does not already have — it just makes sure the defender has it too.

Sources · MITRE ATT&CK T1518.001

They check before they act

This is the step that decides how careful an intruder needs to be. Seeing it means seeing them plan, not react.

The keyword is the catch

Almost nothing legitimate greps a process list for a security product's name. That makes this one of the low-noise detections worth having.

It costs them nothing

No file, no rights, no exploit — two built-ins and a pipe. Cheap for them is exactly why it must not be cheap for you to miss.

The test

Run the real thing. Safely. On a box you own.

Ask the same question an intruder asks about your agent, then open your alerts.

Filter the process list for a security product

Run tasklist piped into findstr looking for a security-product keyword. This is the moment your SOC should notice someone asking who is watching.

Note what the answer would tell them

A hit tells an attacker which agent to work around. Silence tells them the box is unguarded. Either way they now know more than you do about your own coverage.

Check your alerts

Open your SOC or EDR. Did security software discovery fire — or did someone case your defences unnoticed?

test-your-soc-security-software-discovery.ps1 · PowerShell · a machine you own

# test-your-soc-security-software-discovery.ps1 — run on a machine you own.
# Safe: read-only. Lists processes and filters the text. Nothing is changed, nothing to undo.
# STEP 1 - look for the security agent by name, the way an intruder checks what is watching.
cmd /c "tasklist | findstr /i defender"
# STEP 2 - open your SOC / EDR. Did security software discovery alert?

The line lists the running processes and filters that text for a keyword. It touches no security product, changes no setting and disables nothing — it only looks. Nothing is created, changed or deleted, and no admin rights are needed.

Reading the result — honestly

Something fired

Your tooling watches for its own name being looked for

Good — you would see an intruder casing your defences before testing them. On to the next one.

Silence

The check for your agent went unseen — now you know

Not a verdict on your team; a specific, fixable gap you just found in a minute. The detection below closes it.

Straight with you: we never see your alerts — you’re the judge, which is also why we never touch your data. And a lab isn’t production; a test box often logs differently than the real fleet. "It fired" means your EDR flagged the security-product keyword on the command line — note that the rule matches a list of vendor keywords, so a name outside that list, or a lookup made through an API rather than a filter, is a quieter path worth extending the rule for. Treat a pass as a reason to go check prod, not a finish line.

How to catch it

Missed it? Here’s the fix — take it straight to your SOC.

The logic is public and every major SIEM already supports it. Here it is in Sigma, the open, vendor-neutral format your team can translate into whatever you run.

proc_creation_win_findstr_security_keyword_lookup.yml

title: Security Tools Keyword Lookup Via Findstr.EXE
id: 4fe074b4-b833-4081-8f24-7dcfeca72b42
related:
    - id: fe63010f-8823-4864-a96b-a7b4a0f7b929
      type: derived
status: test
description: |
    Detects execution of "findstr" to search for common names of security tools. Attackers often pipe the results of recon commands such as "tasklist" or "whoami" to "findstr" in order to filter out the results.
    This detection focuses on the keywords that the attacker might use as a filter.
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/987e3ca988ae3cff4b9f6e388c139c05bf44bbb8/atomics/T1518.001/T1518.001.md#atomic-test-1---security-software-discovery
    - https://www.microsoft.com/en-us/security/blog/2023/10/18/multiple-north-korean-threat-actors-exploiting-the-teamcity-cve-2023-42793-vulnerability/
    - https://www.hhs.gov/sites/default/files/manage-engine-vulnerability-sector-alert-tlpclear.pdf
author: Nasreddine Bencherchali (Nextron Systems), frack113
date: 2023-10-20
modified: 2023-11-14
tags:
    - attack.discovery
    - attack.t1518.001
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith:
              - '\find.exe'
              - '\findstr.exe'
        - OriginalFileName:
              - 'FIND.EXE'
              - 'FINDSTR.EXE'
    selection_cli:
        CommandLine|endswith:
            # Note: Add additional keywords to increase and enhance coverage
            # Note:
            #   We use the double quote variation because in cases of where the command is executed through cmd for example:
            #       cmd /c "tasklist | findstr virus"
            #   Logging utilties such as Sysmon would capture the end quote as part of findstr execution
            - ' avira'
            - ' avira"'
            - ' cb'
            - ' cb"'
            - ' cylance'
            - ' cylance"'
            - ' defender'
            - ' defender"'
            - ' kaspersky'
            - ' kaspersky"'
            - ' kes'
            - ' kes"'
            - ' mc'
            - ' mc"'
            - ' sec'
            - ' sec"'
            - ' sentinel'
            - ' sentinel"'
            - ' symantec'
            - ' symantec"'
            - ' virus'
            - ' virus"'
    condition: all of selection_*
falsepositives:
    - Unknown
level: medium
regression_tests_path: regression_data/rules/windows/process_creation/proc_creation_win_findstr_security_keyword_lookup/info.yml
simulation:
    - type: atomic-red-team
      name: Security Software Discovery
      technique: T1518.001
      atomic_guid: f92a380f-ced9-491f-b338-95a991418ce2

Security Tools Keyword Lookup Via Findstr.EXE · SigmaHQ rule 4fe074b4-b833-4081-8f24-7dcfeca72b42

Author Nasreddine Bencherchali (Nextron Systems), frack113 · quoted in full and unmodified under the Detection Rule License 1.1 (DRL 1.1)

https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_findstr_security_keyword_lookup.yml

Retrieved 2026-09-11 · file sha256 30e29aa6bbab1d6335f15757e5a13620ca3d70ce2b3e3c8cf42ce28f3b3c6d59

If your test came back silent, that rule is the whole fix. Drop it into your SIEM, or send your provider this page — “we ran this, nothing fired, here’s the detection.” Either way your coverage is better tonight than it was this morning. That’s the point.

A new one every week

This is technique 09 of many.

Each one is a real attacker move, a safe way to try it, and the detection to close the gap. Run them over a few weeks and you’ll learn more about your real coverage than any dashboard has told you.

Curious how a system catches all of these at once, out of the box? That’s what we build — meet Mobula →

Credit & sources

The technique and the incident are documented by MITRE ATT&CK (T1518.001) and the sources linked above. The detection is expressed in Sigma, the open detection format maintained by the SigmaHQ community, so any team can use it freely; its author is credited above under DRL 1.1.

We show you public attacker tradecraft and public detection logic, and hand you both. Nothing here reveals anything an attacker doesn’t already have — it just makes sure the defender has it too.

CYRAY · MOBULA — SECURITY OPERATIONS, ORCHESTRATED BY AI