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

Betekent een pentestrapport zonder critical findings dat je veilig bent?

Geplaatst op: 2 oktober 2026

Nee, een pentestrapport zonder critical findings betekent niet automatisch dat je organisatie veilig is. Een pentest meet een specifieke scope, op een specifiek moment in de tijd, met een specifieke methode. Wat buiten die scope valt, op het moment van de test niet bestond, of niet als losstaande bevinding zichtbaar was, blijft onzichtbaar in het rapport. De vragen hieronder leggen uit waarom die nuance zo belangrijk is en wat je er wél uit kunt concluderen.

Wat meet een pentest eigenlijk, en wat niet?

Een pentest meet of specifieke systemen, applicaties of netwerksegmenten op het moment van de test kwetsbaar zijn voor bekende aanvalstechnieken, binnen een vooraf afgesproken scope. Wat een pentest niet meet, is minstens zo belangrijk: alles buiten die scope, nieuwe kwetsbaarheden die na de test ontstaan, en aanvalspaden die alleen zichtbaar worden door meerdere zwaktes te combineren.

Er zijn ruwweg drie lagen waarop offensieve security waarde toevoegt:

• Bekende kwetsbaarheden (layer 1): Publieke CVE’s, ontbrekende patches en bekende exploits. Dit is het domein van geautomatiseerde vulnerability scans.
• Individuele zwaktes (layer 2): Verkeerde cloudconfiguraties, te ruime permissies, identity weaknesses en onveilige applicatie-instellingen. Hier begint handmatig pentesten pas echt waarde te leveren.
• Gecorreleerde aanvalspaden (layer 3): Combinaties van meerdere kleine zwaktes die samen leiden tot een serieuze aanval. Dit is waar een goede pentest of red team engagement het verschil maakt.

Een standaard pentest kijkt niet altijd naar alle drie de lagen. Veel pentests stoppen bij layer 1 of layer 2. Dat levert een rapport op met bevindingen, maar het zegt weinig over hoe een echte aanvaller jouw organisatie zou benaderen. Begrijpen wat een pentest wél en niet dekt, is daarom de eerste stap in het correct interpreteren van de uitkomsten.

Wat betekent ‘geen critical findings’ in een pentestrapport?

‘Geen critical findings’ betekent dat de pentesters binnen de afgesproken scope en tijdspanne geen kwetsbaarheden hebben gevonden die zij als kritiek classificeren. Het zegt niets over wat buiten de scope valt, niets over aanvalspaden die pas zichtbaar worden bij combinaties van zwaktes, en niets over wat morgen of volgende maand kwetsbaar wordt.

De classificatie van een bevinding als ‘critical’ hangt bovendien af van hoe de pentest is opgezet. Een SSRF-kwetsbaarheid kan op zichzelf als medium worden geclassificeerd. Maar als diezelfde SSRF toegang geeft tot een managed identity, die vervolgens via Azure RBAC toegang heeft tot een Key Vault, en die Key Vault subscription owner-rechten bevat, dan is de gecombineerde aanvalsketen ronduit kritiek. Losse bevindingen zeggen weinig. Aanvalspaden zeggen alles.

Aanvallers denken niet in findings. Ze denken in routes. Een rapport zonder critical findings kan dus een volledig valide technisch document zijn, terwijl er tegelijkertijd een aanvalspad bestaat dat niet als zodanig is herkend of onderzocht.

Waarom kunnen aanvallers slagen waar een pentest niets vindt?

Aanvallers slagen waar een pentest niets vindt omdat ze denken in organisatiestructuren, niet in geïsoleerde technische bevindingen. Een pentest is doorgaans tijdgebonden en scopegebonden. Een aanvaller werkt zonder tijdslimiet en zonder scopebeperking, en combineert informatie over leveranciers, identities, permissies en configuraties op manieren die een gestructureerde test niet altijd nabootst.

Een aanvaller begint bovendien vaak niet met het afvuren van exploits. Eerst wordt de organisatie in kaart gebracht: welke leveranciers hebben toegang, welke accounts bestaan er, welke rechten zijn er toegewezen, welke certificeringen en beveiligingsmaatregelen zijn aanwezig, en waar zitten de gaten tussen die maatregelen. Dit verkenningswerk levert soms al voldoende informatie om een aanval te plannen, nog voordat er ook maar één technische kwetsbaarheid is geëxploiteerd.

Dat maakt het ook zo lastig om op basis van een pentestrapport te concluderen dat je veilig bent. Een pentest is een momentopname van wat testers vinden binnen een afgebakende context. Een aanvaller heeft geen last van die beperkingen.

Hoe snel veroudert een pentestrapport?

Een pentestrapport veroudert direct na afronding. Zodra nieuwe software wordt uitgerold, configuraties worden gewijzigd, medewerkers van rol wisselen of leveranciers toegang krijgen, weerspiegelt het rapport niet langer de werkelijke situatie. In een omgeving die continu verandert, is een jaarlijks rapport al na enkele weken een historisch document.

Cybercriminelen ontwikkelen het hele jaar door nieuwe aanvalstechnieken. Een kwetsbaarheid die op de dag van de test niet bestond, kan een maand later al actief worden misbruikt. Een jaarlijkse penetratietest is in die zin vergelijkbaar met een foto van een bewegend doelwit: de foto klopt op het moment van de opname, maar de werkelijkheid is al veranderd tegen de tijd dat je de foto bekijkt.

Dit is geen argument om pentests te vermijden. Het is een argument om te begrijpen wat een pentest wel en niet garandeert, en om na te denken over wat er tussen twee pentests in gebeurt met de beveiliging van je omgeving.

Wanneer is een jaarlijkse pentest wel of niet voldoende?

Een jaarlijkse pentest is voldoende als je omgeving nauwelijks verandert, de scope beperkt en stabiel is, en je de uitkomsten gebruikt als aanvulling op een bredere beveiligingsstrategie. Voor de meeste organisaties is dat niet het geval. Hoe dynamischer de omgeving, hoe sneller een jaarlijkse test zijn waarde verliest.

Wanneer een jaarlijkse pentest redelijk volstaat

Voor organisaties met een kleine, stabiele IT-omgeving, beperkte cloudadoptie en weinig externe leveranciers kan een jaarlijkse pentest een zinvolle basistest zijn. Zeker als die wordt gecombineerd met regelmatige vulnerability scans en een helder patchbeleid. De pentest fungeert dan als periodieke dieptecheck bovenop bestaande basismaatregelen.

Wanneer een jaarlijkse pentest onvoldoende is

Voor organisaties die regelmatig nieuwe systemen uitrollen, werken met meerdere externe leveranciers of als Managed Service Provider (MSP) diensten leveren aan klanten, schiet een jaarlijkse test structureel tekort. Een MSP is bovendien een aantrekkelijk doelwit voor aanvallers: het compromitteren van één MSP geeft potentieel toegang tot alle klanten van die MSP. De verantwoordelijkheid die daarmee gepaard gaat, vraagt om een frequentere en meer geïntegreerde aanpak van security testing. Meer weten over wat continu testen inhoudt? Bekijk onze aanpak voor continue security testing.

Hoe weet je dan of je organisatie echt veilig is?

Absolute veiligheid bestaat niet, maar je kunt wel weten hoe weerbaar je organisatie is op dit moment. Dat vereist meer dan een jaarlijkse pentest: het vraagt om continu inzicht in je aanvalsoppervlak, aandacht voor aanvalspaden in plaats van losse bevindingen, en een beveiligingsstrategie die meeverandert met je omgeving.

Concrete indicatoren van echte weerbaarheid zijn:

• Je weet welke systemen, identities en leveranciers toegang hebben tot je omgeving, en je beheert die toegang actief.
• Bevindingen uit eerdere tests zijn aantoonbaar opgelost en niet alleen gerapporteerd.
• Je test niet alleen op bekende kwetsbaarheden, maar ook op aanvalspaden en combinaties van zwaktes.
• Je beveiligingsbeleid en je technische maatregelen worden regelmatig getoetst aan de werkelijke dreigingen die voor jouw sector relevant zijn.
• Medewerkers zijn getraind en bewust van hun rol in de beveiliging van de organisatie.

Een pentestrapport zonder critical findings is een goed teken, maar het is geen eindpunt. Weerbaarheid is een levende capaciteit, geen certificaat dat je eenmalig verdient.

Hoe Q-Cyber helpt bij het interpreteren en verbeteren van je pentestresultaten

Bij Q-Cyber geloven we dat een pentestrapport pas echt waarde heeft als je begrijpt wat het zegt én wat het niet zegt. Onze ethical hackers voeren handmatige penetratietests uit die verder gaan dan bekende CVE’s en geautomatiseerde scans. We kijken naar aanvalspaden, gecorreleerde zwaktes en de combinaties die een echte aanvaller zou benutten.

Wat we concreet bieden:

• Handmatige pentests uitgevoerd door gecertificeerde ethical hackers, gericht op aanvalspaden en niet alleen op losse bevindingen
• Heldere rapportage met concrete prioriteiten, zodat je direct weet waar actie vereist is
• Continuous-Q® voor organisaties die continu inzicht willen in hun weerbaarheid, inclusief periodieke retests en een team van specialisten dat meekijkt
• Onafhankelijk advies zonder afhankelijkheid van softwarepartijen of toeleveranciers
• Ondersteuning bij beleid en compliance, zodat technische bevindingen ook vertaald worden naar organisatorische maatregelen

Wil je weten wat een pentest door Q-Cyber voor jouw organisatie oplevert, of wil je bespreken of jouw huidige aanpak voldoende is? Neem contact met ons op en we denken graag met je mee.

Lees meer

Hoe combineren hackers meerdere kwetsbaarheden tot één aanvalspad?

Geplaatst op: 1 oktober 2026

Cybercriminelen werken zelden met één enkele kwetsbaarheid. In de meeste succesvolle aanvallen combineren aanvallers meerdere zwakke plekken tot één samenhangend aanvalspad, ook wel vulnerability chaining of chained exploits genoemd. Een misconfiguratie hier, een account met te veel rechten daar, een onbeveiligde cloudresource ergens anders: op zichzelf lijken het kleine problemen, maar samen vormen ze een directe route naar de kroonjuwelen van je organisatie.

In deze gids leer je stap voor stap hoe je herkent hoe hackers meerdere kwetsbaarheden combineren tot één aanvalspad, hoe je dat aanvalspad blootlegt in je eigen omgeving, en hoe je de keten effectief verbreekt. Zo bouw je niet alleen aan betere beveiliging op papier, maar aan echte weerbaarheid in de praktijk.

Herken de bouwstenen van een geketende aanval

Voordat je een aanvalspad kunt blokkeren, moet je begrijpen waaruit het is opgebouwd. Hackers denken niet in losse kwetsbaarheden, ze denken in combinaties. Een aanvaller zoekt naar een reeks stappen waarbij elke stap de volgende mogelijk maakt. Dat is precies waarom een lijst met opgeloste CVE’s geen garantie is dat het belangrijkste aanvalspad is verdwenen.

De meest voorkomende bouwstenen van een geketende aanval zijn:

• Technische kwetsbaarheden zoals verouderde software of ongepatchte systemen
• Identiteits- en toegangsproblemen zoals accounts met te brede rechten of zwakke wachtwoorden
• Cloudmisconfiguraties zoals openstaande storage buckets of onbeveiligde API-endpoints
• Privileged access waarbij serviceaccounts of beheerders onnodig veel permissies hebben
• Supply chain-zwaktes via leveranciers, MSP’s of externe partijen met toegang tot je netwerk

Controleer of je in je beveiligingsanalyses alleen naar losse bevindingen kijkt of ook naar de combinaties daartussen. Als je alleen individuele kwetsbaarheden scoort zonder te vragen hoe ze zich tot elkaar verhouden, mis je het echte risico. Een aanvalspad bestaat zelden uit één stap, maar uit drie, vier of vijf stappen die samen de schade veroorzaken.

Breng de aanvalsoppervlakte van je organisatie in kaart

Met de bouwstenen in gedachten is de volgende stap het volledig in kaart brengen van je aanvalsoppervlakte. Dat gaat verder dan een lijst van IP-adressen of applicaties. Aanvallers kijken naar de organisatiestructuur als geheel: welke systemen communiceren met elkaar, welke externe partijen hebben toegang, en waar zitten de grenzen tussen beveiligingsmaatregelen.

1. Inventariseer alle systemen, applicaties en cloudresources, inclusief schaduw-IT die buiten de officiële IT-omgeving valt.
2. Breng alle externe toegangspunten in kaart: leveranciers, MSP’s, remote access tools en API-koppelingen.
3. Documenteer welke accounts bestaan, welke rechten ze hebben en of die rechten nog actueel zijn.
4. Identificeer waar beveiligingsmaatregelen naast elkaar bestaan maar niet op elkaar aansluiten, want juist die gaten zijn interessant voor aanvallers.

Na deze stap heb je een overzicht dat verder gaat dan een technische scan ooit kan leveren. Geautomatiseerde tools vinden bekende CVE’s, maar ze begrijpen niet hoe een aanvaller jouw specifieke combinatie van systemen, identiteiten en permissies zou benutten. Dat inzicht krijg je alleen door de aanvalsoppervlakte als geheel te analyseren. Meer achtergrond over hoe aanvallers te werk gaan, vind je in onze cyber research.

Volg het aanvalspad stap voor stap na

Nu je weet wat er in je omgeving aanwezig is, ga je actief nadenken als een aanvaller. Dit is de kern van het begrijpen van hoe hackers meerdere kwetsbaarheden combineren: je volgt de logica van een aanvalspad van begin tot eind, van het eerste toegangspunt tot de uiteindelijke doelstelling.

Bepaal het beginpunt

Stel jezelf de vraag: als een aanvaller vandaag mijn organisatie wil binnenkomen, waar begint hij dan? Dat kan een phishing-mail zijn, een extern beschikbare webapplicatie, of een leverancier met toegang tot je netwerk. Kies het meest realistische beginpunt op basis van je aanvalsoppervlakte.

Teken de stappen naar het doel

Redeneer van het beginpunt naar een waardevol doelwit, zoals klantdata, financiële systemen of domeinbeheerdersrechten. Stel bij elke stap de vraag: wat heeft een aanvaller nodig om van hier naar de volgende stap te komen, en welke kwetsbaarheid, misconfiguratie of permissie maakt dat mogelijk?

1. Noteer elke stap in het pad als een concrete actie, bijvoorbeeld: “een aanvaller verkrijgt toegang via phishing, gebruikt een gecompromitteerd account om interne systemen te verkennen, ontdekt een serviceaccount met domeinrechten, escaleert privileges.”
2. Markeer bij elke stap welke zwakke plek wordt benut en of die zwakke plek momenteel wordt gemonitord of geblokkeerd.
3. Beoordeel hoe realistisch het pad is: hoeveel stappen zijn er nodig, hoeveel kennis en middelen vereist het, en hoe groot is de kans dat het onopgemerkt blijft?

Na deze stap heb je geen lijst met losse kwetsbaarheden meer, maar een concreet scenario dat laat zien hoe een aanvaller jouw organisatie daadwerkelijk zou kunnen compromitteren. Dat is een fundamenteel ander vertrekpunt voor prioritering dan een rapport met twintig bevindingen zonder onderlinge context.

Simuleer de keten met een gecontroleerde pentest

Redeneren als een aanvaller is waardevol, maar de werkelijke test is of het pad ook in de praktijk bewandelbaar is. Een handmatige penetratietest simuleert een echte aanval op jouw systemen, waarbij een ethical hacker precies de combinaties van kwetsbaarheden en permissies onderzoekt die jij in de vorige stap hebt geïdentificeerd.

Het verschil met een geautomatiseerde vulnerability scan is cruciaal. Een scanner vindt bekende technische afwijkingen, maar begrijpt niet hoe ze samenhangen. Een menselijke pentester denkt creatief, past technieken aan op jouw specifieke omgeving en ontdekt aanvalspaden die geen enkel automatisch hulpmiddel zou vinden. Denk daarbij ook aan red teaming, waarbij een gesimuleerde aanvaller de volledige aanvalsketen nabootst, inclusief sociale technieken en supply chain-aanvallen.

1. Definieer de scope van de pentest op basis van de aanvalspaden die je in de vorige stap hebt getekend.
2. Zorg dat de pentester toegang heeft tot de juiste context: welke systemen communiceren met elkaar, welke accounts bestaan, welke externe partijen zijn betrokken.
3. Vraag na afloop niet alleen om een lijst van bevindingen, maar om een beschrijving van de aanvalspaden die succesvol waren of bijna succesvol waren.

Verifieer na de pentest of de gevonden aanvalspaden overeenkomen met de scenario’s die je zelf had bedacht. Zijn er paden die je had gemist? Dat zijn precies de blinde vlekken waar aanvallers op inspelen.

Verbreek de keten met gerichte herstelprioriteiten

Een aanvalspad is zo sterk als de zwakste schakel. Je hoeft niet elke kwetsbaarheid tegelijk op te lossen om een keten te verbreken. Identificeer de stap in het aanvalspad waarbij ingrijpen het meeste effect heeft, en begin daar.

1. Rangschik de gevonden kwetsbaarheden niet op CVSS-score, maar op hun rol in een aanvalspad. Een kwetsbaarheid met een lage score die een cruciale schakel vormt, is gevaarlijker dan een hoge score die nergens op aansluit.
2. Verbreek de keten op het vroegst mogelijke punt. Als je het beginpunt van een aanvalspad kunt elimineren, vervallen alle volgende stappen automatisch.
3. Herstel niet alleen de technische kwetsbaarheid, maar ook de onderliggende oorzaak. Een account met te veel rechten is een technisch probleem, maar ook een procesprobleem als er geen review plaatsvindt bij uitdiensttreding.
4. Documenteer welke aanvalspaden na het herstel nog steeds mogelijk zijn en welke zijn geblokkeerd.

Na deze stap heb je niet alleen een kortere lijst van open bevindingen, maar ook aantoonbaar minder werkbare aanvalspaden. Dat is het verschil tussen schijnveiligheid en echte weerbaarheid.

Voorkom nieuwe ketens met continue monitoring

Een verbroken aanvalspad blijft niet automatisch verbroken. Elke wijziging in je omgeving kan een nieuwe keten creëren: een nieuw account, een aangepaste permissie, een extra cloudresource, of een nieuw kwetsbaar systeem bij een leverancier. Aanvallers ontwikkelen het hele jaar door nieuwe technieken, en een jaarlijkse momentopname houdt dat tempo niet bij.

Continue monitoring betekent niet dat je elke maand dezelfde pentest herhaalt. Het betekent dat je voortdurend inzicht houdt in veranderingen die nieuwe aanvalspaden kunnen openen:

• Monitor wijzigingen in identiteiten, rechten en toegangspunten actief en geautomatiseerd.
• Stel een proces in waarbij nieuwe systemen of cloudresources standaard worden beoordeeld op hun rol in mogelijke aanvalspaden voordat ze live gaan.
• Herhaal de aanvalspadsimulatie na significante wijzigingen in je omgeving, niet alleen op vaste momenten in het jaar.
• Zorg dat beveiligingsinzichten worden gedeeld met de teams die wijzigingen doorvoeren, zodat security een integraal onderdeel wordt van dagelijkse beslissingen.

Met Continuous-Q® houd je het hele jaar inzicht in veranderende aanvalspaden, in plaats van alleen op de testdag. Zo weet je niet alleen dat je op één bepaald moment bent getest, maar dat je ook de overige 364 dagen weerbaarheid opbouwt.

Hoe Q-Cyber helpt bij het blootleggen van aanvalspaden

Bij Q-Cyber helpen we organisaties om verder te kijken dan losse kwetsbaarheden. We brengen in kaart hoe aanvallers meerdere zwakke plekken combineren tot een werkend aanvalspad, en we helpen je die keten gericht te verbreken. Concreet bieden we:

• Handmatige penetratietests waarbij onze ethical hackers denken als echte aanvallers en aanvalspaden blootleggen die automatische tools missen
• Red teaming voor een volledige simulatie van een aanval, inclusief sociale technieken en supply chain-scenario’s
• Continuous-Q® voor doorlopend inzicht in veranderende aanvalspaden, zodat je het hele jaar weerbaarheid opbouwt in plaats van alleen op de testdag
• Onafhankelijk advies over herstelprioriteiten op basis van echte aanvalspaden, niet op basis van CVSS-scores of leveranciersbelangen

Wil je weten welke aanvalspaden er in jouw organisatie open liggen? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Hoe weet je of een pentest daadwerkelijk handmatig is uitgevoerd?

Geplaatst op: 15 september 2026

Je hebt een pentest laten uitvoeren en het rapport ligt op tafel. Maar hoe weet je of die test daadwerkelijk handmatig is uitgevoerd door een ervaren ethical hacker, of dat je in werkelijkheid betaalt voor een geautomatiseerde scan met een duur logo erop? Het onderscheid is cruciaal. Een handmatige pentest ontdekt aanvalspaden die geautomatiseerde tools structureel missen. Een geautomatiseerde scan doet dat niet, maar presenteert zich soms wel als volwaardige penetratietest.

In deze gids leer je stap voor stap hoe je de kwaliteit van een pentest verifieert: van het beoordelen van het rapport tot het stellen van de juiste vragen en het herkennen van rode vlaggen. Zo weet je zeker dat je investering daadwerkelijk waarde heeft opgeleverd.

Wat een echt handmatige pentest onderscheidt van een geautomatiseerde scan

Begrijp eerst het fundamentele verschil voordat je een rapport beoordeelt of vragen stelt. Een geautomatiseerde vulnerability scan werkt op basis van bekende CVE-databases en vergelijkt je omgeving met een lijst van bekende zwakheden. Dat is nuttig voor basishygiëne, maar het stopt daar ook. Een echte handmatige pentest gaat aanzienlijk verder en werkt op drie lagen:

• Laag 1 – Bekende kwetsbaarheden: Bekende CVE’s, publieke exploits en controle of patches correct zijn uitgevoerd. Dit is wat een geautomatiseerde scan ook kan.
• Laag 2 – Individuele zwakheden: Verkeerde Azure-configuraties, te ruime permissies, identity weaknesses en onveilige applicatie-instellingen. Deels automatiseerbaar, maar vereist menselijk oordeel.
• Laag 3 – Gecorreleerde aanvalspaden: Hier voegt een handmatige penetratietest echte waarde toe. Een ethical hacker onderzoekt wat er gebeurt als meerdere kleine zwaktes worden gecombineerd. Denk aan een keten als SSRF naar managed identity naar Azure RBAC naar Key Vault naar subscription owner. Los van elkaar lijkt geen enkele bevinding kritiek. Samen leiden ze tot volledige toegang tot cloudresources.

Het kernprincipe dat je moet onthouden: aanvallers zien geen losse bevindingen, zij zien aanvalspaden. Een geautomatiseerde scan rapporteert bevindingen. Een handmatige pentest reconstrueert aanvalspaden. Als je rapport alleen een lijst van CVE’s bevat zonder narratief over hoe een aanvaller ze zou combineren, is dat een sterke aanwijzing dat er weinig handmatig werk aan te pas is gekomen.

Beoordeel het rapport op tekenen van handmatig werk

Open het rapport en analyseer het op structuur en inhoud. Een kwalitatief handmatig pentestrapport heeft herkenbare kenmerken die je kunt controleren zonder zelf technisch expert te zijn.

1. Controleer de executive summary: Bevat die een verhaallijn over hoe een aanvaller te werk zou gaan, of is het een samenvatting van aantallen gevonden kwetsbaarheden? Een handmatig rapport vertelt een aanvalsverhaal.
2. Zoek naar omgevingsspecifieke details: Staan er screenshots, commando’s of outputs in die specifiek zijn voor jouw systemen, jouw domeinnamen, jouw applicatiestructuur? Generieke beschrijvingen zonder bewijs zijn een waarschuwingssignaal.
3. Beoordeel de bevindingen op diepgang: Een handmatige bevinding beschrijft de exploitatiestap, het bewijs van uitvoering en de specifieke impact voor jouw organisatie. Een geautomatiseerde bevinding kopieert de CVE-beschrijving en plakt daar een CVSS-score bij.
4. Let op attack path-analyse: Worden bevindingen in verband gebracht met elkaar? Staat er beschreven hoe een aanvaller bevinding A gebruikt als opstap naar bevinding B? Zo niet, dan ontbreekt de meest waardevolle laag van handmatig pentestwerk.
5. Tel de low-severitybevindingen: Paradoxaal genoeg is een rapport zonder low-severitybevindingen soms een slecht teken. Handmatige testers ontdekken ook kleine misconfiguraties die geautomatiseerde tools overslaan, juist omdat die in een aanvalsketen gevaarlijk kunnen zijn.

Verwacht je na deze analyse een rapport dat concreet is, omgevingsspecifiek en opgebouwd als een aanvalsverhaal? Dan is de kans groot dat er daadwerkelijk handmatig werk is verricht. Ontbreekt die diepgang, dan is het tijd om vragen te stellen.

Stel de juiste vragen aan je pentestprovider

Met je rapport als uitgangspunt ga je het gesprek aan met de pentestprovider. De antwoorden op onderstaande vragen onthullen snel of je met een echte handmatige test te maken hebt gehad. Stel deze vragen bij voorkeur vóór je een nieuwe opdracht plaatst, maar ze zijn ook waardevol als evaluatiegesprek achteraf.

1. Welke tools hebben jullie gebruikt en wat hebben jullie handmatig gedaan? Een eerlijke provider benoemt beide. Elke serieuze pentest combineert geautomatiseerde tools voor verkenning met handmatige analyse voor exploitatie en attack path-reconstructie. Een antwoord als “wij doen alles handmatig” of “wij gebruiken alleen tools” is allebei een rode vlag.
2. Hoeveel uur heeft de tester actief in mijn omgeving doorgebracht? Een volwaardige handmatige pentest van een gemiddeld netwerk of applicatie kost meerdere dagen. Als het antwoord enkele uren is voor een complexe omgeving, kloppen de getallen niet.
3. Kun je uitleggen hoe bevinding X en bevinding Y samen een aanvalsketen vormen? Kies twee bevindingen uit je rapport en vraag dit concreet. Een handmatige tester kan dit direct beantwoorden. Iemand die een scan heeft gedraaid, kan dat niet.
4. Welke bevindingen hebben jullie handmatig gevalideerd en hoe? Geautomatiseerde tools produceren false positives. Handmatige testers valideren elke bevinding. Vraag naar het validatieproces.
5. Welke certificeringen hebben de testers die mijn omgeving hebben getest? Denk aan OSCP, CEH of vergelijkbare offensieve certificeringen. Vraag specifiek wie de test heeft uitgevoerd, niet welke certificeringen het bedrijf in algemene zin bezit.

Na dit gesprek heb je een helder beeld van de werkwijze achter je rapport. Zijn de antwoorden vaag, defensief of inconsistent met wat er in het rapport staat, dan is verdere technische validatie aan te raden.

Valideer de bevindingen technisch na afloop

Als je intern technische capaciteit hebt, of toegang tot een onafhankelijke partij, kun je een steekproef van de bevindingen zelf valideren. Dit hoeft geen volledige hertest te zijn. Een gerichte validatie van drie tot vijf bevindingen geeft al veel inzicht in de betrouwbaarheid van het volledige rapport.

1. Selecteer een mix van bevindingen: Kies minimaal één high-severity en één low-severitybevinding. Zo test je zowel de kwaliteit van de kritieke als de minder urgente rapportage.
2. Controleer of de bevinding reproduceerbaar is: Kan je eigen team of een tweede partij de bevinding bevestigen op basis van de beschrijving in het rapport? Een goede handmatige bevinding bevat genoeg detail om reproduceerbaar te zijn.
3. Vergelijk de bevindingen met een geautomatiseerde scan: Voer zelf een gratis of goedkope vulnerability scan uit op hetzelfde scope. Staan alle bevindingen uit het pentestrapport ook in de geautomatiseerde scan, en staan er geen bevindingen in het rapport die alleen een handmatige tester had kunnen vinden? Dan is er reden tot twijfel. Een handmatige pentest zou bevindingen moeten bevatten die een geautomatiseerde scan mist.
4. Beoordeel de aanbevelingen op specificiteit: Generieke aanbevelingen zoals “update uw software” of “implementeer sterker wachtwoordbeleid” wijzen op geautomatiseerde output. Handmatige aanbevelingen zijn specifiek voor jouw architectuur en configuratie.

Na deze technische validatie weet je of de bevindingen standhouden. Als meerdere bevindingen niet reproduceerbaar zijn of als alle bevindingen ook door een geautomatiseerde scan worden gevonden, heb je sterke aanwijzingen dat de pentest niet de diepgang had die je betaald hebt.

Herken rode vlaggen bij twijfelachtige pentestleveranciers

Sommige signalen zijn al zichtbaar voordat je het rapport ontvangt. Leer deze rode vlaggen herkennen zodat je ze in een volgende selectieronde kunt vermijden. Zie ook de achtergrond bij offensieve security voor meer context over hoe kwalitatief pentestwerk eruitziet.

• Een onrealistisch lage prijs: Een handmatige pentest kost tijd van gekwalificeerde professionals. Als de prijs te laag is om meerdere dagen menselijk werk te dekken, is de kans groot dat er vooral tools draaien.
• Een te snel opgeleverd rapport: Een volwaardige handmatige pentest duurt meerdere dagen tot weken, afhankelijk van de scope. Een rapport dat binnen 24 uur na de startdatum wordt opgeleverd, is vrijwel zeker geautomatiseerd.
• Geen kickoff of scopegesprek: Handmatige testers willen begrijpen wat ze testen en waarom. Een provider die geen vragen stelt over je architectuur, dreigingsmodel of kritieke assets, test waarschijnlijk niet handmatig.
• Geen mogelijkheid tot toelichting: Een serieuze pentestpartij staat achter haar bevindingen en kan die mondeling toelichten. Als een provider weigert of niet in staat is om bevindingen te verduidelijken, is dat een ernstig signaal.
• Rapport bevat alleen CVSS-scores zonder context: CVSS-scores zijn nuttig, maar een handmatige pentest vertaalt die naar de specifieke impact voor jouw organisatie. Alleen scores zonder contextuele duiding wijzen op geautomatiseerde output.
• Geen aandacht voor aanvalspaden: Als het rapport geen enkele verwijzing bevat naar hoe bevindingen gecombineerd kunnen worden, ontbreekt de meest waardevolle dimensie van handmatig pentestwerk.

Met deze rode vlaggen in gedachten ben je beter uitgerust om leveranciers te beoordelen voordat je een opdracht plaatst. Zo voorkom je dat je budget gaat naar een geautomatiseerde scan die zich voordoet als een handmatige penetratietest. Voor organisaties die twijfelen over hun huidige testprogramma kan ook red teaming een waardevolle aanvulling zijn om te toetsen of een aanvaller daadwerkelijk door de verdediging heen kan breken.

Hoe Q-Cyber helpt bij het kiezen van een betrouwbare pentest

Bij Q-Cyber begrijpen we dat de markt voor penetratietesten onoverzichtelijk is. Leveranciers die geautomatiseerde scans verkopen als handmatige pentests ondermijnen het vertrouwen in de hele sector en laten organisaties met een vals gevoel van veiligheid achter. Onze aanpak is daarom gebouwd op transparantie en technische diepgang.

• Volledig handmatig uitgevoerd: Onze ethical hackers werken zoals echte aanvallers, inclusief creatieve technieken die nog niet in standaard beveiligingsplaybooks staan.
• Attack path-rapportage: We rapporteren niet alleen losse bevindingen, maar reconstrueren hoe een aanvaller meerdere zwakheden combineert tot een volledige aanvalsketen.
• Omgevingsspecifiek en concreet: Elke bevinding is voorzien van bewijs, reproductiestappen en een aanbeveling die past bij jouw specifieke architectuur.
• Onafhankelijk advies: We zijn niet gebonden aan softwarepartijen of toeleveranciers, waardoor ons advies altijd in jouw belang is.
• Optioneel: continu testen via Continuous-Q®: Voor organisaties die verder willen gaan dan een jaarlijkse momentopname bieden we een programma waarbij testen een doorlopend proces wordt in plaats van een eenmalige meting.

Wil je zeker weten dat je volgende pentest daadwerkelijk handmatig en kwalitatief is? Neem contact op en we denken graag met je mee over de juiste aanpak voor jouw organisatie.

Lees meer