NTForge is designed to produce small, repeatable Windows vulnerability reproductions for authorized research and coordinated reporting. Microsoft asks researchers to use the MSRC Researcher Portal and follows Coordinated Vulnerability Disclosure (CVD).
Official references:
- MSRC Researcher Portal
- What to expect when reporting to Microsoft
- Microsoft Coordinated Vulnerability Disclosure
- MSRC bounty guidelines
- Use systems you own or are explicitly authorized to test.
- Prefer disposable VMs with snapshots and isolated networking.
- Do not test against production tenants, third-party data, or unrelated users.
- Keep the reproducer limited to proving the vulnerable security boundary and impact required for triage.
- Do not add persistence, credential collection, lateral movement, evasion, destructive payloads, or automated targeting.
- Coordinate public disclosure with MSRC so customers can be protected first.
A useful submission normally contains:
- A one-paragraph vulnerability and security-boundary summary.
- Exact Windows product, edition, architecture, full build/UBR, and update state.
- Preconditions, required privileges, integrity level, and mitigations involved.
- Minimal source and exact build command/configuration.
- Numbered reproduction steps from a clean snapshot.
- Expected versus observed behavior.
- Stable evidence: status values, debugger output, exception code/address, sanitized stack, event log, or dump instructions.
- Affected/unaffected build matrix and repeat count.
- Impact explanation without an unnecessary post-exploitation payload.
Run scripts/windows/collect-system-info.ps1 on each Windows target. Its JSON
intentionally omits host name, user name, serial numbers, and product keys. Review
every artifact manually before submission.
At minimum, test the exact reported build and the newest serviced revision available to the researcher. When the code path exists across generations, compare Windows 10 build 19045 with relevant Windows 11 build families. Do not infer affectedness from an enum value or resolved pointer alone.
Cross-compilation and Wine are convenient build/smoke-test tools; they are not substitutes for the corresponding Windows kernel, security policy, architecture, and mitigation configuration.
- Resolve undocumented exports dynamically and log absence without crashing.
- Check every
NTSTATUS, Win32 error, transfer count, and returned length. - Cap allocations and validate all offsets/counts before use.
- Make race iteration counts, timeouts, and concurrency explicit and bounded.
- Emit no secrets and avoid system-wide configuration changes when possible.
- Restore temporary state and document any cleanup that cannot be automated.
- Keep symbols and optimization settings recorded for crash reproducibility.