Windows Privileged File Workflows

Bundled with Unleash skills pack. Source: C:\Users\Admin.agents\skills\windows-privileged-file-workflows\SKILL.md

Windows Privileged File Workflow Research

Overview

Find broken object-identity and authorization invariants in privileged Windows file workflows. The highest-value pipelines scan, stage, hydrate, quarantine, update, snapshot, remediate, restore, rename, or execute files asynchronously. For acquisition-focused research, require zero-day-target-eligibility to pass on current stable bytes.

Model the workflow as handles and objects, not path strings:

attacker name -> initial object -> privileged validation -> queued work
              -> name/namespace/lifecycle change -> privileged reopen
              -> privileged write/read/load/execute

A vulnerability exists when the privileged consumer reaches a security-sensitive object that was not the object authorized at the correct boundary.

When to Use

Use for:

• reparse point, junction, symbolic-link, mount-point, or path normalization hypotheses;
• oplock- or notification-gated races;
• rename-by-handle, delete-pending, replace, supersede, hard-link, and share-mode behavior;
• VSS or other snapshot-backed confusion;
• Cloud Files sync roots, placeholders, hydration/dehydration, and provider callbacks;
• Defender scan, remediation, quarantine, update, signature, or offline-scan file flows;
• alternate data stream handling, especially Zone.Identifier and metadata streams;
• virtual disk, ISO, removable-volume, and device-path differences;
• denial or integrity bugs caused by attacker-held file locks.

Do not use for pure Object Manager section/event/mutant confusion without a filesystem leg; use windows-object-manager-confusion.

The Handle Ledger

For every important file operation, record:

Resolve and preserve:

• Win32 path;
• \\?\ or \\.\ path;
• \??\ NT path;
• \Device\... path;
• volume GUID and file ID when possible;
• reparse tag and target;
• default stream versus named ADS;
• whether FILE_OPEN_REPARSE_POINT or equivalent no-follow behavior is used.

Completion criterion: you can point to the exact transition where the consumer abandons a trusted handle or file ID and resolves an attacker-influenced name again.

Phase 1: Trace the Legitimate Transaction

Trigger the workflow once without interference. Use Procmon plus at least one corroborating source:

• ETW/WPR for timing and provider events;
• WinDbg breakpoints on NtCreateFile, NtSetInformationFile, NtFsControlFile, CreateFileW, Cloud Files APIs, or component-specific routines;
• API Monitor or Frida for user-mode call arguments;
• static RE for path construction, flags, and retry logic;
• Object Manager and handle inspection through WinObj, Process Explorer, System Informer, or NtApiDotNet.

Mark:

1. attacker-controlled root or artifact;
2. privileged first open;
3. validation or classification;
4. asynchronous boundary;
5. reopen, rename, or remediation;
6. final sensitive operation;
7. cleanup.

Completion criterion: capture a timestamped transaction with the responsible process and the exact final sink.

Phase 2: Enumerate Mutation Primitives

Test primitives independently before chaining them.

Name redirection

• directory junction/mount point;
• filesystem symbolic link where available;
• Object Manager link feeding a Win32/NT path;
• volume mount point or virtual disk device path;
• relative path under a handle-controlled root;
• drive-letter, volume GUID, UNC, SMB, WebDAV, and local-device variants.

Identity and lifecycle changes

• rename by handle while retaining the original handle;
• mark delete-pending, then recreate the original name;
• replace/supersede with different share modes;
• swap parent directory after child validation;
• hard-link creation or removal;
• stream creation/deletion while the base file remains stable;
• snapshot creation followed by live-object mutation.

Availability and timing controls

• batch/exclusive oplock;
• byte-range lock and restrictive share mode;
• ReadDirectoryChangesW notification;
• Cloud Files fetch/validate/cancel callback;
• service-status notification;
• ETW event or debugger breakpoint;
• transaction open/rollback where TxF behavior is relevant.

Completion criterion: each primitive has a micro-test proving its exact behavior on the target build and filesystem.

Phase 3: Design a Deterministic Gate

Choose a gate immediately before the vulnerable decision.

Preferred order:

1. oplock break caused by the privileged open;
2. Cloud Files callback caused by hydration or validation;
3. directory-change event identifying a newly created staging object;
4. ETW event tied to the relevant operation;
5. service or task state transition;
6. debugger breakpoint;
7. timed polling only for reconnaissance.

For an oplock gate, record:

• handle access and share flags;
• requested oplock level or legacy FSCTL;
• expected breaker process and operation;
• whether the break blocks or merely notifies;
• state changed before acknowledging/closing;
• timeout and cancellation behavior.

Do not assume an oplock means the consumer is paused at the desired code path. Verify with a trace or stack.

Completion criterion: gate activation predicts the privileged operation and the swap occurs before its final name resolution or write.

Phase 4: Test High-Yield Invariants

Validate-by-name, use-by-name

Test whether the component validates a user-controlled file, queues work, and later reopens the same string after the object or parent changed.

Safe behavior: retain a trusted handle or revalidate final file ID, volume, owner, DACL, reparse state, and destination.

Trusted staging root

Test temporary and update directories whose names are created by a privileged component but whose contents, namespace root, or parent traversal can be influenced.

Questions:

• Can the attacker predict or observe the directory name?
• Can they hold or replace children?
• Is the source root accepted through a global/session/object namespace?
• Does the service copy trusted output back into a protected destination?

Snapshot/live-object mismatch

Test whether a privileged component creates or scans VSS data but later uses a live path, attacker-provided name, or link to select snapshot content.

Record snapshot device name and creation time. Distinguish immutable snapshot data from mutable directory entries that refer to it.

Cloud Files trust inversion

For sync roots and placeholders, vary:

• provider identity and registration scope;
• hydration policy and validation-required modifier;
• placeholder metadata, size, file identity, in-sync state, and cloud tag;
• callback timing and returned data;
• rename/delete/recreate before and after hydration;
• behavior under security-product scanning or remediation.

Ask whether the privileged consumer treats provider-supplied content or metadata as the original trusted file and writes it back under stronger authority.

ADS size and metadata assumptions

Test base file and streams independently:

• zero/small/huge Zone.Identifier;
• delayed or non-terminating remote stream reads;
• malformed or changing stream size;
• local, SMB, WebDAV, and virtual-disk behavior;
• quota and disk-space impact;
• whether size limits applied to the base file are omitted for streams.

Completion criterion: each hypothesis has a vulnerable case and a safe negative control differing in one property.

Phase 5: Security-Product Workflow Matrix

Security products expose unusual privileged file workflows even when UI protections are disabled. Test the API/workflow itself, not just real-time protection.

Also test passive mode, disabled real-time protection, Server, and component-platform version independently. A workflow can remain reachable when the normal monitoring feature appears off.

Completion criterion: report reachability and result for each relevant mode rather than assuming the UI state governs the backend.

Phase 6: Minimize the PoC

Structure the PoC as:

prepare -> trace checkpoint -> arm gate -> trigger -> swap -> release -> prove -> restore

Requirements:

• random per-run working directory;
• no fixed sleeps in the final synchronization path;
• explicit timeouts;
• log paths, file IDs, volume IDs, reparse targets, and NTSTATUS/Win32 errors;
• harmless proof first, such as a marker in a controlled protected test target;
• cleanup that tolerates missing, moved, delete-pending, or still-open objects;
• no giant embedded payload unless the payload itself is under test.

For reliability, classify at least 30 trials:

• success;
• gate timeout;
• privileged consumer never reached artifact;
• swap too early/late;
• wrong object opened;
• access denied;
• object remained locked;
• cleanup failure.

Completion criterion: a failed run explains its phase and leaves the VM recoverable.

Variant Hunting

Once root cause is known, search for:

• same file helper or path-normalization routine in sibling services;
• all RPC/COM methods accepting paths or update roots;
• every Cloud Files callback or placeholder state consumer;
• all security-product handlers for base file versus ADS;
• every scheduled task consuming the component's output;
• live versus VSS versions of the same workflow;
• local versus SMB/WebDAV/virtual-disk sources;
• desktop versus Server and online versus recovery implementations;
• pre- and post-patch callers that received only partial mitigations.

Search for the missing invariant, not exploit-specific names.

Common Pitfalls

1. Treating a pathname as an object identity. Record file ID, volume, and handle lifetime.
2. Oplock folklore. Confirm the breaking operation and call stack.
3. Ignoring share flags. They often determine whether replace, rename, or lock primitives work.
4. Assuming reparse checks are recursive. Test every path component and post-check reopen.
5. Ignoring ADS. Metadata streams can bypass size, cache, and remediation assumptions.
6. Ignoring component updates. Defender platform/engine behavior can change outside monthly OS patches.
7. Using resource exhaustion before proving the bug. First show the omitted bound or lifecycle error with a small controlled case.
8. Leaving handles behind. Track every handle and cancel outstanding I/O during cleanup.

Verification Checklist

• End-to-end privileged file transaction captured
• Handle ledger includes path, file ID, volume, access, share, disposition, and reparse behavior
• Exact identity/authorization invariant stated
• Mutation primitives validated independently
• Gate verified against the privileged call stack or trace
• Negative control included
• Local/remote, default-stream/ADS, and relevant volume types tested
• Security-product mode and component versions recorded where relevant
• PoC uses event-driven synchronization and explicit timeouts
• Reliability outcomes classified across repeated trials
• Cleanup survives partial execution
• Variant search follows the root cause