Perform threat hunting →easyMultiple Choice

SC-200 Perform threat hunting Practice Question

You are threat hunting for signs of credential dumping via LSASS access. Which Advanced Hunting schema table in Microsoft Defender XDR should you primarily query to find processes that opened a handle to LSASS?

⚠ Common exam trap

SC-200 often tests the distinction between DeviceProcessEvents (process creation) and DeviceEvents (broader telemetry including ProcessAccess) — candidates who assume 'process' events cover LSASS access pick the wrong table.

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

✓

DeviceEvents

DeviceEvents is the correct table because it captures a broad set of endpoint telemetry including process access events, which is where LSASS handle-opening activity is recorded. When a tool like Mimikatz or a credential-dumping utility opens a handle to lsass.exe with read access, that action surfaces in DeviceEvents with ActionType values such as 'ProcessAccess' and fields identifying the source and target processes. DeviceProcessEvents only records process creation, so it would not show the handle open itself.

Answer analysis

Option-by-option breakdown

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

✗
DeviceProcessEvents
Why it's wrong here
DeviceProcessEvents records process creation events, including command line arguments and parent processes, but it does not capture handle operations or process access attempts. While credential dumping via LSASS often involves launching a tool like mimikatz, the definitive sign of an open LSASS handle appears in DeviceEvents (ActionType: 'LsassAccessedByProcess'), not in the process creation log. Without that access event, you can only infer suspicious activity from the process name or command line, which is weaker evidence.
✓
DeviceEvents
Why this is correct
DeviceEvents is the correct table because it stores security-sensitive behavioral events, and specifically the ActionType 'LsassAccessedByProcess' is emitted when a process attempts to open the LSASS process handle with credential-theft access rights such as PROCESS_VM_READ or PROCESS_ALL_ACCESS. This event directly indicates a potential credential-dumping attempt, making it the definitive data source for this hunt. Other tables may show supporting artifacts, but only DeviceEvents captures the actual LSASS access.
✗
DeviceNetworkEvents
Why it's wrong here
DeviceNetworkEvents is focused on network-level activity, including inbound and outbound connections, DNS resolutions, and protocol data. Credential dumping from LSASS is a local memory operation that does not inherently generate a network connection; unless the attacker subsequently exfiltrates the stolen credentials, no network event will be recorded. Therefore, querying this table for LSASS access would yield nothing, and any network activity would only be correlated after the fact.
✗
DeviceRegistryEvents
Why it's wrong here
DeviceRegistryEvents captures modifications to the Windows registry, such as key/value creation, deletion, and changes. The credential-dumping technique that targets LSASS reads process memory directly and does not require modifying any registry key; while an attacker might later use a registry driver or persistence mechanism, the LSASS access itself is invisible to this table. Thus, using DeviceRegistryEvents would fail to surface the immediate sign of credential dumping.

Go deeper

SC-200 Perform threat hunting Practice Question

Why each option matters

Option-by-option breakdown

Related to this question