27

Is there a binary (.exe) in the System32 folder responsible for the Windows UAC functionalities? (e.g., uac.exe). What would happen if that file was forcefully deleted? Would Windows break or fail to boot?

There's no XY problem here; I'm just curious to know what would happen if UAC was forcefully removed from a PC.

  • 1
    You can easily disable UAC. UAC is a function of the kernel. What you want isn’t possible – Ramhound Mar 18 '18 at 22:38
  • There is a file win32k.sys technize.net/… and apparently that file in a pre patched windows, can be manipulated/changed..to disable UAC. Alternatively one can disable UAC in a normal manner, though it's not an EXE file – barlop Mar 18 '18 at 23:37
  • You can disable UAC using various methods, for example superuser.com/questions/1013702/…. I'm thinking that if you remove it some other hack-ish way, you'd get mostly the same effect, albeit with the errors in the answers below about missing binaries. – YetAnotherRandomUser Mar 19 '18 at 1:54
  • @barlop, win32k.sys is just the kernel side of the Windows subsystem. In other words, the core code used by everything. I would not recommend attempting to change it. pasotech.altervista.org/windows_internals/Win32KSYS.pdf – Dark Falcon Mar 20 '18 at 7:53
  • @DarkFalcon There is probably more to the "kernel side of the windows subsystem" than that. And I was not advising that one "change it"! What do you think somebody is going to do? Open it in notepad? I never suggested such a thing! Open a hex editor? better, but I didn't suggest that either! And nobody would do that and change anything unless they had some idea what they wanted to change, which would take a certain skill level! – barlop Mar 20 '18 at 12:32
55

UAC is a multi-component architechture implemented by multiple binaries

User Account Control (UAC) refers to several components that together form the UAC architecture. I'll briefly review some of them along with the binaries responsible for their implementation, but first here's an overview of the UAC architecture from the Microsoft Docs article How User Account Control Works:

enter image description here

Local Security Authority (LSA) / Filtered Token

Conceptually the "first" component of UAC is implemented by the Local Security Authority subsystem which handles creation of a user's Access Token during the logon process. Starting with Windows Vista, the logon process was modified so that when an Administrator logs on with UAC enabled, the LSA subsystem generates two separate access tokens for the user:

  1. One with full administrator access, and
  2. A second "filtered token" with standard user access

As shown here this process is different than that of a standard user logon:

enter image description here

The LSA subsystem service lives in the lsass.exe process.

Virtualization

Added in Windows 7, File and Registry Virtualization is a component of UAC that shims older applications that are not-UAC compliant but only require administrative rights in order to access certain protected areas of the filesystem or Registry:

When an administrative application that is not UAC compliant attempts to write to a protected directory, such as Program Files, UAC gives the application its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile.

Source

By redirection these access attempts to areas that don't require admin permissions, these applications continue to function despite UAC being enabled on the system.

This virtualization is implemented in the Kernel.

Application Information Service

The Application Information Service (AIS) reads an application's manifest and works with the UAC Consent Prompt to determine if an application is allowed to execute with elevated rights (i.e. start in the context of the non-filtered administrative-level access token created at logon). This blog post provides a good overview of its role in the UAC process:

AIS Facilitates the running of interactive applications with additional administrative privileges. If this service is stopped, users will be unable to launch applications with the additional administrative privileges they may require....The shell checks with this service when it launches an application. AIS is the one that reads the manifest and the ‘trustInfo’ xml section that has the requirements for the ‘requestedExecutionLevel’...

Here's a graphic that follows the above quote detailing AIS' role in the UAC Consent Prompt process:

enter image description here

The AIS is implemented in the DLL appinfo.dll which is executed by svchost.exe.

Consent Prompt

@BenN's answer explains the key role of the (in)famous UAC Consent Prompt. This is implemented in consent.exe and is responsible for getting the user's consent or an administrative user's credentials in order to allow launching of an application requiring admin rights.

Secure Desktop

The Secure Desktop is where the UAC Consent Prompt is displayed by default. Microsoft's UACBlog tells us what's unique about this Desktop compared to the User Desktop:

You most commonly interact with [the Secure Desktop] when you log on to Windows since the Logon UI runs on the Secure Desktop. The Secure Desktop’s primary difference from the User Desktop is that only trusted processes running as SYSTEM are allowed to run here (i.e. nothing running as the User’s privilege level) and the path to get to the Secure Desktop from the User Desktop must also be trusted through the entire chain.

The idea behind using it when asking the user's consent to run an application with elevated permissions is that malware cannot imitate the Secure Desktop unless it already has administrative rights, in which case tricking a user into granting them is moot.


Conclusion: UAC is not just one binary. It's a fabric of interwoven subsystems.

There are yet other aspects of the UAC architecture not covered here, but this should provide enough evidence for the facts that:

  1. UAC is not implemented in a single binary.
  2. If enabled, it's an integral part of performing administrative tasks.

Since its introduction in Windows Vista it has been deeply integrated into key portions of the operating system, making it infeasible delete all the code responsible for UAC without breaking other things (such as your ability to logon!)

I think it's safe to say that if you "forcefully deleted" UAC you would break Windows.

  • 1
    FWIW technize.net/… based on that link, it seems the file win32k.sys seems to play a role I notice that file.exe identifies it as "PE32+ executable (native) x86-64, for MS Windows" – barlop Mar 18 '18 at 23:39
  • win32k.sys is -- essentially -- a large chunk of the kernel. Of course it plays a role in UAC. It is Windows. – Roger Lipscombe Mar 20 '18 at 11:43
25

As Twisty excellently explained, there are a lot of components that help implement UAC. The part of UAC that people are most familiar with is the elevation/consent dialog:

This is provided by consent.exe, "Consent UI for administrative applications." I tried renaming it in a VM and seeing what happens. As expected, no elevation prompts appear when using "run as administrator" — instead, you get a file-not-found error that blames the thing you're trying to elevate:

not found

Trying to use any Control Panel UI element that requires elevation (i.e. has the shield icon), even if logged in as an administrator, fails with similar errors. Trying to launch administrative things from the Start menu produces a slightly different error:

no app associated

Depending on the ACL set when doing the rename that broke everything, it could be impossible to fix this from within the OS, since file operations can require elevation (even if they doesn't usually produce the consent dialog). Normal-user-like activities don't seem to be degraded, though.

  • 3
    @muru, I'd guess consent.exe doesn't just return true or false, but instead the token to execute under. Which means you can't get from a normal user to an administrator token without actually authenticating as the admin. – Joey Mar 19 '18 at 6:03
  • 6
    @muru Windows does verify and replace many system files, not sure if this one is included or not. However, from a security standpoint, the point is moot - to replace consent.exe, you need administrator privileges in the first place, so there's no privilege escalation even if it were possible to replace the way you imagine it. – Luaan Mar 19 '18 at 11:45
  • 3
    Just to include it since the thought came to my mind. You could still boot the machine into Linux or something to replace the file. But that requires physical access to the machine, which is basically administrative access as well. So it's still not a security concern – DeadChex Mar 19 '18 at 15:53
  • 1
    @EricTowers Yes, but since administrative privileges are required to alter consent.exe, an attacker who can do that is already on the other side of the airtight hatchway and has more straightforward ways of doing bad things. – Ben N Mar 19 '18 at 19:01
  • 1
    @TwistyImpersonator Interesting question! Silent elevation seems to also trigger a Consent run (per process start monitoring) when done under a normal admin account. The built-in Administrator account is not subject to UAC, so all its programs are already elevated and Consent doesn't get involved. You can change that behavior using this security policy. – Ben N Mar 19 '18 at 19:32

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.