What Is Privilege Escalation?

Privilege escalation is gaining rights beyond those originally held. It is a necessary step in most intrusions, because initial access usually arrives as an ordinary user and the objective requires more.

It comes in two shapes: vertical, meaning higher rights on the same system or domain, and horizontal, meaning access to another user's resources at the same level. Both matter and the first gets most of the attention.

The routes on an endpoint

Unpatched local vulnerabilities in the operating system or drivers. Services running with high privilege and weak file or registry permissions. Scheduled tasks executing something a user can modify.

Credentials left in scripts, configuration files and deployment artefacts. And the simplest one, which is that the user already holds local administrator rights and no escalation is needed at all.

The routes in a directory

Delegated permissions that allow one account to reset another's password, where the target holds more rights. Group memberships that nest into privileged groups. Service accounts with administrative rights granted years earlier.

These form attack paths, and path analysis tooling finds them reliably. The characteristic finding is that an ordinary user account has a short chain to domain administrator through relationships nobody designed deliberately.

Cloud escalation is about policy, not exploits

In cloud environments the equivalent is permission-based: an identity that can modify its own policy, assume a more privileged role, attach a role to a compute instance it controls, or invoke a service that acts with higher rights.

No vulnerability is involved. It is configuration, which makes it both easier to find systematically and easier to introduce accidentally.

Detection

A process gaining higher privilege unexpectedly. New members added to privileged groups. Service and scheduled task creation. Token manipulation. Access to credential storage on the host.

These are among the higher-fidelity endpoint detections available, because legitimate escalation is infrequent and usually performed by known tooling from known accounts.

Prevention, in order of value

Remove standing local administrator rights, which addresses the most common case. Patch, which closes the exploitation routes. Run attack path analysis against your directory and close what it finds.

Keep secrets out of configuration and scripts. And apply least privilege in cloud policy, with permission boundaries so that an over-permissive grant is capped by something above it.

Container and orchestration escalation

Containerised environments add their own routes: a container running as root with a writable host mount, excessive capabilities granted to ease a deployment, a service account token with cluster-wide rights mounted into every pod by default.

The controls are configuration: run as a non-root user, drop unnecessary capabilities, avoid privileged containers, and scope service account permissions per workload rather than accepting a permissive default. See container security.

One reporting note: escalation findings are frequently recorded as medium severity because they require existing access. That framing understates them, since initial access is the part attackers obtain most reliably. A clean route from any ordinary account to administrative control is a high-severity finding regardless of the prerequisite.

Where to start

Run path analysis against your directory and count the accounts with a short route to domain administrator. That number is usually the most actionable security finding available to you.

See endpoint privilege management. GuardsArm runs internal penetration testing.