If "local exploit" (Entry 01) hides where the attacker stands, "privilege escalation" hides where the attacker arrives. Both pretend to answer questions about cause when they answer questions about position and outcome instead. Privilege escalation is the canonical Semantic Guardrail 4 case — the example every TLCTC reader should be able to recite — because v2.1 added an entire notational construct, the intra-system boundary operator, specifically to give privilege escalation a proper home as observability metadata rather than a phantom cluster.
§ 1The term in the wild
Three usages dominate, and they bleed into each other in routine practice.
The first is MITRE ATT&CK's tactic TA0004 Privilege Escalation — one of fourteen top-level tactics, sitting alongside Initial Access, Execution, Persistence, and the rest. In ATT&CK's framework, this is a goal: "the adversary is trying to gain higher-level permissions." It is a useful operational lens, organising the techniques an analyst might look for at that stage of an intrusion. It is not a cause-side claim and does not pretend to be one.
The second is Microsoft's "Elevation of Privilege" label and the corresponding CVE-advisory convention. CVE-2025-21333 is an Elevation of Privilege vulnerability in the Hyper-V NT Kernel Integration VSP. Here the label describes the outcome the bug enables. It says nothing about whether the bug is server-role mishandling of inbound input, client-role mishandling of consumed data, abuse of designed authorization, or token theft. The label is silent on cause.
The third is the one this entry fixes: "privilege escalation" promoted into a threat-category slot, appearing in risk registers and control catalogues next to entries like "malware" and "phishing." A document that lists these together as peers is doing the same kind of category mixing as Entry 01 attacked. Two of the three name causes; "privilege escalation" names a transition.
The industry's own internal distinction between vertical escalation (low → high privilege) and horizontal escalation (peer-level account takeover) is worth flagging at this point. The cause-side structure is different for each, and the framework reads them differently, as §4 will show.
§ 2Why it fails the TLCTC test
Two structural failures, in the same shape as Entry 01.
First, privilege escalation is an effect. SG-4 — Effects Are Not Threats — was written with this term explicitly in view. The guardrail names privilege escalation, sandbox escape, hypervisor escape, persistence, and exfiltration as the cardinal examples of what is not a cluster. These are things that happen as a result of a cause being realised. They are not the cause. The Bow-Tie model places the cause on the left of the System Risk Event knot and the outcome on the right; privilege escalation belongs to the consequence-side or, when it occurs mid-attack, to the internal-transition annotation between adjacent steps.
Second, privilege escalation is mid-chain. Like "local exploit," it cannot occupy the first position in any attack path. Something must produce the elevation. That something is a cluster-classifiable step with its own cause. A label that structurally requires another step in front of it is not a top-level category; it describes what the preceding step accomplished.
§ 3The framework's positive answer: the intra-system boundary operator
This is where the privilege-escalation case is different from Entry 01's "local exploit" case. The framework does not just say "stop using it as a category"; it provides the right place to put it. TLCTC v2.1 introduced the intra-system boundary operator precisely so that internal trust transitions could be expressed without inflating the cluster set.
The annotation does three things at once. It records that an internal trust boundary was crossed, names the boundary type (privilege — other types include scope, tenant, network), and specifies the directional jump (@from→@to). The cluster identifier still carries the cause-side semantics; the annotation refines the step without replacing its taxonomy. Strip the annotation under SG-7 Backward Recoverability and the underlying cluster sequence remains a valid TLCTC path. Adding it gives the analyst observability over what happened without sacrificing the structural anchor.
The discipline this enforces matters. A reader sees the annotation and asks the right next question: how did this cluster step produce that transition? The cluster gives the answer because the cluster is the cause. A reader who instead encounters "Privilege Escalation: Yes" as a flag in a risk register has nowhere to go for the cause — the cause has been factored out of the description.
§ 4The four major decompositions
Almost every concrete privilege escalation in practice is produced by one of four clusters. The vertical-versus-horizontal industry distinction tracks this decomposition roughly: vertical escalations are usually #1 / #2 / #3 (code-level or configuration causes), and horizontal escalations are usually #4 (identity-level causes). The framework is not bound to four — any cluster can in principle sit upstream of a privilege transition — but these four cover the overwhelming majority of cases the industry actually catalogues.
Designed authorization used in an unintended way
The authorization mechanism does exactly what it is configured to do. The elevation is the design's natural consequence of an overly permissive grant, a missing scope check, or a feature being used in a context its designer did not anticipate. There is no bug to patch — there is a policy or configuration choice to revise.
Examples sudo NOPASSWD on broad commands · IAM role-chaining via AssumeRole when the policy permits it · OAuth scope confusion granting more than intended · GTFOBins-style SUID-feature abuse · Kubernetes RBAC permitting create pods/exec in a privileged namespace
Server-side handler in a privileged process fails on inbound input
Some privileged code accepts and processes attacker-influenced input — argv, environment, syscalls, IPC, IOCTLs — and the implementation has a flaw. Most kernel LPE CVEs sit here. The attacker sends; the privileged code breaks; the elevation follows.
Examples Sudo Baron Samedit (CVE-2021-3156) · Polkit PwnKit (CVE-2021-4034) · Dirty COW (CVE-2016-5195) · Dirty Pipe (CVE-2022-0847) · Calif M5 kernel chain · most Windows kernel EoP CVEs labelled "important" or "critical"
Client-side handler in a privileged process fails on consumed data
A privileged process initiates a read or call and mishandles what comes back. The attacker influences the returned data rather than sending a request to the vulnerable code. Less common than #2 in the privilege-escalation population but structurally distinct and easy to misclassify.
Examples Hyper-V VSP I/O ring response overflow (CVE-2025-21333) · privileged daemons parsing attacker-writable config files · root services consuming responses from compromised peer components via shared memory or named pipes
An existing higher-privileged identity is assumed via credential or token misuse
No code flaw is exploited and no authorization design is abused. The attacker acquires and uses authentication material belonging to a more-privileged principal — a token, hash, ticket, key, or session — and presents it to the authentication system, which validly grants the elevated access. The "horizontal" privilege-escalation case is almost always #4; many "vertical" cases also are when the path involves token theft.
Examples Kerberoasting and AS-REP roasting · pass-the-hash / pass-the-ticket / Silver and Golden tickets · AWS STS token exfiltration leading to AssumeRole as admin · OAuth refresh-token theft from a privileged user · service-account key extraction from CI/CD systems
Other clusters can produce privilege transitions too. #7 Malware rootkits achieve elevated execution by interpreting foreign code in a privileged context. #9 Social Engineering tricks a privileged user into performing an action the attacker cannot perform directly. #10 Supply Chain compromises a trusted dependency that executes at the host's privilege. These are rarer in CVE-catalogued privilege-escalation cases but structurally legitimate. The framework does not artificially restrict the upstream causes; it just refuses to let the transition itself stand in for them.
The two kernel-role posts on this blog both demonstrate the notation pattern. Calif M5 carries |[privilege][@local_user→@root]| on a #2 → #2 spine. CVE-2025-21333 carries |[privilege][@guest_user→@host_SYSTEM]| on a #3 spine.
Entry 01 of this glossary series ("Local Exploit" Is Not a Threat Category) covers the #1 / #2 / #3 decompositions that overlap heavily with the vertical-PE case set. This entry extends the picture with #4 — the cluster that dominates horizontal PE.
§ 5The fix
When the transition matters, annotate it: |[privilege][@from→@to]|. When the category matters, name the cluster. When both matter, do both — that is exactly what the notation was designed to express. The vertical-versus-horizontal industry split is a useful operational shorthand for the #1 / #2 / #3 versus #4 distinction, but it is shorthand; the cluster makes the cause explicit and the annotation makes the transition explicit.
What never works is treating "privilege escalation" as a peer of malware, phishing, or supply-chain compromise in a list of strategic threats. The list is mixing two different things — causes and consequences — and a control framework built on top of it will mix them too. The framework's diagnostic move is to keep the two on opposite sides of the System Risk Event and let each carry its own vocabulary. Privilege escalation is what happened. The cluster is what made it happen.◆