Don’t accept a ticket that just says “make a detection for PSExec.”
Require structure upfront or you’ll waste time guessing intent or build something entirely unnecessary.
Example Scenario: Detection Story
IOCs observed as part of malicious traffic
A command was observed during a real attack where PSExec was used to authenticate with a plaintext password via the -p flag, then copy malware to a list of hosts using a batch script.
Research
Good detection requires full understanding of the idea
Research informs every decision downstream
Research and document findings related to the artifacts in question as you go
Document different avenues you go down, things you look at, etc.
Key principles:
Understand what you’re looking for fully before writing a query
Identify flags, behaviors, and patterns specific to the technique
Research whether the behavior should ever occur legitimately in your environment
Watch your scope — it’s easy to drift from “PSExec plaintext auth” into “all PSExec” or “PSExec + file share interaction,” which are separate detections
Example Scenario: Research
Research reveals the -p flag passes a password in plaintext on the command line
Best practice requires interactive password prompts
Legitimate use of -p in a production environment is essentially nonexistent
this is a strong signal
Build the Query
The query is the core of your detection
should be directly informed by your research
in what to look for, possible exclusions, etc.
Without a good query, you don’t have a detection
Prototype queries as you go and evaluate the results
Balance is key
Too Broad
Just Right
Too Narrow
All PSExec activity
PSExec process name + -p argument
PSExec with -p and a specific known password
High volume, burnout risk
Balance between fidelity and volume
Too specific, Misses variants (quoted args, file-based passwords)
Practical tips:
Lowercase the process name field to avoid case-sensitivity mismatches
Consider PSExec clone/rename variants
Look at process arguments as an array, not just a string match
Think about corroborating signals (e.g., PSEXESVC service installation)
Example Scenario: KQL Query
process.name : "psexec.exe" AND process.args : "-p"
This catches any PSExec execution with the -p argument regardless of other arguments
not too specific, not too broad
Back Test
Estimating volume should be done before the SOC brings you issues
Before going live, validate your query against historical data
Run the query against 90 days of data
30 days is the absolute minimum
Identify noise, known-good activity, or filters you need to apply
If results are unexpectedly high, consider:
Dropping or deprioritizing the detection
Lowering its alert priority
Reformulating the query
stack the data
find common fields in legitimate events
filter accordingly
Document your results
use as evidence:
to propose a severity/priority
If it fires later, you have proof of due diligence
screenshot the query, time range, and result count
Zero results in a back test is either:
great news (high fidelity)
or a sign something is broken
Verify by confirming the query would have caught known-bad traffic
Example Scenario: Back Test
A 90-day back test returned zero results after excluding a known malicious username
confirms the query correctly identified the original attack traffic
Build a Canary
A canary is code that executes on a schedule to generate the exact traffic your detection is supposed to catch.
A canary validates that your detection continues to work after deployment
Without one, a broken detection could go unnoticed for months
logic can be extremely complex or very simple
run on scheduled interval
If it doesn’t fire an alert, you get notified of the failure
Canary tiers:
Best: Dedicated canary infrastructure with scheduled runs and failure alerting
removes environmental variables
Good: Regularly scheduled manual runs
still catches broken detections over time
Avoid: Testing once at deploy time and never again
Tip
Generate traffic as close to the real thing as possible
echoing a command to the CLI may not produce the same log artifacts as actually running the tool
Reference Atomic Red Team (ART) for a library of pre-built canary-style test scripts
If replaying captured malicious traffic,
ensure nothing in your environment has changed that could make it artificially always pass
Example Scenario: Build a Canary
Simply run psexec.exe -p <password> ... in a controlled test environment on a schedule
“If you have a structured process for your detection engineering and you do it well and it’s well thought out, you will have a much better output at the end.”
— Hayden Covington