Preventing Privilege Escalation

Less Trust, Less Damage

In network security, structure beats improvisation: clear paths, fewer privileges and explicit trust boundaries.

For Preventing Privilege Escalation the fundamentals remain the same: less implicit trust and more visibility into anomalous behaviour.

This limits not only the likelihood of incidents, but above all the scope and duration when something does go wrong.

Immediate measures (15 minutes)

• Start with MFA, least privilege and tiering for admin accounts.
• Enforce segmentation and explicit firewall rules on critical paths.
• Embed logging, detection and recovery tests as structural operations.

Why this matters

The core of Preventing Privilege Escalation is risk reduction in practice. Technical context supports the choice of measures, but implementation and embedding are central.

Part 5: Defence

In 1974 Jerome Saltzer and Michael Schroeder at MIT published a paper with the not particularly catchy title "The Protection of Information in Computer Systems." In it they formulated a principle that sounds so obvious you wonder why anyone bothered writing it down: every program and every user should operate with the minimum set of privileges necessary to perform their task. They called it the Principle of Least Privilege. It was 1974. Nixon had just resigned. The average computer was the size of a fridge. And the principle Saltzer and Schroeder described is still – fifty years later – being ignored by virtually every organisation on earth.

It is as if someone wrote a manual for flood prevention in 1974, and in 2026 we are still surprised that the water rises when we do not maintain the dykes. The principle is there. The knowledge is there. The implementation is not.

Privilege escalation is, in essence, the story of the caretaker who finds the master key. Imagine a large office building. Every employee has a key that fits their own office, the canteen and the toilets. That is the principle of least privilege in the physical world. But somewhere in the basement, in a drawer that is not locked, is a master key that fits every door. The caretaker knows the drawer is there – after all, they never locked it. The question is not whether someone finds that master key. The question is how long it takes.

In the digital world that master key is a local admin account. Or a service running as SYSTEM. Or a SUID binary on Linux that was forgotten after an installation three years ago. Or a cron job that is writable by everyone. They are all variants of the same theme: someone once granted more rights than necessary, and nobody revoked them. And now there is a pentester (or worse, an attacker) on the system who knows exactly where to look.

Now that we have extensively discussed how to escalate privileges – from AlwaysInstallElevated to wildcard injection, from Mimikatz to writable cron jobs – it is time for the counteroffensive. Because if this book only described attack techniques without defences, we would not be much better than a handbook for burglars.

The uncomfortable thing about privilege escalation is that the solution has been known for decades. Remove unnecessary admin rights. Implement LAPS. Enable Credential Guard. Fix unquoted service paths. Audit your sudo configuration. These are not advanced measures. These are not expensive measures. These are measures that a motivated system administrator can implement in an afternoon. But they require something rarer than budget or technical knowledge: the organisational will to say no. No to the CEO who wants local admin rights. No to the application that only works as SYSTEM. No to the culture of "we've always done it this way."

What follows is the defence section: concrete measures, ordered from most impactful to most specific. And we start – naturally – with the principle that Saltzer and Schroeder described fifty years ago and that is still the foundation of everything that works.

Least privilege: the principle nobody follows

The principle of least privilege states that every user, every process and every account must have exactly the rights needed for their function, and no more. It is the kind of principle everyone knows, everyone endorses and nobody implements.

The cynical version: "Everyone in an organisation has local admin rights. The CEO needs it to install their printer driver. The accountant needs it because an application from 2003 requires it. The intern needs it because… well, nobody actually knows why. But revoking it would generate a help desk ticket, and that is worse than a data breach."

And that is the fundamental problem. Local admin rights are the single biggest attack surface on Windows machines. With local admin you can:

• Run Mimikatz and dump credentials
• Install and configure services
• Disable the firewall
• Disable or whitelist AV
• Impersonate tokens

Without local admin you can do virtually none of the above.

Concrete measures

LAPS: Local Administrator Password Solution

LAPS is Microsoft's answer to the problem of shared local admin passwords. Without LAPS every machine in the domain has the same local admin password – or no local admin password at all. With LAPS every machine gets a unique, randomly generated password that rotates automatically.

# Controleer of LAPS is geinstalleerd
Get-ADObject 'CN=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=domain,DC=local'

# Bekijk LAPS wachtwoord (als je rechten hebt)
Get-ADComputer -Identity WORKSTATION01 -Properties ms-Mcs-AdmPwd | Select-Object ms-Mcs-AdmPwd

LAPS solves a simple but devastating problem: if you dump a local admin hash on machine A, and every machine has the same password, you can move laterally to machine B, C, D and E. With LAPS the hash only works on one machine.

Credential Guard

Credential Guard uses virtualization-based security (VBS) to isolate LSASS. Mimikatz cannot reach it. It is as if you put the safe not in the bank, but in a separate dimension. Even if the burglar is inside the bank, they cannot reach the safe.

# Controleer of Credential Guard actief is
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object SecurityServicesRunning

Linux hardening

# Vind en repareer onnodige SUID bits
find / -perm -4000 -type f -exec ls -la {} \; 2>/dev/null
# Verwijder SUID waar niet nodig:
chmod u-s /usr/bin/onnodig_binary

# Audit sudo configuratie
visudo
# Vermijd: ALL=(ALL) NOPASSWD: ALL
# Gebruik: specifiek_user specifiek_host = (specifiek_target) specifiek_command

# Controleer cron job permissies
find /etc/cron* -writable -type f 2>/dev/null
# Fix: chmod 644 of strenger

# Controleer capabilities
getcap -r / 2>/dev/null
# Verwijder onnodige capabilities:
setcap -r /usr/bin/onnodig_binary

# Controleer /etc/passwd permissies
ls -la /etc/passwd /etc/shadow
# Moet zijn: -rw-r--r-- root root /etc/passwd
#            -rw-r----- root shadow /etc/shadow

The uncomfortable conversation about local admin

Let us be honest. The entire reason privilege escalation is so effective in most organisations is not a technical problem. It is a political problem. A cultural problem. A human problem.

Somewhere, at some point, someone created a help desk ticket: "I can't install my printer." The system administrator, who already had eighteen tickets in the queue, had missed two meetings and skipped lunch, clicked "Add to local Administrators group" and got on with their day.

That was ten years ago. That user has since retired. But their local admin rights are still there. As are those of the 400 other users who got local admin for similar reasons. And now it is "policy." Because when 400 people have it, it is no longer an exception. It is a standard.

"Do you know what the problem is with security policy?" Let it sink in. "It is written by people who have never experienced an attack, approved by people who do not know what it means, and ignored by the people who should implement it. It is a chain of incompetence so perfect you almost have to admire it."

And that is precisely why pentesters are hired. Not to prove that systems are vulnerable – everyone knows that. But to force the organisation to write it down, attach a risk score to it, and put it in a report that goes to management. Because a PowerPoint is the only language decision-makers speak.

Reference table

Summary

Privilege escalation is not the result of brilliant hacking. It is the result of lazy configuration, forgotten policies and the universal human tendency to "fix it later." Every technique in this chapter – from AlwaysInstallElevated to wildcard injection, from Mimikatz to writable cron jobs – exploits not a technical flaw but a human flaw.

The tools are available. The techniques are documented. The defence is known. The only thing missing is the will to do it right.

And that, dear reader, is why we pentesters still have work.

Next chapter: Chapter 7 – Active Directory Previous chapter: Chapter 5 – Windows Enumeration