/windows-discovery

name: windows-discovery
description: >
  Windows local privilege escalation enumeration and attack surface mapping.
keywords:
  - enumerate privesc
  - check for privilege escalation
  - run winpeas
  - windows privesc
  - local privesc
  - check my privileges
  - escalate on windows
  - what can I escalate
  - post-exploitation windows
tools:
  - WinPEAS
  - PowerUp
  - Seatbelt
  - Watson
  - WES-NG
  - PrivescCheck
  - accesschk
opsec: low

Windows Local Privilege Escalation Discovery

You are helping a penetration tester enumerate a Windows system for local privilege escalation vectors. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[windows-discovery] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

Scope Boundary

This skill covers Windows host discovery — enumerating system configuration, identifying privilege escalation vectors, and reporting findings to the orchestrator. When you confirm an exploitable vector — **STOP**.

Do not load or execute another skill. Do not continue past your scope boundary. Instead, return to the orchestrator with:

• What was found (vulns, credentials, access gained)
• Detection details (finding type, affected service/binary, evidence)
• Context for technique execution (hostname, OS version, current user, etc.)

The orchestrator decides what runs next. Your job is to execute this skill thoroughly and return clean findings.

**Stay in methodology.** Only use techniques documented in this skill. If you encounter a scenario not covered here, note it and return — do not improvise attacks, write custom exploit code, or apply techniques from other domains. The orchestrator will provide specific guidance or route to a different skill.

**Do NOT spider or enumerate SMB shares.** Never run `nxc smb`, `spider_plus`, `manspider`, `smbclient`, or any remote share enumeration tool. Share spidering is performed from the attackbox by ad-discovery or network-recon — not from inside a low-privilege shell. If `net share` (the only allowed share command) reveals a share not already in engagement state, record it as an finding via `add_vuln()` and note it in your return summary. Do not connect to it, read its contents, or spider it — a different agent handles that from the attackbox.

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

State Writes

Write actionable findings **immediately** via state so the orchestrator can react in real time (via event watcher) instead of waiting for your full return summary. Use these tools as you discover findings:

• `add_credential()` — cleartext creds in scheduled tasks, registry, config files, PowerShell history, unattend.xml
• `add_vuln()` — confirmed vulnerabilities (unquoted service paths, weak service permissions, AlwaysInstallElevated, HiveNightmare)
• `add_pivot()` — additional NICs/subnets discovered via `ipconfig /all`/`route print`, new hosts from ARP table
• `add_blocked()` — techniques attempted and failed (so orchestrator doesn't re-route)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Shell access on a Windows system (cmd.exe, PowerShell, or webshell)
• Know current user context (`whoami`)
• Enumeration tools available on target or transferable

Step 1: System Information

Gather baseline system information for exploit matching and context.

systeminfo
systeminfo | findstr /B /C:"OS Name" /C:"OS Version" /C:"System Type" /C:"Hotfix(s)"
hostname

[System.Environment]::OSVersion.Version
Get-ComputerInfo | Select-Object CsName, OsName, OsVersion, OsArchitecture, OsBuildNumber, WindowsVersion
wmic os get Caption, Version, BuildNumber, OSArchitecture

**Key outputs to note:**

• OS version and build number (determines which exploits/Potatoes work)
• Architecture (x86 vs x64 — affects binary compatibility)
• Hotfix count and list (determines kernel exploit eligibility)
• Domain membership (affects lateral movement options)

**Patch analysis (offline — run on attacker machine):**

# WES-NG — compare systeminfo against known vulnerabilities
python3 wes.py --update
python3 wes.py systeminfo.txt

**Watson (on target — .NET 2.0+):**

Watson.exe

Step 2: User Context and Privileges

This is the highest-priority check — token privileges determine immediate escalation paths.

**OPSEC WARNING:** `whoami` and `whoami /priv` are heavily monitored by EDR (CrowdStrike triggers on these). In OPSEC-sensitive engagements, prefer inferring privileges from context or using alternative methods:

# OPSEC-safe alternatives (less signatured than whoami)
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name
[System.Security.Principal.WindowsIdentity]::GetCurrent().Groups | ForEach-Object { $_.Translate([System.Security.Principal.NTAccount]) }

# Check specific privilege without whoami
[bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).groups -match "S-1-5-32-544")  # Is admin?

# Token privileges via .NET (no whoami.exe process creation)
Add-Type -TypeDefinition @"
using System;using System.Runtime.InteropServices;
public class Priv{
    [DllImport("advapi32.dll",SetLast