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