Jump to content

Recommended Posts

In Windows 10, Microsoft introduced a feature called User Account Control virtualization.

1. https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations
2. https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works

In a nutshell, UAC Virtualization is a short-term solution for backwards compatibility with older software which is non-UAC compliant, without forcing the user to grant the application Administrator privileges; in the event of a Denied Access failure, attempted I/O to System directories or registry hives instead get redirected to a per-user directory or hive. However, as this is meant to be a short-term solution, it is not recommended by Microsoft to be used for anything outside of debugging purposes. It also isn't enabled globally and has to be toggled on a per-application basis, and the final nail in the coffin: it can't be enabled for 64-Bit applications. To note, UAC-V is automatically overridden when you choose to grant Administrator privileges to a program anyway.

UAC Virtualization has potential applications in the field of security, but could be seen as a crutch for developers (hence why Microsoft placed these limitations on it). In many Enterprise environments, however, legacy software is often still used to some extent, which can pose a security risk. On the flipside, there's ample room for configuring UAC-V (or an equivalent of it) on an Administrative, Organization-Wide level, and automatically auditing errors for purposes of both debugging and cyberforensics.

So my proposal is as follows; Create both a File System Filter Driver and a Registry Filter Driver as a MalwareBytes component to provide a security-focused equivalent to UAC-V, which could be applied globally to all applications, or only to specific users, applications and groups. In addition, enable the driver to also provide UAC-V for 64-Bit applications. To prevent inexperienced software developers from relying on it and to prevent malicious abuse of the system, Administrators could override the settings of less-privileged users and groups through the management console.

Any thoughts on this subject?

Link to post
Share on other sites

Extending on this idea: Attempted changes made by means of UAC-V could be logged and tracked in detail for both Security and Software-development reasons, and then an Administrator could individually approve those filesystem and registry changes to be distributed system-wide once they're certain that the changes are desirable. An Administrator could even choose to whitelist certain trusted applications so that further UAC prompts would not be required.

This could even be combined with a 64-Bit version of Installer Detection (also detailed in one of the above links) to provide increased safety and compatibility for Enterprise customers, as incorrectly built installers will request elevation and be redirected as they should while also telling the Administrator, Log Viewer or Developer exactly what went wrong.

One more note: All of this could potentially take some time and stress away from the user's workflow as well, as they wouldn't have to constantly deal with UAC.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

Back to top
×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.