Cloud Reconnaissance Voorkomen
Policy In Code, Niet In Hoop
In de cloud is consistentie cruciaal: policy in code, minimale rechten en zicht op drift.
Bij Cloud Reconnaissance Voorkomen is succes afhankelijk van policy-as-code en controles die continu meedraaien in de delivery-keten.
Zo houd je snelheid in de cloud, zonder dat veiligheid afhankelijk wordt van handmatig geluk.
Directe maatregelen (15 minuten)
Waarom dit telt
De kern van Cloud Reconnaissance Voorkomen is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.
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.
| Risico | Maatregel | Prioriteit |
|---|---|---|
| DNS-informatielek | Minimaliseer publieke DNS-records, gebruik split-horizon DNS | Hoog |
| CT log exposure | Accepteer het als onvermijdelijk; focus op het beveiligen van ontdekte endpoints | Medium |
| Storage bucket misconfiguratie | Block Public Access op accountniveau, onvoorspelbare namen | Kritiek |
| Credential leaks in code | Pre-commit hooks, secrets scanning, secrets management | Kritiek |
| Subdomain takeover | DNS-hygiene: verwijder records bij deprovisioning | Hoog |
| Cloud metadata fingerprinting | CDN/reverse proxy, verwijder informatieve headers | Medium |
| API enumeration | Rate limiting, IP-filtering op gevoelige endpoints | Hoog |
| Azure tenant enumeration | Smart Lockout, Conditional Access | Medium |
| Firebase open databases | Security rules auditen, testen met ongeauthenticeerde requests | Kritiek |
| .env file exposure | Webserver-configuratie: blokkeer dotfiles | Kritiek |
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.
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.
Referentietabel
| Techniek | Tool/Commando | Doel | MITRE ATT&CK |
|---|---|---|---|
| DNS Recon | dig, host, dnsrecon |
Cloud provider identificatie via DNS records | T1590.002 |
| CT Log Enumeration | crt.sh, certspotter,
censys |
Subdomain discovery via certificate transparency | T1596.003 |
| Subdomain Enumeration | subfinder, amass |
Volledige subdomain inventarisatie | T1590.002 |
| Cloud Asset Discovery | cloud_enum |
S3/Azure Blob/GCP bucket discovery | T1580 |
| S3 Bucket Scanning | s3scanner, aws s3 ls |
Publiekelijk toegankelijke buckets vinden | T1530 |
| Azure Blob Scanning | blobhunter, curl |
Publiekelijk toegankelijke blob containers vinden | T1530 |
| Shodan/Censys | shodan search, censys search |
Passieve asset discovery | T1596.005 |
| GitHub Dorking | GitHub Search, gh search code |
Credentials in publieke repositories | T1552.004 |
| Credential Scanning | trufflehog, gitleaks |
Geautomatiseerde credential detectie in code | T1552.001 |
| HTTP Header Analysis | curl -sI |
Cloud provider fingerprinting via headers | T1592.004 |
| IP/ASN Lookup | whois, ipinfo.io |
Cloud provider identificatie via IP-bereik | T1590.005 |
| Azure Tenant Enum | login.microsoftonline.com API |
Azure AD tenant en gebruiker enumeratie | T1589.002 |
| GCP Project Discovery | Firebase, App Engine URLs | GCP project identificatie | T1580 |
| SSL/TLS Analysis | testssl.sh, sslyze,
openssl |
Certificate chain analyse, load balancer detectie | T1596.003 |
| Subdomain Takeover | subjack, nuclei |
Dangling DNS records detecteren | T1584.001 |
| .env Exposure | curl, ffuf |
Publiekelijk toegankelijke configuratiebestanden | T1552.001 |
| Pastebin/Breach Search | Google dorks, Dehashed | Gelekte credentials in publieke dumps | T1589.001 |
Volgende hoofdstuk: Hoofdstuk 3 – AWS Aanvallen
Verder lezen in de kennisbank
Deze artikelen in het portaal geven je meer achtergrond en praktische context:
- De cloud — andermans computer, jouw verantwoordelijkheid
- Containers en Docker — wat het is en waarom je het moet beveiligen
- Encryptie — de kunst van het onleesbaar maken
- Least Privilege — geef mensen alleen wat ze nodig hebben
Je hebt een account nodig om de kennisbank te openen. Inloggen of registreren.
Gerelateerde securitymaatregelen
Deze artikelen bieden aanvullende context en verdieping: