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