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 (lsass.exe)

  Why this is correct

  This Attack Surface Reduction rule is specifically engineered to prevent untrusted processes from reading the memory space of lsass.exe, the Windows Local Security Authority Subsystem. By blocking read access to LSASS, it directly thwarts credential-dumping techniques used by tools such as Mimikatz, which rely on extracting password hashes or plaintext credentials from that process's memory. This makes it the most targeted and effective rule for the described credential theft scenario.

• ✗

  Block Office applications from creating child processes

  Why it's wrong here

  While blocking Office applications from creating child processes does mitigate many macro-based attacks and exploits like DDE where Office spawns PowerShell or cmd.exe, it does not address the underlying credential theft vector. An attacker who has already gained code execution on a device could directly access LSASS memory using an existing system process or a standalone credential-dumping utility, without needing Office to launch a child process. This rule therefore reduces one attack chain but leaves LSASS memory exposure unmitigated.

• ✗

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

  Why it's wrong here

  This rule restricts execution of untrusted executables based on prevalence, age, or a trusted-list criterion, which is effective against unknown malware dropped by an initial intrusion. However, credential dumping from LSASS is often performed using built-in Windows tools or trusted binaries (such as comsvcs.dll) that meet prevalence or trusted-list criteria, or by injecting code into an already-running trusted process. Because it controls when executables launch rather than restricting existing processes from accessing LSASS memory, it fails to directly block the specific credential-stealing action.

• ✗

  Block Adobe Reader from creating child processes

  Why it's wrong here

  This rule is narrowly scoped to Adobe Reader, preventing it from spawning child processes to stop PDF-based attacks that chain to other binaries. It has no bearing on LSASS credential theft because it neither restricts access to the Local Security Authority Subsystem nor covers the wide range of other processes (browsers, Office apps, or system utilities) that might be abused. A credential-dumping tool running as a standalone process or from an entirely different application would still be able to read LSASS memory, making this rule irrelevant to the investigation.

Go deeper

Related to this question