312-50 Question 145
Single answer▪ Executing ApplicationsDuring an authorized internal assessment of a Windows 10 workstation, you have obtained a Meterpreter session running under the context of a standard domain user. Your objective is to execute a credential-dumping utility on the target, but the organization uses application whitelisting and blocks unknown executables from launching from the user's Downloads folder. You want to execute your tool while minimizing detection and working within the current user context. Which action is the MOST appropriate next step?
- A
Upload the utility to a user-writable whitelisted path already allowed by the policy and execute it from there
- B
Rename the utility to svchost.exe and run it from the Downloads folder to bypass the whitelist
- C
Change the file extension from .exe to .txt and execute it with cmd.exe
- D
Disable application whitelisting by stopping the AppLocker service from the current standard user session
Show answer and explanation
Correct answer: A
Explanation
The key concept is understanding how application execution controls work in real enterprise environments. During post-exploitation, simply having code to run is not enough; the tester must account for execution restrictions such as AppLocker or Windows Defender Application Control. Practical next steps often involve identifying what the policy allows: execution may be permitted from specific paths, for binaries signed by trusted publishers, or for files explicitly hashed in policy. Among the choices, using an allowed path is the most realistic and technically correct method that aligns with how whitelisting is enforced. Microsoft documentation for AppLocker and WDAC explains that rules are based on publisher, path, and file hash conditions rather than mere filenames. CEH candidates should recognize that execution control bypass attempts based only on renaming files or assuming standard users can disable security controls are unreliable and generally incorrect.
- A. Correct.
Correct. In environments using application whitelisting such as AppLocker or Windows Defender Application Control, execution is often permitted based on approved paths, publishers, or hashes. If a path rule allows execution from a specific user-writable or otherwise approved location, placing the tool there may allow execution without requiring privilege escalation. From a CEH perspective, this reflects practical knowledge of how application control policies are enforced and how execution behavior changes based on rule scope.
- B. Incorrect.
Incorrect. Simply renaming a binary to a trusted Windows process name does not make it trusted by application whitelisting. Controls such as AppLocker and WDAC do not rely only on the filename; they commonly evaluate path, publisher signature, or file hash. This is a common misconception based on older, simplistic controls.
- C. Incorrect.
Incorrect. Renaming an executable to .txt does not make it executable, and cmd.exe will not treat an arbitrary text file as a PE executable. Although some script interpreters can execute scripts with nonstandard extensions when explicitly invoked, that does not apply to a compiled Windows executable. This option confuses file extension obfuscation with valid execution methods.
- D. Incorrect.
Incorrect. A standard domain user typically cannot stop or reconfigure security services such as AppLocker-related enforcement components or bypass WDAC by disabling services. In practice, administrative privileges are generally required, and on many systems policy enforcement continues even if a related service is manipulated. This option reflects an unrealistic assumption about user privileges.