Voorwoord

Er is een fascinerende discrepantie tussen hoe organisaties denken over hun cloudbeveiliging en hoe die beveiliging er werkelijk uitziet. Vraag een CTO hoe het staat met de security van hun cloud-omgeving, en hij zal je vertellen dat alles in orde is. Ze gebruiken AWS. Of Azure. Of Google Cloud. En die providers – dat zijn toch de slimste engineers ter wereld? Die regelen de beveiliging toch? Er is encryptie at rest. Er is encryptie in transit. Er staan vinkjes bij alle compliance-frameworks. Alles is geregeld.

Vraag vervolgens een cloud penetratietester hoe het staat met diezelfde omgeving, en je krijgt een verhaal dat aanzienlijk minder geruststellend is. Een verhaal over S3 buckets die publiek toegankelijk zijn en al maanden stilletjes data lekken naar het internet. Over IAM-rollen met AdministratorAccess die zijn aangemaakt “voor die ene migratie” en er nooit meer zijn afgehaald. Over service accounts met hardcoded credentials in Lambda-functies. Over een Conditional Access Policy die er op papier waterdicht uitziet, maar in de praktijk omzeild kan worden door een aanvaller met een gratis e-mailadres en tien minuten geduld.

Dit boek gaat over dat tweede verhaal.

Het is een verhaal dat zich herhaalt in elke organisatie die naar de cloud is gemigreerd – en dat zijn inmiddels vrijwel alle organisaties. De details verschillen: hier is het een vergeten Access Key, daar een Lambda-functie met environment variables die leesbaar zijn voor iedereen met een GetFunction-permissie, elders een Entra ID-configuratie die ervoor zorgt dat elke gastgebruiker de volledige adreslijst van de organisatie kan downloaden. Maar het patroon is altijd hetzelfde. De beveiligingsaannames kloppen niet. En de aanvaller hoeft alleen maar de aannames te vinden.

Waarom dit boek

“Incompetent Bastards: De Cloud” is het derde deel in een serie over penetratietesten. Het eerste boek – “De Webapplicatie” – behandelde de kwetsbaarheden in webapplicaties, van SQL injection tot Server-Side Request Forgery. Het tweede boek – “Het Netwerk” – ging het interne netwerk in: Active Directory, Kerberos, lateral movement, en alles wat daartussen zit.

Dit boek gaat over het terrein dat in rap tempo het nieuwe slagveld is geworden: de cloud.

En “slagveld” is het juiste woord. De cloud is niet simpelweg een netwerk dat ergens anders staat. Het is een fundamenteel ander paradigma, met eigen regels, eigen aanvalsoppervlakken, en eigen manieren om spectaculair mis te gaan. De vaardigheden die je nodig hebt om een Active Directory-domein te compromitteren overlappen gedeeltelijk met wat je nodig hebt in de cloud, maar de verschillen zijn minstens zo belangrijk als de overeenkomsten.

In de cloud is identiteit de nieuwe perimeter. Een IAM policy is het nieuwe firewall-ruleset. Een misconfiguratie in een resource policy kan meer schade aanrichten dan een ongepatchte server, want die misconfiguratie schaalt mee met alles wat eraan hangt. En dat is precies het probleem: alles schaalt in de cloud. Inclusief de fouten.

De ethische grens

Dit herhalen we in elk deel, en we zullen het blijven herhalen tot het overbodig wordt. Dat moment lijkt nog ver weg.

Alles in dit boek is uitsluitend bedoeld voor gebruik in geautoriseerde penetratietesten. Je hebt schriftelijke toestemming. Je hebt een scope-document dat expliciet beschrijft welke cloud-accounts, subscriptions, projecten, regio’s en services binnen bereik vallen. Je hebt een escalatieprocedure. Je hebt telefoonnummers van mensen die opnemen als je per ongeluk een productie-database hebt verwijderd die niet door een deletion policy werd beschermd.

In de cloud is de ethische grens extra scherp, om twee redenen.

Ten eerste: het shared responsibility model. AWS, Azure en GCP beveiligen de infrastructuur onder je workloads. Jij beveiligt wat er op draait. Dat betekent dat je als pentester de verantwoordelijkheid draagt voor alles wat je doet binnen die gedeelde omgeving. Een misconfiguratie in je pentest-tooling kan data lekken naar het publieke internet. Een verkeerd geconfigureerde security group kan een pad openen dat er niet hoort te zijn. De blast radius van een fout in de cloud is groter dan on-premise, omdat de cloud per definitie verbonden is met het internet.

Ten tweede: multi-tenancy. Cloud-omgevingen delen fysieke infrastructuur met andere klanten. Een pentest die onbedoeld buiten de scope treedt, raakt niet alleen je opdrachtgever – het raakt potentieel andere organisaties op dezelfde infrastructuur. Dat is niet alleen onethisch; het is illegaal in vrijwel elk rechtsgebied.

Zorg ervoor dat je scope-document de volgende cloud-specifieke elementen bevat: AWS Account IDs, Azure Subscription IDs, of GCP Project IDs die binnen scope vallen. Regio’s die getest mogen worden. Services die binnen bereik vallen. En – cruciaal – een expliciete vermelding of je penetration testing notification hebt ingediend bij de cloudprovider. AWS heeft sinds 2023 geen voorafgaande goedkeuring meer nodig voor de meeste pentests, maar Azure en GCP hebben hun eigen regels. Ken die regels. Volg ze.

De wet is duidelijk. In Nederland valt ongeautoriseerde toegang tot computersystemen onder artikel 138ab van het Wetboek van Strafrecht. In de cloud is de grens tussen geautoriseerd en ongeautoriseerd soms subtiel – een account dat je mag testen bevat een role trust naar een account dat buiten scope valt; een SSRF lekt credentials van een service in een andere regio dan afgesproken – maar de wet maakt dat onderscheid niet voor je. Jij maakt dat onderscheid. En je maakt het voordat je op Enter drukt, niet erna.

Gebruik deze technieken verantwoord. Of gebruik ze niet.

Voor wie is dit boek

Dit boek is geschreven voor twee doelgroepen die meer met elkaar gemeen hebben dan ze doorgaans denken.

De eerste groep is de penetratietester die van on-premise naar cloud wil. Je kent Active Directory. Je kent Kerberos. Je kunt in je slaap een Golden Ticket maken. Maar als iemand je vraagt om een AWS-omgeving te testen, sta je daar met je Rubeus in de hand en een leeg gevoel van binnen. Dit boek leert je de cloud-equivalenten van de technieken die je al kent, en de technieken die geen on-premise equivalent hebben.

De tweede groep is de cloud engineer die wil begrijpen hoe aanvallers denken. Je bouwt IaC-templates, configureert IAM policies, en deployt workloads. Maar je hebt nooit vanuit het perspectief van de aanvaller naar je eigen werk gekeken. Dit boek laat je zien welke aannames je maakt die niet kloppen, welke standaardinstellingen onveilig zijn, en waarom die “tijdelijke” exception in je security group al zes maanden meedraait.

Wat we verwachten: basiskennis van cloud computing (je weet wat een VM is, je hebt weleens ingelogd op de AWS Console of Azure Portal), enige ervaring met de command line, en de bereidheid om te leren door te doen.

Wat we niet verwachten: dat je een cloud-expert bent. Daar is dit boek voor.

Een kanttekening, dezelfde als in de vorige delen: dit boek is geen certificeringsgids. Het bereidt je niet voor op de AWS Security Specialty, de AZ-500, de CCSP, of een andere verzameling letters die indruk maakt op een LinkedIn-profiel maar weinig zegt over daadwerkelijke vaardigheid. Wat het wel doet is je de kennis geven die je nodig hebt om die certificeringen te begrijpen – en om de kloof te zien tussen wat een certificering test en wat de echte wereld van je vraagt.

Twee perspectieven

Net als in de voorgaande delen is dit boek geschreven vanuit twee perspectieven.

De eerste is die van de nieuwsgierige ontdekkingsreiziger – iemand die zich oprecht verwondert over het feit dat je met drie regels CLI-code een volledige database kunt deployen in een datacenter op een ander continent, en die vervolgens wil begrijpen waarom de standaard beveiligingsinstellingen van die database zo hartgrondig tekortschieten.

De tweede is die van de cynicus – iemand die niet kan geloven dat we de fouten van het on-premise tijdperk niet alleen hebben meegenomen naar de cloud, maar ze ook nog eens hebben geschaald. Want als er een ding is waar de cloud goed in is, dan is het schalen. Inclusief het schalen van incompetentie.

Samen vormen ze, hopen we, een boek dat je zowel iets leert als bij de les houdt. De nieuwsgierige stem vraagt “hoe werkt dit?” De cynische stem vraagt “hoe hebben we dit laten gebeuren?” En samen komen ze uit bij “wat kunnen we eraan doen?”

De structuur van het boek

Dit boek volgt het pad van een cloud-penetratietest, van de eerste reconnaissance tot het eindrapport. We beginnen met de basis: wat is de cloud vanuit het aanvalsperspectief, hoe werkt identiteit, hoe zet je een lab op. Vervolgens lopen we door de aanvalsfasen: reconnaissance, credential harvesting, privilege escalation, lateral movement, persistence. We eindigen met rapportage en compliance – het deel dat bepaalt of je bevindingen daadwerkelijk tot verbeteringen leiden.

Elk hoofdstuk behandelt alle drie de grote cloudproviders (AWS, Azure, GCP) waar relevant. De commando’s en voorbeelden zijn per provider gemarkeerd, zodat je snel kunt vinden wat je nodig hebt voor het platform waarmee je werkt.

Leesconventies

De conventies uit de voorgaande delen gelden onverminderd, met enkele cloud-specifieke toevoegingen.

Code en commando’s staan in code blocks met syntax highlighting. Cloud CLI-commando’s worden gemarkeerd met hun respectieve CLI:

# AWS CLI
aws sts get-caller-identity

# Azure CLI
az account show

# Google Cloud CLI
gcloud auth list

IB Tips zijn praktische verwijzingen naar het Incompetent Bastard-dashboard:

IB Tip: De Command Library bevat cloud-specifieke commando’s. Zoek op cloud_ voor AWS-, Azure- en GCP-gerichte technieken.

Placeholder-waarden gebruiken cloud-specifieke conventies:

Verdedigingsmaatregelen worden per techniek beschreven. In de cloud zijn verdedigingsmaatregelen vaak een policy-wijziging of een configuratie-aanpassing, niet een patch of een upgrade. Dat maakt ze tegelijkertijd eenvoudiger te implementeren en moeilijker te handhaven – want een policy die niemand afdwingt is geen policy.

MITRE ATT&CK Cloud Matrix-referenties worden per techniek vermeld. De Cloud Matrix bevat technieken die specifiek zijn voor cloud-omgevingen (IaaS, SaaS, Identity Provider) en is een uitbreiding op de Enterprise Matrix die in de voorgaande delen werd gebruikt.

Het gereedschap

Door het hele boek gebruiken we Incompetent Bastard (IB) als operationele hub, aangevuld met cloud-specifieke tooling.

De cloud-gereedschapskist:

IB’s Command Library bevat cloud-commando’s die dezelfde conventies volgen als de netwerk- en webcommando’s: kopieerbare blokken met inline commentaar, placeholders die automatisch worden vervangen, en directe verwijzingen naar de technieken uit dit boek.

De architectuur van IB – een lokale Flask-applicatie met SQLite, zonder cloud-afhankelijkheden, zonder telemetrie – is bijzonder passend voor cloud-pentesting. Je pentest-tooling draait op je eigen machine, geïsoleerd van de cloud-omgeving die je test. Je bevindingen, credentials, en evidence verlaten nooit je systeem. In een vakgebied waar we de hele dag praten over het risico van data in andermans cloud, is het prettig om te weten dat je eigen tooling dat risico niet deelt.

De SSRF-module in IB (/ssrf) is bijzonder relevant voor cloud-pentests. Cloud metadata-endpoints – 169.254.169.254 voor AWS en GCP, 169.254.169.254 voor Azure IMDS – zijn het primaire doelwit van SSRF-aanvallen in cloudomgevingen. IB bevat redirect-endpoints die specifiek zijn ontworpen om deze metadata-services te bereiken via SSRF.

IB Tip: De SSRF redirect-endpoints in IB ondersteunen cloud metadata-extractie. Gebruik /ssrf/redirect?url=http://169.254.169.254/latest/meta-data/ voor AWS Instance Metadata Service. IB logt elke redirect, zodat je precies kunt zien welke metadata werd opgehaald.

De zusterboeken

Dit boek vormt samen met “Incompetent Bastards: De Webapplicatie” en “Incompetent Bastards: Het Netwerk” een drieluik dat het volledige spectrum van penetratietesten bestrijkt.

“De Webapplicatie” behandelt de applicatielaag: SQL injection, XSS, SSRF, deserialisatie, en alles wat daartussen zit. Veel cloud-aanvallen beginnen bij een webapplicatie – een SSRF die metadata lekt, een command injection die IAM credentials dumpt – en de technieken uit het eerste boek zijn daarmee direct relevant.

“Het Netwerk” behandelt het interne netwerk en Active Directory. De hybride wereld waarin de meeste organisaties opereren – met een on-premise AD dat is gesynchroniseerd naar Azure AD via Entra Connect – maakt de technieken uit het tweede boek onmisbaar voor cloud-pentests. Een gecompromitteerd on-premise AD is vaak een directe route naar de cloud, en vice versa.

Waar nodig verwijzen we naar de zusterboeken. De Command Library in IB weerspiegelt het drieluik: web_-commando’s voor webapplicaties, ad_- en kerb_-commando’s voor het netwerk, en cloud_-commando’s voor de cloud.

De drie boeken zijn complementair, maar onafhankelijk leesbaar.

Waarschuwingen

Door het hele boek heen gebruiken we waarschuwingen voor technieken die een hoog risico dragen op onbedoelde gevolgen:

Let op: Het verwijderen van een CloudTrail trail in een productie-omgeving heeft onmiddellijk effect en kan een compliance-schending veroorzaken. Gebruik deze techniek alleen in je lab of wanneer de scope het expliciet toestaat.

Cloud-operaties zijn vaak onomkeerbaar. Een verwijderde S3 bucket met versioning uitgeschakeld is permanent weg. Een geroteerde Access Key invalideert onmiddellijk alle systemen die die key gebruiken. Een aangepaste IAM policy kan honderden services beinvloeden. De blast radius in de cloud is groter dan on-premise, en de snelheid waarmee je schade kunt aanrichten is evenredig.

Wees voorzichtig. Test in je lab. En als je twijfelt, bel je contactpersoon.

Hoe dit boek te lezen

Net als de voorgaande delen kun je dit boek op twee manieren lezen.

De eerste manier is lineair: begin bij hoofdstuk 1, volg het pad van cloud-reconnaissance tot rapportage, en oefen de technieken in je lab terwijl je leest. Dit is de aanbevolen aanpak voor wie nieuw is in cloud-pentesting. De hoofdstukken bouwen op elkaar voort – identiteit vormt de basis voor privilege escalation, privilege escalation opent de deur naar lateral movement, en lateral movement leidt tot data-exfiltratie.

De tweede manier is als naslagwerk: je zit midden in een engagement, je hebt een set AWS-credentials verkregen via een SSRF, en je wilt snel opzoeken welke enumeratie-stappen je nu moet uitvoeren. Blader naar het relevante hoofdstuk, zoek de techniek, kopieer het commando. De referentietabellen aan het einde van elk hoofdstuk zijn hiervoor ontworpen.

Wat je niet moet doen – en we weten dat het toch gebeurt – is willekeurig commando’s uit dit boek kopieren en ze uitvoeren tegen systemen die je niet mag testen. We hebben het er al over gehad. We gaan het er niet nog een keer over hebben. Goed. Misschien nog een keer: niet doen.

Dankwoord

Dank aan de cloud-engineers die dag en nacht werken aan de beveiliging van de infrastructuur waarop de wereld draait. Dank aan de open-source-gemeenschap die tools bouwt als ScoutSuite, Pacu, ROADtools, CloudFox, en Prowler – gereedschappen die het mogelijk maken om cloud-omgevingen systematisch te testen. Dank aan de security-onderzoekers die IAM privilege escalation-paden documenteren en publiceren, zodat verdedigers weten waartegen ze zich moeten beschermen.

Dank aan de lezers van de eerste twee boeken die hebben gevraagd om een derde deel. Jullie feedback, correcties en suggesties hebben ook dit boek beter gemaakt.

En dank aan elke organisatie die na het lezen van een pentest-rapport daadwerkelijk actie onderneemt. Die de overprivileged policies aanpast. Die MFA afdwingt. Die logging inschakelt. Die niet wacht tot het misgaat, maar handelt voordat het zover is. Jullie zijn nog steeds zeldzaam. Maar jullie worden meer. En voor jullie schrijven we.

Veel plezier. En vergeet niet: altijd met toestemming. Vooral in de cloud, waar een vergissing niet beperkt blijft tot een enkel netwerksegment maar zich kan verspreiden met de snelheid van een API-call.

– Jan-Karel Visser, Kropswolde, 2026