Privilege Escalatie Voorkomen

Minder Trust, Minder Schade

In netwerkbeveiliging wint structuur van improvisatie: duidelijke paden, minder privileges en expliciete trust-grenzen.

Voor Privilege Escalatie Voorkomen blijft de basis hetzelfde: minder impliciet vertrouwen en meer zicht op afwijkend gedrag.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Privilege Escalatie Voorkomen is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Deel 5: Verdediging

In 1974 publiceerden Jerome Saltzer en Michael Schroeder aan het MIT een paper met de weinig sexy titel “The Protection of Information in Computer Systems.” Daarin formuleerden ze een principe dat zo vanzelfsprekend klinkt dat je je afvraagt waarom iemand de moeite nam het op te schrijven: elk programma en elke gebruiker zou moeten opereren met de minimale set aan privileges die nodig is om zijn taak uit te voeren. Ze noemden het het Principle of Least Privilege. Het was 1974. Nixon was net afgetreden. De gemiddelde computer was zo groot als een koelkast. En het principe dat Saltzer en Schroeder beschreven, wordt nu – vijftig jaar later – nog steeds door vrijwel elke organisatie op aarde genegeerd.

Het is alsof iemand in 1974 een handleiding schreef voor het voorkomen van overstromingen, en we in 2026 nog steeds verbaasd zijn dat het water stijgt als we de dijken niet onderhouden. Het principe is er. De kennis is er. De implementatie is er niet.

Privilege escalatie is, in essentie, het verhaal van de conciërge die de loper vindt. Stel je een groot kantoorgebouw voor. Elke werknemer heeft een sleutel die past op zijn eigen kantoor, de kantine en de toiletten. Dat is het principe van least privilege in de fysieke wereld. Maar ergens in de kelder, in een la die niet op slot zit, ligt een loper die op elke deur past. De conciërge weet dat die la er is – hij heeft hem tenslotte zelf niet op slot gedaan. De vraag is niet of iemand die loper vindt. De vraag is hoe lang het duurt.

In de digitale wereld is die loper een local admin-account. Of een service die draait als SYSTEM. Of een SUID-binary op Linux die vergeten is na een installatie drie jaar geleden. Of een cron job die schrijfbaar is voor iedereen. Het zijn allemaal varianten van hetzelfde thema: iemand heeft ooit meer rechten uitgedeeld dan nodig was, en niemand heeft ze teruggenomen. En nu zit er een pentester (of erger, een aanvaller) op het systeem die precies weet waar hij moet zoeken.

Nu we uitgebreid hebben besproken hoe je privilege escaleert – van AlwaysInstallElevated tot wildcard injection, van Mimikatz tot writable cron jobs – is het tijd voor het tegenoffensief. Want als dit boek alleen aanvalstechnieken zou beschrijven zonder verdediging, zouden we niet veel beter zijn dan een handleiding voor inbrekers.

Het ongemakkelijke aan privilege escalation is dat de oplossing al decennia bekend is. Verwijder onnodige admin-rechten. Implementeer LAPS. Activeer Credential Guard. Fix unquoted service paths. Audit je sudo-configuratie. Het zijn geen geavanceerde maatregelen. Het zijn geen dure maatregelen. Het zijn maatregelen die een gemotiveerde systeembeheerder in een middag kan implementeren. Maar ze vereisen iets wat schaarser is dan budget of technische kennis: de organisatorische wil om nee te zeggen. Nee tegen de CEO die lokale admin-rechten wil. Nee tegen de applicatie die alleen werkt als SYSTEM. Nee tegen de cultuur van “we hebben het altijd zo gedaan.”

Wat volgt is het verdedigingsdeel: concrete maatregelen, geordend van meest impactvol naar meest specifiek. En we beginnen – uiteraard – met het principe dat Saltzer en Schroeder vijftig jaar geleden beschreven en dat nog steeds het fundament is van alles wat werkt.

Least privilege: het principe dat niemand volgt

Het principe van least privilege stelt dat elke gebruiker, elk proces, en elk account precies die rechten moet hebben die nodig zijn voor zijn functie, en niet meer. Het is zo’n principe dat iedereen kent, iedereen onderschrijft, en niemand implementeert.

Even de cynische versie: “Iedereen in een organisatie heeft local admin rechten. De CEO heeft het nodig om zijn printer driver te installeren. De accountant heeft het nodig omdat een applicatie uit 2003 het vereist. De stagiair heeft het nodig omdat… ja, eigenlijk weet niemand waarom. Maar het intrekken zou een helpdesk-ticket veroorzaken, en dat is erger dan een datalek.”

En dat is het fundamentele probleem. Local admin rechten zijn de single biggest attack surface op Windows-machines. Met local admin kun je:

• Mimikatz draaien en credentials dumpen
• Services installeren en configureren
• De firewall uitschakelen
• AV uitschakelen of whitelisten
• Tokens impersonaten

Zonder local admin kun je vrijwel niets van bovenstaande.

Concrete maatregelen

LAPS: Local Administrator Password Solution

LAPS is Microsoft’s antwoord op het probleem van gedeelde local admin wachtwoorden. Zonder LAPS heeft elke machine in het domein hetzelfde local admin wachtwoord – of helemaal geen local admin wachtwoord. Met LAPS krijgt elke machine een uniek, willekeurig gegenereerd wachtwoord dat automatisch rouleert.

# 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 lost een simpel maar verwoestend probleem op: als je een local admin hash dumpt op machine A, en elke machine hetzelfde wachtwoord heeft, kun je lateraal bewegen naar machine B, C, D, en E. Met LAPS werkt de hash maar op een machine.

Credential Guard

Credential Guard gebruikt virtualization-based security (VBS) om LSASS te isoleren. Mimikatz kan er niet bij. Het is alsof je de kluis niet in de bank zet, maar in een aparte dimensie. Zelfs als de inbreker in de bank staat, kan hij de kluis niet bereiken.

# 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

Het ongemakkelijke gesprek over local admin

Laten we eerlijk zijn. De hele reden dat privilege escalation zo effectief is in de meeste organisaties, is niet een technisch probleem. Het is een politiek probleem. Een cultureel probleem. Een menselijk probleem.

Ergens, ooit, heeft iemand een helpdesk-ticket aangemaakt: “Ik kan mijn printer niet installeren.” De systeembeheerder, die al achttien tickets in de wachtrij had, twee vergaderingen had gemist, en zijn lunch had overgeslagen, klikte op “Toevoegen aan lokale Administrators-groep” en ging door met zijn dag.

Dat was tien jaar geleden. Die gebruiker is inmiddels gepensioneerd. Maar zijn local admin-rechten zijn er nog steeds. Net als die van de 400 andere gebruikers die om soortgelijke redenen local admin kregen. En nu is het “beleid.” Want als 400 mensen het hebben, is het geen uitzondering meer. Het is een standaard.

“Weet je wat het probleem is met beveiligingsbeleid?” Laat het even bezinken. “Het wordt geschreven door mensen die nooit een aanval hebben meegemaakt, goedgekeurd door mensen die niet weten wat het betekent, en genegeerd door mensen die het zouden moeten implementeren. Het is een keten van incompetentie zo perfect dat je het bijna zou bewonderen.”

En precies daarom worden pentesters ingehuurd. Niet om te bewijzen dat systemen kwetsbaar zijn – dat weet iedereen. Maar om de organisatie te dwingen het op te schrijven, er een risicoscore aan te hangen, en het in een rapport te zetten dat naar het management gaat. Want een PowerPoint is de enige taal die beslissers spreken.

Referentietabel

Samenvatting

Privilege escalation is niet het resultaat van briljante hacking. Het is het resultaat van luie configuratie, vergeten beleidsregels en de universele menselijke neiging om “het later wel te fixen.” Elke techniek in dit hoofdstuk – van AlwaysInstallElevated tot wildcard injection, van Mimikatz tot writable cron jobs – exploiteert niet een technisch gebrek, maar een menselijk gebrek.

De tools zijn beschikbaar. De technieken zijn gedocumenteerd. De verdediging is bekend. Het enige dat ontbreekt, is de wil om het goed te doen.

En dat, beste lezer, is waarom wij pentesters nog steeds werk hebben.

Volgend hoofdstuk: Hoofdstuk 7 – Active Directory Vorig hoofdstuk: Hoofdstuk 5 – Windows Enumeratie