Privilege Escalation Assessment

---
name: privilege-escalation-assessment
description: "Assesses and ranks Windows, Linux, and cloud privilege-escalation paths using observed prerequisites, execution authority, operational signal, reliability, risk, cleanup, and verification. Use after gaining an authorized foothold or cloud identity when deciding whether elevation is necessary and which candidate path is defensible."
allowed-tools: Read Grep Glob
---

# Privilege escalation assessment

A candidate condition is not elevated access. Record the current principal,
the required objective, the evidence for every prerequisite, and the exact
identity proof produced after any authorized execution.

This skill evaluates vertical privilege transitions on one host, container, or
cloud authority boundary. Use a directory or cloud attack-path workflow for
multi-principal graph traversal, and a persistence workflow for durable access.
Enumeration authorization does not authorize exploitation or state change.

## When to Use

- Assess privilege escalation for authorized security work.
- Use only within explicit authorization and the stated rules of engagement.

## When NOT to Use

- Do not treat this skill as permission to access, test, or change a target.
- Do not convert missing evidence into a clean result or a stronger claim.

## Workflow

1. Record the subject, platform, current principal and privilege, desired
   privilege, authorization reference, monitoring context, and whether the
   mission actually requires elevation.
2. Collect evidence with a source, locator, known timestamp or bounded
   observation window, and bounded summary. Do not invent precision when only a
   collection interval is known. Tool output is evidence input; its severity
   label is not a conclusion.
3. Cover the common context categories and every category required for the
   platform. Preserve blocked and inconclusive areas instead of calling them clean.
4. Build each candidate from explicit prerequisites. Mark each prerequisite
   `met`, `unmet`, or `unknown` and cite evidence for every `met` or `unmet`
   judgment.
5. Derive candidate status: all prerequisites met is `confirmed`; any unmet is
   `rejected`; otherwise it is `conditional`. A product version alone does not
   establish exploitability; patch state and environmental compatibility remain
   separate prerequisites.
6. State execution authority separately as `authorized`, `approval-required`,
   or `prohibited`. Describe state changes, operational signal, expected
   privilege, reliability, risk, complexity, cleanup, and likely detection
   artifacts before choosing a path.
7. After an authorized attempt, record execution and verification evidence.
   Only a successful identity or effective-permission check establishes achieved
   privilege. Record failure and partial results without rewriting the candidate.

## Interpretation rules

- Prefer configuration and delegated-authority paths before vulnerable-code
  paths when they meet the objective with less risk.
- Current membership, token privilege, file permission, or IAM permission proves
  only that condition. Preserve every downstream trigger and boundary.
- A local administrator at medium integrity and an unprivileged user require
  different transitions; record the actual starting state.
- Kernel and memory-corruption paths carry high failure impact. Require matching
  platform, patch, architecture, and lab evidence before ranking them as reliable.
- A cloud permission name is not a path by itself. Resource scope, denies,
  permission boundaries, trust policy, and the resulting principal all matter.
- If the current privilege already satisfies the mission, record that decision
  and do not select an escalation merely to complete a checklist.

## Rationalizations to reject

- **"The scanner marked it exploitable."** Confirm the underlying prerequisite
  chain; scanners report candidates and can miss patches, ACLs, or trigger state.
- **"The version is vulnerable."** Version matching is one prerequisite, not
  proof of patch state, architecture compatibility, or successful execution.
- **"The file is writable, so we have root."** The privileged consumer, trigger,
  execution context, and resulting identity still need evidence.
- **"Read-only authorization covers a harmless proof."** Replacing files,
  changing policy, starting services, assuming roles, and invoking workloads are
  stateful actions that need explicit authority.
- **"The command returned success, so elevation worked."** Verify the effective
  principal or permission in the new context and cite that evidence.
- **"Root is always the goal."** Elevation that does not advance the mission adds
  signal, risk, and cleanup work without value.
- **"Cleanup can wait until the end."** A path without a restoration plan is not
  ready to execute, especially when it changes services, tasks, files, or IAM.