Hoe kunnen Azure RBAC-rechten onderdeel worden van een aanvalspad?

Geplaatst op: 10 oktober 2026

Azure RBAC (rolgebaseerde toegangscontrole) is de ruggengraat van toegangsbeheer in Microsoft Azure. Goed ingericht biedt het een krachtige manier om te bepalen wie wat mag doen binnen je cloudomgeving. Maar wanneer RBAC-rechten te ruim zijn toegewezen, slecht zijn gedocumenteerd of niet regelmatig worden gecontroleerd, worden ze iets heel anders: een aanvalspad.

In dit artikel leer je stap voor stap hoe je Azure RBAC-rechten analyseert vanuit het perspectief van een aanvaller. Je brengt de RBAC-structuur in kaart, identificeert gevaarlijke escalatiepaden, simuleert een aanvalspad en herstelt de gevonden risico’s structureel. Het doel is niet alleen inzicht, maar concrete actie.

Vereiste kennis en toegang voor deze analyse

Voordat je begint, is het belangrijk om te weten wat je nodig hebt. Deze analyse vereist zowel technische kennis als de juiste toegangsrechten binnen je Azure-omgeving. Zonder de juiste basis loop je het risico om een incompleet beeld te krijgen van de werkelijke risico’s.

Zorg dat je beschikt over het volgende:

• Azure-toegang: Minimaal de rol van Security Reader of Reader op abonnementsniveau, bij voorkeur Global Reader in Microsoft Entra ID (voorheen Azure AD)
• Tooling: Azure CLI of Azure PowerShell, toegang tot de Azure Portal, en optioneel tools zoals AzureHound of BloodHound voor het visualiseren van aanvalspaden
• Basiskennis van RBAC-concepten: Begrip van rollen (built-in en custom), bereiken (management group, subscription, resource group, resource) en principals (gebruikers, groepen, service principals, managed identities)
• Toestemming: Voer deze analyse alleen uit op omgevingen waarvoor je expliciete autorisatie hebt. Zonder toestemming is dit ongeoorloofde toegang

Met deze basis op orde kun je de analyse uitvoeren op een gestructureerde en verantwoorde manier. Heb je niet alle toegang zelf, dan is het verstandig om samen te werken met een Azure-beheerder of een externe specialist die een pentest uitvoert op jouw cloudomgeving.

Breng de RBAC-structuur van je Azure-omgeving in kaart

De eerste stap is inzicht krijgen in wie welke rechten heeft, op welk niveau. Dit klinkt eenvoudig, maar in de praktijk zijn Azure-omgevingen vaak gegroeid zonder centraal overzicht. Rechten zijn toegewezen op meerdere niveaus, via verschillende groepen, en soms direct aan individuele accounts.

Voer de volgende stappen uit om een volledig beeld te krijgen:

1. Exporteer alle role assignments op abonnementsniveau via Azure CLI: az role assignment list –all –output json
2. Filter de output op hoge bevoorrechte rollen zoals Owner, Contributor en User Access Administrator
3. Breng ook de Microsoft Entra ID-rollen in kaart, zoals Global Administrator en Privileged Role Administrator, via het Entra-portaal of via PowerShell
4. Inventariseer service principals en managed identities met toegewezen rollen, want dit zijn vaak vergeten maar krachtige identiteiten
5. Visualiseer de structuur per bereik: welke principals hebben toegang op management group-niveau, en welke rechten erven zij daardoor automatisch op onderliggende abonnementen en resource groups?

Na deze stap heb je een gestructureerde lijst van alle RBAC-toewijzingen in je omgeving. Controleer of de lijst volledig is door het totale aantal role assignments in de Portal te vergelijken met je export. Ontbrekende toewijzingen wijzen op een onvolledige analyse of op rechten die via groepen zijn toegewezen en apart moeten worden uitgevraagd.

Identificeer gevaarlijke rechten en escalatiepaden

Niet elke RBAC-toewijzing is even gevaarlijk. De uitdaging is om te onderscheiden welke rechten, ook als ze op zichzelf onschuldig lijken, kunnen worden misbruikt voor privilege escalation. Dit is precies waar aanvallers naar zoeken: combinaties van rechten die samen meer opleveren dan elk afzonderlijk.

Richt je analyse op de volgende categorieën:

• Directe hoge rechten: Owner en User Access Administrator op abonnementsniveau geven volledige controle. Elke toewijzing hier moet worden gerechtvaardigd.
• Gevaarlijke Entra ID-permissies: Accounts met de mogelijkheid om rollen toe te wijzen, wachtwoorden te resetten of applicaties te registreren kunnen hun eigen rechten uitbreiden
• Managed identities met brede rechten: Een managed identity die is gekoppeld aan een virtual machine en Contributor-rechten heeft op een abonnement, is een potentieel escalatiepad als de VM wordt gecompromitteerd
• Custom rollen met gevaarlijke acties: Controleer custom rollen op acties zoals Microsoft.Authorization/roleAssignments/write, waarmee een principal zichzelf of anderen hogere rechten kan geven

Een concrete escalatieroute die regelmatig voorkomt in Azure-omgevingen is de combinatie van een SSRF-kwetsbaarheid in een applicatie, een managed identity met brede rechten, en vervolgens toegang tot een Key Vault met gevoelige geheimen of certificaten. Los van elkaar lijken dit kleine bevindingen. Samen vormen ze een aanvalspad naar volledige controle over cloudresources. Dit is precies waarom red-teamonderzoek verdergaat dan losse kwetsbaarhedenlijsten.

Simuleer een aanvalspad stap voor stap

Met de gevaarlijke rechten in kaart is de volgende stap het daadwerkelijk doorlopen van een aanvalspad in een gecontroleerde omgeving. Het doel is te bewijzen dat een combinatie van zwaktes exploiteerbaar is, niet alleen theoretisch gevaarlijk. Dit geeft prioriteit aan je herstelacties.

Kies een startpunt

Selecteer een realistisch beginpunt voor de simulatie. Dit kan een account zijn met beperkte rechten (zoals een standaardgebruiker of een service principal met een specifieke rol), een gecompromitteerde applicatie-identiteit, of een managed identity die bereikbaar is via een kwetsbare resource.

Doorloop de escalatieketen

Voer de volgende stappen uit om het aanvalspad te simuleren:

1. Bepaal vanuit het startpunt welke Azure-resources bereikbaar zijn en welke acties zijn toegestaan
2. Identificeer of het account rechten heeft om role assignments te maken of te wijzigen. Controleer dit met: az role assignment list –assignee <object-id>
3. Controleer of via de huidige identiteit toegang is tot een Key Vault, storage account of andere gevoelige resource
4. Probeer vanuit de huidige rechten een hogere rol toe te wijzen aan een testaccount (in een testomgeving) om te bewijzen dat escalatie mogelijk is
5. Documenteer elke stap met screenshots, commando-output en een beschrijving van de gebruikte rechten

Na deze simulatie weet je of het aanvalspad werkelijk exploiteerbaar is en hoeveel stappen een aanvaller nodig heeft om volledige controle te krijgen. Een aanvalspad met drie of minder stappen van beperkte toegang naar Owner-rechten is een kritiek risico dat onmiddellijk aandacht vereist.

Valideer en documenteer de gevonden risico’s

Een gevonden aanvalspad heeft alleen waarde als het goed is gedocumenteerd en gevalideerd. Zonder duidelijke documentatie is het moeilijk om prioriteiten te stellen en zijn de bevindingen lastig over te dragen aan beheerders of management.

Structureer je documentatie per gevonden aanvalspad op de volgende manier:

1. Beschrijf het startpunt: Welke identiteit of toegang is het beginpunt van het pad?
2. Beschrijf de stappen: Welke rechten, misconfiguraties of zwaktes worden opeenvolgend benut?
3. Beschrijf het eindpunt: Wat kan een aanvaller bereiken als het pad volledig wordt doorlopen?
4. Classificeer de ernst: Gebruik een risicoschaal op basis van impact (wat kan worden bereikt?) en kans (hoe realistisch is het startpunt?)
5. Voeg bewijs toe: Commando-output, screenshots of logregels die het pad aantoonbaar maken

Valideer ook of de gevonden rechten daadwerkelijk in gebruik zijn. Een account met Owner-rechten dat al twee jaar niet is ingelogd, is een ander risicoprofiel dan een actief serviceaccount met dezelfde rechten. Azure Monitor en de aanmeldingslogboeken in Entra ID helpen je om activiteit te beoordelen. Meer achtergrond over hoe aanvalspaden worden geanalyseerd in bredere beveiligingsonderzoeken vind je via ons cyberresearch-overzicht.

Herstel gevaarlijke RBAC-toewijzingen structureel

Met de bevindingen gedocumenteerd is het tijd voor herstel. Het verwijderen van één gevaarlijke toewijzing is een begin, maar structureel herstel vereist dat je de onderliggende oorzaken aanpakt. Anders groeit de RBAC-structuur opnieuw toe naar een onveilige situatie.

Pak het herstel in de volgende volgorde aan:

1. Verwijder ongebruikte en onnodige role assignments direct: Begin met accounts die geen actieve gebruikers meer hebben, verlopen service principals en testaccounts met hoge rechten
2. Vervang brede rollen door specifieke rollen: Gebruik het principe van least privilege. Een applicatie die alleen leesrechten nodig heeft op een storage account, krijgt de rol Storage Blob Data Reader, niet Contributor
3. Beperk Owner en User Access Administrator tot een minimum: Gebruik Privileged Identity Management (PIM) om hoge rechten tijdelijk en op aanvraag beschikbaar te stellen in plaats van permanent toe te wijzen
4. Stel alerts in voor wijzigingen in role assignments: Configureer Azure Monitor of Microsoft Sentinel om te signaleren wanneer nieuwe hoge rechten worden toegewezen
5. Documenteer een RBAC-beleid: Leg vast wie rechten mag toewijzen, op welk niveau, en hoe dit wordt gereviewd. Zonder beleid groeien problemen vanzelf terug

Controleer na het herstel opnieuw of de eerder gesimuleerde aanvalspaden nog steeds exploiteerbaar zijn. Als de stappen in het aanvalspad zijn verbroken, is het risico effectief gemitigeerd. Herhaal de inventarisatie uit stap twee om te bevestigen dat er geen nieuwe gevaarlijke combinaties zijn ontstaan door de wijzigingen.

Hoe Q-Cyber helpt met Azure RBAC-beveiliging

Een RBAC-analyse handmatig uitvoeren geeft waardevolle inzichten, maar heeft beperkingen. Het vergt tijd, specifieke toolkennis en het vermogen om losse bevindingen te verbinden tot realistische aanvalspaden. Precies daar voegen wij waarde toe.

Bij Q-Cyber analyseren we Azure RBAC-rechten niet als een checklist, maar als een aanvaller die zoekt naar de snelste route naar volledige controle. Wat we concreet doen:

• We voeren een handmatige pentest uit op je Azure-omgeving, inclusief analyse van RBAC-structuren, managed identities en privilege-escalatiepaden
• We correleren losse bevindingen tot werkelijke aanvalspaden, zodat je weet welke combinaties van zwaktes het grootste risico vormen
• We leveren een helder rapport met concrete herstelprioriteiten, niet alleen een lijst met technische bevindingen
• Via Continuous-Q® blijven we na de initiële pentest je omgeving volgen, zodat nieuwe rechten en configuratiewijzigingen niet onopgemerkt blijven
• We adviseren onafhankelijk, zonder afhankelijkheid van softwarepartijen of toeleveranciers

Wil je weten hoe jouw Azure RBAC-structuur eruitziet vanuit het perspectief van een aanvaller? Neem contact op en we bespreken wat een gerichte analyse voor jouw omgeving kan opleveren.

Lees meer

Hoe denkt een hacker tijdens een cyberaanval?

Geplaatst op: 9 oktober 2026

Begrijpen hoe een hacker denkt is een van de krachtigste dingen die je kunt doen om je organisatie beter te beveiligen. Veel beveiligingsmaatregelen zijn gebouwd vanuit een verdedigersperspectief: firewalls, patches, wachtwoordbeleid. Maar een aanvaller denkt anders. Die zoekt niet naar wat jij hebt beveiligd, maar naar wat je over het hoofd hebt gezien.

In dit artikel doorloop je de stappen die een hacker zet tijdens een cyberaanval, van de eerste verkenning tot het moment waarop hij volledig controle heeft. Door de aanvalsmentaliteit te begrijpen, kun je gerichte keuzes maken in je verdediging en voorkomen dat je je beveiligingsbudget verspilt aan maatregelen die de echte risico’s niet afdekken.

De aanvalsfasen die elke hacker doorloopt

Een cyberaanval is zelden een chaotische stortvloed van exploits. Ervaren aanvallers werken methodisch en geduldig. Ze volgen een herkenbaar patroon dat in de offensieve securitywereld vaak wordt aangeduid als de “kill chain”: een reeks opeenvolgende fasen die samen leiden tot een succesvolle aanval.

Elke fase bouwt voort op de vorige. Dat betekent ook dat het doorbreken van één schakel in die keten een aanval kan stoppen of aanzienlijk vertragen. Begrijp je de fasen, dan weet je ook waar je de meeste impact maakt met je verdediging. De belangrijkste fasen zijn:

1. Verkenning (reconnaissance): de aanvaller verzamelt informatie over het doelwit
2. Initiële toegang: het benutten van een kwetsbaarheid om binnen te komen
3. Persistentie en laterale beweging: uitbreiden van toegang en verankeren in het netwerk
4. Doelrealisatie: data stelen, ransomware uitrollen of systemen saboteren

Controleer bij je eigen beveiliging of je voor elke fase detectiemogelijkheden hebt, niet alleen preventieve maatregelen. Een aanvaller die al binnen is maar niet gedetecteerd wordt, is gevaarlijker dan een aanvaller die wordt tegengehouden bij de voordeur.

Zo kiest een hacker zijn doelwit en verzamelt hij informatie

Voordat een aanvaller ook maar één exploit afvuurt, heeft hij al veel geleerd over zijn doelwit. Dit is de verkenningsfase, en het is de fase die door veel organisaties het meest wordt onderschat. Een goede aanvaller probeert eerst te begrijpen hoe een organisatie is ingericht, welke leveranciers en managed service providers toegang hebben, welke accounts bestaan en welke rechten die accounts hebben.

Veel van deze informatie is publiek beschikbaar. Denk aan LinkedIn-profielen van medewerkers, vacatureteksten die technologiegebruik verraden, DNS-records, certificaten en zelfs per ongeluk openbaar gemaakte configuratiebestanden. Voer de volgende acties uit om te begrijpen wat een aanvaller over jouw organisatie kan vinden:

1. Zoek je eigen domeinnaam op via tools zoals Shodan of Censys om te zien welke diensten publiek zichtbaar zijn
2. Controleer welke medewerkersinformatie via LinkedIn of andere platforms beschikbaar is voor iemand zonder account
3. Bekijk je eigen vacatureteksten: vermelden die specifieke software, cloudomgevingen of beveiligingstools?
4. Controleer of er onbedoeld bestanden, repositories of configuraties openbaar staan via GitHub of Google

Na deze stap weet je wat een aanvaller al weet voordat hij technisch aan de slag gaat. Als je schrikt van wat je vindt, is dat een waardevolle ontdekking. Beperk de publieke informatie die jouw aanvalsoppervlak vergroot.

Hoe een hacker een kwetsbaarheid uitbuit

Met voldoende informatie over het doelwit gaat een aanvaller op zoek naar een ingang. Hier is een belangrijk inzicht: een ervaren aanvaller werkt niet noodzakelijk door honderden exploits af te vuren. Hij zoekt naar de combinatie van zwaktes die samen een werkend aanvalspad vormen. Een bekende CVE op zichzelf is soms minder interessant dan een misconfiguratie in combinatie met te ruime permissies.

Denk aan dit voorbeeld uit de praktijk van offensieve security: een Server-Side Request Forgery (SSRF)-kwetsbaarheid lijkt op zichzelf beperkt. Maar als diezelfde server een managed identity heeft in Azure, en die identity heeft via RBAC toegang tot een Key Vault, dan leidt die ene SSRF uiteindelijk tot volledige controle over cloudresources. Geen van de individuele bevindingen was kritiek. Samen vormen ze een catastrofaal aanvalspad. Aanvallers zien geen losse findings, ze zien aanvalspaden.

Om te begrijpen hoe kwetsbaarheden worden uitgebuit, kijk je op drie niveaus:

1. Laag 1 – Bekende kwetsbaarheden: controleer of patches actueel zijn en bekende CVE’s zijn gedicht
2. Laag 2 – Individuele zwaktes: beoordeel configuraties in Azure, AWS of andere cloudomgevingen, permissies van accounts en applicatie-instellingen
3. Laag 3 – Gecorreleerde aanvalspaden: onderzoek wat er gebeurt als je meerdere kleine zwaktes combineert en of die samen een aanvalspad vormen

Verificatie: als je alleen naar laag 1 kijkt, heb je een onvolledig beeld van je werkelijke risico. Een schoon CVE-rapport betekent niet dat er geen aanvalspad bestaat. Stel jezelf de vraag: heeft iemand ooit gekeken naar wat er mogelijk is als zwaktes worden gecombineerd?

Wat een hacker doet nadat hij binnen is

Het moment van initiële toegang is niet het eindpunt van een aanval, het is het begin. Nadat een aanvaller een eerste voet aan de grond heeft, richt hij zich op drie dingen: zijn positie verankeren, zijn toegang uitbreiden en detectie vermijden. Dit wordt laterale beweging en persistentie genoemd, en het is de fase die organisaties het langst onopgemerkt laten.

Aanvallers zoeken in deze fase naar accounts met verhoogde rechten, onbeheerde systemen, slecht geconfigureerde vertrouwensrelaties tussen systemen en mogelijkheden om hun sporen te wissen. Ze bewegen langzaam en doelgericht. Onderzoek toont aan dat aanvallers soms weken of maanden in een netwerk aanwezig zijn voordat ze hun uiteindelijke doel bereiken. Gebruik de volgende stappen om na te gaan hoe zichtbaar een aanvaller in jouw omgeving zou zijn:

1. Controleer of je logging en monitoring actief zijn op kritieke systemen, inclusief authenticatiepogingen en rechtenwijzigingen
2. Bekijk welke accounts admin- of privileged-rechten hebben en of die rechten echt noodzakelijk zijn
3. Controleer of er vertrouwensrelaties bestaan tussen systemen of cloudomgevingen die een aanvaller kan misbruiken
4. Test of je detectiesystemen een ongewone inlogpoging of een rechtenescalatie daadwerkelijk signaleren

Na deze controle weet je hoe lang een aanvaller onzichtbaar zou kunnen blijven. Als het antwoord “heel lang” is, is dat het moment om je detectiecapaciteiten serieus te verbeteren. Red team-oefeningen zijn een effectieve manier om dit realistisch te testen, omdat ze precies deze fase simuleren.

Gebruik deze inzichten om je verdediging te versterken

Nu je de aanvalsfasen begrijpt, kun je je verdediging gericht inrichten. De meest gemaakte fout is het bouwen van verdediging per laag in isolatie: een firewall hier, een antivirusprogramma daar, een jaarlijkse scan als afsluiting. Maar een aanvaller denkt niet in lagen, die denkt in paden. Je verdediging moet dat ook doen.

Vertaal de hackermentaliteit naar concrete acties in je eigen organisatie:

• Breng je aanvalsoppervlak in kaart: wat is publiek zichtbaar en wat hoeft dat niet te zijn?
• Denk in aanvalspaden, niet alleen in losse kwetsbaarheden: welke combinaties van zwaktes vormen een reëel risico?
• Beperk rechten tot het minimum dat noodzakelijk is (principe van least privilege)
• Zorg voor detectie in elke fase van de kill chain, niet alleen aan de buitengrens
• Test je beveiliging regelmatig, want je omgeving verandert continu: nieuwe applicaties, nieuwe accounts, nieuwe configuraties

Een jaarlijkse test geeft je een momentopname. Maar cybercriminelen ontwikkelen het hele jaar nieuwe technieken. Wat vandaag veilig lijkt, kan morgen een aanvalspad zijn. Continu inzicht is daarom geen luxe, het is een noodzaak.

Hoe Q-Cyber helpt met hackermentaliteit in je beveiliging

Q-Cyber past precies deze aanvalsmentaliteit toe in haar dienstverlening. In plaats van alleen een lijst met bekende kwetsbaarheden te produceren, kijken onze ethical hackers naar hoe een aanvaller jouw organisatie daadwerkelijk zou benaderen: van de eerste verkenning tot gecorreleerde aanvalspaden door identities, permissies en cloudconfiguraties heen.

Wat wij concreet bieden:

• Handmatige pentesten waarbij onze ethical hackers denken en werken zoals een echte aanvaller, inclusief het ontdekken van aanvalspaden die geautomatiseerde tools missen
• Continuous-Q® voor MSP’s en organisaties die niet één keer per jaar getest willen zijn, maar het hele jaar door inzicht willen houden in hun werkelijke kwetsbaarheden
• Red team-oefeningen die de volledige aanvalsketen simuleren, inclusief de laterale beweging en persistentiefase
• Onafhankelijk advies zonder afhankelijkheid van softwarepartijen, zodat onze aanbevelingen altijd in jouw belang zijn

Wil je weten hoe jouw organisatie eruitziet door de ogen van een aanvaller? Neem contact op en ontdek wat een gerichte pentest of ons Continuous-Q®-programma voor jouw beveiliging kan betekenen.

Lees meer

Hoe weet je of een pentest grondig genoeg is uitgevoerd?

Geplaatst op: 8 oktober 2026

Je hebt een pentest laten uitvoeren. Goed gedaan. Maar dan komt de echte vraag: was die test ook grondig genoeg? Een rapport met tientallen bevindingen klinkt indrukwekkend, maar zegt op zichzelf weinig over de werkelijke kwaliteit van de test. Een goede pentest kijkt verder dan bekende kwetsbaarheden en reproduceert hoe een echte aanvaller denkt en handelt. In dit artikel leer je stap voor stap hoe je de kwaliteit van een pentest beoordeelt, zodat je zeker weet of je beveiligingstest daadwerkelijk waarde heeft geleverd.

Wat een grondig pentestrapport moet bevatten

Begin bij het rapport zelf. Een kwalitatief hoogwaardig pentestrapport is meer dan een lijst met gevonden kwetsbaarheden. Het is een gestructureerd document dat je als organisatie in staat stelt om concrete actie te ondernemen. Controleer of het rapport de volgende elementen bevat:

• Een managementsamenvatting die zonder technische kennis leesbaar is en de belangrijkste risico’s helder benoemt
• Een gedetailleerde technische sectie met reproduceerbare bevindingen, inclusief bewijs (screenshots, logs of commando’s)
• Risicoclassificaties per bevinding, met uitleg waarom een kwetsbaarheid als hoog, middel of laag is beoordeeld
• Concrete aanbevelingen per bevinding, niet alleen “patch dit systeem”, maar ook uitleg over de impact als dat niet gebeurt
• Attack paths: een beschrijving van hoe losse zwaktes gecombineerd kunnen worden tot een volledige aanvalsketen

Dat laatste punt is cruciaal. Aanvallers zien geen losse bevindingen. Ze zien aanvalspaden. Een goed rapport laat zien hoe een combinatie van kleine zwaktes, elk onschuldig op zichzelf, kan leiden tot volledige toegang tot kritieke systemen. Ontbreekt die context in het rapport, dan mis je de essentie van wat een professionele pentest onderscheidt van een geautomatiseerde scan.

Controleer de scope en methodologie van de pentest

Een pentest is zo grondig als de afspraken die er vooraf over zijn gemaakt. Bekijk de scope en methodologie kritisch voordat je conclusies trekt uit de resultaten.

1. Controleer welke systemen, netwerken en applicaties zijn meegenomen. Was de scope breed genoeg om realistische aanvalsvectoren te dekken?
2. Vraag of ook externe aanvalsvectoren zijn getest, zoals phishing, supplychaintoegang en identiteitsbeheer
3. Kijk of de test handmatig is uitgevoerd of grotendeels geautomatiseerd. Automatische tools vinden bekende CVE’s, maar missen organisatiespecifieke risico’s zoals te ruime permissies, misconfiguraties in cloudplatformen of zwaktes in identiteitsbeheer
4. Verifieer of de methodologie aansluit op erkende frameworks zoals OWASP, PTES of MITRE ATT&CK

Een veelgemaakte fout is een te smalle scope accepteren. Als alleen de webapplicatie is getest maar de onderliggende cloudinfrastructuur buiten beschouwing is gelaten, heb je een onvolledig beeld. Vraag de uitvoerende partij expliciet te documenteren wat buiten scope viel en waarom.

Beoordeel de diepgang van de gevonden kwetsbaarheden

Het aantal gevonden kwetsbaarheden zegt weinig over de kwaliteit van de pentest. Een goede test vindt niet per se de meeste bevindingen, maar de meest relevante. Beoordeel de diepgang aan de hand van drie lagen:

Laag 1: Bekende kwetsbaarheden

Dit zijn publieke CVE’s, ontbrekende patches en bekende configuratiefouten. Een scanner kan dit vinden. Staan er alleen dit soort bevindingen in het rapport, dan is de test waarschijnlijk grotendeels geautomatiseerd uitgevoerd.

Laag 2: Individuele zwaktes

Denk aan verkeerde Azure-configuraties, te ruime accountrechten, identity weaknesses of onveilige applicatie-instellingen. Deze vereisen handmatig onderzoek en specifieke kennis van de omgeving. Een menselijke tester met offensieve ervaring vindt risico’s die een scanner structureel mist, juist omdat een aanvaller ook kijkt naar organisatiestructuren, leveranciersrelaties en permissies.

Laag 3: Gecorreleerde aanvalspaden

Dit is waar de echte diepgang zit. Vraag jezelf af: beschrijft het rapport hoe meerdere kleine zwaktes samen een gevaarlijk aanvalspad vormen? Een voorbeeld: een SSRF-kwetsbaarheid in combinatie met een managed identity, te ruime Azure RBAC-rechten en toegang tot een Key Vault kan leiden tot volledige controle over een cloudsubscriptie. Elk onderdeel afzonderlijk lijkt misschien laag risico. Samen zijn ze kritiek. Als het rapport dit soort gecorreleerde paden niet beschrijft, ontbreekt de diepste laag van de analyse. Meer over deze aanpak lees je op de pagina over red teaming.

Stel de juiste vragen aan de pentestaanbieder

Een goede manier om de kwaliteit van een pentest te beoordelen, is door gerichte vragen te stellen aan de partij die de test heeft uitgevoerd. Gebruik onderstaande vragen als leidraad:

1. Welke handmatige technieken zijn gebruikt naast geautomatiseerde tools? Een betrouwbare partij kan dit concreet beantwoorden.
2. Hebben jullie ook gekeken naar identiteiten, permissies en supplychaintoegang? Echte aanvallers beginnen hier vaak.
3. Zijn er gecorreleerde aanvalspaden onderzocht? Vraag om een voorbeeld uit het rapport.
4. Wat viel buiten scope en waarom? Dit geeft inzicht in bewuste keuzes versus blinde vlekken.
5. Hoe is de ernst van bevindingen bepaald? Risicoclassificatie moet gebaseerd zijn op exploiteerbaarheid en impact, niet alleen op technische ernst.

Kun je op deze vragen geen duidelijke antwoorden krijgen, dan is dat een signaal dat de test oppervlakkiger was dan gewenst. Een transparante aanbieder legt zijn werkwijze graag uit. Wil je alvast meer begrijpen over hoe security continu getest kan worden, dan geeft de pagina over Continuous-Q een goed beeld van wat doorlopend testen inhoudt.

Valideer de bevindingen met een tweede beoordeling

Zelfs een goed rapport heeft baat bij een onafhankelijke blik. Een tweede beoordeling helpt je te verifiëren of de bevindingen kloppen, of de aanbevelingen realistisch zijn en of er niets over het hoofd is gezien.

1. Laat een interne securityspecialist of een onafhankelijke derde partij de bevindingen doorlopen en beoordelen op volledigheid
2. Verifieer of de beschreven aanvalspaden daadwerkelijk reproduceerbaar zijn. Bevindingen zonder bewijs zijn moeilijk te prioriteren
3. Toets de aanbevelingen op haalbaarheid binnen jouw IT-omgeving. Een goede pentestaanbieder houdt rekening met de praktische context van jouw organisatie
4. Vergelijk de bevindingen met eerdere tests of bekende risico’s in jouw sector om te beoordelen of er blinde vlekken zijn

Met de bevindingen gevalideerd, heb je een betrouwbare basis om prioriteiten te stellen en verbeteringen door te voeren. Onthoud: de waarde van een pentest zit niet in het rapport zelf, maar in wat je ermee doet. Een grondig uitgevoerde test geeft je het inzicht dat nodig is om je beveiliging structureel te versterken.

Hoe Q-Cyber helpt bij het beoordelen en uitvoeren van grondige pentests

Bij Q-Cyber voeren we pentests uit zoals een echte aanvaller dat zou doen: handmatig, methodisch en gericht op de combinatie van zwaktes die samen de grootste risico’s vormen. We kijken verder dan bekende CVE’s en onderzoeken organisatiestructuren, identiteiten, cloudconfiguraties en supplychaintoegang. Zo krijg je niet alleen een lijst met bevindingen, maar een helder beeld van de werkelijke aanvalspaden in jouw omgeving.

Wat je van ons mag verwachten:

• Handmatige pentests uitgevoerd door gecertificeerde ethical hackers met offensieve securityervaring
• Rapportage op drie niveaus: bekende kwetsbaarheden, individuele zwaktes en gecorreleerde aanvalspaden
• Concrete aanbevelingen die aansluiten bij de praktische context van jouw organisatie
• Onafhankelijk advies, zonder afhankelijkheid van softwarepartijen of toeleveranciers
• Optionele doorgroei naar Continuous-Q, voor organisaties die veiligheid structureel willen borgen in plaats van eenmalig meten

Wil je weten of jouw beveiliging een grondige test doorstaat? Neem contact op en we bespreken samen wat een pentest voor jouw organisatie kan betekenen.

Lees meer

Hoe gebruiken hackers leveranciers om een organisatie binnen te komen?

Geplaatst op: 7 oktober 2026

Hackers richten hun pijlen steeds vaker niet op de organisatie zelf, maar op de leveranciers die toegang hebben tot haar systemen. Een softwareleverancier, een IT-dienstverlener of een externe consultant met de juiste inloggegevens is voor een aanvaller een aantrekkelijker doelwit dan een goed beveiligde organisatie. Door één zwakke schakel in de leveranciersketen te compromitteren, krijgt een aanvaller indirect toegang tot tientallen of honderden klanten tegelijk. Dit is de kern van een supplychainaanval, en het is een van de snelst groeiende dreigingen in het huidige cyberlandschap.

In dit artikel lees je stap voor stap hoe je jouw organisatie beschermt tegen hackers van leveranciers die via third-party toegang binnenkomen. Van het in kaart brengen van externe toegangspunten tot het reageren op een gecompromitteerde leverancier: elke stap helpt je om supplychainbeveiliging te verankeren in de praktijk.

Herken de zwakke schakels in je leveranciersketen

Voordat je iets kunt beveiligen, moet je weten wat er te beveiligen valt. De eerste stap is begrijpen waarom leveranciers zo aantrekkelijk zijn als aanvalsvector. Een aanvaller denkt niet in termen van losse systemen, maar in toegangspaden. Hij stelt zichzelf de vraag: wie heeft er al toegang tot mijn doelwit, en hoe goed is die partij beveiligd?

Zwakke schakels zijn niet altijd de meest voor de hand liggende partijen. Denk niet alleen aan grote softwareleveranciers, maar ook aan:

• Kleinere IT-dienstverleners met beheertoegang tot je netwerk
• Clouddiensten die geïntegreerd zijn met je interne systemen
• Externe consultants met tijdelijke accounts die nooit zijn ingetrokken
• Softwaretools die automatisch updates ontvangen en daarmee code uitvoeren in je omgeving
• Leveranciers van je leveranciers, ook wel vierde partijen genoemd

Controleer na deze inventarisatie welke van deze partijen toegang heeft tot gevoelige systemen, klantdata of kritieke infrastructuur. Dit geeft je een eerste beeld van waar het third-partyrisico het grootst is. Pas als je weet wie er toegang heeft, kun je beoordelen hoe groot het risico per leverancier werkelijk is.

Breng al je externe toegangspunten in kaart

Met een overzicht van je leveranciers in handen is de volgende stap het documenteren van alle externe toegangspunten. Dit gaat verder dan een lijst met namen: je wilt per leverancier precies weten hoe, wanneer en via welk kanaal die toegang heeft tot jouw omgeving.

1. Inventariseer alle actieve accounts die zijn aangemaakt voor externe partijen, inclusief serviceaccounts en gedeelde logins.
2. Documenteer via welke methode elke leverancier verbinding maakt: VPN, Remote Desktop, API-koppeling, cloudomgeving of een combinatie.
3. Leg vast welke systemen en data elke externe partij kan bereiken na inloggen.
4. Controleer of er nog accounts actief zijn van leveranciers waarmee de samenwerking al is beëindigd.

Veel organisaties ontdekken in deze stap dat er aanzienlijk meer externe toegangspunten actief zijn dan verwacht. Vergeten accounts, brede rechten die ooit tijdelijk waren bedoeld en koppelingen die nooit zijn opgeschoond: dit zijn precies de ingangen die een aanvaller zoekt. Een handmatige pentest kan helpen om ook de minder zichtbare toegangspaden bloot te leggen die een interne inventarisatie mist.

Beoordeel het risico van elke leverancier

Niet elke leverancier vormt hetzelfde risico. Een partij die alleen facturen verwerkt via een afgeschermd portaal verschilt wezenlijk van een IT-dienstverlener die beheertoegang heeft tot je volledige netwerk. Het doel van deze stap is om prioriteit aan te brengen op basis van daadwerkelijk risico, zodat je je inspanningen gericht kunt inzetten.

Beoordeel elke leverancier op de volgende criteria:

• Toegangsniveau: Heeft de leverancier beheerdersrechten, of alleen leestoegang tot een beperkt systeem?
• Datagevoeligheid: Welke data kan de leverancier bereiken? Gaat het om persoonsgegevens, financiële informatie of bedrijfskritische systemen?
• Eigen beveiligingsvolwassenheid: Heeft de leverancier aantoonbare beveiligingsmaatregelen getroffen, zoals certificeringen of een eigen securitybeleid?
• Afhankelijkheid: Hoe groot is de impact als deze leverancier uitvalt of gecompromitteerd raakt?

Verdeel leveranciers op basis van deze beoordeling in risicocategorieën: hoog, gemiddeld en laag. Leveranciers in de hoogste categorie verdienen de meeste aandacht bij de volgende stappen. Dit maakt supplychainbeveiliging behapbaar, ook voor organisaties met een lange lijst aan externe partijen.

Stel minimale beveiligingseisen aan leveranciers

Zodra je weet welke leveranciers het hoogste risico vormen, is het tijd om concrete eisen te stellen. Cyberbeveiliging van leveranciers begint bij het contractueel vastleggen van wat je van externe partijen verwacht op het gebied van informatiebeveiliging.

1. Stel een minimale baseline op: welke beveiligingsmaatregelen zijn voor elke leverancier verplicht, ongeacht het risiconiveau?
2. Formuleer aanvullende eisen voor hoog-risicoleveranciers, zoals verplichte multifactorauthenticatie, periodieke pentests of aantoonbare naleving van NIS2 of ISO 27001.
3. Leg deze eisen vast in contracten of verwerkersovereenkomsten, inclusief het recht om naleving te controleren.
4. Communiceer de eisen actief naar bestaande leveranciers en maak ze onderdeel van het selectieproces voor nieuwe partijen.

Een veelgemaakte fout is het stellen van eisen zonder te controleren of ze worden nageleefd. Vraag leveranciers om bewijs, zoals een recent auditrapport, een ingevulde vragenlijst of een certificering. Wees daarin proportioneel: een kleine leverancier met beperkte toegang hoeft niet aan dezelfde eisen te voldoen als een partij die dagelijks toegang heeft tot kritieke systemen. Meer achtergrond over beleid en compliance vind je op de pagina over compliance en beleid.

Monitor leverancierstoegang continu op afwijkingen

Eenmalige controle is niet voldoende. Een leverancier die vandaag veilig is, kan morgen gecompromitteerd zijn. Continu monitoren van externe toegang is daarmee een van de meest effectieve maatregelen om een leveranciersaanval te voorkomen voordat er schade ontstaat.

Richt je monitoring in op de volgende signalen:

• Inlogpogingen buiten gebruikelijke tijden of vanuit onverwachte locaties
• Toegang tot systemen of data die buiten de normale werkzaamheden van de leverancier vallen
• Grote hoeveelheden data die worden gedownload of geëxporteerd via een extern account
• Meerdere mislukte inlogpogingen gevolgd door een succesvolle login
• Wijzigingen in rechten of configuraties uitgevoerd vanuit een leveranciersaccount

Koppel monitoring aan duidelijke escalatieprocedures: wie wordt gewaarschuwd bij een afwijking, en welke stappen worden dan gezet? Automatische alerts helpen, maar een menselijke beoordeling blijft nodig om onderscheid te maken tussen een onschuldige afwijking en een werkelijk incident. Continuous-Q® biedt hier een gestructureerde aanpak voor organisaties die dit continu willen borgen.

Wat te doen als een leverancier is gecompromitteerd

Ondanks alle voorzorgsmaatregelen kan het gebeuren dat een leverancier wordt aangevallen en dat aanvallers via die route jouw omgeving proberen te bereiken. Snelheid en een helder plan zijn dan doorslaggevend. Een leveranciersaanval voorkomen is het doel, maar voorbereid zijn op het scenario dat het toch misgaat, is minstens even belangrijk.

1. Isoleer direct alle toegang van de betreffende leverancier: blokkeer accounts, verbreek VPN-verbindingen en deactiveer API-koppelingen.
2. Breng in kaart welke systemen en data de leverancier kon bereiken en of er in de periode voor de ontdekking verdachte activiteit heeft plaatsgevonden.
3. Stel een intern crisisteam samen en informeer relevante stakeholders, inclusief de eigen directie en eventueel betrokken klanten.
4. Beoordeel of er een meldplicht geldt, bijvoorbeeld onder de AVG of NIS2, en handel daar tijdig naar.
5. Voer na het incident een grondige analyse uit: hoe kon de aanvaller via de leverancier binnenkomen, en welke maatregelen voorkomen herhaling?

Documenteer het incident volledig, ook als de schade beperkt bleek. Elk incident levert inzicht op in de zwakke plekken van je leveranciersketen en helpt je toekomstige aanvallen eerder te herkennen. Overweeg na een incident een redteamoefening om te toetsen of aanvallers via vergelijkbare routes nog steeds toegang kunnen krijgen.

Hoe Q-Cyber helpt met supplychainbeveiliging

Q-Cyber helpt organisaties om hun leveranciersketen te beveiligen met een combinatie van technische tests, onafhankelijk advies en continue monitoring. Wij kijken niet alleen naar losse kwetsbaarheden, maar onderzoeken de volledige aanvalsketen: welke leveranciers hebben toegang, via welke routes, en hoe kunnen die worden misbruikt?

Concreet bieden wij:

• Pentests gericht op third-party toegang: onze ethical hackers testen of externe toegangspunten kunnen worden misbruikt om dieper in je omgeving door te dringen.
• Beleidsadvies en leveranciersbeoordelingen: wij helpen bij het opstellen van beveiligingseisen voor leveranciers en het beoordelen van hun naleving.
• Continuous-Q®: voor organisaties die continu inzicht willen in hun aanvalsoppervlak, inclusief wijzigingen in leverancierstoegang en nieuwe risico’s.
• Incidentbegeleiding: als een leverancier is gecompromitteerd, helpen wij bij het snel in kaart brengen van de impact en het nemen van de juiste maatregelen.

Wil je weten hoe kwetsbaar jouw organisatie is via leveranciers? Neem contact op voor een vrijblijvend gesprek.

Lees meer

Hoe kiest een hacker het makkelijkste aanvalspad?

Geplaatst op: 6 oktober 2026

Aanvallers kiezen hun doelwit niet willekeurig. Voordat een hacker ook maar één exploit afvuurt, heeft hij al een duidelijk beeld van hoe jouw organisatie in elkaar zit, waar de zwakke plekken zitten en welk pad hem het snelst naar zijn doel brengt. Dat proces is methodisch, geduldig en veel strategischer dan veel mensen denken.

In dit artikel lees je hoe een aanvaller een aanvalspad opbouwt, van de eerste verkenning tot het moment waarop hij toegang heeft. Door te begrijpen hoe een hacker denkt, kun je gerichte maatregelen nemen die er werkelijk toe doen, in plaats van alleen oppervlakkige kwetsbaarheden te dichten.

Zo bepaalt een hacker waar hij begint

De eerste fase van elke cyberaanval is verkenning. Een aanvaller begint niet met aanvallen, maar met observeren. Hij probeert te begrijpen hoe jouw organisatie is ingericht: welke systemen publiek bereikbaar zijn, welke leveranciers toegang hebben, welke medewerkers welke rechten bezitten en waar de grenzen van je beveiliging liggen.

Daarvoor gebruikt een hacker vaak openbare bronnen die je zelf ook kunt raadplegen. Denk aan LinkedIn-profielen om te achterhalen welke functies en rollen mensen hebben, vacatureteksten die hints geven over gebruikte technologie, publiek toegankelijke cloudomgevingen en domeininformatie via DNS-records. Dit heet ook wel OSINT, oftewel Open Source Intelligence. Het verrassende is dat een aanvaller soms al een goed beeld heeft van waar de organisatie kwetsbaar is, nog voordat hij ook maar één technisch hulpmiddel heeft ingezet.

Wat je hieruit kunt leren: beperk de hoeveelheid informatie die je onbedoeld publiek maakt. Controleer wat er via zoekmachines vindbaar is over jouw infrastructuur, en wees bewust van wat medewerkers delen op sociale media over interne systemen en processen.

Kwetsbaarheden rangschikken op aanvalspotentieel

Nadat een aanvaller een eerste beeld heeft, gaat hij systematisch kwetsbaarheden in kaart brengen. Hierbij is het belangrijk te begrijpen dat niet elke kwetsbaarheid even interessant is voor een hacker. Een aanvaller kijkt niet naar de ernst van een bevinding op zichzelf, maar naar het aanvalspotentieel: wat kan ik hiermee bereiken?

Er zijn globaal drie niveaus waarop een aanvaller kwetsbaarheden beoordeelt:

1. Bekende kwetsbaarheden (CVE’s): Dit zijn gepubliceerde beveiligingslekken in software waarvoor vaak al exploits beschikbaar zijn. Een aanvaller controleert als eerste of patches goed zijn doorgevoerd en of bekende exploits nog werken.
2. Configuratiefouten en identity weaknesses: Denk aan verkeerde Azure-instellingen, te ruime permissies op accounts, onveilige applicatie-instellingen of identities met meer rechten dan nodig. Deze zijn moeilijker automatisch te detecteren, maar bieden een aanvaller vaak meer speelruimte.
3. Gecombineerde aanvalspaden: Dit is waar het echt gevaarlijk wordt. Een aanvaller bekijkt hoe meerdere kleine zwaktes samen een werkend aanvalspad vormen. Een bevinding die op zichzelf weinig lijkt, kan in combinatie met een andere zwakte leiden tot volledige toegang tot kritieke systemen.

Een concreet voorbeeld: een SSRF-kwetsbaarheid (Server-Side Request Forgery) lijkt misschien beperkt in impact. Maar als die kwetsbaarheid toegang geeft tot een managed identity, die vervolgens Azure RBAC-rechten heeft, en daarmee toegang tot een Key Vault, dan kan een aanvaller uitgroeien tot subscription owner. Geen enkele afzonderlijke bevinding was kritiek, maar samen vormen ze een volledig aanvalspad. Dit is precies waarom het aantal gevonden kwetsbaarheden weinig zegt over hoe veilig je werkelijk bent. Meer over hoe dit soort aanvalspaden in kaart worden gebracht lees je op de pentestpagina.

Het aanvalspad samenstellen stap voor stap

Met de verzamelde informatie begint een aanvaller het eigenlijke aanvalspad te bouwen. Hij zoekt de route van de minste weerstand: de combinatie van kwetsbaarheden, misconfiguraties en rechten die hem het snelst naar zijn doel brengt, met het minste risico op detectie.

Zo bouwt een aanvaller een aanvalspad op:

1. Identificeer het einddoel: Wat wil de aanvaller bereiken? Toegang tot klantdata, financiële systemen, intellectueel eigendom of beheerdersrechten over de hele omgeving? Het einddoel bepaalt welke paden interessant zijn.
2. Breng de route in kaart: Welke systemen, accounts en rechten liggen tussen de buitenkant en het doel? Een aanvaller tekent mentaal een kaart van de organisatie en markeert waar overstapmomenten mogelijk zijn.
3. Zoek de zwakste schakel: Dat is niet altijd een technisch lek. Het kan een medewerker zijn met te veel rechten, een externe leverancier met directe netwerktoegang, of een cloudresource met een verkeerde instelling.
4. Test de route stap voor stap: Een goede aanvaller werkt methodisch en langzaam, om detectie te vermijden. Hij test elke stap in het aanvalspad voordat hij verdergaat.
5. Pas het pad aan als een stap mislukt: Als één route geblokkeerd is, zoekt hij een alternatief. Een aanvaller geeft niet op bij de eerste hindernis, maar verkent zijpaden.

Dit is ook waarom een traditionele vulnerability scan tekortschiet: die vindt losse bevindingen, maar ziet de verbindingen daartussen niet. Een echte aanvaller denkt in paden, niet in lijsten.

Herken de signalen van een verkenningsaanval

Verkenning laat sporen achter, als je weet waar je moet kijken. Veel organisaties missen deze vroege signalen omdat ze pas alarmeren bij daadwerkelijke inbraakpogingen. Maar juist in de verkenningsfase heb je de meeste kans om een aanvaller te stoppen.

Let op de volgende signalen die kunnen wijzen op actieve verkenning:

• Ongebruikelijk veel mislukte inlogpogingen op accounts, vooral buiten kantooruren
• Scans op poorten of services die normaal geen verkeer ontvangen
• Onbekende IP-adressen die DNS-informatie opvragen over jouw domein
• Medewerkers die phishingmails ontvangen die specifieke interne informatie bevatten
• Onverwachte API-aanroepen naar cloudresources vanuit onbekende locaties
• Accounts die rechten of configuraties opvragen die buiten hun normale gebruik vallen

Stel je logging en monitoring zo in dat deze activiteiten zichtbaar worden. Zonder zichtbaarheid op je eigen omgeving kun je een aanvaller niet herkennen voordat hij zijn aanvalspad heeft voltooid. Een redteamoefening kan helpen om te testen of jouw detectiemechanismen daadwerkelijk werken onder realistische aanvalsomstandigheden.

Sluit de makkelijkste aanvalspaden structureel af

Nu je begrijpt hoe een aanvaller denkt en handelt, kun je gericht de makkelijkste aanvalspaden afsluiten. Het gaat er niet om alles tegelijk op te lossen, maar om de routes die een aanvaller het minste moeite kosten zo snel mogelijk te blokkeren.

Werk de volgende stappen af in volgorde van prioriteit:

1. Patch bekende kwetsbaarheden consequent: Zorg dat patches snel en volledig worden doorgevoerd. Controleer of updates ook daadwerkelijk zijn toegepast en niet alleen zijn ingepland.
2. Beperk permissies op basis van het principe van minimale rechten: Geef accounts alleen toegang tot wat ze echt nodig hebben. Controleer regelmatig of rechten nog kloppen, zeker na functiewijzigingen of vertrek van medewerkers.
3. Controleer cloudconfiguraties actief: Veel aanvalspaden lopen via verkeerd geconfigureerde cloudresources. Voer periodiek een configuratiereview uit op Azure, AWS of andere cloudplatformen die je gebruikt.
4. Beveilig externe toegangspunten: Leveranciers, MSP’s en andere partijen met toegang tot jouw omgeving zijn een favoriet aanvalspad. Controleer welke toegang zij hebben en of die toegang nog noodzakelijk en veilig is.
5. Test combinaties, niet alleen losse bevindingen: Laat periodiek testen of kwetsbaarheden samen een aanvalspad vormen, ook als ze afzonderlijk laag scoren op ernst.

Controleer na elke maatregel of het aanvalspad daadwerkelijk is afgesloten, niet alleen of de maatregel technisch is doorgevoerd. Een bevinding oplossen betekent niet automatisch dat het aanvalspad verdwenen is. Soms bestaat er nog een alternatieve route die je over het hoofd ziet.

Hoe Q-Cyber helpt bij het blootleggen van aanvalspaden

Bij Q-Cyber denken we precies zoals een aanvaller dat doet: niet in losse kwetsbaarheden, maar in aanvalspaden. We helpen organisaties inzicht te krijgen in hoe een echte hacker hun omgeving zou benaderen en welke combinatie van zwaktes het grootste risico vormt.

Wat we concreet voor je doen:

• We voeren handmatige pentests uit waarbij onze ethical hackers actief zoeken naar gecombineerde aanvalspaden, niet alleen naar bekende CVE’s
• We analyseren identities, permissies, cloudconfiguraties en externe toegangspunten als onderdeel van een volledige aanvalsketen
• We leveren een helder rapport met concrete prioriteiten, zodat je weet welke aanvalspaden het meest urgent zijn om af te sluiten
• Via Continuous-Q® blijven we je omgeving continu monitoren, zodat nieuwe aanvalspaden snel worden gesignaleerd
• We adviseren onafhankelijk, zonder afhankelijkheid van softwarepartijen of andere toeleveranciers

Wil je weten welke aanvalspaden er nu in jouw organisatie openstaan? Neem contact met ons op en we kijken samen hoe we jouw beveiliging structureel kunnen versterken.

Lees meer

Hoe kan één gehackt account leiden tot toegang tot andere systemen?

Geplaatst op: 5 oktober 2026

Eén gehackt account lijkt op het eerste gezicht misschien een beperkt probleem. Maar in de praktijk is het voor een aanvaller vaak slechts het beginpunt van een veel grotere operatie. Via een techniek die lateral movement heet, beweegt een cybercrimineel zich na een eerste inbraak zijwaarts door een netwerk, van systeem naar systeem, totdat hij toegang heeft tot precies de data of rechten die hij zoekt. Het resultaat kan verwoestend zijn: gestolen klantdata, gegijzelde systemen of volledige toegang tot cloudinfrastructuur.

In deze gids leer je stap voor stap hoe je dit aanvalspatroon herkent, kwetsbare plekken in je toegangsbeheer blootlegt en concrete maatregelen treft om de schade van een gecompromitteerd account te beperken. Elke stap bouwt voort op de vorige, zodat je aan het einde een solide verdediging hebt staan.

Herken de aanvalstechnieken achter laterale beweging

Begrijpen hoe aanvallers te werk gaan is de eerste vereiste voor een effectieve verdediging. Lateral movement is geen willekeurig proces. Aanvallers volgen een logische redenering: ze zoeken naar de weg van de minste weerstand, combineren kleine zwaktes en bouwen zo stap voor stap hun toegang uit. Wie dit patroon herkent, kan het onderbreken voordat er echte schade ontstaat.

De meest voorkomende technieken die aanvallers inzetten na een eerste inbraak zijn:

• Credential stuffing: gestolen gebruikersnamen en wachtwoorden worden getest op andere systemen, omdat mensen dezelfde inloggegevens hergebruiken.
• Pass-the-hash en pass-the-ticket: aanvallers stelen versleutelde authenticatietokens en gebruiken die om zich als een legitieme gebruiker voor te doen, zonder het wachtwoord te kennen.
• Privilege escalation: via misconfiguraties of te ruime rechten werkt een aanvaller zich op van een gewoon gebruikersaccount naar een beheerdersaccount.
• Misbruik van vertrouwde relaties: een aanvaller maakt gebruik van de bestaande vertrouwensband tussen systemen, bijvoorbeeld tussen een werkstation en een domeincontroller.
• Living-off-the-land: de aanvaller gebruikt ingebouwde systeemtools zoals PowerShell of WMI, zodat zijn activiteiten moeilijker te onderscheiden zijn van normaal gebruik.

Controleer na het doornemen van deze technieken of je securityteam of IT-afdeling elk van deze aanvalsvormen herkent en weet welke signalen ze achterlaten in logbestanden. Als dat niet het geval is, is dat zelf al een bevinding die om actie vraagt. Een goede basis is het bestuderen van het MITRE ATT&CK-framework, dat lateral movement als afzonderlijke tactiekcategorie beschrijft met concrete subtechnieken.

Breng de zwakste schakels in je toegangsbeheer in kaart

Aanvallers zoeken altijd naar de zwakste schakel. In de meeste organisaties zitten die zwakste schakels niet in spectaculaire technische kwetsbaarheden, maar in de dagelijkse inrichting van accounts, permissies en vertrouwensrelaties. Een aanvaller die één account compromitteert, kijkt direct verder: welke rechten heeft dit account, tot welke systemen heeft het toegang en welke andere accounts of resources zijn bereikbaar?

Voer de volgende inventarisatie uit om je blootstelling te begrijpen:

1. Maak een overzicht van alle accounts met beheerdersrechten, zowel lokaal als in de cloud. Vraag jezelf af: zijn al deze rechten nog nodig?
2. Identificeer serviceaccounts en geautomatiseerde processen die met hoge rechten draaien. Dit zijn favoriete doelwitten, omdat ze zelden worden gemonitord.
3. Controleer welke accounts toegang hebben tot meerdere systemen tegelijk, inclusief cloudomgevingen zoals Azure of Microsoft 365.
4. Zoek naar accounts die al lange tijd inactief zijn maar nog steeds actief staan. Slapende accounts zijn een makkelijk instappunt.
5. Breng in kaart welke externe partijen, leveranciers of MSP’s toegang hebben tot jullie systemen en met welke rechten.

Na deze inventarisatie heb je een concreet beeld van waar een aanvaller na een eerste inbraak naartoe kan bewegen. Veel organisaties schrikken van wat ze vinden: accounts die jaren geleden zijn aangemaakt en nooit zijn opgeschoond, serviceaccounts met domeinadminrechten die eigenlijk alleen een printserver hoeven te bereiken, of externe partijen met bredere toegang dan strikt noodzakelijk. Dit overzicht is de basis voor de volgende stap.

Beperk de schade met het principe van least privilege

Met de inventarisatie in handen kun je gericht aan de slag met het beperken van rechten. Het principe van least privilege houdt in dat elk account, elke applicatie en elke service alleen de toegang krijgt die strikt noodzakelijk is voor de taak die het uitvoert. Niets meer. Dit klinkt eenvoudig, maar in de praktijk is het een van de meest impactvolle maatregelen die je kunt nemen tegen lateral movement.

Implementeer least privilege stap voor stap:

1. Verwijder overbodige beheerdersrechten van gebruikersaccounts. Geef medewerkers een apart beheerdersaccount voor taken die dat vereisen, en laat ze dagelijkse werkzaamheden uitvoeren met een account zonder verhoogde rechten.
2. Beperk de rechten van serviceaccounts tot het absolute minimum. Een account dat alleen een database moet lezen, heeft geen schrijfrechten nodig.
3. Segmenteer je netwerk zodat systemen die niet met elkaar hoeven te communiceren dat ook niet kunnen. Zo beperk je hoever een aanvaller kan reiken vanuit één gehackt systeem.
4. Activeer multi-factor authenticatie (MFA) voor alle accounts, maar zeker voor accounts met verhoogde rechten. MFA maakt credential stuffing en gestolen wachtwoorden aanzienlijk minder effectief.
5. Stel tijdgebonden toegang in voor beheerderstaken via Privileged Access Management (PAM), zodat verhoogde rechten automatisch verlopen na gebruik.

Verifieer na het doorvoeren van deze aanpassingen of de wijzigingen ook daadwerkelijk van kracht zijn. Test of een gewoon gebruikersaccount nog steeds toegang kan krijgen tot systemen waar het geen toegang toe zou mogen hebben. Kleine fouten in de configuratie kunnen een heel privilegeschema ongedaan maken. Goed toegangsbeleid is hierbij een onmisbare basis.

Detecteer verdachte accountactiviteit voordat schade ontstaat

Zelfs met de beste preventieve maatregelen is het mogelijk dat een aanvaller toch een account compromitteert. Detectie is daarom minstens even belangrijk als preventie. Hoe eerder je afwijkend gedrag signaleert, hoe kleiner de schade blijft. Lateral movement laat vrijwel altijd sporen achter in logbestanden, maar alleen als je weet waar je op moet letten.

Stel de volgende detectiemechanismen in:

1. Activeer uitgebreide logging op authenticatiepogingen, inclusief mislukte inlogpogingen en inlogpogingen op ongebruikelijke tijdstippen of vanuit onbekende locaties.
2. Stel alerts in voor accounts die zich aanmelden op meerdere systemen in korte tijd. Dit is een klassiek signaal van lateral movement.
3. Monitor het gebruik van beheerderstools zoals PowerShell, Remote Desktop Protocol (RDP) en WMI, zeker als dit buiten kantooruren plaatsvindt.
4. Gebruik User and Entity Behavior Analytics (UEBA) als dat beschikbaar is. Deze tools leren het normale gedrag van accounts kennen en slaan alarm bij afwijkingen.
5. Stel een duidelijk escalatieproces in: wie wordt er gewaarschuwd als een alert afgaat, en wat is de eerste actie?

Een goede manier om te verifiëren of je detectie werkt, is een gesimuleerde aanval. Laat iemand bewust proberen om zich met een testaccount zijwaarts door het netwerk te bewegen en controleer of de alerts daadwerkelijk afgaan. Als dat niet het geval is, weet je dat je monitoring verder moet worden aangescherpt. Red teaming is een effectieve methode om dit realistisch te testen.

Test regelmatig of aanvallers kunnen doorbreken

De voorgaande stappen geven je een sterkere verdediging, maar geen garantie. Omgevingen veranderen continu: nieuwe applicaties worden uitgerold, accounts worden aangemaakt, cloudconfiguraties worden aangepast. Wat vandaag veilig is, hoeft morgen niet meer veilig te zijn. Regelmatig testen is daarom geen luxe maar een noodzaak.

Een professionele pentest gaat verder dan een automatische vulnerability scan. Waar een scanner bekende CVE’s en technische afwijkingen vindt, kijkt een menselijke tester naar de combinatie van zwaktes: hoe kunnen een misconfiguratie, een te ruim account en een onbeveiligde cloudresource samen leiden tot volledige toegang? Aanvallers zien geen losse bevindingen, ze zien aanvalspaden. Een goede pentest doet dat ook.

Houd bij het opzetten van een testcyclus rekening met het volgende:

• Voer minimaal één grondige pentest per jaar uit als baseline, maar test ook na significante wijzigingen in je IT-omgeving.
• Laat niet alleen de technische infrastructuur testen, maar ook de reactie van je team: herkennen zij een aanval als die plaatsvindt?
• Vraag na een pentest niet alleen om een lijst met bevindingen, maar om inzicht in de volledige aanvalsketen: welke combinatie van zwaktes maakt de grootste schade mogelijk?
• Gebruik de testresultaten als input voor de volgende cyclus van verbetering, niet als eindpunt.

Na het doorlopen van een testcyclus weet je niet alleen wat er kwetsbaar is op de testdag, maar ook waar de structurele risico’s in je omgeving zitten. Dat inzicht is de basis voor een verdediging die ook stand houdt als de omgeving verandert.

Hoe Q-Cyber helpt bij het stoppen van lateral movement

Bij Q-Cyber helpen we organisaties om niet alleen te begrijpen waar ze kwetsbaar zijn, maar ook hoe een echte aanvaller die kwetsbaarheden zou combineren tot een werkend aanvalspad. Onze aanpak is praktisch, onafhankelijk en gericht op wat er echt toe doet.

Wat we concreet voor je kunnen doen:

• Handmatige pentesten waarbij onze ethical hackers denken zoals een aanvaller: niet alleen losse kwetsbaarheden, maar volledige aanvalspaden inclusief lateral movement en privilege escalation.
• Inzicht in access paths en permissies via onze scans, zodat je precies weet welke accounts en configuraties het grootste risico vormen.
• Continu inzicht via Continuous-Q®, ons programma voor organisaties die niet alleen op de testdag inzicht willen, maar het hele jaar door.
• Advies en beleidsvorming rondom toegangsbeheer, least privilege en detectie, afgestemd op jouw specifieke omgeving.

Wil je weten hoe sterk jouw verdediging is tegen lateral movement en andere aanvalstechnieken? Neem contact met ons op en we kijken samen wat de meest effectieve eerste stap is voor jouw organisatie.

Lees meer

Wat is privilege escalation en hoe gebruiken hackers dit?

Geplaatst op: 4 oktober 2026

Privilege escalation is een van de meest gebruikte technieken in het arsenaal van een aanvaller. Zodra een hacker voet aan de grond heeft in een systeem, is de volgende stap bijna altijd hetzelfde: meer rechten bemachtigen. Meer rechten betekent meer toegang, meer controle en uiteindelijk meer schade. Begrijpen hoe dit werkt, is de eerste stap om jezelf er effectief tegen te verdedigen.

In dit artikel leggen we uit hoe je de tekenen van privilege escalation herkent, welke vormen er bestaan, hoe aanvallers deze aanval stap voor stap uitvoeren en wat je concreet kunt doen om je systemen te beschermen.

Zo herken je de tekenen van privilege escalation

Privilege escalation begint zelden met een grote, opvallende actie. Aanvallers werken bewust onder de radar en proberen zo lang mogelijk onopgemerkt te blijven. Toch zijn er signalen die erop wijzen dat iemand probeert zijn rechten te verhogen binnen een systeem of netwerk.

Let op de volgende waarschuwingssignalen in je omgeving:

• Accounts die plotseling toegang hebben tot systemen of bestanden waarvoor ze nooit rechten hadden
• Ongebruikelijke aanmeldpogingen buiten kantooruren of vanuit onbekende locaties
• Wijzigingen in groepslidmaatschappen of rollenbeleid die niet zijn aangevraagd
• Processen of services die draaien onder een account met hogere rechten dan nodig
• Onverwachte installaties van software of het aanmaken van nieuwe beheerdersaccounts
• Logbestanden die ontbreken of zijn aangepast, wat kan wijzen op pogingen om sporen te wissen

Veel van deze signalen zijn op zichzelf niet alarmerend. Een aanvaller combineert juist meerdere kleine afwijkingen tot een werkend aanvalspad. Verificatiepunt: controleer regelmatig je auditlogs en Identity and Access Management (IAM)-rapporten op bovenstaande afwijkingen. Als je twee of meer van deze signalen tegelijk ziet, is verder onderzoek noodzakelijk.

De twee hoofdvormen van privilege escalation uitgelegd

Binnen cyberbeveiliging onderscheiden experts twee fundamenteel verschillende vormen van privilege escalation. Beide zijn gevaarlijk, maar ze vereisen een andere aanpak om ze te detecteren en te voorkomen.

Verticale privilege escalation

Bij verticale privilege escalation probeert een aanvaller zijn rechten omhoog te tillen: van een gewone gebruiker naar een beheerder, of van een beheerder naar een systeemaccount. Dit is de meest bekende vorm. Een aanvaller exploiteert hierbij bijvoorbeeld een kwetsbaarheid in het besturingssysteem, een verkeerd geconfigureerde service of een zwakke plek in een applicatie die met te hoge rechten draait. Het einddoel is volledige controle over het systeem of de omgeving.

Horizontale privilege escalation

Bij horizontale privilege escalation blijft een aanvaller op hetzelfde rechtenniveau, maar breidt hij zijn toegang uit naar andere accounts of systemen op dat niveau. Denk aan een medewerker die toegang krijgt tot de bestanden van een collega zonder dat zijn eigen rechten formeel zijn verhoogd. Deze vorm is lastiger te detecteren omdat de rechten technisch gezien niet veranderen, maar de reikwijdte van de aanvaller wel groeit. In cloudomgevingen en netwerken met veel gekoppelde identiteiten is horizontale privilege escalation bijzonder effectief.

Beide vormen worden in de praktijk vaak gecombineerd. Een aanvaller begint horizontaal om meer accounts in handen te krijgen, en gebruikt vervolgens een van die accounts als springplank voor verticale privilege escalation.

Stap voor stap: hoe aanvallers privilege escalation uitvoeren

Een privilege-escalationaanval volgt zelden een willekeurig pad. Aanvallers denken strategisch en werken methodisch. Begrijpen hoe dit proces eruitziet, helpt je om de juiste verdedigingsmaatregelen op de juiste plek te zetten.

1. Initiële toegang verkrijgen: De aanvaller begint met een beperkt toegangspunt, vaak via phishing, een gestolen wachtwoord of een kwetsbare applicatie. Op dit punt heeft hij minimale rechten.
2. Verkenning uitvoeren: Vervolgens brengt de aanvaller de omgeving in kaart. Welke accounts bestaan er? Welke permissies hebben ze? Welke services draaien er met verhoogde rechten? Welke configuratiefouten zijn aanwezig? In cloudomgevingen zoals Azure of AWS kijkt een aanvaller specifiek naar managed identities, roltoewijzingen en misconfiguraties in IAM-beleid.
3. Kwetsbaarheden identificeren: De aanvaller zoekt naar exploiteerbare zwaktes. Dit kunnen bekende CVE’s zijn in niet-gepatchte software, maar ook te ruime permissies, onveilige serviceaccounts of misconfiguraties die op zichzelf onschuldig lijken.
4. Privilege escalation uitvoeren: Met de gevonden zwaktes verhoogt de aanvaller zijn rechten. Een klassiek voorbeeld in cloudomgevingen is een combinatie van SSRF (Server-Side Request Forgery), een managed identity, Azure RBAC-rechten en toegang tot een Key Vault. Geen van deze stappen is op zichzelf kritiek, maar samen leiden ze tot volledige controle over cloudresources.
5. Persistentie opbouwen: Zodra hogere rechten zijn verkregen, zorgt de aanvaller ervoor dat hij ook na een herstart of wachtwoordwijziging toegang behoudt. Dit kan via backdoors, nieuwe beheerdersaccounts of aanpassingen aan opstartscripts.
6. Laterale beweging en verdere exploitatie: Met verhoogde rechten beweegt de aanvaller door het netwerk, compromitteert aanvullende systemen en bereikt uiteindelijk zijn einddoel, of dat nu datadiefstal, ransomware of sabotage is.

Verificatiepunt: doorloop dit aanvalsscenario mentaal voor je eigen omgeving. Welke stap zou een aanvaller bij jullie het gemakkelijkst kunnen zetten? Dat is precies waar je verdediging het zwakst is.

Beveilig je systemen tegen privilege escalation

Het goede nieuws is dat privilege escalation voorkomen grotendeels neerkomt op het consequent toepassen van bekende beveiligingsprincipes. De meeste succesvolle privilege-escalationaanvallen maken gebruik van configuratiefouten en te ruime permissies, niet van geavanceerde zero-day exploits.

Neem de volgende maatregelen om je aanvalsoppervlak te verkleinen:

• Least-privilegeprincipe: Geef accounts alleen de rechten die strikt noodzakelijk zijn voor hun taak. Controleer en beperk permissies regelmatig, ook voor serviceaccounts en geautomatiseerde processen.
• Patchmanagement: Houd besturingssystemen, applicaties en firmware consequent up-to-date. Veel privilege-escalationaanvallen maken gebruik van bekende kwetsbaarheden in niet-gepatchte software.
• Multi-factor-authenticatie (MFA): Verplicht MFA voor alle accounts, en zeker voor accounts met verhoogde rechten. Dit maakt het stelen van een wachtwoord op zichzelf onvoldoende voor toegang.
• Segmentatie en isolatie: Beperk de bewegingsvrijheid van accounts en systemen binnen het netwerk. Zorg dat een gecompromitteerd account niet automatisch toegang geeft tot alle andere systemen.
• Monitoring en logging: Log alle authenticatie- en autorisatiegebeurtenissen en stel alerts in voor afwijkend gedrag. Zonder zicht op wat er gebeurt, is detectie onmogelijk.
• Regelmatige audits van permissies: Controleer periodiek welke accounts welke rechten hebben, inclusief rollen in cloudomgevingen. Permissiecreep, het onbedoeld ophopen van rechten over tijd, is een van de meest voorkomende oorzaken van escalation-risico’s.

Verificatiepunt: voer een interne audit uit van je IAM-configuratie en controleer of er accounts zijn met meer rechten dan ze nodig hebben. Kijk ook specifiek naar serviceaccounts en geautomatiseerde processen. Als je beleid rondom toegangsbeheer nog niet schriftelijk hebt vastgelegd, is dat een logische eerste stap.

Test je weerbaarheid met continue pentesting

Beveiligingsmaatregelen treffen is één ding. Weten of ze daadwerkelijk werken, is iets anders. Omgevingen veranderen continu: er worden applicaties aangepast, nieuwe accounts aangemaakt, permissies gewijzigd en cloudresources toegevoegd. Wat vandaag veilig is geconfigureerd, kan morgen een kwetsbaarheid zijn. Een jaarlijkse pentest geeft je inzicht op één moment, maar zegt niets over de overige 364 dagen.

Effectieve weerbaarheid tegen privilege escalation vereist een aanpak die meebeweegt met die veranderingen. Dat betekent in de praktijk:

• Een grondige baseline-pentest die niet alleen losse kwetsbaarheden opspoort, maar ook aanvalspaden in kaart brengt die ontstaan door combinaties van zwaktes
• Continue monitoring van wijzigingen in permissies, rollen en configuraties die nieuwe escalation-risico’s kunnen introduceren
• Periodieke herhaling van gerichte tests op de meest kritieke systemen en identiteiten
• Inzicht in hoe aanvallers jouw specifieke omgeving zouden benaderen, niet alleen een lijst met gevonden CVE’s

Een redteamoefening gaat hierin nog een stap verder: een gesimuleerde aanvaller probeert actief privilege escalation toe te passen in jouw omgeving, zodat je precies ziet waar de zwakste schakels zitten.

Hoe Q-Cyber helpt met privilege escalation

Wij bij Q-Cyber helpen organisaties om privilege escalation niet alleen te begrijpen, maar ook structureel te voorkomen en tijdig te detecteren. Onze aanpak gaat verder dan het uitvoeren van een standaard kwetsbaarheidsscan. We kijken zoals een echte aanvaller: we onderzoeken aanvalspaden, combinaties van misconfiguraties en identity-zwaktes die samen een groter risico vormen dan elk afzonderlijk.

Concreet bieden we hiervoor:

• Handmatige pentests waarbij onze ethical hackers actief proberen privileges te escaleren via dezelfde technieken als echte aanvallers, inclusief cloud- en identity-specifieke aanvalspaden
• Redteamoefeningen voor een realistische simulatie van hoe een aanvaller jouw omgeving zou doorlopen van initiële toegang tot volledige controle
• Continuous-Q®, ons programma voor continue offensieve security waarbij we na de baseline-pentest doorlopend meekijken naar nieuwe risico’s die ontstaan door wijzigingen in je omgeving
• Concrete rapportages met geprioriteerde bevindingen en praktisch advies, zodat je direct weet wat je als eerste moet aanpakken

Wil je weten hoe kwetsbaar jouw organisatie is voor privilege escalation? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Hoe ontstaat een attack path tijdens een cyberaanval?

Geplaatst op: 3 oktober 2026

Een cyberaanval lijkt van buitenaf vaak op een plotselinge inbraak, maar in werkelijkheid is het een zorgvuldig georkestreerd proces. Aanvallers werken stap voor stap, bouwen een aanvalspad op en benutten elke zwakke schakel die ze tegenkomen. Dat aanvalspad, ook wel een attack path of aanvalspad genoemd, is de route die een cybercrimineel aflegt van het eerste contactpunt tot het uiteindelijke doel.

Door te begrijpen hoe zo’n aanvalspad ontstaat, kun je als organisatie veel gerichter nadenken over je verdediging. In dit artikel doorloop je stap voor stap de fases die een aanvaller doorloopt, zodat je precies weet waar de risico’s zitten en waar je als eerste moet ingrijpen.

Hoe aanvallers een doelwit verkennen en in kaart brengen

Verkenning is de eerste en vaak langste fase van een cyberaanval. Voordat een aanvaller ook maar één exploit afvuurt, verzamelt hij informatie. Deze fase heet ook wel reconnaissance en vindt grotendeels passief plaats, zonder dat het doelwit er iets van merkt.

Identificeer wat een aanvaller over jouw organisatie kan vinden via openbare bronnen. Denk aan:

• Vacatures die technologiekeuzes verraden (welke software, cloudomgeving of frameworks jullie gebruiken)
• LinkedIn-profielen van medewerkers die rollen en verantwoordelijkheden blootleggen
• Domeinnamen, subdomeinen en IP-adressen via DNS-lookups
• Certificaten en SSL-informatie die infrastructuur zichtbaar maken
• Gegevens van leveranciers en MSP’s die toegang hebben tot jullie systemen

Na deze stap heeft een aanvaller een gedetailleerd beeld van hoe jouw organisatie is ingericht, welke leveranciers er toegang hebben en waar mogelijk gaten zitten tussen beveiligingsmaatregelen. Controleer periodiek wat er over jouw organisatie vindbaar is via openbare kanalen. Wat jij kunt vinden, kan een aanvaller ook vinden.

Kwetsbaarheden identificeren en rangschikken als aanvaller

Met de verkenningsinformatie op zak gaat een aanvaller op zoek naar concrete kwetsbaarheden. Belangrijk om te begrijpen: een ervaren aanvaller denkt niet in losse kwetsbaarheden, maar in combinaties. Eén misconfiguratie is misschien niet gevaarlijk, maar in combinatie met een zwak wachtwoordbeleid en te ruime cloudpermissies wordt het een werkbaar aanvalspad.

Rangschik kwetsbaarheden daarom niet alleen op ernst (CVSS-score), maar ook op bereikbaarheid en combinatiepotentieel. Een aanvaller kijkt specifiek naar:

1. Technische kwetsbaarheden zoals verouderde software of bekende CVE’s
2. Misconfiguraties in cloudomgevingen, zoals te open opslagbuckets of onjuiste netwerksegmentatie
3. Identiteiten en accounts met meer rechten dan nodig (privilege creep)
4. Zwakke punten in de supply chain, zoals leveranciers met directe toegang tot systemen
5. Menselijke factoren, zoals medewerkers die vatbaar zijn voor phishing

Verifieer na deze analyse of er combinaties van kwetsbaarheden bestaan die samen een realistisch aanvalspad vormen. Een schoon lijstje met opgeloste CVE’s betekent niet automatisch dat het gevaarlijkste aanvalspad is verdwenen. Zie ook onze uitleg over wat een pentest werkelijk test voor meer context over dit onderscheid.

Initial access verkrijgen via het zwakste punt

Zodra een aanvaller weet waar de zwakste schakels zitten, probeert hij toegang te krijgen. Dit heet initial access en is het moment waarop de aanvaller voor het eerst voet aan de grond krijgt binnen de organisatie. Vaak is dit niet via de meest voor de hand liggende route.

Begrijp welke ingangspunten het meest kwetsbaar zijn. Veelgebruikte methoden voor initial access zijn:

• Phishing-e-mails gericht op specifieke medewerkers (spear phishing)
• Misbruik van publiek toegankelijke applicaties met bekende kwetsbaarheden
• Gestolen of zwakke inloggegevens via credential stuffing
• Compromittering van een leverancier of MSP met toegang tot jouw netwerk
• Misbruik van VPN- of remoteaccessoplossingen zonder meervoudige authenticatie

Controleer of jullie meest kritieke ingangspunten zijn beveiligd met meervoudige authenticatie en actuele patchniveaus. Een aanvaller kiest altijd het pad van de minste weerstand. Als één leverancier toegang heeft tot jouw netwerk zonder strikte toegangscontrole, is dat pad vaak aantrekkelijker dan een directe aanval op de organisatie zelf. Meer over hoe aanvallers via supply chains opereren lees je op onze pagina over red teaming.

Laterale beweging en privilege escalation door het netwerk

Na de initiële toegang stopt een aanvaller zelden. De volgende fase is laterale beweging: het verplaatsen door het netwerk om toegang te krijgen tot meer systemen, data en rechten. Tegelijkertijd probeert de aanvaller zijn privileges te verhogen via privilege escalation, zodat hij steeds meer kan doen.

Breng in kaart hoe accounts en systemen binnen jullie netwerk met elkaar verbonden zijn. Aanvallers maken in deze fase gebruik van:

1. Gestolen sessietokens of hashes van het eerste gecompromitteerde account
2. Misconfiguraties in Active Directory of cloudidentiteiten om hogere rechten te verkrijgen
3. Interne tools en legitieme software (ook wel living off the land genoemd) om detectie te vermijden
4. Zwak gesegmenteerde netwerken waarbij systemen onbeperkt met elkaar kunnen communiceren

Verifieer of jullie netwerk voldoende gesegmenteerd is en of het principe van least privilege consequent wordt toegepast. Een aanvaller die eenmaal binnen is en onbeperkt lateraal kan bewegen, heeft feitelijk toegang tot alles. Detectie in deze fase is moeilijk omdat de aanvaller legitieme tools gebruikt en zich gedraagt als een normale gebruiker.

Het einddoel bereiken: data-exfiltratie of sabotage

Na succesvolle laterale beweging en privilege escalation bereikt de aanvaller zijn einddoel. Afhankelijk van de motivatie kan dit data-exfiltratie zijn, waarbij gevoelige informatie wordt gestolen, of sabotage, waarbij systemen worden verstoord of versleuteld met ransomware.

Identificeer welke data en systemen het meest aantrekkelijk zijn als einddoel voor een aanvaller. Typische einddoelen zijn:

• Klantgegevens, financiële informatie of intellectueel eigendom
• Toegang tot back-upsystemen om herstel te bemoeilijken
• Kritieke bedrijfsprocessen die bij uitval directe schade veroorzaken
• Inloggegevens van andere organisaties (bij aanvallen via MSP’s)

Controleer of jullie meest kritieke data extra beveiligd is en of er detectiemechanismen zijn die ongebruikelijke datatoegang of -overdracht signaleren. Het is in deze fase dat de schade zichtbaar wordt, maar het aanvalspad begon al veel eerder. Wie alleen op dit eindpunt focust, mist de echte oorzaak.

Attack paths doorbreken met continue testing

Nu je begrijpt hoe een aanvalspad ontstaat, is de logische vraag: hoe doorbreek je het? Het antwoord ligt niet in het oplossen van een lijst met losse kwetsbaarheden, maar in het continu testen of er werkbare aanvalspaden bestaan binnen jouw omgeving. Want jouw omgeving verandert elke dag: nieuwe accounts worden aangemaakt, applicaties worden aangepast, cloudresources komen en gaan.

Een jaarlijkse pentest is in dat opzicht een momentopname. Op de testdag weet je wat er kwetsbaar is, maar de 364 dagen daarna verandert de omgeving verder terwijl de testresultaten verouderen. Aanvallers ontwikkelen ondertussen nieuwe technieken en zoeken actief naar nieuwe ingangspunten.

Neem de volgende stappen om aanvalspaden structureel te doorbreken:

1. Voer eerst een grondige pentest uit als baseline om bestaande aanvalspaden in kaart te brengen
2. Los niet alleen losse kwetsbaarheden op, maar analyseer welke combinaties een werkbaar aanvalspad vormen
3. Implementeer netwerksegmentatie en least-privilegebeleid om laterale beweging te beperken
4. Zorg voor continue monitoring van identiteiten, permissies en cloudconfiguraties
5. Test regelmatig opnieuw, zodat wijzigingen in de omgeving niet ongemerkt nieuwe aanvalspaden openen

Verifieer na elke significante wijziging in jullie IT-omgeving of er nieuwe aanvalspaden zijn ontstaan. Nieuwe cloudresources, gewijzigde permissies of een nieuwe leverancier kunnen een bestaand aanvalspad opnieuw openen. Meer over hoe continue testing werkt lees je op onze pagina over Continuous-Q.

Hoe Q-Cyber helpt bij het blootleggen van aanvalspaden

Bij Q-Cyber helpen we organisaties om hun aanvalspaden te identificeren voordat een echte aanvaller dat doet. We denken daarbij niet in losse kwetsbaarheden, maar in de combinaties van zwaktes die samen een werkbaar aanvalspad vormen, precies zoals een echte aanvaller dat zou doen.

Wat we daarvoor bieden:

• Handmatige pentesten waarbij onze ethical hackers denken als aanvallers en zoeken naar realistische aanvalspaden, niet alleen bekende CVE’s
• Red teaming waarbij een gesimuleerde aanvaller jouw volledige verdediging test, inclusief detectie en respons
• Continuous-Q, ons programma voor continue testing waarbij experts jouw omgeving blijven volgen na de initiële pentest, zodat nieuwe aanvalspaden direct worden gesignaleerd
• Onafhankelijk advies zonder afhankelijkheid van softwarepartijen, zodat onze aanbevelingen altijd in jouw belang zijn

Wil je weten welke aanvalspaden er op dit moment in jouw organisatie bestaan? Neem contact met ons op en we bespreken hoe we jouw beveiliging kunnen testen en versterken.

Lees meer

Is iedere critical CVE ook daadwerkelijk kritiek voor jouw organisatie?

Geplaatst op: 3 oktober 2026

Niet elke critical CVE is automatisch kritiek voor jouw organisatie. Of een kwetsbaarheid daadwerkelijk urgent is, hangt af van context: staat het kwetsbare systeem bij jou in gebruik, is het bereikbaar vanaf het internet, en bestaat er al een werkende exploit? Een CVSS-score van 9.8 zegt iets over de ernst van een kwetsbaarheid in het algemeen, maar niets over het risico dat jij persoonlijk loopt. In dit artikel beantwoorden we de meest gestelde vragen over CVE-beoordeling, CVSS-scores en hoe je vulnerability management opbouwt dat echt aansluit bij jouw situatie.

Wat bepaalt of een CVE écht kritiek is voor jouw situatie?

Of een CVE kritiek is voor jouw organisatie, wordt bepaald door drie factoren: of het kwetsbare systeem bij jou in gebruik is, of dat systeem bereikbaar is voor een aanvaller, en of er een realistische exploit beschikbaar is. Een kwetsbaarheid die in theorie een score van 10.0 haalt maar alleen van toepassing is op software die jij niet gebruikt, is in de praktijk irrelevant voor jouw risicobeoordeling.

Dit klinkt eenvoudig, maar in de praktijk worstelen veel organisaties hier dagelijks mee. Securityteams worden overspoeld met meldingen van nieuwe critical CVE’s, terwijl de capaciteit om ze allemaal te beoordelen beperkt is. Het gevolg is dat teams óf alles als urgent behandelen en vastlopen, óf een prioritering hanteren die niet goed is doordacht.

De kern van goede CVE-beoordeling is contextualisering. Dat betekent: koppel elke nieuwe kwetsbaarheid aan je eigen asset inventory, je netwerktopologie en je dreigingslandschap. Pas dan kun je bepalen of een patch morgen moet worden doorgevoerd of volgende maand.

Hoe werkt de CVSS-score en waar schiet die tekort?

De CVSS-score (Common Vulnerability Scoring System) is een gestandaardiseerde methode om de ernst van een kwetsbaarheid te beoordelen op een schaal van 0 tot 10. De score is gebaseerd op factoren zoals aanvalsvector, complexiteit, vereiste privileges en de impact op vertrouwelijkheid, integriteit en beschikbaarheid. Een hoge score signaleert dat een kwetsbaarheid in ideale omstandigheden voor een aanvaller ernstig is.

Maar precies daar zit de beperking: CVSS beoordeelt kwetsbaarheden in isolatie, zonder rekening te houden met jouw specifieke omgeving. De score houdt geen rekening met:

• Of het kwetsbare systeem bij jou überhaupt in gebruik is
• Of het systeem intern staat of publiek bereikbaar is
• Of er compenserende maatregelen zijn zoals netwerksegmentatie of aanvullende authenticatie
• Of er actieve exploitatie in het wild plaatsvindt
• Hoe het kwetsbare systeem zich verhoudt tot andere systemen in jouw omgeving

Een CVSS-score is daarmee een startpunt voor beoordeling, geen eindoordeel. Organisaties die uitsluitend op basis van CVSS-scores prioriteren, lopen het risico om veel tijd te steken in patches die weinig impact hebben op hun werkelijke aanvalsoppervlak, terwijl gevaarlijkere combinaties van zwaktes onopgemerkt blijven.

Wat is het verschil tussen CVSS-score en werkelijk exploitatierisico?

Het werkelijke exploitatierisico is de kans dat een aanvaller een kwetsbaarheid succesvol misbruikt in jouw specifieke omgeving. Dat is fundamenteel anders dan de CVSS-score, die de theoretische ernst van een kwetsbaarheid weergeeft onder optimale aanvalsomstandigheden. Een kwetsbaarheid met een hoge CVSS-score kan een laag exploitatierisico hebben als jouw omgeving de aanvalsvector neutraliseert.

Een praktisch voorbeeld: een kritieke kwetsbaarheid in een webserver die alleen intern bereikbaar is, heeft een veel lager werkelijk risico dan een kwetsbaarheid met een lagere CVSS-score in een publiek bereikbare applicatie die direct is gekoppeld aan je productiedatabase.

Twee aanvullende factoren bepalen het werkelijke exploitatierisico sterk:

• Exploitbeschikbaarheid: Bestaat er al een publiek beschikbare exploit of proof-of-concept? Databases zoals CISA’s Known Exploited Vulnerabilities (KEV) catalogus geven hier inzicht in.
• Aanvalspadcontext: Kan een aanvaller deze kwetsbaarheid combineren met andere zwaktes in jouw omgeving om een werkend aanvalspad te creëren? Een handmatige pentest brengt dit soort gecombineerde risico’s in kaart, iets wat een geautomatiseerde scanner niet kan.

Welke vragen moet je stellen bij elke nieuwe critical CVE?

Bij elke nieuwe critical CVE moet je minimaal vijf vragen beantwoorden voordat je bepaalt hoe urgent de patch is. Deze vragen vormen samen een snelle risicobeoordeling die CVSS-scores in context plaatst en je helpt prioriteiten te stellen.

1. Gebruiken wij het kwetsbare systeem of de kwetsbare software? Als het antwoord nee is, stop dan hier. De CVE is irrelevant voor jouw organisatie.
2. Is het kwetsbare systeem bereikbaar voor een aanvaller? Staat het publiek op internet, of alleen intern? Is er netwerksegmentatie aanwezig?
3. Bestaat er al een werkende exploit? Controleer CISA KEV en bronnen zoals Exploit-DB. Actieve exploitatie in het wild verhoogt de urgentie sterk.
4. Welke data of systemen zijn bereikbaar via dit aanvalspad? Een kwetsbaar systeem zonder toegang tot gevoelige data of kritieke processen heeft een ander gewicht dan een systeem dat centraal staat in je infrastructuur.
5. Zijn er compenserende maatregelen aanwezig? Denk aan WAF-regels, aanvullende authenticatie, monitoring of netwerksegmentatie die de exploitatie bemoeilijken.

Deze vijf vragen kosten weinig tijd maar voorkomen dat je resources verspilt aan patches die nauwelijks bijdragen aan je werkelijke veiligheid.

Wanneer is een CVE met lage score toch urgent voor jouw organisatie?

Een CVE met een lage CVSS-score kan urgent zijn wanneer die kwetsbaarheid onderdeel wordt van een aanvalspad waarbij meerdere zwaktes worden gecombineerd. Aanvallers denken niet in losse bevindingen, maar in ketens van stappen die samen leiden tot toegang tot wat ze willen bereiken. Een lage score betekent niet dat een kwetsbaarheid onschadelijk is, alleen dat ze in isolatie beperkte impact heeft.

Concrete situaties waarin een lage CVE-score toch directe actie vereist:

• De kwetsbaarheid geeft een aanvaller een eerste voet aan de grond (initial access) in jouw omgeving, ook al is de directe impact beperkt
• Ze is combineerbaar met een misconfiguratie in je cloudomgeving of te ruime permissies op accounts, waardoor privilege escalation mogelijk wordt
• Ze bevindt zich in een systeem dat toegang heeft tot privileged accounts of kritieke bedrijfsprocessen
• Ze maakt laterale beweging mogelijk tussen systemen die normaliter gescheiden zijn

Dit is precies de reden waarom kwalitatief securityonderzoek verder kijkt dan individuele bevindingen. Een aanvaller die een SSRF-kwetsbaarheid combineert met een managed identity, ruime Azure RBAC-rechten en toegang tot een Key Vault kan volledige controle over cloudresources krijgen, terwijl geen van die stappen op zichzelf als critical is beoordeeld. Losse scores vertellen dat verhaal niet.

Hoe bouw je een contextueel vulnerabilitymanagementproces op?

Een contextueel vulnerabilitymanagementproces bouw je op door kwetsbaarheden altijd te beoordelen in relatie tot jouw specifieke omgeving, niet op basis van generieke scores alleen. Dat vraagt om een gestructureerde aanpak met vier bouwstenen: een actuele asset inventory, inzicht in je aanvalsoppervlak, een prioriteringsmodel dat context meeneemt, en continue monitoring in plaats van periodieke snapshots.

Stap 1: Zorg voor een actuele asset inventory

Je kunt geen kwetsbaarheid beoordelen als je niet weet welke systemen je hebt. Een actuele inventarisatie van alle assets, inclusief cloudresources, SaaS-applicaties en third-party koppelingen, is de basis van alles. Veel organisaties onderschatten hoe snel hun omgeving verandert door nieuwe applicaties, accounts en cloudresources.

Stap 2: Koppel kwetsbaarheden aan aanvalsoppervlak en context

Zodra een nieuwe CVE verschijnt, koppel je die direct aan je asset inventory. Welke systemen zijn kwetsbaar? Zijn ze intern of extern bereikbaar? Welke data of processen zijn via die systemen bereikbaar? Dit geeft een directe prioritering op basis van werkelijk risico in plaats van theoretische ernst.

Stap 3: Gebruik een gelaagd prioriteringsmodel

Een effectief model kijkt naar drie lagen: bekende kwetsbaarheden en CVE’s, individuele zwaktes zoals misconfiguraties en te ruime permissies, en gecombineerde aanvalspaden waarbij meerdere zwaktes samen een serieus risico vormen. De derde laag wordt door veel organisaties over het hoofd gezien maar is vaak waar het echte risico zit.

Stap 4: Test continu in plaats van eenmalig

Een jaarlijkse pentest geeft inzicht op één moment, maar je omgeving verandert doorlopend. Nieuwe applicaties, gewijzigde permissies, extra cloudresources: elke wijziging kan een nieuw aanvalspad openen. Continuous testing houdt inzicht actueel, zodat je niet alleen weet dat je op de testdag veilig was, maar ook de 364 dagen erna. Meer over deze aanpak lees je op de pagina over Continuous-Q.

Hoe Q-Cyber helpt bij CVE-beoordeling en vulnerability management

Wij helpen organisaties om verder te kijken dan CVSS-scores en generieke kwetsbaarheidslijsten. In plaats van een stapel bevindingen zonder context, brengen wij in kaart welke kwetsbaarheden in jouw specifieke omgeving daadwerkelijk een risico vormen en hoe aanvallers die zouden combineren tot een werkend aanvalspad.

Concreet biedt Q-Cyber:

• Handmatige pentests waarbij onze ethical hackers denken zoals een echte aanvaller en gecombineerde aanvalspaden blootleggen die scanners missen
• Contextuele risicoanalyse waarbij bevindingen worden beoordeeld op basis van jouw omgeving, niet op basis van generieke scores
• Continuous-Q voor organisaties die na een baseline pentest doorlopend inzicht willen houden in hun aanvalsoppervlak
• Pragmatisch advies over patchprioritering en compenserende maatregelen, onafhankelijk van softwareleveranciers

Wil je weten welke CVE’s in jouw omgeving daadwerkelijk urgent zijn? Neem contact op en we kijken samen naar jouw situatie.

Lees meer