Turn automated Windows findings into manually verified candidates

Needs: Verified current token and architecture, a compatible reviewed executable or allowed PowerShell runtime, and a writable report location

Windows commands

REM Baseline
winPEASx64.exe log
Seatbelt.exe -group=system -outputfile="C:\Windows\Temp\seatbelt-system.txt"
Seatbelt.exe -group=user -q -outputfile="C:\Windows\Temp\seatbelt-user.json"

PowerShell commands

# Baseline
powershell.exe -ExecutionPolicy Bypass -Command ". .\PrivescCheck.ps1; Invoke-PrivescCheck -Report TXT,HTML"
Import-Module .\PowerUp.ps1
Invoke-AllChecks

Convert every highlight into

# Convert every highlight into
CANDIDATE | CURRENT TOKEN | CONTROLLED INPUT | EFFECTIVE RIGHT | CONSUMER | RUN-AS | TRIGGER | EXPECTED EFFECT | STATUS

Verify → Read out.txt or the helper report. Use sc.exe qc/sdshow plus icacls for a service, inspect task XML/run-as for a scheduled task, or check whoami /priv for a token finding

If it fails → Binary/script blocked or report empty: check architecture and PowerShell language/policy, then use native service/task/ACL checks. A blocked helper does not disprove the finding More detail ↓

If → then

A privileged object appears writable or an ACL tool reports a useful right → Prove effective file, registry and service-object permissions
Needs: Correct trustee/token, object type and effective rights including parents and deny entries
Effective SERVICE_CHANGE_CONFIG on a higher-privileged service → Change a privileged service's executable configuration
Needs: Configuration-change right, accessible compatible payload path and a separate start/restart trigger
whoami /priv exposes a relevant token privilege → Select a privilege-backed impersonation or object-control route
Needs: The exact privilege and usable operation; impersonation additionally needs a compatible privileged authentication source, OS/service state and executable context

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Turn automated Windows findings into manually verified candidates

USE WHEN: A Windows foothold is available; run winPEAS or a focused survey for service/task permissions, token privileges and credentials
STARTING ACCESS: A verified Windows foothold with a known token, integrity level and groups
RESULT: A shortlist of permissions, consumers and credential sources to validate

Recognize the clue

Select a reviewed tool after checking host/runtime; treat each highlighted service, token or path as a lead to native evidence.

whoami /all
$PSVersionTable
$ExecutionContext.SessionState.LanguageMode

SYNTHETIC EXAMPLE OUTPUT

Tool candidate: unquoted SERVICE path
Writable earlier prefix: not checked
Trigger: not checked

Means: The enumerator located a configuration clue, not the full usable chain.

Confirm: Run winPEAS with log output, then inspect the exact reported service with sc qc/sc sdshow and its file with icacls. Check token highlights with whoami /priv. A collector's colored line is not the resulting elevated token.

After validation: The native checks establish the complete method conditions: select its owning route.
Ruled out in this context: Protected prefixes or a low consumer disprove the proposed elevation: discard the finding's exploit interpretation.
Still inconclusive: Tool blocking/partial visibility leaves enumeration incomplete; use native/application-specific checks.

Troubleshooting: Binary/script blocked or report empty: check architecture and PowerShell language/policy, then use native service/task/ACL checks. A blocked helper does not disprove the finding

winPEAS is broad; Seatbelt is a targeted survey and publishes source rather than official binaries; PrivescCheck evaluates the current token and skips some checks when elevated; PowerUp is useful but its upstream repository was archived. AV/script-policy failure is a tooling limitation—use native checks.

Convert every highlight into:

Why it works

winPEAS, PrivescCheck, Seatbelt and PowerUp collect different evidence. Highlighted services or privileges still require exact ACL, token, identity and trigger checks.

Worked example · hypothetical

Observation: a scanner flags an unquoted path. Test: inspect the earlier path prefixes and trigger. Illustrative output: none is writable. Interpretation: discard the exploit hypothesis and retain the configuration fact.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗