Why elevating the issue won’t always alleviate it

“We’ve done it!” – The majority of your users have admin rights removed, meaning your environment is far more secure than it was before and you’ve successfully mitigated 85% of critical vulnerabilities in Windows. But are you as secure as you think? A surprisingly common pitfall that we come across in the support team are those who, either intentionally or unwittingly, elevate everything. Everything.

As a quick summary, there are two main account types; standard user accounts, and Administrator accounts. A standard user account is relatively locked down – you can’t make any serious overarching changes using a standard user account. An Administrator on the other hand has the keys to the kingdom and can make as many changes as they wish.

Here is where the confusion can begin – since Windows 7 (technically Vista, but we don’t talk about that), every user logs in with standard user rights. The difference being that Administrators have the option to elevate something if they need it to perform a certain action. This is called UAC (or User Account Control), and is responsible for those “Are you sure you wish to install this program?” type warnings you will have seen on your machines.

Unfortunately, instead of taking time and creating tailored Privilege Management policies (that only elevate specific applications), or creating a UAC replacement policy (which audits whenever a user proceeds in allowing their Privilege Management software to elevate an application or process), they instead implement a simple rule which elevates everything on the machine.

The main reasons for this appear to be a lack of understanding in the way that Windows works with regards to Administrator rights, the desire to get Privilege Management software into the environment hastily rather than correctly, or simply that it was just “easier to get Software XYZ to work instead of having to mess about with policies”.

Believe me when I say that I’d rather you gave every single user their local Administrator rights back than use a Privilege Management configuration that elevates everything without warning.

Those are big words (literally; I put them in bold!), especially in a world where we’re trying to remove admin rights from as many users as possible to adhere to the principal of Least Privilege. But you’re actually better off if your users log in as a local Administrator vs logging in with a misconfigured Privilege Management policy that elevates all.

Elevating everything in Windows can cause instability in the operating system, as many components of the OS are not supposed to run with admin rights any more, and doing so can make the machine prone to crashing, especially when explorer.exe is elevated. It can also cause certain programs to be incapable of communication, due to the fact the integrity levels of those processes are no longer compatible with parts of the OS with which they would expect to be able to communicate. At least when running as a real local Administrator with UAC, a user has the chance to cancel any elevation prompts they do not understand or did not explicitly choose to open. This is especially relevant when malware tries to gain admin rights by running via infected content delivered through emails, drive-by downloads and so on.

In the end though, the entire argument is pointless, and is akin to choosing whether you’d like a burglar to enter your house through the front door or an open window. To an attacker, the source of the admin rights does not matter in the slightest. This is why removing admin rights, setting up a well-managed whitelist, and implementing a privilege management solution that is correctly configured to only elevate specific required processes, tasks and scripts, is the best way to secure your endpoints.