Here your task will be to discover the File System Virtualization mechanism and use it to make the app prepared by us running fine in the user context.
You will have a chance to learn how to run the application with standard user privileges even though it’s requiring access to some restricted directories.
A file called CQChallenge2.exe will be provided. If we execute the file and click on „Save user data“ it will work with admin priviledges, but it won’t work with an unpriviledged account.
Let’s open that file first with admin priviledges:
Checking the file path:
The file is there and that’s my Username /SID and timestamp
Now let’s login with the unprivileged Useraccount John Doe and see what we get:
As we can see we don’t have permissons to write in the filepath where data.txt is stored.
Let’s start Task-Manager and activate UAC-Virtualization on the CQChallenge2.exe process.
And now it works. But if we browse to the path where the file data.txt is stored there is no new data in it.
Let’s check out this guide from microsoft.
Windows 10 includes file and registry virtualization technology for apps that are not UAC-compliant and that require an administrator’s access token to run correctly. When an administrative apps that is not UAC-compliant attempts to write to a protected folder, such as Program Files, UAC gives the app its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user’s profile. This strategy creates a separate copy of the virtualized file for each user that runs the non-compliant app.
That would be the explanation! We see there’s a folder called „VirtualStore“ in %localappdata% where the files are being redirected. The registry knows a similar mechanism for that.
Virtualization is not an option in the following scenarios:
- Virtualization does not apply to apps that are elevated and run with a full administrative access token.
- Virtualization supports only 32-bit apps. Non-elevated 64-bit apps simply receive an access denied message when they attempt to acquire a handle (a unique identifier) to a Windows object. Native Windows 64-bit apps are required to be compatible with UAC and to write data into the correct locations.
- Virtualization is disabled if the app includes an app manifest with a requested execution level attribute.
Which locations are redirected to safer, user-specific locations when UAC Virtualization is enabled for particular application?
- * %programFiles%,%WinDir%,%WinDir%\System32
- * %programFiles%,%WinDir
- * HKLM:\Software and all other registry keys that an administrator can write to
- * Answer A and C are correct
For which scenarios from the below, UAC Virtualization is not possible?
- *Applications that are elevated and run with a full administrative access token
- *64bit applications
- *Applications including an application manifest with a requested execution level attribute
- *All answers are correct
When an application with UAC Virtualization enabled attempts to write something to the restricted folder, where does the UAC Virtualization mechanism redirect the request to?
- *\Appdata\local\virtualStore\ folder in the user’s profile
- *\Appdata\LocalLow\VirtualStore\ folder in the user’s profile
- *\Appdata\Roaming\VirtualStore folder in the users’s profile
How to make sure that UAC Virtualization will be disabled system-wide?
- * Set „EnableVirtualization“ DWORD value to 0 in the following registry key: HKLM:\Software\Microsoft\CurrentVersion\Policies\System
- * It’s not possible
- * Create a manifest with explicit execution level attribute for every application on the system
- * Forbid users from running task manager