Alle onderstaande cases zijn geanonimiseerd onder een NDA. Cijfers, sector en aanvalsvector zijn echt — de naam van de klant niet.
Een beheerendpoint lag open door een misconfiguratie van de API-gateway. In combinatie met IDOR in de overboekingsroutes gaf dat toegang tot elke rekening. Gevonden op dag 2 van de opdracht.
De staging-bucket repliceerde productiegegevens zonder versleuteling of toegangscontrole. Hersteld vóór de externe ISO-audit.
Red Team-opdracht die begon met phishing. Vanaf een engineeringwerkstation naar het OT-netwerk via een VPN met standaardinloggegevens. Opgelost met segmentatie, een jump host en MFA.
Reflected XSS op de zoekpagina, gecombineerd met een te ruim cookiebeleid, maakte diefstal van de beheerderssessie mogelijk. Gevonden bij een reguliere pentest.
De naam van een klant publiceren naast de fout die zij hadden, stelt hen twee keer bloot: tijdens het incident, en daarna voorgoed. De vector en de impact beschrijven leert iets; het slachtoffer benoemen is alleen een etalage — en het verdraait de prikkel, want de partij die publicatie durft toe te staan is doorgaans die met het minst te verliezen.
Andere sectoren, andere architecturen — en toch lijken de routes die werken op elkaar. Dit zijn de patronen die het vaakst opduiken, en ze zijn het bekijken waard vóór u een test uitzet.
Staging met een kopie van productie, een oud beheerpaneel, een dienst die voor een demo werd opgezet en nooit is uitgezet. Meestal ontbreekt die in de inventaris en valt zij daardoor buiten elke maatregel die op de rest wél is toegepast.
Het systeem controleert dat u bent ingelogd, maar niet dat het record van u is. Dit is de fout die geautomatiseerde tooling het vaakst mist, omdat de request er volstrekt legitiem uitziet.
Ruime toegang verleend om een oplevering vlot te trekken, met de belofte die later dicht te zetten. Maanden verder staat zij er nog, inmiddels overgeërfd door mensen die nooit wisten dat zij die hadden.
Een sleutel in een blootgestelde omgevingsvariabele, een inloggegeven in de historie van een repository, een token in een versiebeheerd configuratiebestand. Het is de kortste weg naar binnen en de eenvoudigste om te sluiten.
Twee applicaties die elkaar herkennen op netwerkpositie of een gedeeld geheim. Wie de minst beschermde overneemt, krijgt de best beschermde erbij, en de segmentatie die dat zou moeten indammen is zelden getest.
De gebeurtenis is gelogd, het alarm ging af — en belandde in een wachtrij die niemand leest. Technisch gedetecteerd, praktisch onzichtbaar: het verschil komt pas aan het licht in een onaangekondigde oefening.
Omdat de toestemming om te publiceren zou komen van wie het minst te verliezen heeft, niet van wie de leerzaamste case had. Al het materiaal is geanonimiseerd onder een geheimhoudingsovereenkomst, en de technische vector — het bruikbare deel — blijft behouden.
Ja, mits de betrokken partijen daarvoor toestemming geven. Voor de meeste trajecten geeft echter de afsluitende verklaring van uw eigen opdracht de doorslag, opgesteld na de hertest: dat is direct bewijs, in plaats van het oordeel van een derde over andermans werk.
Nee. De route hangt af van architectuur, koppelingen en keuzes die pas in uw eigen omgeving zichtbaar worden. De cases laten zien wat er doorgaans gevonden wordt, niet een script dat zich herhaalt.
Nooit. Niets wordt openbare tekst voordat het herstel klaar is en door een hertest is bevestigd, en zelfs dan alleen met toestemming. Hetzelfde criterium geldt voor ons eigen onderzoek, vastgelegd in de responsible-disclosurepolicy.