How is using the standard Windows account more secure than using the administrator Windows account with highest UAC settings?

Question

If someone uses the administrator Windows account for everyday work while having the default UAC settings they will be prompted by UAC whenever an application other than certain predefined system apps requires elevated permissions. From the security point of view this is equivalent to no protections against malware getting elevated permissions:

the Notify only when apps try to change settings option can be subverted by any app simply by injecting a thread into Explorer and doing its dirty work there. Since Explorer is a program that the setting allows to elevate silently, this lets you perform a silent elevation from any thread that has thread injection rights into Explorer (which is pretty much any program running at medium integrity level or higher).

One may, therefore, set the UAC slider to the highest setting ('Always notify'). However, not even such a setting is recommended. As exemplified in a recent discussion in the 'The DMZ' chatroom, many people will recommend to use a standard Windows account for everyday work. If elevated permissions are needed, a UAC prompt will ask for the password of the administrator account and only then allow a process to run, but this time under a different account (the administrator account, rather than the standard account).

How does this protect against malware getting elevated privileges more than using the administrator account with the highest UAC settings?

I can see two possible options and I don't have enough knowledge to say which - if any - is correct:

1. Under the administrator account with highest UAC setting malware can inject arbitrary code into Explorer. Unlike in case with the default UAC settings this malware won't get elevated permissions immediately, but will still get them at the first time the user elevates Explorer, for example because they need to copy a file to a protected location. If, instead of using the administrator account, the user is logged in a standard account the same thing will happen: malicious code will be run under the administrator account with elevated permissions the moment the user elevates Explorer, with the only difference being that the user will have to enter a password into the UAC prompt.

2. As suggested in the chatroom elevating Explorer spawns a new process and therefore - provided that Explorer is elevated by UAC and not automatically, as in the default settings - no threats injected by malware can get elevated with Explorer. Again, this would render using the administrator account with highest UAC settings no different from running a standard account.

Is there a 3rd option I overlooked? Does using the standard Windows account offer any security benefits to using the administrator account with highest UAC settings?

Answer 1

There are a few reasons. The main reason, from a policy standpoint, is that Microsoft does not consider UAC to be a "security boundary"; that is, UAC bypasses are not treated as the same class of bug as, say, cross-user attacks (when the attacker is not an admin). As you might expect, this means that the UAC bypasses which have been found have not always been fixed, or not promptly. It's true that allowing any form of auto-elevate is dangerous, with many easy bypasses. However, even without auto-elevate, there's been at least one complete bypass.

Another is that it can sometimes be useful to have a clear distinction between privileged and unprivileged users. Breaking this distinction can lead to breakdowns of certain security models. For example, consider a program that writes to an Administrators-only location (of any kind; it could be a registry key, directory, device driver, whatever) and creates a new object. The program can safely assume that it's running as an Administrator, so if it wants to ensure the current user has access to the new object - e.g. by setting the "Creator/Owner" principal to have full access - it's assuming that it's not granting access to any non-admins. Yet in fact it is; your group memberships change (sort of) when you elevate with UAC, but your user identity doesn't, so something that you own when elevated is still owned by you (and all code running as you) when not elevated. There are ways to resolve this (one of which - mandatory integrity control - is implemented automatically by Windows for certain object types) but for certain types of interaction that might not work (e.g. if the new object checks your identity only). Yes, there have been real security bugs like this (though they're relatively rare).

---

As for your "two possible options", neither is correct. Elevation always requires spawning another process (or calling out to, via RPC, another process that is already elevated). The difference is, if auto-elevation is enabled, a trusted process can just invisibly say "hey, I know I'm not elevated, but I want to do {thing that needs elevation} with this new process" and the OS will invisibly go "OK, that new process is allowed to auto-elevate, here's its admin token, have fun". However, if auto-elevation is disabled, then the user will be prompted with the full command line of the new process, and assuming they didn't expect it (or that the command looks fishy), they won't approve it.

However, there are many other ways to bypass UAC than through Explorer. See https://cqureacademy.com/cqure-labs/cqlabs-how-uac-bypass-methods-really-work-by-adrian-denkiewicz, and then Ctrl+F for "Always Notify".