Privilege Escalation Is Usually Just One Forgotten Admin Right

Privilege escalation rarely looks dramatic. It usually looks like one unnecessary admin right, granted years ago, that nobody ever took back. MITRE ATT&CK sums up the attacker’s goal in one sentence: gain higher-level permissions. Most businesses picture a dramatic exploit. From what internal testing actually turns up, most real cases are closer to an accountant’s audit finding: a small, boring gap that quietly matters far more than it should.

Why privilege escalation usually has a boring cause

Privilege escalation gets marketed as a sophisticated art. In practice, most cases trace back to something dull. Security marketing loves a novel technique: a kernel zero-day, a clever token manipulation trick, a fresh sub-technique with its own catchy name. What testing actually finds is usually less interesting than the marketing. A shared local admin password. A service account nobody remembers creating. An employee whose access was never trimmed after a role change three years ago.

Since none of that requires sophistication to exploit, it just requires an attacker who is patient enough to look for what was left behind, and patience is a cheap, common trait among attackers.

Vertical and horizontal privilege escalation are both worth understanding

Vertical escalation gets the attention: a standard user becomes an administrator. It is the more dramatic-sounding of the two, and it is genuinely dangerous. But horizontal escalation, moving sideways between accounts at the same level, deserves equal attention. An attacker who quietly accumulates access to a dozen ordinary accounts can often reach as much sensitive data as one who gained admin rights outright. None of it trips the alarms that watch for privileged account activity.

What actually stops this, and why it gets skipped anyway

NCSC’s guidance is not complicated. Apply least privilege. Tier your administrative accounts. Use dedicated, locked-down workstations for privileged work. Patch consistently. Monitor privileged activity for anything unusual.

None of that is exotic, and none of it needs a new product. That is precisely why it gets skipped. There is no vendor booth pitching “review your admin accounts properly.” Yet that unglamorous work closes more real paths than most of what does get pitched. Security budgets tend to flow toward things that are visible and demoable, not toward the quiet discipline of trimming access nobody remembers granting.

How an attacker actually climbs

MITRE ATT&CK lists 13 techniques under its Privilege Escalation tactic, but the patterns repeat. Abuse a mechanism meant to control elevation, such as tricking UAC or sudo into running something it should have blocked. Exploit an unpatched flaw that lets a low-privilege process act with more power than intended. Steal an access token and simply borrow someone else’s permissions. Find a service account with more reach than its job needs, and use that instead of attacking anything directly.

Every one of these techniques depends on a gap between what was configured and what should have been configured, since nobody sets out to build an exploitable system. Nobody designs a system to be climbable. It becomes climbable through drift: settings nobody revisited, accounts nobody reviewed, patches nobody applied on the internal network because the internet-facing systems got priority instead.

Where testing earns its keep

A policy document describing least privilege proves nothing about whether least privilege actually holds in practice. An internal network penetration test starts from a low-privilege foothold and genuinely tries to climb, the same way a patient real attacker would. It turns “we believe our access controls are tight” into an actual, tested answer.

That test usually surfaces the boring gap, not the dramatic exploit. The forgotten service account. The admin right nobody revoked. Our guide on judging a provider’s penetration testing methodology covers what a tester should actually be doing here. A scan alone will not find what a genuine attempt to climb finds.

The relationship with lateral movement

Privilege escalation and lateral movement are rarely separate events in a real attack. An attacker escalates on one machine, uses that access to reach another, escalates again, and repeats. Testing one without the other tells only half the story. A useful internal engagement reports the whole chain, since fixing one link while leaving the next intact solves very little.

What a genuine review actually finds

Ask most IT teams whether their access controls are tight, and they will say yes, in good faith. Then run an actual audit and the picture usually looks different. An admin account for a contractor who left two years ago. A shared password on a legacy system nobody wants to touch. A service account with domain admin rights because it was easier to grant them once than scope them properly at the time.

None of these findings are exciting, though all of them are exactly the kind of gap that lets privilege escalation happen in practice. It does not matter how tight the policy document claims things are.

Building the habit, not just the audit

A one-off cleanup helps, but access drifts again the moment nobody is watching. Businesses that keep this under control build review into a regular rhythm. New starters get scoped access tied to their actual role. Leavers lose access immediately, not eventually. Admin rights get revisited on a fixed schedule, not only when something goes wrong. The discipline matters more than any single audit.

Frequently asked questions

Why does horizontal escalation get overlooked?

Because it doesn’t set off the alarms built to watch privileged accounts. Moving between ordinary user accounts looks unremarkable, even as an attacker steadily builds up reach across the business.

Is this a bigger risk on-premise or in the cloud?

Both, through different mechanisms. Cloud environments trade Windows tokens and sudo rules for over-permissioned roles and leaked API keys. The underlying problem, more access than intended, is identical either way.

What is the single most cost-effective fix?

Auditing and trimming existing access. It requires no new software, only the discipline to actually do it and keep doing it as roles change. That discipline, more than any tool, is what separates businesses that stay ahead of this from those that do not.

Can automated tools catch this on their own?

They help with discovery and monitoring. But confirming whether escalation is genuinely possible still requires a human attempting it, the way a real attacker would.

Does compliance certification mean this is already handled?

Not necessarily. Frameworks like ISO 27001 or Cyber Essentials expect access controls and least privilege in principle. Still, passing an audit is not the same as those controls surviving a genuine attempt to escalate privileges. The gap between the two is exactly where testing earns its value.

How often should access reviews happen?

At minimum annually, alongside your penetration testing cycle. A faster review makes sense whenever someone changes role or leaves the business, since waiting for the annual cycle alone leaves privilege escalation paths open for months at a time.

Aardwolf Security’s internal testing is built to find out whether your access controls look tighter on paper than they would actually hold up. Get in touch to talk it through, or see our full penetration testing services.