User Account Control: Standard User versus Protected Administrator Accounts
Introduced in Windows Vista, User Account Control (UAC) is an umbrella term for a collection of technologies — including registry and file virtualization, integrity levels, and elevation prompts — making it easier to use Windows with less privileges. In this article, I’ll explain why using a standard user account is more secure than a UAC Protected Administrator.
Protected Administrator (PA) accounts were designed with consumers in mind, allowing Windows to be used with standard user rights most of the time, but privileges can be elevated to full administrator rights without needing to know the credentials of a separate user account. UAC adds the required rights to the user’s security token if the user approves the elevation request.
Microsoft recommends the use of standard user accounts, and a password for an administrator account must be entered if elevated privileges are required. In Vista and later versions of Windows, standard user accounts can be used to perform Windows tasks, such as changing the time zone and adding devices with signed drivers, that were limited to members of the Power Users and Administrators group in Windows XP. This important change makes it more realistic for organizations to remove administrative privileges from users.
UAC is not a security boundary
Although UAC Protected Administrator accounts might seem like an acceptable compromise for organizations also, it’s important to understand that UAC isn’t a security boundary and was designed to balance security and usability, rather than create an impermeable security boundary.
Furthermore in Windows 7 and later, many Windows tasks and programs don’t prompt Protected Administrators before silently elevating themselves to run with elevated privileges, potentially opening a door for malware to gain privileged access without users noticing. Although it’s possible to configure UAC to always notify, as was the default UAC setting in Windows Vista.
It should also be noted that while UAC configuration can be centrally managed or manually set to always notify, administrative users can potentially disable Group Policy processing, manually change UAC settings, or turn off UAC completely.
Bypass UAC using DLL hijacking techniques
While Microsoft has patched many vulnerabilities that enabled hackers to easily abuse the way Windows handles loading dynamic-link libraries (DLLs), zero-day exploits and out-of-the-box UAC settings in Windows 7 (and later) could still lead to UAC being bypassed when a Protected Administrator account is used.
IT staff and privileged credentials
Hackers are increasingly targeting IT staff via social networking sites, such as LinkedIn, as they often prove to be an easy point of entry to a corporate network. It’s long been standard practice in many organizations to grant IT staff not only local administrative rights to their workstations, but also domain administrative privileges.
Best practice dictates that domain administrative accounts should only be used to log in to domain controllers, but partly due to the default security configuration in Windows, the easiest and quickest way to give IT staff administrative access to all servers and client devices on a domain is to add their user accounts to the Domain Admins group.
Exposing domain administrator credentials
But because of the way Windows caches account credentials by default, allowing users to log in even if a domain controller isn’t present to authenticate the request, once a user is given local administrative rights to a device where a domain administrator has previously logged on, it’s possible to compromise the Security Accounts Manager (SAM) database, and retrieve password hashes for highly privileged domain accounts.
You are owned, you just don’t know it yet
The best way to protect against the possibility of being exposed to malware that attempts to circumvent UAC is to deploy standard user accounts, because they automatically block auto-elevation of Windows tasks, and also prevent users from diluting security by changing UAC settings or bypassing Group Policy controls.
Additionally, while most organizations deploy antivirus, and some application whitelisting to further protect against malicious processes, it’s not always possible to say with one hundred percent certainty whether a device is compromised. So if security is a priority, I recommend that you assume your network is compromised, and take measures to protect privileged accounts accordingly.
More in Security
Git Releases New Security Updates to Block Remote Code Execution Attacks
Jan 18, 2023 | Rabia Noureen
PyTorch Discloses Internal Dependency Compromised with Malicious Code
Jan 4, 2023 | Rabia Noureen
How to Create Conditional Access Policies using PowerShell
Jan 4, 2023 | Liam Cleary
Bitwarden – An Open-Source Alternative to LastPass for Business and Personal Use
Jan 3, 2023 | Russell Smith
LastPass Confirms Hackers Stole Personal Data and Encrypted Password Vaults
Dec 23, 2022 | Rabia Noureen
How Does eDiscovery Work Within Microsoft 365?
Dec 23, 2022 | Liam Cleary
Most popular on petri