Windows privilege escalation

A document service needs to write reports. Does that mean everyone who can start it should be able to change the program it runs? This is the central question behind privilege boundaries: who can cause an action, under whose authority, on which object?

Windows privilege escalation describes gaining authority beyond the intended security context. Understanding the boundary helps you prevent mistakes, explain a finding, and choose a proportionate fix. Begin with the model here, then explore the short lessons below at your own pace.

A process carries a security context

An access token includes a user identity, group information, privileges, and other security attributes. A process normally uses its primary token. A thread may use an impersonation token when acting for a client. These contexts are related, but they are not interchangeable.

A familiar account name is a useful label, not a complete account of authority. Group membership, token restrictions, enabled privileges, and the requested operation matter. Follow access tokens with security identifiers to separate identity from display names.

Ask about an operation on an object

A file, registry key, or service object exposes specific operations. Reading a document, changing its contents, and changing its permissions are different requests. A DACL describes discretionary access through entries for security identities. Their order, inheritance, and the token’s attributes can affect evaluation.

Avoid guessing from a single visible grant. A null DACL and an empty DACL also have very different meanings. The DACL lesson introduces those distinctions; permission inheritance explains how access can change as an object moves through its lifecycle.

Integrity adds another check

An integrity level is a trust label, separate from ordinary object permissions. Under no-write-up policy, a lower-integrity process cannot write to a higher-integrity object even when the DACL would otherwise grant that write. Matching levels does not itself grant access.

User Account Control influences how administrative tasks obtain an elevated context. Membership in Administrators does not mean every process starts with the same unrestricted token. Read UAC context after trying the model.

EXPLORE THE CONCEPT

Why a permission can still be insufficient

Compare these situations, then change the two controls in the model.

The DACL grants the write

A medium-integrity process still cannot write to this high-integrity file under its no-write-up policy. A discretionary grant does not cancel the integrity check.

The integrity levels match

Matching integrity levels removes that particular block. The token still needs permission from the DACL for the requested operation.

Both controls permit the write

The model allows the write when both conditions hold. A real system may also apply other checks; this model deliberately isolates these two concepts.

A simplified learning model. It connects to no systems and uses no real data.

Services have two boundaries to review

A service identity determines the context in which the service works. Its effective access should match its purpose. Separately, consider who can change its configuration, executable, or trusted dependencies. Controlling those inputs can change the work performed under the service identity.

For our document service, a useful review records the report destination, the required write permission, configuration ownership, and how changes are approved. It also considers failure: where sensitive temporary files go, what logs reveal, and whether recovery preserves the intended permissions. Explore service change control and scheduled task boundaries.

Reduce authority and verify the result

Credential isolation, separate local administrator passwords, application control, and patch maintenance address different failure paths. No single control substitutes for understanding the actual permissions. Local SYSTEM authority also does not automatically establish administrative authority over an entire domain.

A strong finding names the affected identity, object, operation, and evidence. Recommend the smallest change that removes unnecessary authority while preserving the service’s legitimate task. Verify normal work, denied operations, monitoring, and recovery afterward. That turns a permission observation into a useful improvement.

Apply these ideas in the Windows service-permission review case. Compare approved duties with supplied grants, separate service management from file access, and explain what evidence would justify closing the findings.

Worked review: separate the two failed boundaries

The fictional Ledger service publishes reports. These records concern ordinary processes, valid security descriptors, and the stated integrity policy. The case excludes special privilege overrides and additional blocking controls.

W1: A medium-integrity reporting process requests a write to a high-integrity report file. Its DACL allows that write, but the file applies no-write-up.

W2: The service owner approves Operators to start Ledger and query its status. The effective service-object permissions also grant Operators configuration changes.

W3: Maintainers control the executable files. Ledger’s runtime file access is limited to its input and report folders. No domain permission evidence is supplied.

PredictWould granting more file permissions fix both W1 and W2?

No. W1 already has the discretionary grant; integrity policy blocks the write. W2 concerns service management, a different object and operation. Adding runtime file access addresses neither mismatch.

For W1, the owner must decide whether the reporting process and destination were designed for the same trust level. A supported redesign might use an appropriately protected report destination or a narrowly authorized publishing component. Automatically elevating the entire reporting application expands its authority and needs a separate justification.

For W2, remove the unsupported configuration-change grant while preserving approved start and status operations. Keep executable protection from W3; it remains useful, but it does not cancel service configuration authority. Record permission evidence for each object separately.

Acceptance should confirm that Operators can start Ledger and obtain status but cannot change its configuration. Also confirm that the intended reporting design produces the required file under its approved context. These checks support a local correction. Neither successful publication nor a service account name establishes domain-wide authority.