Windows 0day Hunting

Bundled with Unleash skills pack. Source: C:\Users\Admin.agents\skills\windows-0day-hunting\SKILL.md

Windows 0-Day Hunting

Overview

Hunt composition bugs in Windows workflows rather than starting from a favorite exploit primitive. The recurring shape is:

attacker-controlled state
  -> privileged component interprets it
  -> identity/path/state changes between validation and use
  -> privileged write, load, mount, execution, or disclosure

Prioritize first-party components that cross user-to-SYSTEM, user-to-other-user, offline-to-online, boot-to-recovery, or encrypted-to-unlocked boundaries. Use the specialist skills when the hypothesis centers on files, profiles/hives, or recovery state.

The methodology was distilled from public MSNightmare/NightmareEclipse repositories and Project Nightcrawler posts. Read references/msnightmare-method.md when provenance, examples, or confidence limits matter.

When research is governed by a latest-stable, widespread-deployment, non-public acquisition policy, run zero-day-target-eligibility before exploit engineering and again before reporting.

When to Use

Use for:

• Windows local privilege escalation and sandbox or security-boundary escape research;
• privileged services, COM/RPC servers, scheduled tasks, maintenance jobs, AV/EDR, setup, update, backup, restore, and recovery workflows;
• logic flaws involving path trust, object identity, stale authorization, state transitions, impersonation, or cross-user data;
• turning a suspicious Procmon/ETW/WinDbg observation into a controlled vulnerability hypothesis;
• variant analysis after a Windows LPE or boundary-bypass fix.

Do not use this as the primary workflow for kernel memory corruption, browser exploitation, or network-parser fuzzing. Route those to the corresponding specialist skill.

Core Research Invariant

Never begin with “how can I use a junction?” Begin with:

Which privileged action depends on state a weaker actor can influence, and what identity or authorization invariant must remain true from input acceptance through the final side effect?

The bug is the broken invariant. A junction, oplock, hive edit, boot artifact, RPC trigger, or scheduled task is only a way to demonstrate it.

Phase 1: Build the Research Boundary

Record before testing:

• exact Windows edition, architecture, build, cumulative update, component/package version, and security-product platform/signature version;
• initial token, integrity level, privileges, session, user SID, groups, and whether the actor is local, remote, interactive, service, or recovery environment;
• expected target boundary: SYSTEM, administrator, another user, protected path, encrypted volume, or trusted boot state;
• VM snapshot identifier and rollback procedure;
• one success signal and one negative-control signal.

Completion criterion: another researcher can recreate the starting state without relying on your machine history.

Phase 2: Select Workflow-Rich Targets

Rank candidates by boundary crossings and statefulness, not merely by binary size.

Prefer workflows with at least three of these properties:

1. low-privileged trigger;
2. privileged asynchronous worker;
3. attacker-visible intermediate artifact;
4. path reconstructed more than once;
5. temporary directory or snapshot;
6. impersonation transition;
7. persisted state consumed after reboot/logon;
8. final write/load/execute under stronger authority.

Completion criterion: maintain a ranked target list with a concrete trigger and expected privileged side effect for each item.

Phase 3: Trace One End-to-End Transaction

Use Procmon, ETW/WPR, service logs, WinDbg, API Monitor, RPC/COM tracing, and static RE as appropriate. Capture one clean transaction from low-privileged trigger to privileged sink.

For every meaningful event, record:

• timestamp and thread/process identity;
• token and impersonation state;
• path in Win32, NT, device, and Object Manager form when applicable;
• whether the component holds a handle or later reopens by name;
• requested access, share mode, create disposition, and reparse behavior;
• registry/config value supplying the path or state;
• side effect and cleanup behavior.

Mark all transitions:

validate -> queue -> impersonate/revert -> resolve -> open -> mutate -> execute/load

Completion criterion: the trace identifies both the first privileged interpretation of attacker-influenced state and the final security-sensitive operation.

Phase 4: Build the Hypothesis Ledger

One row per hypothesis:

Useful invariant families:

• Object identity: the object validated is the object later used.
• Principal binding: data belonging to user A cannot select user B's object.
• Namespace binding: a path cannot resolve differently across process, session, device, or boot namespaces.
• Authorization continuity: access is checked under the correct principal at the final operation.
• State authenticity: persisted mode/config accurately represents the current authorized transition.
• Volume trust: writable pre-auth media cannot supply trusted commands or configuration.
• Lifecycle ordering: cleanup, unload, rename, and replacement cannot race the privileged consumer.

Reject rows that name only a primitive and no invariant.

Completion criterion: every active hypothesis predicts a specific event that distinguishes vulnerable from safe behavior.

Phase 5: Run Small Differential Experiments

Change one variable at a time:

• path spelling, namespace, case, trailing separators, short name, UNC/device form;
• symlink/junction/reparse presence before validation versus after validation;
• rename/delete/replace while a handle remains open;
• alternate stream versus default stream;
• same artifact under another user, session, volume, or boot phase;
• clean state versus prior workflow state;
• standard user versus filtered admin versus SYSTEM;
• desktop versus Server and stable versus Insider/Canary build;
• cold boot versus reboot, logon, profile unload, recovery entry, or task retry.

Use event-driven synchronization whenever possible. Sleeps may explore timing but cannot establish the final PoC.

Keep a negative control that preserves the expected invariant. If both test and control succeed, the signal is not diagnostic.

Completion criterion: the ledger contains repeatable evidence for or against each hypothesis, not just screenshots or a one-off success.

Phase 6: Assemble the Minimum Chain

Separate the chain into named stages:

1. Seed: create or alter attacker-controlled state.
2. Trigger: invoke the legitimate privileged workflow.
3. Gate: pause at a deterministic observable event.
4. Swap: change object, path, namespace, identity, or state.
5. Sink: allow the privileged operation to continue.
6. Proof: produce a harmless, unambiguous boundary-crossing result.
7. Restore: revert modified system/user state.

First prove the primitive with a benign marker. Then prove impact. Do not add payload complexity before the root cause is stable.

Completion criterion: each stage has an independent log line or trace event and a defined failure reason.

Phase 7: Stabilize and Measure

For races and asynchronous workflows:

• replace polling and sleeps with oplocks, directory notifications, ETW events, debugger breakpoints, named events, or handle-state observations;
• measure gate-to-swap and swap-to-sink timing;
• run at least 30 trials per relevant build/state;
• record success, timeout, wrong-object, access-denied, cleanup failure, and crash separately;
• test under low/high CPU and I/O pressure only after the baseline is understood;
• ensure cleanup is idempotent after partial failure.

A PoC that works once is a lead. A vulnerability claim requires a reproducible transaction and a root-cause explanation.

Completion criterion: report trial counts and classified outcomes, including failed configurations.

Phase 8: Root Cause and Variant Hunt

State root cause in implementation terms:

<Component> accepts <attacker-influenced state> under <principal/phase>,
then later <re-resolves/reuses/trusts> it under <stronger authority>
without preserving <identity/authorization/state invariant>, enabling <impact>.

Then search siblings:

• callers of the same helper or RPC method;
• other consumers of the same registry/config value;
• similar scheduled tasks and service methods;
• all workflows using the same staging-root convention;
• server/client and online/offline implementations;
• adjacent setup passes, recovery modes, profile types, and volume types;
• pre-fix and post-fix binaries to identify incomplete checks.

Completion criterion: produce a variant matrix with tested status, not a list of guesses.

Required Research Output

Create these artifacts:

1. environment and build matrix;
2. transaction trace or event timeline;
3. hypothesis ledger;
4. root-cause statement;
5. minimized PoC with stage logging and cleanup;
6. reliability table;
7. affected/unaffected version evidence;
8. variant matrix;
9. remediation invariant and regression-test idea.

Common Pitfalls

1. Primitive-first tunnel vision. A reparse point is not a finding. Identify the violated invariant.
2. Procmon-only conclusions. Procmon reveals behavior but not always token state, handle reuse, or internal checks. Corroborate with ETW, debugger, or RE.
3. Name/handle confusion. Explicitly determine whether the component reopens by path or acts on the validated handle.
4. Dirty-state false positives. Roll back and test clean versus historically primed machines.
5. Uncontrolled races. Replace sleeps with observable gates before evaluating impact.
6. Build overgeneralization. Component platform updates can matter independently of the OS cumulative update.
7. PoC complexity hiding root cause. Reduce to one broken invariant and one harmless proof first.
8. Missing rollback. Profile, hive, recovery, and security-product experiments can persist across reboot; document restoration before the first run.

Verification Checklist

• Exact build, component version, token, session, and starting state recorded
• Privileged transaction traced end to end
• Broken invariant identified independently of the exploit primitive
• Negative control behaves differently from the vulnerable case
• Synchronization is event-driven or its limitation is quantified
• PoC stages and cleanup are independently observable
• Reliability measured across repeated trials
• Clean-snapshot reproduction completed
• Affected/unaffected matrix includes meaningful state and edition differences
• Variant hunt follows the root-cause pattern
• Fix recommendation preserves identity/authorization through the final side effect