Windows User Accounts (Administrator vs. Standard User, UAC)

#UAC Is Not Just a Popup—It's Your Kernel's Last Stand#link

When a banking trojan tricks a standard user into clicking a malicious attachment, it's limited to user-mode actions—unless that user is a local administrator with UAC set to "Never notify." Windows account types and User Account Control (UAC) form a critical privilege boundary. This lesson dissects the differences between Administrator and Standard user tokens, how UAC actually splits the token, and how to configure the consent prompt for maximum security without killing usability.

The Split Token: How UAC Works Under the Hood

When an administrator logs in, Windows creates two tokens: a filtered standard-user token and a linked elevated token. Most processes run with the filtered token unless elevation is explicitly requested. UAC's consent prompt then switches to the full admin token. For standard users, only one token exists, and elevation requires credential entry for an administrator account. This architecture is why Windows ≥ Vista can run admins with reduced exposure—if you respect it.

A Medium integrity level means the process is running with a filtered token. An elevated Command Prompt shows High Mandatory Level. UAC enforces that processes cannot write to higher-integrity objects, providing a barrier even for admins.

Local Administrator vs. Standard User: Security Implications

A standard user cannot install kernel drivers, write to Program Files, or modify system registry hives without elevation. An attacker gaining a standard user shell must perform privilege escalation to gain full control. If that same victim was an admin, many attacks succeed with just a consent prompt bypass or token manipulation. Thus, the baseline: all day-to-day accounts, including IT staff, should be Standard users. A separate privileged account is used only for administrative tasks.

# Add a new local admin user, then immediately demote them to standard
New-LocalUser -Name "admin.helper" -Password (Read-Host -AsSecureString)
Add-LocalGroupMember -Group "Administrators" -Member "admin.helper"
# ... but never log in daily; use runas or separate session for admin work
Remove-LocalGroupMember -Group "Administrators" -Member "admin.helper"
Add-LocalGroupMember -Group "Users" -Member "admin.helper"

The PowerShell above creates a privileged account, but demonstrates the concept that after creation, it's demoted to standard. In real deployments, IT staff use two accounts: jdoe (standard) and jdoe-admin (administrator, enrolled in MFA).

Hardening UAC: Registry and Group Policy

UAC settings are stored in the registry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Key values: ConsentPromptBehaviorAdmin, EnableLUA, and PromptOnSecureDesktop. Enabling secure desktop (PromptOnSecureDesktop=1) isolates the elevation prompt from malware keystroke interception. Via Group Policy: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, configure 'User Account Control: Behavior of the elevation prompt…' to 'Prompt for credentials on the secure desktop' for maximum protection.

• ▪Convert all daily driver accounts to standard users; create separate admin accounts.
• ▪Set UAC to 'Always notify' or at minimum 'Prompt for consent for non-Windows binaries'.
• ▪Enable secure desktop for elevation prompts (PromptOnSecureDesktop=1).
• ▪Use Group Policy to enforce UAC settings across the domain.