Privilege Escalation And How Attackers Actually Probe

The last chapter closed with a warning: no cookie attribute alone protects against an attacker who's determined and willing to probe for gaps. This is the chapter where that warning gets specific.

The Word "Escalation" Oversells It

When I first heard "privilege escalation," I pictured something dramatic: a hacker cracking root access on a server, alarms going off, the works. Most of it looks nothing like that.

Privilege escalation is just doing anything an account was never supposed to be able to do. Becoming an admin counts. So does something much smaller.

Go back to the plain-text username mistake from the last chapter. Editing a cookie from user=peter to user=denver and suddenly reading Denver's notes is, technically, already a privilege escalation. Nobody granted that access. The account just took it, because nothing stopped it from asking.

That reframes the whole category. It's not one dramatic exploit. It's the general shape of "I have some access, and now I have more than I should."

Two Directions, Same Idea

Security write-ups usually split this into two flavors, and the split is worth knowing even if the underlying idea stays the same.

• Vertical escalation means gaining a higher level of access than the account was granted, like a normal user reaching admin-only functionality
• Horizontal escalation means staying at the same level but reaching into someone else's account, like Peter reading Denver's private notes without ever becoming an admin

Both are privilege escalation. Neither requires the other. The cookie-editing trick from the last chapter is horizontal: same permission level, wrong account. A misconfigured route that lets any logged-in user call an admin-only endpoint is vertical. Most real incidents involve some mix of both, one unlocking the other.

Attackers Rarely Just Know the Exploit

Here's the part that surprised me most when I started reading real disclosure reports: attackers almost never walk in already knowing the exact flaw.

The typical shape looks like this.

• They already have some baseline access, usually a normal account they signed up for like anyone else
• They start looking for misconfigurations, not writing exploits from scratch
• They watch what the system gives back, and build a picture from the leftovers

ExpandA baseline account moving through probing for signals to an escalated outcome, with bug bounty programs framed as the legal channel for the middle step.

It's investigation first, exploitation second. A surprising amount of real-world hacking looks less like a movie hacking montage and more like a patient audit of everything an API happens to reveal.

Reading the Tells in an API Response

The clearest example I've seen of this patience is a trick that doesn't even touch the server's logic.

Say an attacker suspects there's a hidden admin panel somewhere on the page, but they can't see it and don't have permission to load it directly. Instead of guessing URLs, they inject a small piece of CSS through some field the app lets them control, maybe a bio field or a comment.

That CSS targets a background image on a specific element ID, something like #admin-panel-toggle. If the image loads, that ID exists somewhere on the page, even if it's invisible to a normal user. The attacker never touched a line of JavaScript, never broke anything, and now knows something about the page's structure they weren't supposed to know.

That's the pattern worth remembering: the probe itself often looks completely harmless. No error is thrown. No alert fires. All that happened was one styled element quietly confirming or denying a guess.

Stack traces leaking in error pages work the same way, just louder. So does a response that returns a slightly different shape for an account that doesn't exist versus one that does. Every one of these is a small leak, and small leaks are how the map of a system gets built.

There's a Legal Version of This

It's worth saying plainly: this kind of probing isn't automatically malicious.

Bug bounty programs exist specifically because companies would rather pay someone to find these gaps than have a stranger find them first. A researcher signs up for the program, gets explicit permission to test, and agrees to report anything found privately before it goes public. That agreement is usually called responsible disclosure.

The technique is identical either way, probing, watching responses, building a picture. The only thing that changes is whether anyone gave permission first. That distinction is the entire line between a paid bug bounty report and a breach.

What Comes Next

Watching API responses for tells is one way in. The far more common one, and the one that does the most damage, is injecting something directly into a query the server was never expecting.

That's the next post: what actually happens, character by character, when unescaped input reaches a SQL statement.

The Essentials

1. Privilege escalation means doing anything an account wasn't meant to do, not just becoming an admin.
2. Switching to another user by editing a plain-text cookie already counts, even without a dramatic exploit.
3. Attackers usually start with baseline access and probe from there, rather than knowing the exact flaw upfront.
4. A CSS-into-a-hidden-element trick can leak page structure with zero JavaScript and zero errors.
5. Bug bounty programs and responsible disclosure are the legal version of the exact same probing technique.

Next up: what a SQL injection actually does to the query itself, and why raw string interpolation is the root cause every time.

Further Reading and Watching

• Top privilege escalation techniques - bug bounty case study: a real disclosure report walked through step by step, showing the probing pattern in practice.
• OWASP Broken Access Control: the reference entry for the category privilege escalation falls under, with common real-world patterns.