Privilege Without Exploits: Gaining SYSTEM with SeTcbPrivilege
Windows · Privilege Escalation · Download the full PDF ↓
SeTcbPrivilege, better known by its friendly name “Act as part of the operating system”, is one of the most sensitive rights a Windows account can hold. When a process has it, it can impersonate any user and act with the same level of trust as the operating system itself. It is rare in the wild, but a misconfiguration that hands it to the wrong account can turn a normal user into a full SYSTEM compromise.
This is a writeup about why the privilege is so powerful, the two broad ways it gets abused, and, most importantly for anyone defending a network, how to notice when it is being misused and shut it down.
What SeTcbPrivilege actually is
It is a built-in Windows user right that lets a process act as part of the operating system. Processes that hold it can step around certain security checks, impersonate any user, and talk directly to core OS functions. That level of trust is normally reserved for critical processes such as the Local Security Authority Subsystem (LSASS), not for ordinary user accounts.
- Running code under any security context
- Impersonating SYSTEM-level tokens
- Sitting inside the authentication flow
Two ways it gets abused
There are two broad routes from “this account has SeTcbPrivilege” to “this account is running as SYSTEM”. The step-by-step detail for each, including the proof-of-concept and the exact API calls, is in the PDF linked above. Here is the shape of each one and, more usefully, what it leaves behind.
A Windows service set to run as LocalSystem runs as SYSTEM. With this privilege in play, even a non-administrator can register and start one. A public proof-of-concept tool (Antonio Cocomazzi’s TcbElevation) shows the idea in practice.
What it leaves behind: a brand new service appearing (Event ID 7045), and a SYSTEM process launching from a binary that has no business being there.
Instead of a new service, an existing SYSTEM process’s token is duplicated and reused to launch a fresh process as SYSTEM. It is quieter in some ways, but harder to pull off: it needs enough access to open a protected process such as lsass.exe, so in practice it usually needs local admin as well.
What it leaves behind: use of the standard Windows token APIs, which is exactly what EDR and Sysmon token monitoring are built to watch.
Side by side
| Method | Needs SeTcb | Leaves an artifact | Shows in logs | Needs a SYSTEM token | Needs extra rights |
|---|---|---|---|---|---|
| Service creation | Yes | Yes | Yes (Event ID 7045) | No | No |
| Token impersonation | Yes | No | Possibly | Yes | Yes |
Spotting it
The privilege is powerful, but neither path is invisible. As a defender:
- Audit which accounts currently hold SeTcbPrivilege in the first place
- Monitor service-installation logs, Event ID 7045 in particular
- Alert on SYSTEM-level processes starting from unusual binaries
- Use Sysmon or your EDR to watch token-related API activity
Shutting it down
- Apply least privilege across every account, so this right is never handed out casually
- Review Group Policy and local privilege assignments on a schedule
- Limit who can touch process and token manipulation APIs
- Audit any third-party software that asks for SeTcbPrivilege, and ask why it needs it
Final thoughts
SeTcbPrivilege is powerful and easy to overlook. Both the service-creation and token-impersonation paths are realistic in a real environment. Checking who actually holds this right is one of the cheaper things you can do to close off a route to lateral movement or a full system compromise.