SC-200 Perform threat hunting Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  SecurityEvent | where EventID == 4624 and AccountType == 'User' and LogonType == 3 | where IpAddress != '' | summarize count() by Account, IpAddress

  Why it's wrong here

  This query collects all successful network logons (Event 4624, LogonType=3) but lacks a filter for the NTLM authentication protocol, so it also captures Kerberos logons that are unrelated to pass-the-hash. The summarization by Account and IpAddress loses the WorkstationName and LogonProcessName details needed to pinpoint adversary lateral movement, and it does not exclude computer accounts ($) or domain controllers, flooding the result with legitimate machine and DC authentication. Consequently, it would produce high false positives and fail to isolate the NTLM-specific evidence that PtH relies on.

• ✓

  SecurityEvent | where EventID == 4624 and LogonType == 3 and LogonProcessName contains 'NTLM' | where TargetUserName !endswith '$' | where Computer !in (list of domain controllers) | project TimeGenerated, Account=TargetUserName, SourceWorkstation=WorkstationName, LogonProcessName

  Why this is correct

  This query precisely identifies NTLM network logons by combining EventID 4624, LogonType 3, and LogonProcessName containing 'NTLM', which is the signature of pass-the-hash authentication. The `TargetUserName !endswith '$'` filter removes machine accounts, and the `Computer !in (list of domain controllers)` exclusion eliminates the large volume of legitimate DC-to-DC NTLM activity, leaving only suspicious user logons from non-DC hosts. By projecting TimeGenerated, Account, SourceWorkstation, and LogonProcessName, it retains the forensic context needed for incident investigation, making it the correct detection for PtH lateral movement.

• ✗

  SecurityEvent | where EventID == 4624 and LogonType == 2 and LogonProcessName contains 'NTLM' | project TimeGenerated, Account=TargetUserName

  Why it's wrong here

  This query targets LogonType 2 (Interactive) with NTLM, but interactive logons are console sessions where a user physically logs on at the keyboard, not network authentication used for pass-the-hash. PtH scenarios exploit network logons (Type 3) to access SMB, WMI, or scheduled tasks; Type 2 would instead indicate a local authentication attempt, which is a different attack vector such as privilege escalation. Furthermore, the projection only preserves TimeGenerated and Account, omitting WorkstationName and LogonProcessName, so even if NTLM interactive logons were relevant, the query would lack key investigative data.

• ✗

  SecurityEvent | where EventID == 4624 and LogonType == 10 and AuthenticationPackageName == 'NTLM' | project TimeGenerated, Account=TargetUserName, SourceIP=IpAddress

  Why it's wrong here

  This query uses LogonType 10 (RemoteInteractive), which corresponds to RDP or other interactive remote sessions, not the network logon required for pass-the-hash lateral movement. While `AuthenticationPackageName == 'NTLM'` might appear valid, NTLM can be used in many logon types, and RemoteInteractive specifically indicates a user-level remote desktop session, not a service or network connection that would accept an NTLM hash. It also omits the `TargetUserName !endswith '$'` filter and domain-controller exclusion, so computer account logins and DC-generated events would dilute the results, further reducing its precision for PtH detection.

Go deeper

Related to this question