Can your SOC see someone checking what is running?
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 T1057 · Process Discoveryseen in Akirawhere any Windows box
What this is about
Can your SOC see an attacker reading the process list?
An intruder who has just landed wants to know what else is on the box: which agent is running, which backup service, which database. tasklist prints the list, and piping it into findstr narrows it to the one name they care about. That pipe is the tell — a person reading a list does not need to filter it, a script hunting for one process does.
The detection watches for exactly that shape: a reconnaissance command whose output goes straight into a filter on the same command line.
The detection watches one thing: a process listing being piped straight into a filter, so the attacker reads only the name they came for.
This is not hypothetical
The Akira ransomware operation is documented enumerating running processes on the machines it reaches. The process list tells an operator what is guarding the box and what is holding the data open — both of which decide what happens next.
It needs no exploit, no tooling and no admin rights: two commands that ship with Windows, joined by a pipe. The same line you are about to run.
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.
Listing processes is ordinary. Listing them and immediately grepping for one name is a question being asked on purpose.
It tells them what is watching
The process list is where an intruder finds your agent, your backup service and your database. What they find decides their next move.
No rights, no files
Any account can read the process list, and nothing is written to disk. There is no artifact to find afterwards — only the command line, if you logged it.
The test
Run the real thing. Safely. On a box you own.
Run the same filtered process listing an intruder runs, then open your alerts.
01
List and filter in one line
Run tasklist piped into findstr looking for a process you know is there. This is the moment your SOC should notice a recon command being filtered.
02
Look at what came back
One line of output. That is the whole point — the attacker asked a narrow question and got a narrow answer, with nothing written to disk.
03
Check your alerts
Open your SOC or EDR. Did process discovery fire — or did the box get read in silence?
test-your-soc-process-discovery.ps1 · PowerShell · a machine you own
# test-your-soc-process-discovery.ps1 — run on a machine you own.
# Safe: read-only. Lists processes and filters the list. Nothing is changed, nothing to undo.
# STEP 1 - list what is running and filter it the way an intruder does.
cmd /c "tasklist | findstr /i explorer"
# STEP 2 - open your SOC / EDR. Did process discovery alert?
Both halves of the line are read-only: one lists the running processes, the other filters that text. Nothing is created, changed or deleted, so there is nothing to undo and no admin rights are needed.
Reading the result — honestly
Something fired
Your tooling watches for recon output being piped into a filter
Good — you would see an intruder asking what is running before they act on the answer. On to the next one.
Silence
The process listing 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 piped recon command — note that this rule keys on the pipe appearing on one command line, so an attacker who runs the two commands separately, or reads the process list through an API instead, is a quieter path worth a second rule. 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.
Copy this to your detection team
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_recon_pipe_output.yml
title: Recon Command Output Piped To Findstr.EXEid: ccb5742c-c248-4982-8c5c-5571b9275ad3related: - id: fe63010f-8823-4864-a96b-a7b4a0f7b929 type: derivedstatus: testdescription: | Detects the execution of a potential recon command where the results are piped to "findstr". This is meant to trigger on inline calls of "cmd.exe" via the "/c" or "/k" for example.
Attackers often time use this technique to extract specific information they require in their reconnaissance phase.
references: - https://github.com/redcanaryco/atomic-red-team/blob/02cb591f75064ffe1e0df9ac3ed5972a2e491c97/atomics/T1057/T1057.md#atomic-test-6---discover-specific-process---tasklist - https://www.hhs.gov/sites/default/files/manage-engine-vulnerability-sector-alert-tlpclear.pdf - https://www.trendmicro.com/en_us/research/22/d/spring4shell-exploited-to-deploy-cryptocurrency-miners.htmlauthor: Nasreddine Bencherchali (Nextron Systems), frack113date: 2023-07-06modified: 2025-10-08tags: - attack.discovery
- attack.t1057
logsource: category: process_creation product: windowsdetection: selection: CommandLine|contains: # Note: Add additional CLI to increase and enhance coverage
# Note: We use wildcards in this instance to avoid writing a lot of variations that can be avoided easily. You can switch to regex if its supported by your backend.
- 'ipconfig*|*find'
- 'net*|*find'
- 'netstat*|*find'
- 'ping*|*find'
- 'systeminfo*|*find'
- 'tasklist*|*find'
- 'whoami*|*find'
filter_optional_xampp: CommandLine|contains|all: - 'cmd.exe /c TASKLIST /V |'
- 'FIND /I'
- '\xampp\'
- '\catalina_start.bat'
condition: selection and not 1 of filter_optional_*falsepositives: - Unknown
level: mediumregression_tests_path: regression_data/rules/windows/process_creation/proc_creation_win_findstr_recon_pipe_output/info.yml
Recon Command Output Piped To Findstr.EXE · SigmaHQ rule ccb5742c-c248-4982-8c5c-5571b9275ad3
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 06 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 (T1057) 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