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

Answer analysis

Option-by-option breakdown

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

• ✓

  Block credential stealing from the Windows Local Security Authority Subsystem

  Why this is correct

  This ASR rule is specifically designed to block attempts to open and read the memory space of the Local Security Authority Subsystem Service (LSASS), the process in which Windows stores authentication credentials. By intercepting suspicious process calls to LSASS, it directly stops credential dumping tools such as Mimikatz from extracting plaintext passwords and NTLM hashes. When enabled in block mode, it logs and prevents these access attempts, making it the correct rule for reducing credential dumping on managed devices.

• ✗

  Block executable files from running unless they meet prevalence, age, or trusted list criteria

  Why it's wrong here

  This rule evaluates executable files based on Microsoft's cloud reputation, using factors like prevalence, age, and trusted publisher lists, and blocks those that are unknown or low-reputation. While this helps prevent many malware samples from running, it does not monitor or restrict process calls to LSASS memory, so an attacker could still use a known, signed, or trusted binary to dump credentials. Credential dumping often leverages built-in Windows tools or malicious code injected into legitimate processes, both of which would bypass this reputation-based block.

• ✗

  Block untrusted and unsigned processes that run from USB

  Why it's wrong here

  This ASR rule targets processes that are both untrusted and unsigned when they originate from removable USB media, thereby preventing USB-spread malware from executing on a system. It is irrelevant to credential dumping because an attacker's process could already be running from system memory, a network share, or a PowerShell in-memory payload, none of which involve USB execution. LSASS memory access is a local runtime action, not an execution-from-USB event, so this rule would not block a credential-dumping attack even if the tool had been previously dropped to disk by other means.

• ✗

  Block JavaScript or VBScript from launching downloaded executable content

  Why it's wrong here

  This rule blocks JavaScript or VBScript files from launching executable content that was downloaded from the internet, which is a common infection chain used by script-based droppers. However, credential dumping from LSASS is performed by directly obtaining a handle to lsass.exe and reading its memory, which can be done via PowerShell Invoke-Mimikatz or a compiled native tool without any script launching a downloaded executable. This rule neither monitors LSASS access nor stops in-memory credential extraction, so it fails to address the specific technique described in the question.

Go deeper

Related to this question