Perform threat hunting →mediumMultiple Choice

SC-200 Perform threat hunting Practice Question

Exhibit

Refer to the exhibit.
```powershell
# PowerShell script to run a custom hunting query in Microsoft Sentinel via REST API
$query = @"
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "rundll32.exe"
| where ProcessCommandLine contains "javascript"
| summarize Count = count() by DeviceName
| where Count > 5
"@
$workspaceId = "12345678-1234-1234-1234-123456789abc"
$body = @{query = $query} | ConvertTo-Json
Invoke-RestMethod -Uri "https://api.loganalytics.io/v1/workspaces/$workspaceId/query" -Method Post -Body $body -ContentType "application/json"
```

An analyst runs this PowerShell script to query Microsoft Sentinel data. The query returns no results. What is the most likely reason?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

No events matched the specific combination of process name and command line in the last 7 days

The query syntax is valid (e.g., using where and summarize appropriately), the API endpoint and timestamp filter are standard for Microsoft Sentinel queries. The most probable reason for no results is that no events with rundll32.exe and javascript in the command line occurred within the specified 7-day window. Options A, B, and D describe issues that would typically cause errors, not just empty results, making C the most likely explanation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The timestamp filter is invalid; it should use TimeGenerated instead of Timestamp
Why it's wrong here
DeviceProcessEvents in Microsoft 365 Defender Advanced Hunting stores event timestamps in a column named Timestamp, not TimeGenerated; TimeGenerated is the ingestion-time column used in Log Analytics workspaces for table data, not in the Advanced Hunting schema. Filtering on Timestamp is therefore valid, and the script's use of this column is not the reason the result set is empty. The option misidentifies the schema, so it is incorrect.
✗
The query syntax is incorrect; summarize cannot be used after where
Why it's wrong here
KQL is a streaming pipeline where the where operator filters rows before subsequent operators are evaluated, and summarize can legally follow where to aggregate the filtered results. For example, a query can filter by process name and then summarize counts by timestamp; this is standard syntax. The option's claim that summarize cannot appear after where misunderstands KQL's operator ordering, so it is not the cause of an empty result.
✓
No events matched the specific combination of process name and command line in the last 7 days
Why this is correct
The script likely used a query such as DeviceProcessEvents | where ProcessCommandLine contains 'javascript:' combined with a filter for rundll32.exe as the process name. In most environments, rundll32.exe executing a JavaScript URI (e.g., JScript or VBScript) is an uncommon attack pattern that rarely occurs, so the query returned an empty table even though the syntax and endpoint are correct. The absence of matching records, not an API error or schema mistake, explains why no data was returned.
✗
The API endpoint URL is incorrect; it should be /v2/workspaces
Why it's wrong here
The Azure Log Analytics query API endpoint follows the pattern /v2/workspaces/{workspaceId}/query (or /v1/...) and requires the workspace ID to identify the target workspace; simply using /v2/workspaces with no ID and no /query suffix is not a valid call. The script's URL already includes the correct path and method, so the endpoint is not the source of the empty result. This option incorrectly asserts a URL error where none exists.

Go deeper

SC-200 Perform threat hunting Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question