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

Hoe gebruiken hackers trust relationships tussen organisaties?

Geplaatst op: 14 september 2026

Hackers beginnen zelden met het kraken van een wachtwoord of het uitbuiten van een bekende kwetsbaarheid. Steeds vaker kiezen aanvallers een slimmere route: ze misbruiken het vertrouwen dat organisaties onderling hebben opgebouwd. Een leverancier met toegang tot jouw netwerk, een MSP die systemen beheert, een partner die gegevens uitwisselt – elk van deze verbindingen is een potentieel aanvalspad. Dit fenomeen staat bekend als het misbruiken van trust relationships, en het is een van de meest effectieve technieken in het arsenaal van moderne cybercriminelen.

In deze gids leer je stap voor stap hoe je de vertrouwensrelaties binnen en rondom jouw organisatie in kaart brengt, beveiligt en actief test. Zo zorg je ervoor dat aanvallers geen gebruik kunnen maken van de verbindingen die jij bewust hebt opgebouwd.

Herken welke vertrouwensrelaties jouw organisatie blootstellen

Voordat je iets kunt beveiligen, moet je weten wat er bestaat. Veel organisaties hebben in de loop der jaren tientallen vertrouwde verbindingen opgebouwd zonder dat dit centraal is bijgehouden. Denk aan IT-leveranciers met beheertoegang, softwareleveranciers die gegevens synchroniseren, of cloudplatformen die via serviceaccounts met elkaar communiceren. Elk van deze relaties vertegenwoordigt een potentiële ingang voor een aanvaller die trust relationships wil misbruiken.

Begin met een gestructureerde inventarisatie van alle externe en interne vertrouwensrelaties. Stel jezelf bij elke verbinding de vraag: wie heeft toegang, tot wat, en waarom?

1. Breng alle externe partijen in kaart die toegang hebben tot jouw netwerk, systemen of data – inclusief MSP’s, leveranciers en cloudproviders.
2. Documenteer welke technische mechanismen die toegang mogelijk maken: VPN-tunnels, API-koppelingen, federated identity, serviceaccounts of gedeelde certificaten.
3. Identificeer welke interne accounts of systemen automatisch vertrouwen genieten op basis van groepslidmaatschap, domeinvertrouwen of configuratie.
4. Noteer voor elke relatie het toegangsniveau: leesrechten, schrijfrechten, beheertoegang of volledige controle over systemen.

Na deze stap heb je een overzicht van alle verbindingen die een aanvaller in theorie zou kunnen misbruiken. Vertrouwensrelaties die je niet kende, kun je ook niet beveiligen. Een veelgemaakte fout is dat organisaties zich richten op de bekende kwetsbaarheden, terwijl de echte risico’s schuilgaan in de verbindingen die als vanzelfsprekend worden beschouwd.

Breng het aanvalspad via trust relationships in kaart

Met je inventarisatie op orde is de volgende stap het denken zoals een aanvaller. Een hacker die een supplychainaanval uitvoert, kijkt niet naar losse kwetsbaarheden – hij kijkt naar hoe hij via vertrouwde verbindingen van de ene omgeving naar de andere kan bewegen. Dit noemen we laterale beweging via trust relationships, en het is precies de reden waarom een MSP zo’n aantrekkelijk doelwit is: wie de MSP compromitteert, heeft direct toegang tot alle klanten van die MSP.

Analyseer voor elke vertrouwde verbinding wat er mogelijk is als die verbinding wordt misbruikt. Volg daarbij de logica van een aanvaller die stap voor stap verder beweegt door jouw omgeving.

1. Stel per vertrouwde verbinding vast: wat is het ergste dat een aanvaller kan doen als hij deze verbinding overneemt?
2. Kijk of meerdere kleine vertrouwensrelaties gecombineerd kunnen worden tot een groter aanvalspad – bijvoorbeeld: leverancierstoegang via VPN, gecombineerd met een te ruim serviceaccount, gecombineerd met een cloudconfiguratie die escalatie mogelijk maakt.
3. Identificeer welke vertrouwensrelaties leiden naar kritieke systemen, gevoelige data of beheerfuncties.
4. Prioriteer de aanvalspaden op basis van impact en kans: welke combinaties zijn het meest realistisch én het meest schadelijk?

Na deze analyse heb je geen lijst met losse kwetsbaarheden, maar een beeld van werkelijke aanvalspaden. Dat is precies het verschil tussen een oppervlakkige vulnerability scan en echte offensieve security: aanvallers zien geen findings, ze zien aanvalspaden. Jij zou dat ook moeten doen.

Stel beperkingen in op vertrouwde verbindingen

Nu je weet welke vertrouwensrelaties bestaan en welke risico’s ze vertegenwoordigen, is het tijd om actie te ondernemen. Het doel is niet om alle externe verbindingen te verwijderen – dat is onrealistisch en onwenselijk. Het doel is om het principe van least privilege consequent toe te passen: elke partij krijgt alleen de toegang die strikt noodzakelijk is, niets meer.

1. Verwijder vertrouwensrelaties die niet langer actief of noodzakelijk zijn. Oude leverancierstoegang die nooit is ingetrokken, is een open deur.
2. Beperk de scope van bestaande toegang: heeft een leverancier beheertoegang tot het hele netwerk nodig, of volstaat toegang tot één specifiek systeem?
3. Implementeer tijdgebonden toegang voor externe partijen, zodat verbindingen automatisch verlopen en bewust opnieuw moeten worden aangevraagd.
4. Segmenteer je netwerk zodat een gecompromitteerde vertrouwde verbinding niet automatisch toegang geeft tot kritieke systemen – laterale beweging in het netwerk wordt zo beperkt.
5. Dwing meervoudige authenticatie af op alle externe toegangspunten, ook voor serviceaccounts en geautomatiseerde koppelingen waar mogelijk.

Controleer na het doorvoeren van deze maatregelen of de beoogde beperkingen daadwerkelijk werken. Test of een externe partij nog steeds toegang heeft tot systemen die buiten hun scope vallen. Een configuratiewijziging die op papier correct lijkt, kan in de praktijk anders uitpakken door overerving van rechten of uitzonderingen in groepsbeleid.

Monitor afwijkend gedrag op vertrouwde accounts

Technische beperkingen alleen zijn niet voldoende. Aanvallers die eenmaal toegang hebben via een vertrouwde verbinding, gedragen zich aanvankelijk vaak normaal – ze gebruiken legitieme accounts en bewegen zich binnen de grenzen van de toegekende rechten. Detectie vereist daarom dat je begrijpt wat normaal gedrag is, zodat je afwijkingen tijdig herkent.

Stel monitoring in die specifiek gericht is op vertrouwde accounts en externe verbindingen. Dit zijn de plekken waar een aanvaller het langst onopgemerkt kan blijven als er geen actieve bewaking is.

1. Definieer een baseline van normaal gedrag voor elke vertrouwde externe verbinding: op welke tijden is er activiteit, welke systemen worden benaderd, hoeveel data wordt overgedragen?
2. Stel alerts in op afwijkingen van die baseline: toegang buiten kantooruren, ongebruikelijke bestemmingen, grote hoeveelheden gedownloade data of pogingen om rechten te escaleren.
3. Log alle activiteit van externe accounts centraal en zorg dat die logs niet toegankelijk zijn voor de externe partij zelf.
4. Koppel monitoring aan een duidelijk escalatieproces: wie wordt gewaarschuwd bij een alert, en welke stappen worden dan gezet?

Een goed ingesteld monitoringsysteem verkleint de tijd tussen een succesvolle inbraak via een trust relationship en de detectie ervan. Hoe sneller je een aanvaller detecteert, hoe minder schade hij kan aanrichten. Voor organisaties die dieper willen gaan in hun detectiemogelijkheden, biedt red teaming een manier om te toetsen of jouw monitoring ook echt werkt onder realistische aanvalsomstandigheden.

Test je eigen trust relationships voordat aanvallers dat doen

De laatste en misschien wel belangrijkste stap is het actief testen van de vertrouwensrelaties die je hebt geïdentificeerd en beveiligd. Technische maatregelen en monitoring geven je vertrouwen, maar pas een echte test laat zien of de beveiliging ook standhoudt als iemand er gericht tegenaan gaat. Dit is precies waar een aanvaller anders denkt dan een beheerder: hij zoekt naar de combinaties die jij over het hoofd hebt gezien.

Plan een gerichte test van jouw trust relationships als onderdeel van een bredere pentestscope. Zorg dat de test niet alleen kijkt naar bekende kwetsbaarheden, maar expliciet de vraag stelt: kan een aanvaller via een vertrouwde verbinding verder bewegen in onze omgeving?

1. Stel een testscope op die specifiek de externe vertrouwensrelaties omvat: leverancierstoegang, MSP-verbindingen, cloudkoppelingen en federated identity.
2. Vraag de pentester om niet alleen losse kwetsbaarheden te rapporteren, maar om werkelijke aanvalspaden te demonstreren die gebruikmaken van trust relationships.
3. Verifieer na de test of de aanbevelingen zijn geïmplementeerd en test opnieuw of de aanvalspaden daadwerkelijk zijn gesloten.
4. Herhaal de test na significante wijzigingen in je omgeving: nieuwe leveranciers, cloudmigraties, reorganisaties of wijzigingen in toegangsrechten.

Een eenmalige test geeft je een momentopname. Maar je omgeving verandert continu: nieuwe leveranciers komen erbij, accounts worden aangemaakt, rechten worden aangepast. Alleen door regelmatig te testen weet je zeker dat de aanvalspaden die je vandaag hebt gesloten, morgen ook nog gesloten zijn. Meer weten over hoe continu testen werkt? Bekijk dan wat Continuous-Q® inhoudt.

Hoe Q-Cyber helpt bij het beveiligen van trust relationships

Trust relationships misbruiken is een van de meest onderschatte aanvalstechnieken van dit moment. Het vereist geen zero-dayexploit – het vereist alleen dat een aanvaller begrijpt hoe jouw organisatie is verbonden met de wereld om haar heen. Wij helpen organisaties om die verbindingen te doorgronden, te beveiligen en actief te testen.

Wat wij concreet bieden:

• Gerichte pentests op trust relationships en supplychainrisico’s, waarbij onze ethical hackers denken zoals een aanvaller en werkelijke aanvalspaden blootleggen in plaats van losse kwetsbaarheden.
• Attack path analyse, waarbij we meerdere kleine zwaktes combineren om te laten zien hoe een aanvaller van een leveranciersaccount naar kritieke systemen kan bewegen.
• Continuous-Q®, ons programma voor doorlopende offensieve security dat ervoor zorgt dat jouw beveiliging niet alleen op de testdag klopt, maar het hele jaar door.
• Onafhankelijk advies, zonder binding aan softwarepartijen of leveranciers – zodat onze aanbevelingen altijd in jouw belang zijn.

Wil je weten hoe jouw organisatie ervoor staat als het gaat om het beveiligen van vertrouwensrelaties? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer

Wat onderzoekt een hacker voordat hij een bedrijf probeert binnen te dringen?

Geplaatst op: 13 september 2026

Voordat een hacker ook maar één technisch aanvalsmiddel inzet, heeft hij al uitgebreid huiswerk gemaakt. De verkenningsfase, ook wel reconnaissance genoemd, is het fundament van vrijwel elke succesvolle cyberaanval. Een aanvaller brengt eerst in kaart hoe een organisatie is opgebouwd, wie er werken, welke systemen er aan het internet hangen en waar de zwakke plekken zitten. Hoe gedetailleerder dat beeld, hoe gerichter de aanval. In dit artikel beantwoorden we de meest gestelde vragen over wat een hacker onderzoekt voordat hij een bedrijf probeert binnen te dringen.

Welke informatie is openbaar beschikbaar over jouw bedrijf?

Verrassend veel. Zonder ook maar één systeem aan te raken kan een hacker via openbare bronnen een gedetailleerd beeld opbouwen van jouw organisatie. Denk aan domeinnamen, IP-adressen, e-mailformaten, gebruikte softwareplatforms, SSL-certificaten en zelfs interne bestandsnamen die via zoekmachines vindbaar zijn. Dit noemen we OSINT, ofwel Open Source Intelligence.

Zoekmachines indexeren meer dan de meeste mensen beseffen. Via geavanceerde zoekoperatoren, ook wel “Google dorks” genoemd, kan een aanvaller documenten, inlogpagina’s en configuratiebestanden vinden die eigenlijk niet bedoeld zijn voor publieke toegang. Daarnaast zijn er gespecialiseerde tools en databases die historische DNS-gegevens, gelekte inloggegevens en bekende kwetsbaarheden per domein bijhouden. Informatie die jij als organisatie misschien allang bent vergeten, kan voor een aanvaller nog steeds actueel en bruikbaar zijn.

Hoe gebruiken hackers OSINT om een doelwit in kaart te brengen?

OSINT-technieken stellen hackers in staat om een volledig aanvalsplan te maken zonder ook maar één alarm te activeren. Via platforms als Shodan, Censys en diverse certificaatregisters brengen aanvallers in kaart welke systemen een organisatie online heeft staan, welke softwareversies er draaien en welke subdomeinen er bestaan. Omdat dit allemaal publieke informatie is, laat de aanvaller in deze fase geen sporen achter.

Concreet kan een aanvaller via OSINT het volgende achterhalen:

• Welke cloudproviders en SaaS-platforms een organisatie gebruikt
• Welke e-mailbeveiliging (of het gebrek daaraan) er actief is
• Historische datalekken met bijbehorende wachtwoorden of e-mailadressen
• Technologiestacks via headers, cookies en metadata van websites
• Interne structuur via openbare documenten met metadata

Het gevaarlijke aan OSINT is juist dat het zo laagdrempelig is. Een aanvaller hoeft geen geavanceerde hacker te zijn om deze informatie te verzamelen. De informatie is er gewoon, en wie weet waar hij moet kijken, vindt het. Een grondige penetratietest begint daarom altijd met een externe verkenning vanuit het perspectief van een aanvaller.

Wat zoeken hackers in vacatures en social media?

Vacatures en sociale media zijn voor een hacker een goudmijn aan informatie over de interne werking van een organisatie. Uit een vacature voor een systeembeheerder kan een aanvaller afleiden welke technologieën een bedrijf gebruikt, welke beveiligingstools er aanwezig zijn en zelfs welke kennis er intern ontbreekt. Sociale media geven inzicht in de organisatiestructuur, namen van medewerkers en hun functies.

LinkedIn is daarbij bijzonder waardevol voor aanvallers. Via het netwerk van een organisatie kunnen ze zien wie er werkt, welke rollen ze bekleden en via welke externe partijen of leveranciers het bedrijf verbonden is. Dat laatste is relevant omdat aanvallers steeds vaker kiezen voor aanvallen via de supply chain: door een leverancier of MSP te compromitteren, krijgen ze indirect toegang tot de eigenlijke doelorganisatie.

Vacatureteksten bevatten bovendien regelmatig specifieke versienummers, productbenamingen of interne terminologie die een aanvaller helpt zijn aanval te preciseren. Een vacature die vraagt om ervaring met een specifieke firewallversie vertelt een aanvaller precies welk systeem hij moet onderzoeken op bekende kwetsbaarheden.

Hoe ontdekken aanvallers kwetsbare systemen aan de buitenkant?

Aanvallers scannen het volledige externe aanvalsoppervlak van een organisatie met gespecialiseerde tools die het internet systematisch doorzoeken op open poorten, actieve diensten en bekende kwetsbaarheden. Dit heet externe reconnaissance en vormt de technische tegenhanger van de informatie die via OSINT wordt verzameld. Systemen die onbedoeld aan het internet hangen, verouderde software draaien of verkeerd geconfigureerd zijn, vallen hierbij direct op.

Wat aanvallers hierbij onderscheidt van een eenvoudige vulnerability scanner, is de manier waarop ze bevindingen interpreteren. Een geautomatiseerde scanner rapporteert losse kwetsbaarheden. Een aanvaller kijkt naar de combinatie: welke systemen zijn bereikbaar, welke identiteiten en permissies hangen eraan, en hoe kunnen meerdere kleine zwaktes samen leiden tot een werkend aanvalspad? Dit onderscheid is precies waarom een handmatige penetratietest verder gaat dan een automatische scan.

Voorbeelden van wat aanvallers aan de buitenkant zoeken:

• Onbeveiligde remoteaccessdiensten zoals RDP of VPN zonder MFA
• Verlopen of zwak geconfigureerde SSL-certificaten
• Vergeten testomgevingen of subdomeinen die niet meer worden onderhouden
• Publiek toegankelijke beheerinterfaces van routers, firewalls of servers
• Cloudresources die per ongeluk publiek toegankelijk zijn gemaakt

Waarom zijn medewerkers een primair doelwit in de verkenningsfase?

Medewerkers zijn voor aanvallers interessant omdat zij de menselijke toegangspoort vormen tot systemen die technisch goed beveiligd kunnen zijn. In de verkenningsfase verzamelt een aanvaller namen, e-mailadressen, functies en gedragspatronen van medewerkers om gerichte phishing- of socialengineeringaanvallen voor te bereiden. Hoe meer een aanvaller weet over een specifieke medewerker, hoe overtuigender en gevaarlijker de aanval.

Aanvallers richten zich daarbij niet willekeurig op medewerkers. Ze zoeken specifiek naar personen met verhoogde rechten of toegang tot gevoelige systemen, zoals systeembeheerders, financiële medewerkers of directieleden. Ook nieuwe medewerkers zijn een aantrekkelijk doelwit, omdat zij minder vertrouwd zijn met interne procedures en daardoor sneller geneigd zijn op een verzoek in te gaan zonder het te verifiëren.

Daarnaast kijken aanvallers naar medewerkers die betrokken zijn bij leveranciers of externe partijen. Via een medewerker die toegang heeft tot klantomgevingen of supplychainsystemen, kan een aanvaller zijn bereik ver buiten de eigen organisatie uitbreiden. Dit maakt bewustwording en security awareness een onmisbaar onderdeel van een volwassen beveiligingsaanpak.

Hoe weet je of jouw organisatie al in het vizier van een hacker ligt?

In de meeste gevallen weet je dat niet, en dat is precies wat de verkenningsfase zo gevaarlijk maakt. Omdat een aanvaller in deze fase uitsluitend gebruikmaakt van openbare informatie en passieve technieken, laat hij vrijwel geen sporen achter in jouw systemen. Toch zijn er signalen en maatregelen die kunnen helpen om vroegtijdig te detecteren of jouw organisatie actief wordt verkend.

Enkele indicatoren om op te letten:

• Ongebruikelijk veel zoekopdrachten op jouw domeinnaam of subdomeinen in serverlogs
• Herhaalde inlogpogingen op externe diensten vanuit onbekende locaties
• Phishingmails die intern jargon of namen van collega’s bevatten, wat duidt op voorafgaand onderzoek
• Meldingen van medewerkers over verdachte LinkedIn-verbindingsverzoeken van onbekende profielen

De beste manier om te begrijpen hoe jouw organisatie eruitziet vanuit het perspectief van een aanvaller, is door zelf die blik aan te nemen. Een redteamoefening simuleert precies wat een echte aanvaller zou doen in de verkenningsfase en daarna, zodat kwetsbaarheden aan het licht komen voordat een echte aanvaller ze ontdekt.

Hoe Q-Cyber helpt bij het begrijpen van jouw aanvalsoppervlak

Wij bij Q-Cyber helpen organisaties om hun eigen kwetsbaarheid te zien door de ogen van een aanvaller. Niet met een lijst van losse bevindingen, maar met inzicht in hoe een echte aanvaller jouw organisatie zou verkennen en welke aanvalspaden daadwerkelijk gevaarlijk zijn. Concreet bieden we:

• Handmatige penetratietesten waarbij onze ethical hackers dezelfde verkennings- en aanvalstechnieken gebruiken als echte cybercriminelen
• Externe aanvalsoppervlakanalyse om te achterhalen wat er over jouw organisatie openbaar vindbaar is
• Redteamoefeningen die de volledige aanvalsketen simuleren, van OSINT tot toegang
• Continu inzicht via Continuous-Q® zodat je niet alleen op de testdag weet waar je staat, maar het hele jaar door

Een eenmalige scan of jaarlijkse test vertelt je hoe je er op dat moment voor staat. Maar aanvallers stoppen niet na die ene dag. Wil je weten hoe jouw organisatie eruitziet vanuit het perspectief van een hacker? Neem contact met ons op en we kijken samen wat de beste aanpak is voor jouw situatie.

Lees meer

Wat zegt het aantal gevonden vulnerabilities over de kwaliteit van een pentest?

Geplaatst op: 12 september 2026

Het aantal gevonden kwetsbaarheden zegt weinig tot niets over de kwaliteit van een pentest. Een pentest die tientallen lage risico’s rapporteert, kan van beduidend mindere kwaliteit zijn dan een test die slechts drie bevindingen oplevert maar daarmee een kritieke aanvalsketen blootlegt. Wat telt, is niet de hoeveelheid maar de diepgang, relevantie en bruikbaarheid van de bevindingen. In dit artikel beantwoorden we de meest gestelde vragen over hoe je pentestkwaliteit correct beoordeelt.

Betekent meer gevonden kwetsbaarheden een betere pentest?

Nee. Een hoog aantal gevonden kwetsbaarheden is geen maatstaf voor de kwaliteit van een penetratietest. Een ethical hacker die methodisch en creatief te werk gaat, kan met drie kritieke bevindingen meer waarde leveren dan een rapport vol laag-risicomeldingen. De kwaliteit zit in de relevantie van de bevindingen, niet in de kwantiteit.

Dit misverstand ontstaat doordat organisaties pentestresultaten beoordelen zoals een rapport van een auditor: hoe dikker, hoe beter. Maar een pentest is geen compliance-oefening. Het doel is inzicht in wat een echte aanvaller zou kunnen bereiken, en dat hangt af van de aanpak, de scope en de vaardigheid van de tester.

Een ervaren ethical hacker denkt als een aanvaller. Die zoekt niet naar zoveel mogelijk losse kwetsbaarheden, maar naar de combinatie van zwakke plekken die samen een aanvalsketen vormen. Eén misconfiguratie in combinatie met een verouderde authenticatiemethode kan een volledige overname van een systeem mogelijk maken. Dat is de bevinding die ertoe doet, ook als het rapport verder leeg is.

Welke factoren bepalen wél de kwaliteit van een pentest?

De kwaliteit van een penetratietest wordt bepaald door de methodiek, de scope, de ervaring van de tester en de bruikbaarheid van de rapportage. Een goede pentest legt aanvalsketens bloot, prioriteert bevindingen op werkelijk risico en levert aanbevelingen die je direct kunt omzetten in actie.

Concrete factoren om op te letten:

• Methodiek: Werkt de tester met een gestructureerde aanpak zoals OWASP, PTES of TIBER? Dat borgt volledigheid zonder creativiteit te beperken.
• Scope en diepgang: Is de test afgestemd op de werkelijke dreigingen voor jouw organisatie, of is het een generieke scan van de buitenkant?
• Handmatig werk: Worden er ook technieken ingezet die geautomatiseerde tools missen, zoals logische fouten in applicaties of social engineering?
• Kwalificaties van de tester: Beschikt de ethical hacker over relevante certificeringen en aantoonbare ervaring in jouw sector?
• Rapportage: Zijn bevindingen voorzien van duidelijke risicoclassificaties, reproductiestappen en concrete hersteladviezen?

Een pentest zonder bruikbare aanbevelingen is een duur document. De waarde zit in wat je ermee kunt doen na afloop.

Wat is het verschil tussen een vulnerability scan en een pentest?

Een vulnerability scan is een geautomatiseerde controle die bekende kwetsbaarheden vergelijkt met een database van bekende beveiligingsproblemen. Een pentest gaat verder: een menselijke tester probeert actief in te breken, combineert kwetsbaarheden en ontdekt complexe aanvalsketens die geautomatiseerde tools structureel missen.

De vulnerability scan is waardevol voor het bewaken van de basishygiëne van een IT-omgeving. Die geeft snel inzicht in verouderde software, ontbrekende patches en bekende configuratiefouten. De resultaten zijn echter beperkt tot wat al bekend is en wat een tool herkent.

Een pentest voegt de menselijke factor toe. Een ethical hacker denkt buiten de gebaande paden, combineert informatie uit verschillende bronnen en test ook scenario’s die niet in een standaard playbook staan. Denk aan het misbruiken van een interne vertrouwensrelatie tussen systemen, of het omzeilen van authenticatie via een onverwachte applicatieflow.

Kort samengevat: een vulnerability scan vertelt je wat er mis is. Een pentest vertelt je wat een aanvaller daarmee zou kunnen doen.

Hoe beoordeel je of een pentestrapport betrouwbaar is?

Een betrouwbaar pentestrapport bevat reproduceerbare bevindingen met duidelijke risicoclassificaties, technische onderbouwing en concrete herstelstappen. Als een rapport alleen een lijst met CVE-nummers bevat zonder context of aanbeveling, is het waarschijnlijk grotendeels geautomatiseerd gegenereerd en mist het de diepgang van een echte penetratietest.

Let bij het beoordelen van een pentestrapport op de volgende kenmerken:

1. Executive summary: Is er een samenvatting die ook voor niet-technische lezers begrijpelijk is, met een helder beeld van het werkelijke risico?
2. Reproductiestappen: Legt het rapport per bevinding uit hoe de kwetsbaarheid gevonden en misbruikt is? Dit bewijst dat de tester het daadwerkelijk heeft getest.
3. Risicoprioritering: Worden bevindingen ingedeeld op werkelijk risico voor jouw organisatie, niet alleen op technische ernst?
4. Aanbevelingen: Zijn de herstelstappen specifiek en uitvoerbaar, of zijn het generieke adviezen die je ook via een zoekmachine had kunnen vinden?
5. Scopeverantwoording: Beschrijft het rapport wat er wel en niet getest is, en waarom?

Een goed rapport is een werkinstructie voor je technisch team, geen bewijs voor een auditor.

Wanneer is een jaarlijkse pentest niet meer voldoende?

Een jaarlijkse pentest is niet meer voldoende wanneer je organisatie regelmatig wijzigingen doorvoert in systemen, applicaties of infrastructuur, of wanneer je een verhoogd risicoprofiel hebt. In die gevallen is een momentopname eens per jaar een foto van een bewegend doelwit: de realiteit verandert sneller dan de testfrequentie bijhoudt.

Cybercriminelen ontwikkelen het hele jaar door nieuwe aanvalstechnieken. Een kwetsbaarheid die in februari wordt ontdekt, is in maart al actief in gebruik bij aanvallers, terwijl jouw volgende pentest pas in december gepland staat. Voor organisaties die verantwoordelijkheid dragen voor de beveiliging van anderen, zoals managed service providers, is dit risico extra groot. Het compromitteren van één MSP geeft een aanvaller direct toegang tot alle klanten van die organisatie.

Situaties waarbij een jaarlijkse pentest onvoldoende is:

• Je voert meerdere keren per jaar significante wijzigingen door in je IT-omgeving
• Je verwerkt gevoelige klant- of persoonsgegevens op grote schaal
• Je bent een MSP of levert diensten aan kritieke sectoren
• Je valt onder regelgeving zoals NIS2 die continue weerbaarheid vereist
• Je hebt eerder een incident gehad en wilt structureel zicht houden op je aanvalsoppervlak

In die gevallen biedt continu testen een realistischer beeld van de werkelijke beveiliging dan een jaarlijkse meting ooit kan geven.

Hoe Q-Cyber helpt bij het beoordelen en verbeteren van je pentestkwaliteit

Bij Q-Cyber voeren gecertificeerde ethical hackers handmatige penetratietests uit die verder gaan dan geautomatiseerde scans. We denken als een aanvaller, combineren kwetsbaarheden tot realistische aanvalsketens en leveren een rapport dat je direct kunt omzetten in actie.

Wat je van ons kunt verwachten:

• Handmatige pentests uitgevoerd door ervaren ethical hackers met aantoonbare certificeringen
• Heldere rapportage met risicoprioritering, reproductiestappen en concrete hersteladviezen voor je technisch team
• Onafhankelijk advies zonder binding aan softwarepartijen of toeleveranciers
• Optie voor continue testing via ons Continuous-Q®-programma, speciaal ontwikkeld voor organisaties die weten dat een jaarlijkse meting niet volstaat
• Red team-oefeningen voor organisaties die hun weerbaarheid willen testen tegen geavanceerde, realistische aanvalsscenario’s via red teaming

Wil je weten wat een pentest bij Q-Cyber oplevert voor jouw organisatie? Neem contact met ons op en we bespreken samen welke aanpak het beste past bij jouw situatie en risicoprofiel.

Lees meer

Hoe herken je een oppervlakkige pentest?

Geplaatst op: 11 september 2026

Niet elke pentest is gelijk. Sommige testen bieden echte inzichten in hoe een aanvaller jouw organisatie zou benaderen, terwijl andere niet veel meer zijn dan een geautomatiseerde scan met een mooi rapport eromheen. Het probleem is dat je dat verschil van buitenaf nauwelijks kunt zien, totdat je weet waar je op moet letten.

In deze gids leer je stap voor stap hoe je een oppervlakkige pentest herkent, nog voordat de eerste regel code is geschreven. Je leert welke vragen je moet stellen, hoe je een rapport beoordeelt op echte diepgang, en waarom de kwaliteit van een pentest bepalend is voor of jouw organisatie werkelijk beschermd is.

Signalen vóór de pentest al begint

De kwaliteit van een pentest kun je al inschatten voordat de uitvoering start. Een serieuze pentestprovider investeert tijd in de voorbereiding, stelt gerichte vragen en wil de context van jouw organisatie begrijpen. Ontbreekt die fase, dan is dat een eerste waarschuwingssignaal.

Let op de volgende rode vlaggen in de aanloopfase:

• De provider vraagt weinig tot geen informatie over jouw IT-omgeving, applicaties of cloudinfrastructuur
• Er wordt direct een standaardofferte gestuurd zonder intakegesprek of scopebepaling
• De doorlooptijd is opvallend kort voor de omvang van jouw omgeving
• Er wordt niet gevraagd naar recente wijzigingen, zoals nieuwe cloudresources, applicaties of gebruikersaccounts
• De provider kan niet uitleggen welke methodologie zij hanteren

Controleer ook of de provider gecertificeerde ethical hackers inzet. Certificeringen als OSCP, CEH of CREST zijn een indicatie van vakmanschap. Ontbreekt elke vermelding van kwalificaties, dan is dat een reden om door te vragen. Een goede voorbereiding is geen luxe, het is een vereiste voor een test die werkelijk iets zegt over jouw risicoprofiel.

Controleer de methodologie en scope van de uitvoering

Vraag expliciet naar de methodologie voordat je akkoord gaat. Een oppervlakkige pentest steunt zwaar op geautomatiseerde tools die bekende kwetsbaarheden scannen, ook wel CVE-scanning genoemd. Dat is nuttig als basischeck, maar het is geen volwaardige penetratietest. Een echte pentest combineert geautomatiseerde tools met handmatig, creatief onderzoek door een ervaren tester.

Beoordeel de scope en methodologie aan de hand van deze punten:

1. Vraag of de test handmatig wordt uitgevoerd, geautomatiseerd, of een combinatie van beide. Een volledig geautomatiseerde test is vrijwel altijd onvoldoende.
2. Controleer of de scope expliciet is vastgelegd: welke systemen, netwerken, applicaties en cloudresources worden getest?
3. Vraag of de tester ook kijkt naar identiteiten, permissies en configuratiefouten, niet alleen naar bekende exploits.
4. Vraag of er aandacht is voor aanvalspaden, dus de combinatie van meerdere kleine zwaktes die samen tot een groot risico leiden.
5. Vraag of de tester de aanpak van een echte aanvaller nabootst, inclusief verkenning van organisatiestructuur en leveranciersketens.

Een goede provider kan je uitleggen hoe zij denken als een aanvaller. Aanvallers beginnen namelijk niet met het afvuren van exploits. Ze verkennen eerst de organisatiestructuur, identificeren welke identiteiten en permissies bestaan, en zoeken naar gaten tussen beveiligingsmaatregelen. Een test die dat proces niet nabootst, geeft je een incompleet beeld van je werkelijke kwetsbaarheid. Meer weten over hoe aanvallers te werk gaan? Bekijk onze uitleg over red teaming.

Beoordeel het rapport op diepgang en bruikbaarheid

Het rapport is het tastbare eindproduct van een pentest. Hier zie je direct of de test oppervlakkig was of werkelijk diepgang had. Een lijst met CVE-nummers en CVSS-scores zegt weinig als er geen context bij staat over wat die kwetsbaarheden betekenen voor jouw specifieke omgeving.

Beoordeel een pentestrapport op de volgende criteria:

• Contextualiteit: Worden bevindingen vertaald naar jouw specifieke situatie, of zijn het generieke beschrijvingen die ook voor elke andere organisatie hadden kunnen gelden?
• Aanvalspaden: Worden losse kwetsbaarheden ook in samenhang beschreven? Een lage SSRF-kwetsbaarheid die, gecombineerd met een verkeerde Azure RBAC-configuratie, toegang geeft tot een Key Vault, is kritiek, ook al lijkt elke bevinding op zichzelf onschuldig.
• Prioritering: Maakt het rapport duidelijk wat je als eerste moet aanpakken en waarom?
• Concrete aanbevelingen: Staan er specifieke, uitvoerbare herstelstappen bij elke bevinding?
• Technisch én begrijpelijk: Is het rapport leesbaar voor zowel een technische beheerder als een manager die beslissingen moet nemen?

Een rapport dat alleen een lijst met kwetsbaarheden bevat zonder aanvalspaden, prioritering of concrete aanbevelingen, is een teken van een oppervlakkige aanpak. Aanvallers zien geen losse bevindingen, ze zien aanvalspaden. Een goed rapport doet hetzelfde.

Stel deze vragen aan je pentestprovider

Met de juiste vragen kun je snel inschatten of een provider serieus werk levert. Gebruik onderstaande vragen als checklist tijdens het selectieproces. Een betrouwbare provider geeft concrete, specifieke antwoorden. Vage of uitwijkende antwoorden zijn een waarschuwingssignaal.

1. Welke methodologie hanteren jullie en hoe verhoudt die zich tot frameworks zoals OWASP of PTES?
2. Voeren jullie de test handmatig uit, of voornamelijk met geautomatiseerde tools?
3. Kijken jullie ook naar aanvalspaden, niet alleen naar individuele kwetsbaarheden?
4. Hoe gaan jullie om met gevoelige data die tijdens de test wordt aangetroffen?
5. Wat zijn de kwalificaties van de tester die mijn omgeving test?
6. Wat ontvang ik na afloop en hoe helpen jullie mij de bevindingen te prioriteren?
7. Wat adviseren jullie als mijn IT-omgeving na de test significant verandert?

Die laatste vraag is bewust opgenomen. Een provider die geen antwoord heeft op wat er na de test gebeurt, denkt niet verder dan de opdracht. Maar jouw omgeving verandert continu: nieuwe applicaties, nieuwe accounts, nieuwe cloudresources. De vraag of je na de test nog veilig bent, is minstens zo belangrijk als de test zelf.

Waarom continue testing een jaarlijkse pentest overtreft

Een jaarlijkse pentest is vergelijkbaar met een foto van een bewegend doelwit. Op het moment van de test weet je wat er kwetsbaar is. Maar daarna worden applicaties aangepast, permissies gewijzigd en nieuwe kwetsbaarheden ontdekt door aanvallers die 365 dagen per jaar actief zijn. De vraag is niet of jouw omgeving verandert, maar hoe snel.

Het fundamentele probleem met een eenmalige test is dat de geldigheid ervan direct na afloop begint te vervallen. Overweeg wat er in de maanden na een pentest kan veranderen:

• Nieuwe cloudresources worden aangemaakt met standaardconfiguraties
• Medewerkers krijgen ruimere permissies dan nodig
• Softwareleveranciers brengen updates uit met nieuwe kwetsbaarheden
• Aanvallers ontdekken nieuwe technieken die nog niet bestonden tijdens jouw test

Continue penetratietesting lost dit probleem op door security te behandelen als een levend proces in plaats van een jaarlijkse afvinkpost. Daarmee verschuif je van een statische verdediging naar een dynamische weerbaarheid waarbij je continu weet waar je staat. Meer over deze aanpak lees je op de pagina over Continuous-Q.

De pentestkwaliteit herkennen begint met begrijpen dat een goede test nooit een eindpunt is. Het is een meting in een doorlopend proces van testen, verbeteren en opnieuw testen.

Hoe Q-Cyber helpt bij het uitvoeren van een grondige pentest

Bij Q-Cyber voeren we pentesten uit zoals een echte aanvaller te werk gaat, niet zoals een geautomatiseerde scanner. Onze gecertificeerde ethical hackers combineren technische diepgang met het denken in aanvalspaden, zodat je niet alleen een lijst met kwetsbaarheden krijgt, maar werkelijk begrijpt welke risico’s er in jouw omgeving spelen.

Dit is wat je van ons kunt verwachten:

• Handmatige uitvoering door gecertificeerde ethical hackers die denken zoals aanvallers
• Drie lagen van onderzoek: bekende kwetsbaarheden, individuele zwaktes en gecorreleerde aanvalspaden
• Helder rapport met concrete prioriteiten en uitvoerbare aanbevelingen
• Onafhankelijk advies zonder afhankelijkheid van softwarepartijen of toeleveranciers
• Optionele doorgroei naar Continuous-Q voor doorlopende beveiliging na de eerste meting

Wil je weten of jouw huidige pentestaanpak werkelijk beschermt, of wil je een grondige test laten uitvoeren? Neem contact met ons op en we kijken samen wat de beste aanpak is voor jouw organisatie.

Lees meer

Waarom betekent minder gevonden kwetsbaarheden niet automatisch dat je veiliger bent?

Geplaatst op: 10 september 2026

Je hebt net een beveiligingsscan laten uitvoeren. Het rapport komt binnen en je ziet een beperkt aantal kwetsbaarheden, misschien zelfs minder dan vorig jaar. Opgelucht adem je uit. Maar klopt dat gevoel van geruststelling wel? In dit artikel leggen we uit waarom het aantal gevonden kwetsbaarheden weinig zegt over hoe veilig je organisatie werkelijk is, en hoe je beveiliging wél op een betrouwbare manier kunt meten.

We bouwen de uitleg stap voor stap op: van wat een scan eigenlijk meet, tot hoe aanvallers denken, en wat een zinvolle beveiligingsmeting onderscheidt van een die je een vals gevoel van veiligheid geeft.

Wat zegt een kwetsbaarheidsscan eigenlijk over je beveiliging?

Een kwetsbaarheidsscan is een geautomatiseerd hulpmiddel dat bekende technische zwakke plekken in je systemen opspoort. Denk aan verouderde software, ontbrekende patches of bekende configuratiefouten die zijn vastgelegd in publieke databases zoals de CVE-lijst.

Wat zo’n scan goed doet, is snel en breed controleren of je IT-omgeving voldoet aan basishygiëne. Maar daar stopt het ook. Een vulnerability scan vergelijkt je systemen met een lijst van bekende problemen. Wat niet op die lijst staat, wordt ook niet gevonden. En dat is precies waar de beperking zit.

Stel je voor dat je huis wordt gecontroleerd op bekende inbraakroutes: een kapot slot, een openstaand raam, een defecte deur. Als die allemaal in orde zijn, krijg je een groen rapport. Maar niemand heeft gecontroleerd of de achterdeur openstaat, of dat een sleutel onder de mat ligt. Een beveiligingsscan werkt op vergelijkbare wijze: het is een momentopname van bekende risico’s, geen volledig beeld van je werkelijke kwetsbaarheid.

Hoe scanresultaten een vals gevoel van veiligheid creëren

Het gevaar van minder gevonden kwetsbaarheden is dat het een succesgevoel wekt dat niet altijd terecht is. Er zijn meerdere redenen waarom de uitkomst van een beveiligingsscan misleidend kan zijn.

Ten eerste meet een scan alleen wat hij kan zien. Misconfiguraties in cloudplatformen zoals Azure of AWS, te ruime gebruikersrechten of zwakke identiteitsinstellingen worden door veel geautomatiseerde tools niet of nauwelijks opgepikt. Toch zijn dit precies de zwakke plekken die aanvallers actief misbruiken.

Ten tweede verandert je IT-omgeving voortdurend. Na elke applicatie-update, elke nieuwe cloudresource of elke gewijzigde gebruikerspermissie kan een nieuwe kwetsbaarheid ontstaan. De penetratietestresultaten van drie maanden geleden zeggen niets over de veiligheid van vandaag. Een jaarlijkse scan is daarmee vergelijkbaar met een foto van een bewegend doelwit: op het moment van de foto klopt het beeld, maar een seconde later is de situatie al veranderd.

Ten derde worden bevindingen te vaak los van elkaar beoordeeld. Een lage prioriteit krijgt weinig aandacht, terwijl diezelfde bevinding in combinatie met andere kleine zwaktes een serieuze aanvalsroute kan vormen. Dat is een cruciaal inzicht dat we in de volgende secties verder uitwerken.

Welke factoren bepalen hoeveel kwetsbaarheden er worden gevonden?

Het aantal kwetsbaarheden in een scanrapport is geen objectieve maatstaf voor veiligheid. Het is een getal dat sterk afhankelijk is van hoe en wat er wordt getest. Drie factoren spelen hierbij een grote rol.

De scope van de scan

Hoe breder de scope, hoe meer er gevonden kan worden. Een scan die alleen de buitenkant van je netwerk bekijkt, mist alles wat zich intern afspeelt. Een scan die ook cloudconfiguraties, applicatielagen en gebruikersrechten meeneemt, levert een veel rijker beeld op.

De methode: geautomatiseerd versus handmatig

Geautomatiseerde tools zijn snel en consistent, maar ze volgen vaste patronen. Een ervaren ethical hacker denkt creatief en combineert bevindingen op manieren die een tool nooit zou overwegen. Juist die combinaties leiden tot de meest gevaarlijke aanvalsroutes.

De kwaliteit van de interpretatie

Twee organisaties kunnen een identiek scanrapport krijgen en toch een heel ander risicoprofiel hebben. De context bepaalt de ernst: een kwetsbaarheid in een systeem zonder gevoelige data is anders dan dezelfde kwetsbaarheid in een systeem dat toegang geeft tot je volledige klantendatabase. Zonder die interpretatie is een getal nietszeggend.

Waarom aanvallers denken in kansen, niet in lijstjes

Hier zit misschien wel het grootste conceptuele verschil tussen hoe organisaties beveiliging meten en hoe aanvallers beveiliging benaderen. Aanvallers werken niet met een checklist van bekende kwetsbaarheden. Ze zoeken naar aanvalspaden: een combinatie van stappen die samen leiden naar hun doel.

Een concreet voorbeeld maakt dit duidelijk. Stel dat een scan drie bevindingen oplevert die elk op zichzelf als “laag risico” worden geclassificeerd:

• Een server is kwetsbaar voor een SSRF-aanval (Server-Side Request Forgery)
• Die server heeft een managed identity met te ruime rechten in Azure
• Via die identity is toegang mogelijk tot een Key Vault met gevoelige sleutels

Los van elkaar lijkt geen van deze bevindingen kritiek. Maar een aanvaller die deze drie stappen combineert, kan zo toegang krijgen tot de volledige Azure-omgeving. Aanvallers zien geen losse bevindingen. Ze zien aanvalspaden. Dit is precies wat een goede redteamaanpak blootlegt: niet alleen individuele zwaktes, maar de ketens die ze met elkaar vormen.

Dit verklaart ook waarom een rapport met weinig gevonden kwetsbaarheden gevaarlijk geruststellend kan zijn. Als de scan alleen naar losse bevindingen kijkt en niet naar hoe ze samenhangen, blijven de gevaarlijkste aanvalsroutes onzichtbaar.

Hoe meet je beveiliging wél betrouwbaar?

Voortbouwend op het inzicht dat aanvallers in aanvalspaden denken en niet in lijstjes, is de logische conclusie dat betrouwbare beveiligingsmeting ook zo moet werken. Dat vraagt om een andere aanpak dan de traditionele jaarlijkse scan.

Een betrouwbare meting van cybersecuritykwetsbaarheden combineert drie elementen:

1. Diepte: Niet alleen bekende CVE’s controleren, maar ook misconfiguraties, identiteitszwaktes en applicatie-instellingen onderzoeken.
2. Aanvallersperspectief: Testen zoals een echte aanvaller zou doen, inclusief het combineren van kleine zwaktes tot een aanvalspad.
3. Continuïteit: Beseffen dat een momentopname veroudert zodra je IT-omgeving verandert, en testen daarom structureel inbedden in je beveiligingsstrategie.

Een aanpak zoals continue penetratietesten sluit hier direct op aan: in plaats van één jaarlijkse meting wordt beveiliging doorlopend getoetst. Zo weet je niet alleen dat je op één dag bent getest, maar dat je het hele jaar door inzicht hebt in je werkelijke kwetsbaarheid.

Het getal in een scanrapport is daarmee niet het einddoel. Het gaat om de vraag: wat kan een aanvaller doen met wat er is gevonden? Die vraag beantwoorden vraagt om menselijk redeneren, context en een aanvallersmentaliteit die geen geautomatiseerd hulpmiddel kan vervangen.

Hoe Q-Cyber helpt met het meten van echte kwetsbaarheid

Bij Q-Cyber geloven we dat je niet kunt verdedigen wat je niet test, en dat testen meer is dan een lijst met bevindingen aanleveren. Onze aanpak is gericht op het blootleggen van wat een aanvaller werkelijk kan bereiken, niet op het produceren van een rapport dat op papier goed oogt.

Wat we concreet bieden:

• Handmatige pentesten uitgevoerd door gecertificeerde ethical hackers die denken zoals aanvallers en aanvalspaden in kaart brengen, niet alleen losse bevindingen.
• Attack path-analyse waarbij we kleine kwetsbaarheden in samenhang beoordelen en laten zien wat er werkelijk op het spel staat.
• Continuous-Q®, ons programma voor doorlopende penetratietesten, zodat je beveiliging niet veroudert zodra je omgeving verandert.
• Onafhankelijk advies zonder afhankelijkheid van softwarepartijen, zodat onze bevindingen altijd in jouw belang zijn.

Wil je weten wat een aanvaller werkelijk bij jouw organisatie kan bereiken? Neem contact met ons op en ontdek hoe een eerlijke meting eruitziet.

Lees meer

Welke openbare informatie gebruiken hackers om een aanval voor te bereiden?

Geplaatst op: 9 september 2026

Hackers gebruiken openbare informatie om een aanval voor te bereiden door via zogenoemde OSINT-technieken (Open Source Intelligence) zoveel mogelijk te weten te komen over een doelwit voordat er ook maar één technische aanval wordt ingezet. Denk aan bedrijfsstructuren, medewerkersnamen, technische configuraties en sociale media. Hoe meer een hacker weet, hoe gerichter en effectiever de aanval kan zijn. In dit artikel beantwoorden we de belangrijkste vragen over hoe hackers informatie verzamelen en wat je daartegen kunt doen.

Welke stappen zetten hackers vóór een aanval?

Voordat een hacker een technische aanval uitvoert, doorloopt hij een uitgebreide verkenningsfase. In die fase probeert hij zoveel mogelijk te begrijpen over hoe een organisatie is ingericht: welke systemen draaien er, wie heeft er toegang, welke leveranciers zijn betrokken en waar zitten de zwakke plekken. Pas als dat beeld compleet genoeg is, kiest een aanvaller zijn aanvalspad.

Veel mensen denken dat een cyberaanval begint met het afvuren van exploits of het raden van wachtwoorden. In de praktijk begint een aanval bijna altijd met informatie verzamelen. Een aanvaller die goed voorbereid is, heeft al lang voordat hij actie onderneemt een helder beeld van de organisatiestructuur, de gebruikte technologie en de mensen die er werken.

Die verkenningsfase bestaat grofweg uit drie stappen:

1. Passieve verkenning: het verzamelen van openbare informatie zonder direct contact met de doelorganisatie.
2. Actieve verkenning: het direct bevragen van systemen, zoals het scannen van open poorten of het opzoeken van DNS-records.
3. Analyse en aanvalsplanning: het combineren van gevonden informatie tot een concreet aanvalspad, waarbij meerdere kleine zwaktes samen worden gebruikt.

Dit laatste punt is cruciaal. Een aanvaller kijkt niet naar losse kwetsbaarheden, maar naar hoe die samen een route vormen naar waardevolle systemen of data. Dat maakt de verkenningsfase zo gevaarlijk: de schade begint al voordat er ook maar iets technisch is aangevallen.

Welke openbare bronnen gebruiken hackers om informatie te verzamelen?

Hackers gebruiken een breed scala aan openbaar toegankelijke bronnen om informatie over een doelwit te verzamelen. Dit heet Open Source Intelligence, of OSINT. De meest gebruikte bronnen zijn zoekmachines, bedrijfsregisters, vacaturesites, technische databases en sociale media. Al deze bronnen zijn legaal toegankelijk en bevatten meer gevoelige informatie dan de meeste organisaties beseffen.

Enkele concrete voorbeelden van openbare bronnen die hackers actief inzetten:

• Zoekmachines: Via geavanceerde zoekopdrachten (ook wel “Google dorking” genoemd) kunnen hackers publiek toegankelijke bestanden, loginpagina’s en configuratiedocumenten vinden die eigenlijk niet bedoeld zijn voor extern publiek.
• Bedrijfsregisters en de Kamer van Koophandel: Hier staan namen van bestuurders, vestigingsadressen en soms ook informatie over dochterondernemingen of samenwerkingsverbanden.
• Vacaturesites: Vacatures verraden welke technologie een organisatie gebruikt. Een advertentie voor een “Azure DevOps engineer” of een “Fortinet-beheerder” vertelt een aanvaller direct welke systemen er draaien.
• WHOIS- en DNS-databases: Hiermee achterhalen hackers wie een domein beheert, welke mailservers worden gebruikt en welke subdomeinstructuur een organisatie heeft.
• Shodan: Een zoekmachine voor verbonden apparaten. Hackers gebruiken Shodan om open poorten, verouderde software en onbeveiligde apparaten te vinden die direct via het internet bereikbaar zijn.

Voor organisaties die willen weten hoe zichtbaar ze zijn voor aanvallers, biedt een cyber research-aanpak inzicht in welke informatie er over hen publiek beschikbaar is.

Hoe gebruiken hackers sociale media als aanvalsinformatie?

Sociale media zijn voor hackers een rijke bron van persoonlijke en organisatorische informatie. Via platforms als LinkedIn, X (voorheen Twitter) en Facebook verzamelen aanvallers namen van medewerkers, functietitels, interne projecten, gebruikte tools en soms zelfs reisschema’s van sleutelfiguren. Die informatie wordt vervolgens ingezet voor gerichte phishingaanvallen of social engineering.

LinkedIn is daarbij het meest waardevolle platform voor aanvallers. Een volledig ingevuld LinkedIn-profiel van een medewerker vertelt een hacker:

• Welke rol iemand heeft en hoeveel toegang hij waarschijnlijk heeft tot systemen.
• Welke collega’s of leidinggevenden er zijn, handig voor het nabootsen van interne communicatie.
• Welke tools en technologieën iemand dagelijks gebruikt.
• Of iemand recent van functie is gewisseld, wat kan wijzen op tijdelijk ruimere toegangsrechten.

Maar ook ogenschijnlijk onschuldige berichten op sociale media kunnen informatie lekken. Een foto van een kantoorborrel waarop een whiteboard met projectinformatie zichtbaar is, een tweet over een nieuwe cloudmigratie of een bericht over een storing geven aanvallers waardevolle context. Socialengineeringaanvallen, waarbij hackers zich voordoen als collega’s of leveranciers, zijn veel effectiever als ze zijn gebaseerd op echte, geloofwaardige details.

Wat kunnen hackers ontdekken via technische openbare data?

Via technische openbare data kunnen hackers ontdekken welke systemen, software en configuraties een organisatie gebruikt, welke kwetsbaarheden daarin bekend zijn en hoe de IT-infrastructuur is opgebouwd. Dit gaat verder dan wat de meeste organisaties verwachten: zelfs foutmeldingen, certificaten en e-mailheaders bevatten bruikbare informatie voor een aanvaller.

Concrete voorbeelden van wat hackers via technische bronnen kunnen achterhalen:

• SSL-certificaten: Via diensten als crt.sh zijn alle uitgegeven certificaten voor een domein openbaar. Hiermee ontdekken aanvallers subdomeinstructuren die niet bedoeld zijn voor extern gebruik, zoals testomgevingen of interne applicaties.
• E-mailheaders en SPF/DKIM-records: Deze vertellen een aanvaller hoe e-mail wordt afgehandeld en of een domein kwetsbaar is voor e-mailspoofing.
• Verouderde software en bekende CVE’s: Als een hacker weet welke softwareversie een organisatie gebruikt, kan hij in publieke databases opzoeken welke bekende kwetsbaarheden daarvoor bestaan.
• Code op GitHub of GitLab: Medewerkers die per ongeluk API-sleutels, wachtwoorden of interne configuraties in publieke repositories plaatsen, geven aanvallers directe toegang.

Wat hackers met al deze losse stukjes informatie doen, is ze combineren tot een aanvalspad. Eén open poort hoeft geen probleem te zijn. Maar een open poort, gecombineerd met een verouderde softwareversie, een bekende CVE en een zwak geconfigureerde identiteit, kan samen leiden tot volledige toegang tot cloudresources. Dit is precies waarom een grondige pentest verder gaat dan het controleren van losse kwetsbaarheden.

Hoe bescherm je je organisatie tegen OSINT-gebaseerde aanvallen?

Je beschermt je organisatie tegen OSINT-gebaseerde aanvallen door eerst te begrijpen welke informatie er over jou openbaar beschikbaar is, die informatie waar mogelijk te beperken en medewerkers bewust te maken van wat ze online delen. Aanvallers gebruiken openbare informatie als startpunt, dus minder zichtbaarheid betekent een kleiner aanvalsoppervlak.

Concrete maatregelen die organisaties kunnen nemen:

• Voer een OSINT-audit uit op jezelf: Zoek actief naar welke informatie er over jouw organisatie publiek beschikbaar is. Kijk naar domeinen, certificaten, vacatures en sociale media. Wat een aanvaller kan vinden, kun jij ook vinden.
• Beperk technische zichtbaarheid: Zorg dat testomgevingen, interne applicaties en beheerinterfaces niet publiek bereikbaar zijn. Controleer regelmatig welke poorten en services extern zichtbaar zijn.
• Train medewerkers: Maak medewerkers bewust van wat ze op LinkedIn en andere sociale media delen over interne systemen, projecten en collega’s. Bewustwording is een van de effectiefste verdedigingen tegen social engineering.
• Controleer GitHub en andere repositories: Stel automatische scans in die waarschuwen als er API-sleutels of interne configuraties in publieke code terechtkomen.
• Denk vanuit de aanvaller: Vraag jezelf af welk aanvalspad een hacker zou kiezen op basis van de informatie die nu al openbaar is. Die denkwijze helpt om blinde vlekken te ontdekken die technische tools missen.

Belangrijk om te beseffen: het gaat niet alleen om het dichten van technische gaten. Een aanvaller die via red teaming wordt nagebootst, laat zien hoe ver iemand kan komen met alleen openbare informatie als startpunt. Dat inzicht is onmisbaar om te begrijpen waar de echte risico’s zitten.

Hoe Q-Cyber helpt bij bescherming tegen OSINT-aanvallen

Bij Q-Cyber begrijpen we dat een aanval zelden begint met een technische exploit, maar vrijwel altijd met informatie. Daarom helpen we organisaties niet alleen met het testen van systemen, maar ook met het begrijpen van wat er over hen openbaar beschikbaar is en hoe een aanvaller dat zou gebruiken.

Wat we concreet voor je kunnen doen:

• Pentesten: Onze ethical hackers voeren een gesimuleerde aanval uit waarbij ze dezelfde verkennings- en OSINT-technieken gebruiken als echte aanvallers, zodat je ziet waar de werkelijke risico’s zitten.
• Red teaming: We simuleren een volledige aanval inclusief de verkenningsfase, social engineering en technische exploitatie, om te testen hoe ver een aanvaller komt met openbare informatie als startpunt.
• Continuous-Q®: Via ons Continuous-Q-programma houden we je omgeving continu in de gaten, zodat nieuwe kwetsbaarheden of veranderingen in je aanvalsoppervlak direct worden opgemerkt, niet pas bij de volgende jaarlijkse test.
• Pragmatisch en onafhankelijk advies: We geven concrete aanbevelingen zonder afhankelijkheid van softwarepartijen, zodat je altijd het eerlijke verhaal krijgt.

Wil je weten wat er over jouw organisatie openbaar beschikbaar is en hoe een aanvaller dat zou gebruiken? Neem contact met ons op voor een vrijblijvend gesprek.

Lees meer