PowerShell Threat Hunting: Two Practical KQL Examples

PowerShell threat hunting works best when a query tests a specific question. A PowerShell process alone is not evidence of compromise: administrators and management tools use it every day. The useful question is whether its parent process, user, timing and network activity fit the device’s normal role.

This guide uses hypothesis-driven threat hunting to investigate two patterns with Microsoft Defender XDR advanced hunting. The examples are fictional teaching scenarios, not accounts of real incidents. The queries are read-only starting points; they have not been executed against a live tenant and need validation against your environment.

The technique: start with a testable hypothesis

A hypothesis states what suspicious behaviour might look like and what evidence would support or weaken that explanation. Write it before searching, define the devices and time range, then compare the results with normal activity.

1. Define: describe the behaviour and the business context in which it would be unexpected.
2. Collect: check that the necessary endpoint events exist for the devices and period.
3. Investigate: connect process, account and network evidence instead of treating a query match as a verdict.
4. Conclude: record a supported finding, an explained benign result, or an unresolved visibility gap.

MITRE ATT&CK maps adversary use of PowerShell to T1059.001. That mapping describes a behaviour; it does not establish that an individual PowerShell execution is malicious.

Before running the queries

You need access to advanced hunting and relevant Defender for Endpoint telemetry. Microsoft documents DeviceProcessEvents for process activity and DeviceNetworkEvents for network activity. Check the in-portal schema and event coverage before interpreting results.

The queries use a seven-day window as a starting point. Adjust it to your retention, permissions and investigation scope. If the tables return no recent events for a known active device, resolve that visibility gap first. An empty result is not proof that a device is clean.

Example 1: an Office application launches PowerShell

Hypothesis: a document application launching PowerShell may indicate unexpected script execution on a workstation where that workflow is not normally used.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName in~ (
    "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe")
| project Timestamp, DeviceId, DeviceName, AccountName,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    FileName, ProcessCommandLine, ProcessId, ProcessCreationTime
| order by Timestamp desc

This finds direct parent-child relationships. It will miss chains with an intermediate process, renamed executables and execution not captured by the sensor. Expand the investigation through the device timeline rather than assuming this query covers every PowerShell technique.

A fictional investigation

On FIN-LAPTOP-07, Word launches PowerShell shortly after a user opens a document. The parent relationship is unusual for this device, but it is only the starting observation.

• Review the full process tree and command line. Establish which document and workflow preceded the process where telemetry allows.
• Check the user’s role, relevant support activity and whether an approved document integration explains the behaviour.
• Look for nearby file creation, child processes and network events associated with the same process instance.
• Compare with similar workstations and earlier activity. Ask whether this is a new pattern or a known business workflow.

If an unapproved document launch is followed by an unexplained script and related external communication, preserve the evidence and escalate through the incident-response process. If a verified reporting add-in explains the chain and the activity matches an approved change, document that explanation. Neither the parent name nor the user’s recollection is sufficient on its own.

False positives and tuning

Reporting tools, document automation and support workflows can produce legitimate matches. Use narrow exceptions tied to a verified workflow and review date. Avoid excluding every PowerShell process launched by an entire user group: that would hide unrelated activity.

Example 2: PowerShell makes an unfamiliar network connection

Hypothesis: PowerShell network activity deserves closer review when the destination and initiating command do not fit the device’s expected administrative tasks.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("powershell.exe", "pwsh.exe")
| where isnotempty(RemoteIP) or isnotempty(RemoteUrl)
| project Timestamp, DeviceId, DeviceName, ActionType,
    RemoteUrl, RemoteIP, RemotePort,
    InitiatingProcessAccountName, InitiatingProcessCommandLine,
    InitiatingProcessId, InitiatingProcessCreationTime
| order by Timestamp desc

This returns observed network events, not a list of malicious destinations. Review ActionType to distinguish the recorded outcomes; do not assume every row represents a successful connection. A blank RemoteUrl also does not mean the destination was harmless or that no network activity occurred.

A fictional investigation

On OPS-WS-12, PowerShell contacts a destination absent from the team’s approved automation inventory. Its unfamiliarity makes it worth investigating; it does not prove command-and-control activity.

1. Identify the exact process instance using the device, process ID and process creation time. A process ID by itself can be reused.
2. Inspect its parent process and full command line in the endpoint timeline. Determine whether a scheduled task, management agent or interactive user initiated it.
3. Review the destination in approved DNS, proxy and threat-intelligence tools. Treat reputation as one signal, not a final verdict.
4. Compare the timing with change records and other devices performing the same task. Correlate relevant file and child-process events.

Suppose the endpoint owner supplies an approved inventory job and its destination and timing match the evidence. That supports a benign conclusion. If the command, destination and process chain remain unexplained, record the uncertainty and escalate with the supporting timeline. Do not open a suspicious destination from a normal workstation just to investigate it.

False positives and coverage limits

Software maintenance and cloud administration can legitimately use PowerShell networking. This query does not automatically calculate rarity, prove data transfer or identify what was sent. Connections made by a child process may appear under that child instead. Use an appropriate historical baseline and additional telemetry to answer those questions.

What a useful hunt report should contain

• Scope: hypothesis, dates, devices and data sources checked.
• Evidence: timestamps, process relationships and relevant events, with sensitive details handled under your organisation’s rules.
• Assessment: what supports the finding, what weakens it and what remains unknown.
• Disposition: escalate, close with a documented benign explanation, or assign a follow-up for missing visibility.
• Improvement: a logging fix, a narrowly scoped exception or a candidate detection to validate.

Validate a candidate detection with labelled benign and suspicious examples in an authorised environment before turning a hunt into an alert. Review the query’s coverage and false positives with the SOC; these examples are not ready-made production detection rules.

Common questions

Does unusual PowerShell activity always mean compromise?

No. Investigate the complete sequence and business explanation. Suspicion becomes more useful when several independent observations support it.

What if the hunt returns no results?

Confirm device onboarding, permissions, event availability and the time range. Then record that this specific search found no matches within its coverage, rather than claiming there was no malicious activity.

Can I use this technique with another SIEM?

Yes. Map the same questions to your process and network logs. The KQL shown here depends on the Defender schema and will need adaptation for other datasets.

For more defensive learning, browse the Knowledge Base Articles. To practise communicating evidence and risk, read the PSIRT interview preparation guide.