You are hunting for endpoints that have recently executed PowerShell commands. Which two XQL query steps are appropriate?

The correct answer is A. Use the xdm.process table B. Filter events by command-line arguments. Hunting PowerShell activity requires querying process execution data, which lives in the xdm.process table (A) - this table captures process creation events including the executable name, parent process, and command-line arguments. Filtering on command-line arguments (B) is…

Threat Hunting

Question

Options

AUse the xdm.process table
BFilter events by command-line arguments
CQuery the xdm.asset table for policy info
DExport user reports from SIEM

How the community answered

(40 responses)

A
70% (28)
C
20% (8)
D
10% (4)

Explanation

Hunting PowerShell activity requires querying process execution data, which lives in the xdm.process table (A) - this table captures process creation events including the executable name, parent process, and command-line arguments. Filtering on command-line arguments (B) is essential because PowerShell invocations appear there (e.g., powershell.exe -EncodedCommand ...), letting you pinpoint suspicious or encoded execution patterns.

Why C is wrong: xdm.asset contains asset inventory and policy configuration data - not runtime process execution events. It tells you about a machine, not what ran on it.

Why D is wrong: Exporting user reports from a SIEM is a passive, administrative action and not an XQL query step at all - it's a different tool and workflow entirely.

Memory tip: Think "Process + Parameters = PowerShell hunting." In XQL, you always need to (1) target the right table (xdm.process) and (2) apply the right filter (command-line args). The other two options are red herrings because one is the wrong table and one isn't even XQL.

Topics

#XQL Threat Hunting#PowerShell Detection#Process Data#Command-Line Analysis

Community Discussion

No community discussion yet for this question.

Full XSIAM-ANALYST Practice