Finding Zero-Days in Windows

Part 0 · Windows Vulnerability Research · NINJAS

Most people meet Windows security through Patch Tuesday. Researchers meet it earlier—at the moment an untrusted input crosses a privilege boundary and the code’s assumptions fail.

This series is written for that earlier moment. It is a practical field guide for discovering Windows vulnerabilities: how to map trust boundaries, choose surfaces worth your time, keep a lab that survives kernel crashes, and convert findings into reports that vendors can triage.

It is methodology and craft. It is not a weaponization manual.

What you should be able to do

After working through the series, you should be able to:

• Express any candidate issue as a boundary crossing (from layer A to layer B)
• Build a surface map before writing a harness
• Commit to a 90-day focus with explicit kill criteria
• Produce root-cause notes suitable for MSRC or other vendor programs

Why Windows still yields discoveries

Windows is not one binary. It is an ecosystem of parsers, elevation brokers, drivers, and identity protocols that expands faster than it can be fully re-audited. New features arrive with thin historical scrutiny. Legacy formats remain reachable from modern preview and shell paths. Privileged services still accept structured input from less-privileged callers.

Working rule: any interface that accepts attacker-influenced input and makes a security decision is a candidate—especially when it runs above the caller’s privilege.

How mitigations change where you should focus

On current Windows clients with VBS, HVCI, CET, and related controls, turning a raw memory-corruption primitive into reliable elevation is harder than it was a decade ago. That does not make research obsolete. It changes the portfolio.

Memory corruption remains worth studying—for skill, and for components that still parse complex input on interesting boundaries. On modern mitigated hosts, though, logic bugs at privilege edges are often the shortest path from research hours to a reportable finding.

The discovery mindset

Zero-days are rarely found by “looking for bugs.” They are found by asking better questions:

1. What crosses a trust boundary? — file, packet, handle, token, RPC stub, shared memory
2. Who parses it, and at what privilege?
3. What does the code assume was already validated? — failed assumptions are the bug
4. If that assumption fails, which boundary breaks? — AppContainer→User, User→SYSTEM, User→Kernel, Guest→Host

If you cannot answer the fourth question, you have an interesting crash—not yet a finding.

Patterns that keep producing Windows findings

You rarely need a novel bug class. You need a neglected intersection of complexity and privilege.

How to use this series

Ground rules

Work only on systems you own or are authorized to test, inside isolated labs. Prefer root cause and minimal reproduction over exploit chains. Disclose through MSRC or the relevant vendor program.

Windows is not a flat catalog of features—it is a stack of trust rings. Every high-value finding describes a controlled jump from an outer ring to an inner one, or a break in isolation between peers that should not trust each other. Before you pick tools or targets, map where you stand and where impact must land. That mental model turns scattered crashes into coherent vulnerability narratives.

Trust rings (working model)

Diagram numbering may run outside→inside or the reverse depending on the visual. Operationally, the from → to sentence matters—not label arithmetic.

The triage sentence every finding needs

This issue allows an attacker at [Layer A] to affect [Layer B] because of [root cause] in [component], under [preconditions].

Examples:

• Font out-of-bounds write inside AppContainer → sandbox-scoped impact until escape exists
• RPC logic bug with missing authorization → User→SYSTEM
• Third-party METHOD_NEITHER IOCTL → User→Kernel
• VSP shared-memory race → Guest→Host

Without this sentence, severity arguments collapse and reports lose triage momentum.

Where to focus discovery effort now

1) Privilege amplifiers

Prioritize surfaces where low privilege speaks to high privilege:

• SYSTEM RPC servers callable by normal users
• Auto-elevating or elevation-broker COM servers
• Kernel devices openable by Everyone / Users
• Sandbox brokers that proxy filesystem, registry, or device access

2) Auto-parse and “no click” paths

Input the OS consumes without an explicit “Open with…”:

• Explorer preview and thumbnail handlers
• Shell link resolution
• Clipboard format handlers
• Print and document conversion paths
• Identity material parsed on domain controllers

3) Failed cross-component assumptions

Bugs cluster where component A assumes B already checked lengths, SIDs, paths, or ACLs. Diff the trust: who actually enforces the check?

4) Patch shadows

After monthly updates, binary-diff changed modules. Incomplete fixes and copy-paste siblings remain one of the highest-ROI independent discovery pipelines on Windows.

5) Saturation awareness

Some historically rich targets (classic spooler paths, heavily fuzzed image codecs) still reward study only with a novel angle: new API entry, new host process/IL, new feature flag, or a patch-diff hypothesis. Repeating 2018 strategies without a hypothesis underperforms.

Practical scenario — Surface-map a privileged service

In 45–90 minutes, produce a table for one SYSTEM service (inbox or third-party agent):

Recon toolkit

sc.exe qc / sdshow
Process Explorer (integrity level, privileges, handles)
RpcView / OleViewDotNet
NtObjectManager
Procmon (CreateFile, Reg*, TCP)

Discovery filter: retain only rows where user-influenced data reaches code running above Medium IL.

Practical scenario — Choosing a layer for 30 days

Priority matrix: Part 11.

Drill

State from→to for each:

1. Pre-auth memory corruption in HTTP.sys
2. Use-after-free in an AppContainer image codec
3. Writable service binary path leading to LocalSystem
4. Guest write into host via a VSP

Key takeaways

• Map rings before tools
• Hunt privilege amplifiers, auto-parse paths, and patch siblings
• Write the boundary sentence early—everything else hangs from it

Next: Part 1 Soon