Terug naar overzicht

Van LinkedIn-profiel tot volledige gebruikerslijst: hoe ver je komt zonder ooit één regel exploit-code te schrijven

6 oktober 2026

Als mensen aan een "hack" denken, denken ze vaak aan een geavanceerde kwetsbaarheid, ingewikkelde hacktools, of een kwaadaardige bijlage die iemand per ongeluk opent. Maar in de praktijk van onze pentestopdrachten is dat patroon meestal een stuk minder spannend, en juist dat maakt het zo confronterend voor de organisaties die we testen. Er is geen zero-day of malware voor nodig. Meestal komen we niet verder dan wat openbare informatie, een beetje
geduld, en één account dat net niet goed genoeg beveiligd was. Dit verhaal is geen letterlijke weergave van één specifieke klant, maar een optelsom van dingen die we het afgelopen jaar bij meerdere organisaties zijn tegengekomen.

Fase 1: Wat je bedrijf allemaal al over zichzelf vertelt

Voordat we ook maar íets technisch proberen, kijken we eerst naar wat er al publiekelijk over de organisatie bekend is. LinkedIn is daarbij goud. Functietitels, teamstructuren, wie er recent is aangenomen bij de IT-afdeling, welke systemen in vacatureteksten worden genoemd ("ervaring met Exchange Online en Entra ID gewenst"), het staat er allemaal gewoon. Combineer dat met de bedrijfswebsite, een blik op hoe e-mailadressen zijn opgebouwd, en eventuele oude
datalekken waarin wachtwoordpatronen van medewerkers zichtbaar zijn geworden, en je hebt binnen een paar uur een verrassend compleet beeld van wie er werkt, hoe accounts waarschijnlijk heten, en welke systemen er in gebruik zijn.

Dit kost geen enkele techniek, alleen tijd en een systematische aanpak. En dat is precies waarom het zo goed werkt, want er is niets om tegen te "patchen".

Fase 2: Testen op basis van herkenbare patronen

Met een lijst van waarschijnlijke gebruikersnamen gaan we aan de slag met password spraying. Niet door duizenden willekeurige wachtwoorden op één account te proberen, want dat valt op en loopt vaak vast op account lockout. In plaats daarvan proberen we een klein aantal voorspelbare wachtwoorden op heel veel accounts tegelijk, precies één poging per account, zodat het onder de radar blijft. Denk aan het klassieke "Welkom01", een seizoen met een
uitroepteken erachter zoals "Zomer2026!" of "Winter2025!", de huidige maand, of een variant op de bedrijfsnaam met een jaartal erachter. Het klinkt bijna te simpel om te werken, maar op een organisatie met honderden medewerkers staat er vrijwel altijd wel iemand met precies zo'n wachtwoord. Service en systeemaccounts zijn daarbij vaak de zwakste schakel. Ze zijn ooit aangemaakt voor een specifiek doel, hebben zelden MFA, en het wachtwoord wordt jaren niet
meer aangepast omdat er nog een koppeling op draait.

Fase 3: Een geldig wachtwoord, maar nog niet binnen

Bij honderden of duizenden accounts is de kans groot dat er ergens één poging raak is, en dan hebben we een geldige combinatie van gebruikersnaam en wachtwoord in handen. Dat is een belangrijke stap, maar we zijn er nog niet. Bij de meeste organisaties staat er namelijk gewoon MFA voor de deur, en daar kom je met een goed wachtwoord alleen niet doorheen.

Fase 4: Op zoek naar de uitzondering op MFA

Precies dat is waar we vervolgens naar op zoek gaan: een account waarvoor die extra beveiligingslaag toch niet geldt. De meeste organisaties hebben MFA namelijk goed op orde voor de gemiddelde medewerker, maar waar het vaak nog misgaat, is bij de uitzonderingen. Denk aan een legacy koppeling die geen MFA ondersteunt, een "trusted locations" regel die te ruim is ingesteld, een service account dat is uitgesloten omdat een applicatie er anders niet mee overweg kan, of een conditional access policy die per ongeluk een hele gebruikersgroep overslaat. Die uitzonderingen zijn zelden kwaadwillig ontstaan, meestal is het een praktische keuze geweest die nooit meer is herzien. Valt ons geldige account toevallig onder zo'n uitzondering, of vinden we via dezelfde spray een ander account dat er wel onder valt, dan zijn we voor het eerst écht binnen.

Fase 5: Van een voet in de deur naar een volledig overzicht van de organisatie

Eenmaal echt binnen hebben we in één klap toegang tot van alles: interne documentatie, een adresboek van collega's, of gewoon een geldige sessie waarmee we verder kunnen kijken wat er nog meer misconfigureerd is. Vanaf hier kunnen we ook een toegangstoken aanvragen voor de omgeving, bijvoorbeeld voor Microsoft 365 of Entra ID. Vanaf dat punt is er geen exploit meer nodig. We gebruiken simpelweg de legitieme API's die de omgeving zelf aanbiedt. Met
tooling die gespecialiseerd is in het bevragen van de Microsoft Graph API (zoals GraphRunner) is het mogelijk om binnen korte tijd een volledig overzicht op te bouwen van alle gebruikers, groepen, rollen en onderlinge afhankelijkheden binnen de organisatie. Geen enkele kwetsbaarheid misbruikt, alleen de eigen infrastructuur van de klant, gebruikt zoals die is bedoeld, maar dan door iemand die er niet had mogen zijn.

Waarom dit precies het punt is

Het ongemakkelijke aan dit soort aanvalspaden is dat er geen "patch" voor bestaat. Je kunt niet één kwetsbaarheid dichten en het probleem is opgelost. Het gaat om een optelsom van kleine, op zichzelf logische keuzes. Denk aan een service account zonder MFA, een uitzondering die nooit is opgeschoond, of een wachtwoordbeleid dat net niet streng genoeg is. Precies daarom is een pentestopdracht waardevol. Niet om aan te tonen dat er één specifieke bug is, maar om te laten zien hoe die kleine keuzes zich in de praktijk tegen je kunnen keren. Wil je weten hoe jouw organisatie ervoor staat op dit soort aanvalspaden, van open bronnen tot een volledige interne kaart van je gebruikers? Neem contact met ons op voor een pentestopdracht op maat.