Overview

SeTcbPrivilege — formally “Act as part of the operating system” — is one of the most powerful Windows privileges in existence. It grants the holder the ability to impersonate any user account on the system — including NT AUTHORITY\SYSTEM — by calling trusted authentication APIs that are normally reserved for the Windows Trusted Computing Base (TCB). When a Domain Administrator mistakenly assigns this privilege to a low-privileged domain user through Group Policy, an attacker who gains access to that account can weaponize the privilege to escalate directly to local administrator without requiring any additional credentials or exploiting any software vulnerability.

This article demonstrates a complete, end-to-end exploitation chain: creating a domain user, assigning SeTcbPrivilege via the Default Domain Policy, verifying the privilege over a WinRM session, and leveraging the open-source tcb-lpe exploit (tcb.exe) to add the compromised account to the local Administrators group — all within a controlled penetration-testing lab built on the ignite.local Active Directory domain.

Table of Contents:

• Introduction
• Lab Environment
• Understanding SeTcbPrivilege
• Creating a Target Domain User
• Opening Group Policy Management
• Editing the Default Domain Policy
• Navigating to User Rights Assignment
• Enabling the Policy Setting
• Adding the User to the Privilege
• Confirming the Policy Assignment
• Forcing a Group Policy Update
• Verifying SeTcbPrivilege over WinRM
• Confirming Standard Group Membership Before Exploitation
• Downloading the tcb-lpe Exploit
• Uploading tcb.exe and Executing the Exploit
• Confirming Local Administrator Privilege
• Mitigation Strategies
  • Restrict SeTcbPrivilege to Required Service Accounts Only
  • Audit User Rights Assignments Regularly
  • Enable Advanced Audit Policy for Privilege Use
  • Monitor Service Control Manager Activity
  • Block Unsigned Executables with Windows Defender Application Control
  • Apply the Principle of Least Privilege
  • Restrict WinRM Access to Administrative Accounts
• Conclusion

Introduction

Windows privilege management forms the cornerstone of the operating system’s security model. Standard domain users operate with a minimal privilege set that restricts their interaction with sensitive system resources. Certain User Rights Assignments, however, create critical attack surfaces when granted to accounts that do not strictly require them. SeTcbPrivilege is the most dangerous of these rights.

Originally intended for components such as the Local Security Authority (LSA) and trusted authentication services, SeTcbPrivilege allows its holder to act as a fully trusted OS component. A process running under a user who holds this right can craft arbitrary logon sessions, impersonate SYSTEM-level tokens, and inject into privileged service contexts — effectively bypassing the user/kernel trust boundary.

In real-world penetration testing, discovering that a domain account holds SeTcbPrivilege represents an immediate critical finding. The exploitation path is straightforward, reliable, and can be completed in seconds using publicly available tooling. Understanding this attack in depth allows both red teamers to demonstrate impact and defenders to identify and remediate the misconfiguration before a real attacker does.

Lab Environment

The lab runs on the ignite.local Active Directory domain, with DC.IGNITE.LOCAL — a Windows Server 2019 machine — serving as the Domain Controller. The target is a Windows host joined to the ignite.local domain, reachable at 192.168.1.15, against which the privilege escalation chain is executed. The attacker operates from a Kali Linux machine, using Evil-WinRM v3.9 to establish a remote shell over WinRM. Supporting tools include net.exe and the Group Policy Management Console (GPMC) on the Domain Controller for user creation and privilege assignment, and tcb-lpe — specifically the precompiled tcb.exe binary authored by CharminDoge — as the exploitation payload delivered to the target.

Understanding SeTcbPrivilege

SeTcbPrivilege (SE_TCB_NAME in the Windows security API) grants a process membership in the Trusted Computing Base — the set of hardware, firmware, and software components that the operating system trusts absolutely when enforcing its security policy. A process holding this privilege gains the following capabilities:

• Call LsaLogonUser to create new logon sessions for any account, including SYSTEM and built-in administrator accounts.
• Impersonate any access token on the system without restriction, regardless of the token’s integrity level.
• Add privileges and modify Security Identifiers (SIDs) in existing access tokens to elevate their effective rights.
• Bypass standard user-mode access checks by presenting a SYSTEM-level token to privileged APIs.
• Interact with the Service Control Manager (SCM) to create and start services that execute arbitrary commands under SYSTEM context.

The tcb-lpe exploit (available at github.com/CharminDoge/tcb-lpe) combines all of the above by hooking AcquireCredentialsHandleW to verify that the privilege is active, connecting to the SCM, creating a transient service with an attacker-specified command line, starting it under SYSTEM, and immediately cleaning up the service entry — leaving no persistent artefact behind.

Creating a Target Domain User

The attacker (or, in a lab setup, the administrator simulating a misconfiguired environment) first creates a new domain user named raaj. On the Domain Controller, an Administrator opens a Command Prompt and runs the following command to add raaj to the domain with the password Password@1:

net user raaj Password@1 /add /domain

The command executes against the domain controller and returns a success message confirming that the user account now exists in Active Directory. At this stage, raaj is a plain Domain Users member with no elevated rights on any machine.

Opening Group Policy Management

To assign SeTcbPrivilege via Group Policy, the attacker opens Server Manager on the Domain Controller, clicks the Tools menu, and selects Group Policy Management from the list of available administrative tools.

Editing the Default Domain Policy

Inside the Group Policy Management console, the attacker expands the tree to Forest: ignite.local → Domains → ignite.local. Right-clicking Default Domain Policy — the policy that applies to all domain objects by default — reveals a context menu. The attacker selects Edit… to open the Group Policy Management Editor.

Navigating to User Rights Assignment

Inside the Group Policy Management Editor, the attacker follows this navigation path to reach the privilege settings:

Computer Configuration

  └─ Policies

       └─ Windows Settings

            └─ Security Settings

                 └─ Local Policies

                      └─ User Rights Assignment

The right-hand pane displays all user rights that the policy can define. The attacker locates Act as part of the operating system — currently set to Not Defined — and double-clicks it to open its properties dialog.

Enabling the Policy Setting

The Act opens as part of the operating system Properties dialog box. The attacker checks the Define this policy settings checkbox to activate the policy, then clicks Add User or Group… to begin adding the target account.

Adding the User to the Privilege

The Add User or Group dialog appears. The attacker types the domain-qualified account name IGNITE\raaj into the User and group names field and clicks OK.

Confirming the Policy Assignment

The policy properties dialog now shows IGNITE\raaj listed under the defined settings. The attacker clicks Apply and then OK to save the configuration. The Default Domain Policy now grants SeTcbPrivilege to the raaj account across the entire ignite.local domain.

Forcing a Group Policy Update

To apply the policy change immediately without waiting for the default 90-minute refresh cycle, the attacker runs the following command on the Domain Controller:

gpupdate /force

Both Computer Policy and User Policy update successfully, confirming that the new SeTcbPrivilege assignment is now active across the domain.

Verifying SeTcbPrivilege over WinRM

From the Kali Linux attacker machine, the attacker connects to the target machine at 192.168.1.15 using Evil-WinRM with the raaj credentials:

evil-winrm -i 192.168.1.15 -u raaj -p Password@1

After establishing the shell, the attacker runs whoami /priv to inspect the current privilege set. The output confirms that SeTcbPrivilege (Act as part of the operating system) is present and in the Enabled state, confirming that the Group Policy assignment propagated correctly to the target machine.

Confirming Standard Group Membership Before Exploitation

Before running the exploit, the attacker verifies raaj’s current group membership using the following command inside the Evil-WinRM shell:

net user raaj

The output shows that raaj belongs only to Remote Management Use (which allows WinRM access) and Domain Users. The account holds no local administrative rights on the target machine — establishing the baseline from which the privilege escalation will occur.

Downloading the tcb-lpe Exploit

The attacker browses to the GitHub release page for CharminDoge’s tcb-lpe project at the following URL:

https://github.com/CharminDoge/tcb-lpe/releases/tag/v1.0.0

The latest release (v1.0.0, published October 19, 2025) provides a precompiled binary named tcb.exe. The attacker downloads tcb.exe (1.67 MB) to the Kali machine’s Downloads directory. The binary accepts a single argument — the full command line to execute under SYSTEM context.

Uploading tcb.exe and Executing the Exploit

Back in the Evil-WinRM shell, the attacker uploads tcb.exe from the Kali machine to the raaj user’s Documents directory on the target:

upload /root/Downloads/tcb.exe

Evil-WinRM transfers the full 2,331,304 bytes successfully. The attacker then executes tcb.exe, passing a command that adds raaj to the local Administrators group via cmd.exe:

.\tcb.exe "C:\Windows\system32\cmd.exe /c net localgroup administrators raaj /add"

The exploit output confirms each stage of execution: SeTcbPrivilege is detected and enabled, AcquireCredentialsHandleW is hooked, a connection to the Service Control Manager is established, a service named AAATcb is created with the supplied command, the service starts and executes the command, and the service is deleted to clean up. Despite the StartService warning (the service exits immediately after running the command, which is expected behaviour), the net localgroup command executes successfully under SYSTEM context.

Confirming Local Administrator Privilege

The attacker runs net user raaj again to verify the result of the exploitation:

net user raaj

The Local Group Memberships field now shows Administrators alongside Remote Management Use. The raaj account — which was previously a plain domain user — has been successfully elevated to local administrator on the target machine, purely by leveraging the SeTcbPrivilege right. The attacker can now run commands as Administrator, access sensitive files, dump credentials, and pivot further through the network.

Mitigation Strategies

Restrict SeTcbPrivilege to Required Service Accounts Only

SeTcbPrivilege must never appear in any User Rights Assignment policy for ordinary users or non-service accounts. Review all Group Policy Objects across the domain using the following PowerShell command from an administrative workstation:

Get-GPOReport -All -ReportType XML | Select-String “SeTcbPrivilege”

Any GPO that grants this privilege to accounts other than explicitly required service accounts must be corrected immediately.

Audit User Rights Assignments Regularly

Schedule periodic audits of User Rights Assignments across all GPOs using the Group Policy Management Console and automated scripts. Integrate these audits into the organisation’s vulnerability management program and flag any newly added SeTcbPrivilege grants as critical findings.

Enable Advanced Audit Policy for Privilege Use

Configure the Advanced Audit Policy to log Sensitive Privilege Use events. Enable the following audit subcategory on all domain-joined machines:

Audit Sensitive Privilege Use → Success and Failure

Windows generates Event ID 4672 (Special privileges assigned to new logon) and Event ID 4673 (A privileged service was called) when SeTcbPrivilege is exercised, providing visibility into exploitation attempts.

Monitor Service Control Manager Activity

Enable auditing for Windows Service events. Event ID 7045 (A new service was installed) appearing alongside Event ID 4672 from the same account is a strong indicator of tcb-lpe style exploitation. Correlate these events in a SIEM to generate high-priority alerts.

Block Unsigned Executables with Windows Defender Application Control

Deploy Windows Defender Application Control (WDAC) policies that block unsigned or untrusted executables from running on domain-joined machines. The tcb.exe binary is unsigned and would be blocked by a correctly configured WDAC policy before it executes.

Apply the Principle of Least Privilege

Regularly review and enforce least privilege across all user accounts, service accounts, and Group Policy assignments. No account used for day-to-day activity should hold SeTcbPrivilege, SeDebugPrivilege, or SeImpersonatePrivilege unless the operational requirement is explicitly documented and approved.

Restrict WinRM Access to Administrative Accounts

Limit membership in the Remote Management Use group to explicitly trusted administrative accounts. Prevent low-privileged domain users from establishing WinRM sessions by configuring a restrictive WinRM session configuration policy. This eliminates the attacker’s initial remote shell even when the underlying privilege misconfiguration exists.

Conclusion

SeTcbPrivilege is not a vulnerability in Windows — it is a powerful, legitimate operating system capability that the OS intentionally protects through the User Rights Assignment framework. The vulnerability lies entirely in misconfiguration: granting this right to any account that does not strictly require it creates an immediate, exploitable path to privilege escalation.

This article demonstrated that assigning SeTcbPrivilege to a standard domain user via Group Policy, and then gaining remote shell access to that account, allows an attacker to escalate to local administrator in a matter of seconds using the publicly available tcb-lpe exploit. The exploit requires no additional vulnerabilities, no credential theft, and leaves no persistent artefact on disk after execution.

Defenders must treat any detection of SeTcbPrivilege on non-service accounts as a critical finding. The remediation steps outlined in this article — privilege auditing, advanced audit logging, WDAC enforcement, and WinRM access restriction — form a layered defence that significantly reduces both the likelihood of exploitation and the time to detection when exploitation does occur.