SeTcbPrivilege

SeTcbPrivilege is the Act as part of the operating system right.

This is one of the most sensitive Windows privileges. A process with this right can operate as a trusted part of the local security authority model and may be able to assume identities or interact with authentication flows in ways normal services cannot.

In practice, this privilege is rare. It is normally reserved for core Windows components and a small number of security or authentication products. Do not assume there is a standard one-command exploit just because the privilege appears.

The operator primitive is trust at the authentication boundary. Abuse usually requires code execution inside a process or service account that has the right, plus a technique that interacts with LSA or token creation behavior.

When enumerating SeTcbPrivilege opportunities, try to identify:

• Whether the privilege is present in the current token
• Which service or account received the right
• Whether the process is a legitimate authentication/security component
• Whether the account is overprivileged
• Whether custom software runs with the privilege
• Whether token creation, impersonation, or LSA interaction is exposed
• Whether safer escalation paths already exist

Enumeration

Check current privileges:

whoami /priv

Look for:

SeTcbPrivilege

Check local security policy export:

secedit /export /cfg C:\Users\Public\secpol.cfg
findstr /i "SeTcbPrivilege" C:\Users\Public\secpol.cfg

List services and service accounts:

wmic service get name,displayname,startname,pathname

Check running processes for unusual security products or custom services:

tasklist /v

Interesting findings include:

• SeTcbPrivilege present in the token
• Non-standard service account has the right
• Custom service runs with the right
• Security product exposes local code execution or plugin loading
• Account also has SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege

Once the holder is identified, focus on how code can execute under that account. The privilege itself is not enough without a usable abuse path.

Exploit

No generic lab-safe exploit is included here because SeTcbPrivilege abuse depends heavily on the process, service account, and exposed LSA/token behavior.

A practical assessment workflow is:

1. Identify the account or service holding SeTcbPrivilege.
2. Determine whether the current operator can execute code as that account.
3. Inspect the software running under that account for plugins, writable paths, service misconfiguration, or local RPC interfaces.
4. Check whether the process exposes token creation, impersonation, or authentication package behavior.

If custom code execution is already available in a process with SeTcbPrivilege, treat the host as highly compromised and investigate token/LSA abuse in a lab that matches the target build.

Remediation

Patch the weakness:

• Keep Act as part of the operating system empty unless a vendor explicitly requires it.
• Remove the right from custom service accounts unless the design has been reviewed.
• Prefer managed service accounts with narrowly scoped rights.
• Review security products that request this privilege and validate the vendor requirement.
• Isolate hosts running software that legitimately needs this right.

Detect abuse:

• Monitor assignments of SeTcbPrivilege in local and domain policy.
• Alert when non-standard accounts receive the right.
• Monitor service creation or binary changes for services running under accounts with this privilege.
• Review Security Event IDs 4672, 4673, and 4674.
• Hunt for unexpected child processes from authentication or security services.