312-50 Question 147
Single answer▪ Executing ApplicationsDuring an authorized internal penetration test of a Windows environment, you gain low-privilege access to a workstation through a validated phishing simulation. The client wants to know whether application control is properly preventing users from launching unauthorized binaries. You copy a custom unsigned executable to the user's Downloads folder and attempt to run it from a Command Prompt. The system blocks execution and displays a policy-related message indicating that the app is restricted. Which action is the most appropriate next step to verify whether the restriction is based on file path rules rather than a complete application-control block, while staying within the scope of an ethical test?
- A
Move the same executable to a different user-writable location, such as %TEMP%, and attempt to run it again
- B
Use Mimikatz to dump LSASS credentials so you can disable the policy with elevated privileges
- C
Modify the executable's hash and embedded resources until Windows Defender no longer detects it
- D
Reboot into Safe Mode and manually stop AppLocker or Software Restriction Policies services
Show answer and explanation
Correct answer: A
Explanation
The best answer is to move the same executable to another user-writable directory and test execution there. In real-world CEH-style scenarios involving executing applications, the tester should first identify how the control is enforced before attempting bypasses. Windows application control commonly uses AppLocker or Software Restriction Policies, which can enforce rules by path, hash, publisher, or other attributes. A block that occurs in Downloads but not in another writable location can indicate weak path-based restrictions, a common misconfiguration. This is a practical validation step that aligns with ethical testing principles: minimize impact, remain within scope, and gather evidence systematically. Microsoft documentation for AppLocker and Software Restriction Policies describes these rule models and highlights that poorly designed path rules can leave gaps if users can write to alternate allowed locations.
- A. Correct.
Correct. In Windows environments, application control mechanisms such as AppLocker or Software Restriction Policies (SRP) may rely on path, publisher, or hash rules. If execution is blocked from the Downloads folder, moving the same file to another user-writable path such as %TEMP% is a controlled and realistic way to test whether the policy is path-based. This directly assesses the effectiveness of the client's execution restrictions without introducing unnecessary privilege escalation or out-of-scope bypass activity.
- B. Incorrect.
Incorrect. Dumping LSASS credentials with Mimikatz is an escalation and credential-access technique, not an appropriate first step for validating whether application execution controls are path-based. It also increases operational risk and may exceed the agreed scope if the objective is specifically to evaluate execution prevention rather than credential theft or administrative bypass.
- C. Incorrect.
Incorrect. Altering the file repeatedly to evade antivirus focuses on malware detection bypass, not on testing the application's execution control design. AppLocker and SRP are separate from Microsoft Defender detection logic. A candidate might choose this because AV and application control are often confused, but they solve different security problems.
- D. Incorrect.
Incorrect. Rebooting into Safe Mode and attempting to disable controls is invasive and generally outside the least-impact approach expected during an ethical assessment. It also does not answer the immediate question of whether the existing block is based on a path rule. This option represents an unnecessarily disruptive method instead of a scoped validation step.