Active Directory Dangerous User Rights GPO SeDebug SeTcb: SeLoadDriver Privilege Escalation to SYSTEM

What Is a Dangerous User Rights Assignment in Active Directory

Group Policy doesn't only push software or map drives — its Security Settings container can also grant local user rights ("privileges" in the Windows access-token model, distinct from object permissions) to any security principal, including Authenticated Users, Domain Users, or a custom group. When a GPO's [Privilege Rights] section assigns a high-impact privilege such as SeDebugPrivilege, SeLoadDriverPrivilege, or SeTcbPrivilege to accounts that are not local administrators, every computer the GPO applies to inherits a direct, no-exploit-required path from "any domain account" to SYSTEM. Security teams and auditors increasingly flag this pattern — dangerous user rights granted by GPO — as a distinct Active Directory finding, separate from the more familiar "GPO adds a user to local Administrators" misconfiguration.

This is not a vulnerability in Windows — it's a Group Policy authoring mistake, usually introduced to unblock a monitoring agent, a backup product, or a helpdesk tool that legitimately needs elevated rights, then left in place (or copied into unrelated GPOs) long after the original justification is gone. GPO misconfigurations are one of the more common ways Group Policy becomes an attack vector, precisely because they are silent: nothing breaks, no alert fires, and the GPO keeps applying on every policy refresh cycle.

The blast radius scales with the GPO's link, not with how the assignment was justified. A GPO built to fix one server's monitoring agent, then linked at an OU or the domain root for convenience, quietly hands the same right to every computer under that link — turning a narrow, defensible exception into a domain-wide escalation path that nobody signed off on, and one more variant of dangerous group nesting's hidden paths to Domain Admin.

Why Active Directory Treats These GPO-Assigned User Rights as Dangerous

Windows enforces roughly three dozen user rights through the access token. Most are benign in the wrong hands — "Change the time zone" is not a path to SYSTEM. Three of them are the exception.

SeDebugPrivilege ("Debug programs")

SeDebugPrivilege lets its holder open a handle to any process or thread on the machine, bypassing the access check that would otherwise block a non-owner from touching another user's process — including processes owned by NT AUTHORITY\SYSTEM. Because LSASS runs as SYSTEM and holds cached credential material in memory, an account with SeDebugPrivilege can open a handle to LSASS and dump usable credentials from it — the same primitive tools like Mimikatz's sekurlsa module rely on, and the same primitive behind living-off-the-land techniques such as dumping LSASS via comsvcs.dll's MiniDump export. By default, only Administrators hold this right.

SeLoadDriverPrivilege ("Load and unload device drivers")

SeLoadDriverPrivilege allows the holder to load a kernel-mode driver via the NtLoadDriver() API. Kernel drivers run with no security boundary against the rest of the OS, so an account with this right can register and load a known-vulnerable signed driver (the Capcom.sys driver is a well-documented example) and use it as a primitive to read/write kernel memory or run arbitrary code as SYSTEM — a technique commonly called BYOVD (Bring Your Own Vulnerable Driver). This path matters even against hosts with modern EDR, since a signed vulnerable driver is trusted by code-integrity checks that block unsigned code.

SeTcbPrivilege ("Act as part of the operating system")

SeTcbPrivilege is the most direct of the three: it lets the holder call the authentication APIs normally reserved for the Windows Trusted Computing Base, which includes impersonating any account on the system, SYSTEM included. An attacker holding this right doesn't need to dump a credential or load a driver — they can create a service that calls the trusted logon APIs directly and impersonate SYSTEM outright. On a properly configured system, no non-administrator account should ever hold SeTcbPrivilege.

🚨 Danger: all three rights are treated as critical because none of them require a code-execution exploit. If the GPO grants the right, the escalation is a documented, supported use of a Windows API — not a bug.

The Attack Chain: From GPO Misconfiguration to SYSTEM

Step 1 — Discover the assignment

An attacker who already holds any domain foothold (a phished user, a low-privilege service account) enumerates the GPOs applied to interesting OUs — domain controllers, tier-0 servers, jump hosts — and reads the [Privilege Rights] section of each GPO's GptTmpl.inf in SYSVOL, which any authenticated user can read by default:

# Enumerate every GPO's User Rights Assignment section for the three critical rights
Get-GPO -All | ForEach-Object {
    $report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
    $report.GPO.Computer.ExtensionData.Extension.UserRightsAssignment |
        Where-Object { $_.Name -match 'SeDebugPrivilege|SeLoadDriverPrivilege|SeTcbPrivilege' } |
        Select-Object @{n='GPO';e={$report.GPO.Name}}, Name, Member
}

Step 2 — Confirm the account is in scope

The attacker checks whether their current account — or a group they control, including a broad group like Authenticated Users if the GPO is scoped that loosely — is listed as a member of the assignment, and which computers the GPO links to. A GPO linked at the domain root or at an OU containing domain controllers turns this from "interesting" into "domain-ending."

Step 3 — Weaponize the right

• With SeDebugPrivilege: open a handle on lsass.exe and dump credential material for offline cracking or replay.
• With SeLoadDriverPrivilege: register and load a vulnerable signed driver, then exploit it for a SYSTEM shell.
• With SeTcbPrivilege: call the trusted logon APIs to impersonate SYSTEM directly, no driver or credential dump required.

Any of the three converts "domain user in this OU" into "local SYSTEM on every machine the GPO touches" — which, if the OU includes tier-0 assets, is functionally equivalent to an attack path straight to Domain Admin. From local SYSTEM on a domain controller, the attacker is one step away from DCSync rights and the domain's entire credential set.

Detection

Active Directory Monitoring covers the broader set of event IDs worth alerting on if you're building detection out further than just these three privileges. Elastic's public detection-rules repository also ships a "Group Policy Abuse for Privilege Addition" rule that watches for the AD directory-service-change event (Event ID 5136) fired when a GPO's Security Client-Side Extension GUID is touched — the signal that its GptTmpl.inf content, including [Privilege Rights], has changed — flagging exactly this class of high-impact right (SeDebugPrivilege, SeTakeOwnershipPrivilege, SeEnableDelegationPrivilege, SeImpersonatePrivilege) — a useful reference even outside Elastic Security. Whichever source you alert from, treat any hit as high-severity: there is no legitimate reason for these three rights to reach a non-admin account through routine policy drift.

Remediation

1. Inventory every GPO that touches [Privilege Rights]. Export every GPO with Get-GPOReport -All -ReportType Xml and search for UserRightsAssignment nodes; don't assume only "security baseline" GPOs touch this section.
2. Restrict the three critical rights to Administrators. CIS benchmarks for Windows Server and Windows 11 both set "Debug programs" (SeDebugPrivilege) to Administrators only as a baseline recommendation; apply the same standard to SeLoadDriverPrivilege and SeTcbPrivilege unless a specific, documented, time-boxed exception exists.
3. Trace any exception to its origin. If a monitoring agent or backup product genuinely needs one of these rights, scope the GPO to the smallest possible security group instead of a broad OU or Authenticated Users, and document the exception with an owner and a review date.
4. Test in an isolated OU before rollout. Roll a tightened User Rights Assignment baseline out to a pilot OU first — some legacy agents fail loudly (and obviously) if a right they depend on is removed, which is a much cheaper discovery than finding out in production.
5. Version-control GPO changes. Treat GptTmpl.inf changes like code changes — a GPO diff/review process turns a silent privilege grant into a reviewable change instead of a surprise.
6. Re-run the sweep on a schedule, not just once. GPOs get copied, inherited, and re-linked over time, and a clean baseline today doesn't guarantee a clean baseline next quarter. Privileged access drift is exactly this pattern: rights creep back in after the original audit closes.

How EtcSec Detects This

EtcSec's Active Directory audit checks every linked GPO's [Privilege Rights] section against the three critical assignments covered here — PRIVILEGE_SEDEBUG_ABUSE, PRIVILEGE_SELOADDRIVER_ABUSE, and PRIVILEGE_SETCB_ABUSE — and flags any non-default SID granted one of them outside the built-in Administrators group, with the GPO name and linked OU so the finding is actionable without a manual Get-GPOReport sweep.