You're told injecting into a user's browser 'escalated' the operator's privileges. On a shared desktop, is that right?

## The claim and why it is tempting When an operator's traffic suddenly appears as a real user browsing from a signed browser, it looks powerful, and 'they injected and escalated' is a natural shorthand. It is also wrong, and getting it wrong sends a platform owner chasing the wrong control. ## Same integrity level: injection is free Every process runs under an **access token** naming a user and their rights, and at an **integrity level**. Code that is already executing as a given user, at that user's integrity, can open and modify that user's *own* processes — that is not a special capability, it is what running as the user means. So writing into the user's own browser and running there requires no privilege the operator did not already have. The move is **horizontal** in privilege terms: - same rights, - different *identity on the wire* - and different *egress path*. The operator trades a conspicuous process for the one process whose internet traffic looks normal. ## Why the traffic proving 'it's the user' is the tell Precisely because nothing was elevated, the outbound requests carry the user's authenticated sessions and proxy configuration. If this had been an escalation — new rights the operator did not have — you would expect signs of a **privilege transition**. Instead you see the user being the user. The very normality of the traffic is evidence that no privilege boundary was crossed. ## Where privilege actually is spent: the session boundary A **multi-session terminal server** has many users logged on at once, each in their own session. Reaching into *another* user's process — say, to wear a different person's identity and destinations — is a different matter. Opening and writing a process that belongs to a separate session requires the **debug privilege** or administrative rights; a plain user cannot do it to a stranger's process. *That* crossing is a real escalation. So the honest statement is: - **same-session injection** is not escalation; - **cross-session injection** is, and it is gated by privilege the operator must first obtain. ## What to tell the platform owner The action item is not 'stop the escalation' — there was none within the session. It is to recognise: - that a user's own code can always wear the user's own browser, so outbound identity tied to the host process is not trustworthy, - and that the control worth having sits at the **session boundary** and at **egress**, not at the same-user process boundary, which cannot be closed against the user's own code. ## The boundary this owns, and where it stops The distinction here is specifically the **injection/session/integrity** boundary on this host. General theory of vertical versus horizontal *movement* across an estate, and intrusions where nothing was escalated end to end, live with the identity and credential material — this answer stays on the concrete question of whether *this* injection, into *this* browser, elevated anything.