Permissions, user rights, privileges, and UAC: Authority concepts that are not the same thing

1. Core mechanism

User Rights Assignment covers two different decisions: which logon types an account can use, and which privileges it is assigned. A logon right permits or denies the selected logon type; the privilege list belongs to the token created after successful logon. UAC affects the token used for an operation. MIC and the DACL evaluate object access; some documented operations can use a separate, operation-specific privilege path.

Interfaces and specifications

• Permission/access right: an operation requested on a securable object; evaluated against DACL ACEs.
• User Rights Assignment: logon-right and privilege assignments in device policy.
• Privilege: a special capability for a local system task or resource; it must be present in the token and, where required, enabled.
• UAC: under Admin Approval Mode and applicable account and policy conditions, separates standard and administrator tokens and governs elevation.
• Mandatory Integrity Control: compares the token integrity level with the object's mandatory label before DACL evaluation.

Name the five distinct decision layers

Read permission on a file is an object-specific access right. SeBackupPrivilege is a privilege for a particular system task. 'Log on as a service' is a logon right. UAC affects which token starts an operation. An integrity label can block certain writes even when the DACL contains an Allow ACE.

Calling all of these concepts 'admin rights' makes failures impossible to diagnose. The useful question is which layer rejected the operation and which token was effective.

Separate logon eligibility, token selection and access paths

Local or Group Policy determines whether an account can log on using a particular type, such as a service logon. That logon right is not an entry added to the token’s privilege list. After successful logon, privileges assigned to the account and its groups are included in the access token. Depending on UAC conditions, an administrator account may have a filtered standard token and an administrator token; the operation runs within the limits of the token used.

Object access first identifies the effective token of the process or impersonating thread. For ordinary file access, MIC evaluates token integrity and the object’s mandatory label policy before the DACL; the DACL compares the requested access mask against active SIDs. A documented backup operation using SeBackupPrivilege is a bounded alternative path, not a universal step after every DACL check. Operation semantics, privilege presence and enabled state determine that path. The map distinguishes these paths; it does not calculate a Windows access result.

DACL Allow is not the result of every layer

The artifact's DACL grants Authenticated Users generic read and write. Even so, the Medium mandatory label and No-Write-Up policy in the SACL can stop a low-integrity token from writing at the MIC stage.

This is not a complete effective-access calculation. A definitive result requires generic mapping, the requested mask, inheritance, the actual token, and the object type. The artifact shows only that MIC and the DACL are separate controls.

Relate privilege coverage to operation

For backup purposes, SeBackupPrivilege can provide a documented read capability independent of the normal ACL on persistent objects such as files and directories. This is not Full Control and does not automatically grant other access requests.

Assignment to the account, presence in the effective token and enabled state are different conditions. A local operation with documented backup semantics can use the supported read capability; ordinary file requests do not all use that path. This does not change privilege assignments on another host, directory group membership or the file’s DACL.

State and data flow

1. Local or Group Policy separately defines allow/deny conditions for the selected logon type and privilege assignments.
2. After successful logon, account/group SIDs and assigned privileges enter the token; a logon right is not a token privilege.
3. Depending on UAC policy and account type, a filtered standard token and an administrator token may be separated.
4. The effective token is selected for the process or impersonating thread.
5. For ordinary object access, MIC evaluates effective-token integrity and the target’s mandatory label policy before the DACL.
6. The ordinary DACL path compares the requested operation’s access mask with ACEs applicable to active token SIDs.
7. A separate documented privilege path evaluates operation semantics and privilege presence/enabled state in the local token; it is not used for every request.

2. Exploitation

Broken trust assumption

The broken assumption is: if the DACL denies read access, no local privilege can provide another documented path to the file.

Technical prerequisites

• SeBackupPrivilege is present in the token on the target host.
• The privilege is enabled during the operation.
• The call requests access using backup semantics.
• Ability to execute code in this token context.
• The target is governed by that same host's privilege model.

Exploitation mechanism

For backup purposes, SeBackupPrivilege can provide documented read access independent of the normal ACL on files, directories, and similar persistent objects. This is not GENERIC_ALL: other requests remain subject to ACLs and other controls. Assigning the privilege changes neither directory membership nor rights on another host.

Do not turn a bounded exception into a general bypass

Privilege is effective only in documented operation and scope. It does not mean that every API call uses it.

A valid test must therefore record the call semantics, active privilege state, and target host separately.

3. Defense & Detection

Telemetry scope

• Audit Sensitive Privilege Use is associated with the 4673/4674 event family.
• Auditing Backup/Restore privilege use additionally requires the Audit the use of Backup and Restore privilege setting.
• An object SACL is not a prerequisite for these privilege-use events.
• Microsoft classifies this audit subcategory as high volume, so enable it in a pilot scope first.

Events and relevant fields

• 4673: SubjectUserSid, SubjectUserName, SubjectDomainName, SubjectLogonId, ObjectServer, Service, PrivilegeList, ProcessId and ProcessName.
• 4674: ObjectType, ObjectName, HandleId, and AccessMask in addition to the subject fields.
• In 4674, AccessMask is decimal and depends on the object server and type; do not translate it into a universal right name.
• 4673/4674 identify a class of operation attempt; alone, they prove neither that a DACL was bypassed nor that data was read.

Treat attempts as evidence, not outcomes

4673/4674 can provide context for an operation attempt involving a privilege, but they do not prove that a DACL was bypassed or that target data was obtained.

Evaluate the session through SubjectLogonId, the executable through ProcessName, and the outcome through additional target-specific telemetry.

Detection logic · XPath

*[System[(EventID=4673 or EventID=4674)]]

Query assumptions

• Add a PrivilegeList subfilter only after verifying how the target backend represents the field.
• Do not translate AccessMask into a universal right name without knowing the object server and type.
• The query was not run on a real Windows host; no data set or threshold was defined.

False positives

• Backup software, security products, and LSASS can produce routine sensitive-privilege use.
• This audit subcategory can generate a high event volume.
• Negative boundary: if auditing is disabled, the absence of an event does not show that the privilege was unused.
• 4673/4674 do not by themselves show that the operation successfully read data.

Hardening

• Constrain SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, and SeImpersonatePrivilege assignments by role.
• Separate service-account use from interactive administration.
• Enable Success/Failure auditing on pilot hosts first; measure event volume and establish the expected process list.
• Assess the volume impact of the additional Backup/Restore audit setting; verify application function after the change and restore the previous assignment or audit policy if disruption occurs.

Read the examples

O:SYG:SYD:(A;;GRGW;;;AU)S:(ML;;NW;;;ME)

Two reality checks

Assumption: An Allow ACE in the DACL guarantees access.

In fact: Mandatory Integrity Control is evaluated before the DACL. A low-integrity token may still be unable to write because of the Medium mandatory label and No-Write-Up policy.

Assumption: Holding a privilege means having Full Control over an object.

In fact: Each privilege applies to a specific operation and scope. For example, SeBackupPrivilege's documented read capability does not automatically cover other access requests, other hosts, or directory membership.

Sources

• Microsoft · Privileges
  Introduction and the first two items; the difference between a privilege and an object access right.
• Microsoft · User Rights Assignment
  Introduction and table; the scope of logon rights and privileges.
• Microsoft · How DACLs control access to an object
  DACL, access-token, and impersonation context.
• Microsoft · Mandatory Integrity Control
  Integrity Labels and Mandatory Policy; MIC evaluation before the DACL.
• Microsoft · How UAC works
  Sign-in process; separation of standard and administrator tokens.
• Microsoft · ACE strings
  ACE types, generic rights and mandatory label rights: ML and NW.
• Microsoft · 4673(S, F) A privileged service was called
  Event XML, Field Descriptions and Version 0.
• Microsoft · 4674(S, F) An operation was attempted on a privileged object
  Event XML, Requested Operation, and AccessMask boundaries.