Manage security and threats by using Microsoft Defender XDR →hardMultiple Choice

MS-102 Practice Question: Manage security and threats by using Microsoft Defender XDR

Exhibit

KQL query:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "cmd.exe")
| where ProcessCommandLine has_any ("-EncodedCommand", "-e", "-enc")
| summarize Count = count() by DeviceName, FileName
| where Count > 5

Refer to the exhibit. You are analyzing a KQL query in Microsoft Defender XDR Advanced Hunting. The query returns a list of devices where PowerShell or cmd.exe with encoded commands executed more than 5 times in the last 7 days. The security team suspects that one of the devices is compromised due to excessive use of encoded commands. However, a legitimate administrative script uses encoded commands regularly. How can you refine the query to reduce false positives while still detecting potentially malicious activity?

⚠ Common exam trap

Many exam-takers choose to increase the count threshold (Option A) thinking it will reduce false positives, but this is a blunt instrument that also reduces true positives, whereas the correct approach is to use contextual filters like certificate or account exclusions to surgically remove known-good activity.

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

✓

Add a filter to exclude processes signed by a trusted certificate or running under specific service accounts.

Adding a filter to exclude processes signed by a trusted certificate or running under specific service accounts directly addresses the legitimate administrative script that uses encoded commands. This refinement reduces false positives by allowing trusted, signed executables or known service accounts to bypass detection, while still flagging unsigned or anomalous encoded command executions that are more likely malicious. In Microsoft Defender XDR Advanced Hunting, you can use the `SigningCertificate` or `InitiatingProcessAccountName` fields in the KQL query to implement this exclusion.

Answer analysis

Option-by-option breakdown

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

✗
Increase the Count threshold to 10.
Why it's wrong here
Raising the Count threshold from, say, 2 to 10 simply requires the same cmd.exe process to be seen more frequently before alerting. A legitimate script that runs on every sign-in or as a scheduled task will still exceed that higher limit, so the false positive remains. Moreover, a high threshold can suppress genuinely malicious, low-volume attacks that execute only once, reducing the detection sensitivity. The false positive arises from the query's matching logic, not from the count aggregation, so frequency tuning is a poor remedy.
✓
Add a filter to exclude processes signed by a trusted certificate or running under specific service accounts.
Why this is correct
Add a filter such as `where Process.Signer != 'Microsoft Corporation'` or `where AccountName !in ('svc_backup', 'svc_monitoring')` to exclude processes from known trusted sources. Many legitimate automation scripts are signed by an internal certificate authority or run under dedicated service accounts, so these allowlist-style filters reduce noise without hiding unknown or unsigned binaries. This is the correct approach because it preserves detection of suspicious, unsigned processes that lack a trustworthy signer and are not expected to run under service accounts. It targets the actual root cause: the alert currently flags benign, trusted execution as suspicious.
✗
Remove cmd.exe from the FileName filter.
Why it's wrong here
Deleting `cmd.exe` from the FileName filter would suppress all command-line interface activity, yet `cmd.exe` is a common living-off-the-land binary that attackers use to run scripts, download payloads, or enumerate the network. If the query no longer looks for it, you would lose visibility into legitimate security events as well as malicious use, creating a blind spot. A better remedy is to keep `cmd.exe` and exclude specific known-good instances, such as a managed service account's scheduled backup script, rather than removing the process entirely. This preserves detection of the process family while eliminating the offending false positive.
✗
Change the time range to 1 day instead of 7 days.
Why it's wrong here
Narrowing the time range to 1 day does not change what the query matches; it only changes how much historical data is scanned. If the benign script runs daily or every few hours, it will still appear within a 1-day window and generate the same alert. The false positive is caused by the absence of a filter on the signer or the service account, not by the length of the time range. Even worse, a shorter hunting window can miss a slow-and-steady attack that triggers only once or twice in a week, so this change actually weakens the detection without fixing the noise.

Go deeper

MS-102 Practice Question: Manage security and threats by using Microsoft Defender XDR

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question