Privilege escalation

Privilege escalation is the process by which an attacker obtains a level of access or control inside a system that is greater than the one they had on entry. They start with low privileges, those of an ordinary user, look for a vulnerability they can use (an insecure configuration, a permission granted too widely, an unpatched flaw), and use it to get around the restrictions that were holding them back.

Once up, the next move is to consolidate: keep the elevated access, cover the trail, and make sure they can come back.

Escalation comes in two shapes, and treating them as one is the reason estates defend against the wrong one.

Vertical escalation gains rights the account did not have: user to administrator, container to host, standard account to directory administrator. Horizontal escalation stays at the same level and reaches another subject’s data, which in an application is a broken object-level check and in a directory is taking over a peer account that happens to have something the attacker wants.

The routes divide by layer. On a single host, the classic openings are a service running with high privileges whose binary or configuration a low-privileged account can write, a scheduled task pointing at a writable path, a search order that lets an attacker place a library where a privileged process will load it, a token privilege that permits impersonation, or an unpatched kernel flaw. In a directory, almost none of it is an exploit: it is delegated permissions, nested groups, computer account delegation settings, and certificate templates that let a requester name any subject. In cloud, it is an identity that can modify policy, assume a more privileged role, or update the code of a function that already runs as one.

The pattern across all three is the same. Something is writable, assumable or modifiable by an account that should not be able to, and the platform is doing exactly what the configuration says.

The finding we write most often is not a vulnerability at all. It is a permission granted for a reason that made sense at the time and never removed. A group given rights to reset passwords for a helpdesk process, which turns out to include accounts with directory rights. A cloud role given permission to attach policies during a migration. A service account added to a privileged group years ago because working out the right permissions would have taken a fortnight.

These accumulate silently. No single grant looks unreasonable in its ticket, and nobody ever re-reads the sum. The result is a graph in which a route from any authenticated user to full control exists and is composed entirely of intended permissions. That is why the first thing we do on an internal test is map the graph, and why the map is usually the most valuable single page of the report.

The second recurring failure is the local one: writable paths. A service binary in a directory that authenticated users can write to, an application installed under a path with inherited permissions, a scheduled task that runs a script from a share. Configuration management tools distribute these consistently across an entire estate, which turns one packaging error into an estate-wide escalation.

The third is containers and cloud, where the boundary people believe in and the boundary that exists are different. A container running privileged, or with a host path mounted, or with a capability it did not need, is a process on the host wearing a costume. A workload whose identity can modify its own policy is an administrator that has not exercised the right yet.

Four words that get used loosely. The distinctions decide who owns the fix.

The practical point is the last row. Local escalation leaves endpoint telemetry. Directory escalation leaves control plane events. Horizontal escalation in an application usually leaves nothing at all, because reading another customer’s record is a successful request that returns 200, and nobody logs which object was returned.

Equating escalation with exploits. Most of what we use is configuration. Patching alone does not address it.

Auditing group membership and stopping there. Object permissions, delegation and role assumption paths are where the routes are, and none of them appear in a membership list.

Granting broad permissions temporarily. Temporary grants become permanent because nothing removes them. If the grant has no expiry, it is permanent.

Assuming a container is a security boundary. It is a packaging and resource boundary. Treated as a security boundary it needs specific configuration, and container escape is the routine consequence of not applying it.

Ignoring horizontal escalation because it is not root. Reading every customer’s data is not a lesser outcome because no administrator account was involved.

Map before you fix. A permission graph across the directory and the cloud tenant, computed from an ordinary user’s starting position, tells you which routes exist. Almost every estate is surprised by its own output, and the shortest routes are usually removable within a sprint.

Apply least privilege to machines as seriously as to people. Service accounts that run one service need the rights for that service. Workload identities need the specific actions their code performs. Any identity that can modify identity policy is an administrator and should be counted as one.

On hosts, fix the writable paths systematically rather than one at a time: audit permissions on service binaries, installation directories and scheduled task targets across the estate, because whatever distributed the error distributed it everywhere. Keep hardening baselines enforced continuously so that the state you fixed is the state that persists.

For detection, the useful signals are specific and low volume. Changes to privileged group membership. New role assumption paths in a cloud tenant. Directory replication requests from an unexpected host. Certificate requests whose subject does not match the requester. Service creation or modification outside a change window. Each of these is rare in a healthy estate, which makes them cheap to alert on.

Escalation appears in a report as a step in a path, with three parts recorded: the state before, the specific configuration or permission that allowed the step, and the state after. That third part decides severity, and we state it in terms of what became reachable rather than in terms of the account name.

Evidence is the configuration itself, quoted so the client’s own team can verify it, plus the minimum demonstration that the step worked. Where the escalation depended on a delegated right we quote the access control entry; where it depended on a writable path we give the path and the permission.

We separate escalation that required a patch from escalation that required a permission change, because they go to different backlogs and because the second kind is invisible to the client’s vulnerability management process. A finding that will never appear in a scan is worth flagging as such.

This is one of the two questions an internal engagement exists to answer, alongside movement, and it is what testing from a standard user’s position is designed to establish.

What is the difference between vertical and horizontal privilege escalation? Vertical gains a higher level of privilege than the account had. Horizontal stays at the same level and reaches another subject’s data. Vertical is what most people mean by the term; horizontal is more common in web applications and often has a larger data impact.

Is privilege escalation always caused by a vulnerability? No, and in the estates we test it usually is not. Most of the routes we use are permissions that were granted deliberately, plus writable paths and delegation settings. That is why patching alone does not close them.

How do we find escalation paths before an attacker does? Compute the permission graph from an unprivileged starting point, in both the directory and the cloud tenant, and read the shortest paths to your most privileged roles. Then review host configuration for writable service paths across the whole estate rather than on samples.

Does an attacker always need to escalate? No. If the data they want is reachable with the access they already have, escalation is unnecessary work. Many incidents involve no escalation at all, which is why an estate that is only watching for it sees nothing.