Windows privesc: token privileges and UAC

Overview

Token privileges are escalation primitives: SeImpersonate (potato → SYSTEM, common on service accounts), SeBackup/SeRestore (read/write any file), SeDebug (dump LSASS), SeTakeOwnership. Check via whoami /priv. UAC is a convenience split, not a boundary — a 'bypass' is escalation within admin. Fixes: grant privileges sparingly, Credential Guard, protect LSASS.

Why it matters

Token-privilege abuse is why compromising an IIS/SQL service account so often becomes SYSTEM, and dumping LSASS/SAM yields credentials for lateral movement. Knowing UAC isn't a boundary keeps escalation findings accurately scoped.

Core concepts

SeImpersonate. Potato attacks → SYSTEM (service accounts). SeBackup/SeRestore. Read/write any file (SAM, NTDS). SeDebug. Dump LSASS for creds. whoami /priv. Enumerate. UAC. Convenience split, not a boundary. Fix. Sparse privileges, Credential Guard, LSASS protection.

Lesson

The most "Windows-specific" escalation class abuses access-token privileges directly — see the Windows Fundamentals privilege-model lesson for the token basics.

Dangerous token privileges

Check yours with whoami /priv. Several are effectively SYSTEM:

• SeImpersonatePrivilege / SeAssignPrimaryToken → the "potato" family of attacks: trick a SYSTEM process into authenticating to you, impersonate its token, become SYSTEM. Service accounts (IIS, SQL) often hold this — which is why a web/db compromise so often reaches SYSTEM.
• SeBackupPrivilege → read any file (dump the SAM/SYSTEM hives or NTDS.dit).
• SeRestorePrivilege → write any file (overwrite a privileged binary).
• SeDebugPrivilege → open any process and inject (dump LSASS for credentials).
• SeTakeOwnership → take ownership of objects, then re-permission them.

The pattern: a privilege that looks narrow is actually a generic primitive for reading, writing, or impersonating across the trust boundary.

UAC bypasses

UAC is a convenience split (standard + elevated token for admins), not a security boundary — Microsoft says so. Numerous "bypasses" auto-elevate without a prompt (auto-elevating binaries, hijacked registry/COM). In a report, a UAC bypass is escalation within an already-admin account, not crossing a trust boundary — describe it accurately.

The fixes

Grant token privileges sparingly (especially SeImpersonate on service accounts — or use virtual/managed accounts with the modern protections); enable Credential Guard; keep LSASS protected; don't rely on UAC as a boundary.

Summary

Windows token privileges (SeImpersonate, SeBackup/Restore, SeDebug) are generic read/write/impersonate primitives that reach SYSTEM, and UAC is a convenience split rather than a trust boundary. Defend by granting privileges sparingly and protecting credentials in memory.