Stored Flammables: How Local Privilege Escalation Threatens Your Security Program

 TL;DR: LPE scores low in vulnerability management because it requires local access to exploit. That's the wrong frame once an attacker already has a foothold: LPE invalidates your security architecture and compresses lateral movement time to near zero.


Here's something you might not think about: Building codes save more lives from fire than firefighters do.

When you look at the sheetrock in a modern home, you don't stop to consider that someone did fire resistance testing. The code works because it's invisible, unglamorous, and does its job before the fire starts. Security architecture works the same way. When a network is built right, attacks can't spread quickly. Incidents get mitigated down to inconveniences. Nobody notices.

Most security programs never evaluate what happens when flammable materials end up somewhere they weren't designed to be stored.


Cluttered garages degrade fire resistance.

A building's fire resistance rating is calibrated for expected materials burning at expected rates. The ratings hold. Introduce gasoline stored in the wrong area and the assumptions behind the rating no longer apply. Barriers designed to contain a normal fire can't contain an accelerated one. The code didn't fail. The conditions changed in a way nobody accounted for.

Local privilege escalation (LPE) is the step where an attacker converts a low-privilege foothold into elevated access: a standard user account becoming SYSTEM on Windows, or an unprivileged process becoming root on Linux. LPE is that accelerant.

Your network's fire resistance (segmentation, least privilege policy, EDR coverage) was calibrated for a low-priv attacker moving through expected channels. Elevation changes the burn rate.

The flammables didn't arrive intentionally. Garages accumulate them: paint thinner, old gas cans, linseed-soaked rags. None of it stocked as a fire hazard. Things just end up there. Networks work the same way. Credentials cached on endpoints not designed as credential stores. Service accounts scoped to convenience. Management plane tooling trusted across segments. Cloud metadata reachable from machines nobody flagged as an exposure surface. Each decision made sense on its own. Active work spaces accumulate material, sometimes that material is a fire hazard.


The scoring system is measuring the entry barrier, not what happens after it

CVSS "local access required" deflates vulnerability scores because it assumes the barrier to local access is meaningful. It was, once. Getting a low-priv foothold is now a commodity: phishing, credential stuffing, MFA fatigue, exposed services. The score is answering "can an unauthenticated remote attacker reach this?" That's the right question when the perimeter is your primary control and the wrong one once someone is already inside. Vulnerability management isn't wrong about the metric. The metric stops being relevant the moment practitioners start paying attention.


A harm reduction mindset

Zero trust and least privilege are harm reduction strategies. They accept that the network won't be perfectly defended and design to limit what an attacker can reach. LPE is what breaks that containment at the endpoint boundary. A low-priv foothold is constrained: limited file access, no interaction with privileged processes, no access to credential stores or security tooling. Elevation opens that surface entirely.

Three things elevation unlocks.

EDR, logging agents, and AV all run as privileged processes. A low-priv user can't touch them. Elevated access can blind or kill them.

Platform credential stores (DPAPI and LSA secrets on Windows, keyring material and SSH keys on Linux) are all gated behind privilege. A dedicated workstation is often more valuable here than a shared one: it has that specific person's credentials cached on it.

Managed endpoints, service accounts with accumulated permissions, implicit east-west trust: the environment was built assuming that if you're authenticated and present, you belong there.


"In theory, there is no difference between theory and practice. In practice, there is."

Security architecture and policy teams design for the environment as intended. Detection engineers and DFIR practitioners work in the environment as it exists. The gap between those two environments is where attacks live.

The pattern I've watched run consistently in purple team exercises: low-priv foothold, LPE, security controls blinded, credentials harvested from memory or disk, lateral movement to more critical infrastructure, repeat. Each step is made possible by the one before it. An attacker without elevation is a low-priv user on one machine. Elevation turns the network's own trust architecture into the attack path.

It's easy to invent scenarios where LPE doesn't matter. Detection engineers don't get to work in those.

The most common version sounds like this: we've done the segmentation work, our service accounts are tight, our machines aren't shared, there's no viable lateral movement path from a compromised endpoint. It's a reasonable position. It's also describing an architecture diagram, not a running environment.

Two reasons it doesn't hold. First, the management plane is always there. Patch management, backup agents, configuration management, monitoring tooling: all of it needs privileged access to endpoints and creates trusted channels to central infrastructure. An elevated account can interact with those agents. The security program itself is often the most trusted communication channel on the machine, which makes it a path to the security stack.

Second, the attacker finds pathways you haven't catalogued. Privileged enumeration reveals actual network connections, running services, NFS mounts, SSH agent forwarding state, cloud metadata, credentials sitting in environment variables. The attacker isn't working from your network diagram.

Offensive security thinkers assume any one control will fail. That's correct planning posture. Build around failure, design for defense in depth. But planning around control failure is different from accepting it without instrumentation. The organization that says "red teams blind EDR anyway, so why invest in LPE detection" has taken a correct design assumption and used it to justify a gap that negates their detection investments. Assume breach means instrument for breach, not abandon the watch.


In closing

Building codes give us time. LPE is the event that starts compressing that clock. Post-escalation, an attacker with elevated access can blind your detection. Lateral movement breakout time approaches zero. You don't know it yet, because you weren't watching for the moment the accelerant ignited.

Detection isn't glamorous. Neither is the building code. Both give you time you wouldn't otherwise have.

While we're on the topic. Your lifetime probability of having a fire large enough to be reported to a fire department is about 1 in 4. Once a smoke alarm sounds, you have less than three minutes to escape. Roughly 75% of all fire deaths are caused by home fires. Go check your detectors folks.

Comments

Popular posts from this blog

Lab Notes: Persistence and Privilege Elevation using the Powershell Profile

Lab Notes: Claude Code Session Logs as a Forensic Artifact

Setting Static IP Addresses In VMware Fusion