Cloud Penetrationstest: AWS, Azure, GCP & Kubernetes im Fokus

Cloud Computing ist heute integraler Bestandteil moderner Unternehmens-IT. Gleichzeitig wächst die Angriffsfläche: Fehlkonfigurierte S3-Buckets, überprivilegierte IAM-Rollen, offene Kubernetes-API-Server - die Bedrohungsszenarien sind vielfältig und unterscheiden sich fundamental von klassischen On-Premise-Umgebungen. Dieser Artikel erklärt, was einen Cloud Penetrationstest ausmacht, welche Regelwerke gelten und welche typischen Schwachstellen Pentester in AWS, Azure, GCP und Kubernetes-Clustern finden.

Einen professionellen Cloud-Pentest bietet AWARE7 unter Cloud Security.

Warum Cloud-Pentests anders sind als klassische Pentests

Bei einem klassischen Penetrationstest gegen eine On-Premise-Infrastruktur gelten im Wesentlichen zwei Parteien: der Auftraggeber und das Pentest-Unternehmen. In Cloud-Umgebungen kommt eine dritte Partei hinzu: der Cloud-Anbieter. Dessen Nutzungsbedingungen definieren verbindlich, welche Tests erlaubt sind - unabhängig davon, was der Auftraggeber genehmigt.

Ein weiterer struktureller Unterschied liegt im Shared-Responsibility-Modell. Die zugrundeliegende Infrastruktur der großen Cloud-Provider ist in der Regel sicher - die Anbieter investieren erhebliche Ressourcen in interne und externe Pentests sowie Bug-Bounty-Programme. Google hat seit 2010 über 21 Millionen Dollar an Bug-Bounty-Hunter ausgezahlt. Die Verantwortung für die Konfiguration dieser Infrastruktur liegt jedoch beim Kunden. Genau hier setzen Cloud-Pentests an.

Das Shared-Responsibility-Modell variiert je nach Service-Modell:

• IaaS (Infrastructure as a Service): Der Kunde kontrolliert Betriebssystem, Anwendungen und Daten. Der Pentest kann deutlich aggressiver durchgeführt werden.
• PaaS (Platform as a Service): Die Plattformschicht liegt beim Anbieter. Der Pentest fokussiert auf Anwendungslogik und Konfiguration.
• SaaS (Software as a Service): Nur Konfiguration und Zugriffsrechte sind kundenseitig - der Pentest-Scope ist entsprechend eingeschränkt.

Ebenso relevant ist der Cloud-Typ: In einer Public Cloud teilen sich viele Kunden dieselbe Infrastruktur, was DDoS-Tests grundsätzlich ausschließt. Eine Virtual Private Cloud (VPC) ist eine isolierte Umgebung innerhalb einer öffentlichen Cloud, die nur für eine bestimmte Organisation bereitsteht. Eine hybride Cloud kombiniert private und öffentliche Anteile, was den Pentest-Scope besonders komplex macht.

Testansätze im Cloud-Kontext

AWARE7 unterscheidet drei Ansätze:

• Black Box / Testing gegen die Cloud: Getestet werden Applikationen, die als Cloud-Anwendung gehostet sind - klassische Webapplikationsvektoren, fehlkonfigurierte Nutzerberechtigungen oder falsch konfigurierte Speicherinstanzen wie S3-Buckets oder EC2-Metadaten.
• Grey Box / Testing in der Cloud: Systeme, die nicht öffentlich zugänglich sind (z. B. hinter einer Firewall). Dem Tester werden häufig gültige Zugänge zum Backend bereitgestellt, um zu prüfen, was ein Angreifer mit kompromittierten Zugangsdaten erreichen kann.
• White Box / Testing der Konsole: Die Konfiguration der Cloud-Umgebung wird überprüft - welche Nutzer welche Rechte haben, ob Zugangskontrollen korrekt gesetzt sind. So lassen sich Privilege-Escalation-Vektoren und Informationslecks effizient schließen.

Scoping und Regelwerke der Cloud-Anbieter

Bevor ein Cloud-Pentest beginnt, muss der Scope präzise definiert sein - und zwar unter Berücksichtigung der Richtlinien des jeweiligen Anbieters. Ein Verstoß gegen diese Richtlinien kann zum Ausschluss aus dem Dienst führen.

Grundsätzlich verboten bei allen Anbietern:

• DDoS-Angriffe (Denial of Service)
• Port Flooding
• Tests gegen geteilte Infrastruktur, die nicht dem eigenen Account gehört

Vom Anbieter erlaubt (kundeneigene Ressourcen):

• Tests gegen eigene EC2-Instanzen, S3-Buckets, IAM-Schlüssel
• Tests gegen eigene Azure Virtual Machines, App Services
• Tests gegen eigene GKE/EKS/AKS-Cluster und die darauf laufenden Workloads

Der erhöhte Planungs- und Durchführungsaufwand bei Cloud-Pentests ergibt sich genau aus dieser Konstellation: Neben der Abstimmung mit dem Kunden muss stets auf die Anforderungen der unterschiedlichen Cloud-Anbieter eingegangen werden.

AWS Penetrationstest

Was AWS erlaubt und verbietet

Amazon erlaubt Pentests auf kundeneigenen Ressourcen ausdrücklich. Testbar sind insbesondere:

• EC2-Instanzen (Elastic Compute Cloud) - vollständig testbar, inklusive Anwendungs-APIs, virtuellen Maschinen und laufenden Anwendungen
• S3-Buckets - Berechtigungskonfiguration, öffentliche Zugänglichkeit, Bucket-Policies
• IAM-Schlüssel - Berechtigungsumfang, Rotation, Exponierung
• Anwendungen auf EC2 - klassische Web-App-Vektoren

Nicht testbar sind die physische Hardware in AWS-Rechenzentren, EC2-Umgebungen von Partnern oder Dienstleistern außerhalb der eigenen administrativen Kontrolle sowie Amazon RDS in bestimmten Konfigurationen. Tests im Bereich Stabilität und Erreichbarkeit - also DoS-Szenarien - sind ausdrücklich verboten.

Typische Findings bei AWS

AWS-Pentests drehen sich weniger um klassisches Hacking als um Konfigurationsfehler. Die häufigsten Findings:

Fehlkonfigurierte S3-Buckets: Öffentlich zugängliche Buckets mit sensiblen Daten - Konfigurationsdateien, Backups, interne Dokumente - gehören zu den häufigsten und folgenreichsten Cloud-Findings. S3-Buckets haben sich als primäres Angriffsziel etabliert.

Überprivilegierte IAM-Rollen: IAM-Schlüssel mit zu weit gefassten Berechtigungen, die im Schadensfall einem Angreifer weitreichenden Zugang zur gesamten AWS-Umgebung ermöglichen.

Exponierte Metadaten-Endpunkte: Der Instance Metadata Service (IMDS) unter 169.254.169.254 liefert bei fehlender IMDSv2-Erzwingung IAM-Credentials der Instance-Role - ein häufiger Pivoting-Vektor nach einer initialen Kompromittierung.

Unsichere EC2-Konfigurationen: Security Groups mit zu offenen Regeln, fehlende Verschlüsselung von EBS-Volumes, ungepatchte Betriebssysteme auf EC2-Instanzen.

Da AWS auf dem SaaS-Prinzip basiert - Kunden mieten eine Umgebung, werden aber nicht Eigentümer der physischen Infrastruktur - liegt die Sicherheitsverantwortung für die eigene Konfiguration vollständig beim Kunden. Hilfreiche hauseigene Lösungen wie der Amazon Inspector bieten ein automatisiertes Schwachstellenmanagement, ersetzen aber keinen manuellen Pentest durch erfahrene Tester.

Azure Penetrationstest

Microsoft erlaubt das Testing von Azure-Produkten ohne gesonderte Voranmeldung. Portscans gegen virtuelle Azure-Instanzen sind dabei ausdrücklich erlaubt - ein Unterschied zu einigen anderen Anbietern. DoS-Tests bleiben auch hier verboten.

Typische Findings bei Azure-Pentests:

Azure Active Directory / Entra ID: Fehlkonfigurierte Conditional-Access-Policies, zu weitreichende Gastbenutzer-Berechtigungen, schwache MFA-Konfigurationen oder unsichere App-Registrierungen mit übermäßigen API-Berechtigungen.

Blob Storage: Ähnlich wie S3-Buckets bei AWS sind öffentlich zugängliche Azure Blob Storage-Container ein häufiger Befund. Fehlende Private Endpoints oder unsichere Shared-Access-Signatures (SAS) erweitern die Angriffsfläche.

Azure RBAC-Fehlkonfigurationen: Zu weitreichende Rollen-Zuweisungen, insbesondere Contributor- oder Owner-Rechte auf Subscription-Ebene für Dienstkonten oder automatisierte Prozesse.

Unsichere App Services und Function Apps: Fehlende Authentifizierung, exponierte Debugging-Endpunkte oder unsichere Umgebungsvariablen mit Secrets in Plaintext.

GCP Penetrationstest

Google Cloud Platform (GCP) erlaubt Sicherheitstests gegen eigene Ressourcen ohne gesonderte Genehmigung, sofern die Google Cloud Acceptable Use Policy eingehalten wird. DoS-Tests sind auch hier ausgeschlossen.

Typische Findings bei GCP-Pentests:

Service Account Missbrauch: Überprivilegierte Service Accounts mit Project-Owner-Rechten, exportierte Service-Account-Keys in Code-Repositories oder CI/CD-Pipelines, fehlende Rotation.

GCS Buckets (Google Cloud Storage): Ähnlich wie bei AWS S3 und Azure Blob Storage sind fehlerhafte Bucket-IAM-Policies ein häufiger Befund - insbesondere allUsers- oder allAuthenticatedUsers-Berechtigungen.

GKE (Google Kubernetes Engine) Cluster: Öffentlich erreichbare API-Server ohne Authorisierungs-Kontrollen, fehlende Workload Identity-Konfiguration oder überprivilegierte Node-Service-Accounts.

Compute Engine Metadaten-Endpunkt: Der GCP-Metadaten-Server unter metadata.google.internal liefert OAuth-Tokens für die Node-Service-Accounts - ein direkter Pivoting-Pfad bei kompromittierten Containern.

Kubernetes Penetrationstest

Kubernetes ist heute die Standard-Plattform für Container-Orchestrierung in Unternehmen - und damit ein primäres Angriffsziel. Ein K8s-Cluster verbindet oft Hunderte von Microservices, Secrets, Cloud-Credentials und privilegierten Workloads. Ein einziger unsicherer Pod kann zur vollständigen Cluster-Kompromittierung führen.

Angriffsfläche eines Kubernetes-Clusters

Die relevanten Komponenten und ihre Ports:

Control Plane:

• kube-apiserver (Port 6443) - zentraler Angriffspunkt, alle Cluster-Operationen laufen hierüber
• etcd (Port 2379) - enthält alle Kubernetes-Secrets des Clusters im Klartext, sofern kein Encryption at Rest konfiguriert ist
• kube-scheduler (Port 10259), kube-controller (Port 10257)

Worker Nodes:

• kubelet API (Port 10250) - direkter Pod-Zugriff, in älteren Konfigurationen ohne Authentifizierung erreichbar
• Container Runtime (Docker, containerd, CRI-O)

Externe Angriffsfläche:

• API-Server öffentlich erreichbar? (GKE, EKS, AKS haben das teilweise standardmäßig)
• Kubernetes Dashboard ohne Authentifizierung
• NodePort-Services (Ports 30000-32767) auf allen Nodes
• Prometheus/Grafana-Monitoring-Endpunkte mit Cluster-Informationen

Phase 1: Cluster-Enumeration

Ein Kubernetes-Pentest beginnt mit der Prüfung auf anonymen Zugriff am API-Server. Ein 403 Forbidden bestätigt die Existenz des Servers; in schlecht konfigurierten Clustern ist vollständiger anonymer Zugriff möglich. Die Kubelet-API (Port 10250) listet in manchen Konfigurationen alle Pods eines Nodes ohne Authentifizierung auf. Ist etcd ohne TLS erreichbar, sind alle Kubernetes-Secrets des Clusters im Klartext abrufbar.

Für automatisiertes K8s-Scanning eignet sich kube-hunter:

pip install kube-hunter
kube-hunter --remote CLUSTER-IP   # Remote-Scan
kube-hunter --pod                  # Pod-interner Scan (aus kompromittiertem Container)

Phase 2: RBAC-Analyse und Privilege Escalation

RBAC-Fehlkonfigurationen sind die häufigsten Kubernetes-Findings:

Wildcard-Berechtigungen: ClusterRoles mit apiGroups: ["*"], resources: ["*"], verbs: ["*"] - vollständige Cluster-Kontrolle für jeden zugeordneten Service Account.

Pod-Erstellung gleich Cluster-Admin: Wer Pods erstellen und das privileged-Flag setzen darf, kann das Host-Filesystem mounten und beliebige Befehle auf dem Node als Root ausführen.

Secrets lesen gleich alle Credentials: Wer Secrets im Cluster lesen darf, erhält API-Keys, Datenbankpasswörter, TLS-Zertifikate und OAuth-Tokens aller Namespaces.

Impersonation: Wer die impersonate-Berechtigung hat, kann als beliebiger Nutzer oder Service Account auftreten - bis hin zum cluster-admin.

Gefährliche Verbs im Überblick:

Verb	Resource	Risiko
create	pods	Container Escape (privileged pod)
create	clusterrolebindings	Privilege Escalation
get/list	secrets	Credential-Diebstahl aus allen Namespaces
patch/update	clusterroles	RBAC-Manipulation
exec	pods	Command Execution in laufenden Pods
port-forward	pods	Interne Services von außen erreichbar
impersonate	users/serviceaccounts	Privilege Escalation zu beliebiger Identität

RBAC-Audit-Tools:

• rakkess (kubectl krew install rakkess) — zeigt alle Berechtigungen eines Service Accounts
• kubectl-who-can (kubectl who-can create pods) — welche Identitäten dürfen eine Aktion ausführen?
• rbac-police — statische RBAC-Analyse von YAML-Manifesten

Phase 3: Container Escape

Ein privilegierter Container kann auf alle Host-Devices zugreifen:

• Privileged + hostPath: Das Host-Root-Filesystem kann direkt gemountet werden (/dev/sda1). Angreifer können die Host-Crontab bearbeiten oder SSH-Keys hinterlegen - Persistence auf Node-Ebene.
• hostPID: true: Über nsenter kann eine Root-Shell im Host-Namespace geöffnet werden.
• hostNetwork: true: Der Container sieht alle Host-Netzwerkinterfaces und kann direkt auf den Cloud-Metadaten-Endpunkt 169.254.169.254 zugreifen - und damit IAM-Credentials der Node-Role abrufen.
• Docker-Socket gemountet: /var/run/docker.sock innerhalb eines Containers entspricht Root-Zugriff auf den Node.

Offensives Container-Tool CDK (Container Duck Knife):

./cdk_linux_amd64 eva auto        # Automatische Escape-Erkennung
./cdk_linux_amd64 exploit docker-sock-check

CDK prüft automatisch auf privilegierte Capabilities, hostPath-Mounts, exponierte Sockets und bekannte Escape-Pfade.

Phase 4: Laterale Bewegung im Cluster

Nach einer initialen Kompromittierung suchen Angreifer nach Wegen, sich horizontal im Cluster zu bewegen:

• Service-Discovery über Kubernetes DNS (<service-name>.<namespace>.svc.cluster.local) zur Identifikation interner Dienste
• Secrets aus anderen Namespaces stehlen, sofern ClusterRoles mit secrets/get vorhanden
• Bei EKS: Node-IAM-Role via Instance Metadata Service abrufen und AWS-Credentials des Worker-Nodes nutzen
• Bei GKE: GCP OAuth-Token des Node-Service-Accounts über den GCP-Metadaten-Server abrufen

Kubernetes-Härtung

Die wichtigsten Schutzmaßnahmen:

• API-Server absichern: Anonymen Zugriff deaktivieren (--anonymous-auth=false), RBAC erzwingen (--authorization-mode=Node,RBAC), Audit-Log aktivieren
• Pod Security Standards (PSS): Namespaces mit restricted-Policy verhindern privilegierte Container, hostPath-Mounts sowie hostPID/hostNetwork/hostIPC - und damit die meisten Container-Escape-Techniken
• Network Policies (Zero Trust): Default-Deny für alle Namespaces, dann explizite Allow-Policies für benötigte Kommunikation
• RBAC Least Privilege: Service Accounts ohne unnötige Rechte, automountServiceAccountToken: false wenn nicht benötigt, nur spezifische Ressourcen und Verbs freigeben
• Secrets verschlüsseln: Encryption at Rest für etcd konfigurieren
• Container-Image-Security: Keine :latest-Tags, Non-root User, Vulnerability-Scanning mit Trivy oder Grype im CI/CD

Empfohlene Tools für kontinuierliche K8s-Sicherheit: kube-bench (CIS Kubernetes Benchmark), Falco (Runtime-Detection), OPA/Gatekeeper (Policy-Enforcement), kube-score (YAML-Analyse vor Deployment).

Typische Schwachstellen in Cloud-Umgebungen

Anbieterübergreifend zeigen sich beim Cloud-Pentest wiederkehrende Schwachstellenklassen:

Fehlkonfigurierte Speicher-Services: Öffentlich zugängliche S3-Buckets, Azure Blob Container oder GCS-Buckets mit sensiblen Daten sind konsistent die häufigsten und folgenreichsten Findings. 85 % der 2019 verursachten Datendiebstähle waren auf Fehlkonfigurationen zurückzuführen.

Überprivilegierte Identitäten: IAM-Rollen, Service Accounts und Managed Identities mit zu weitreichenden Berechtigungen - das Principle of Least Privilege wird in der Praxis häufig nicht konsequent umgesetzt.

Exponierte Metadaten-Endpunkte: Der Cloud-Metadaten-Service (IMDS bei AWS, äquivalente Endpunkte bei GCP und Azure) ist ein zentraler Pivoting-Vektor: Er liefert temporäre Credentials, die einem Angreifer nach einer initialen Kompromittierung Zugang zur gesamten Cloud-Umgebung ermöglichen können.

Fehlende Verschlüsselung: Unverschlüsselte Daten at Rest (EBS-Volumes, etcd-Inhalte), unsichere Übertragung interner Services oder fehlende TLS-Verifizierung zwischen Cluster-Komponenten.

Unsichere CI/CD-Pipelines: Secrets in Umgebungsvariablen, überprivilegierte Deployment-Service-Accounts, fehlende Supply-Chain-Security (unsigned Images, kein Vulnerability-Scanning).

Abhängigkeit von Diensten: Der AWS-Vorfall von 2017 zeigt exemplarisch, dass ein einziger falscher Befehl zahlreiche abhängige Dienste vom Netz nehmen kann. Pentests decken auch solche Abhängigkeiten und fehlende Resilience-Maßnahmen auf.

Cloud-Fehlkonfigurationen: Erkennung und Behebung

Die größten Cloud-Datenpannen der letzten Jahre — Capital One, Toyota, Twitch, Microsoft — hatten eines gemeinsam: keine Zero-Day-Exploits, keine hochentwickelte Schadsoftware, sondern falsch gesetzte Konfigurationen. Ein öffentlicher S3-Bucket. Eine zu offene Security Group. Ein Root-Account ohne MFA.

AWS: Die häufigsten Fehlkonfigurationen

Öffentliche S3-Buckets

Capital One verlor 2019 durch einen öffentlichen S3-Bucket 106 Millionen Kundendatensätze; Toyota 2023 Daten von 2,15 Millionen Fahrzeugen durch denselben Fehler. Erkennung und Behebung via AWS CLI:

# Account-Level Block Public Access prüfen:
aws s3control get-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text)

# Alle Buckets auf öffentliche Policy prüfen:
for bucket in $(aws s3api list-buckets --query "Buckets[].Name" --output text); do
  aws s3api get-bucket-policy-status --bucket $bucket \
    --query 'PolicyStatus.IsPublic' --output text 2>/dev/null && echo " $bucket"
done

# Behebung auf Account-Ebene (empfohlen):
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
    BlockPublicPolicy=true,RestrictPublicBuckets=true

Offene Security Groups (0.0.0.0/0)

Security Groups mit Freigabe auf 0.0.0.0/0 für SSH (22), RDP (3389) oder Datenbankports (3306, 5432) entstehen häufig als temporäre Lösung — und bleiben dauerhaft:

# Security Groups mit 0.0.0.0/0 auf sensitiven Ports:
aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query "SecurityGroups[?contains(IpPermissions[].FromPort,\`22\`) \
           || contains(IpPermissions[].FromPort,\`3389\`)].{ID:GroupId,Name:GroupName}"

# Behebung: SSH auf Management-IP beschränken:
aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 --protocol tcp --port 22 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 --protocol tcp --port 22 --cidr 10.0.100.0/24

Root-Account ohne MFA und überprivilegierte IAM-Policies

Ein Root-Account ohne MFA ist eine vollständige Kompromittierung im Schadensfall. IAM-Policies mit Action: * und Resource: * geben jedem kompromittierten Key Gottmodus über die gesamte AWS-Umgebung:

# Root-MFA-Status prüfen (0 = kein MFA → KRITISCH):
aws iam get-account-summary --query "SummaryMap.AccountMFAEnabled"

# User mit Admin-Rechten auflisten:
aws iam list-attached-user-policies --user-name USERNAME | grep AdministratorAccess

CloudTrail deaktiviert

Kein CloudTrail bedeutet: kein Audit-Log, keine Forensik im Incident-Fall.

# CloudTrail-Status prüfen:
aws cloudtrail describe-trails \
  --query "trailList[*].{Name:Name,Multi:IsMultiRegionTrail}"

# Aktivierung (alle Regionen, mit Manipulationsschutz):
aws cloudtrail create-trail \
  --name organization-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name organization-trail

Azure: Die häufigsten Fehlkonfigurationen

Öffentliche Blob Storage Container

# Alle öffentlichen Container finden:
for storage in $(az storage account list --query "[].name" -o tsv); do
  az storage container list \
    --account-name $storage \
    --query "[?properties.publicAccess!='off'].{Name:name,Access:properties.publicAccess}" \
    --output table 2>/dev/null
done

# Behebung auf Account-Ebene:
az storage account update \
  --name mystorageaccount \
  --resource-group myRG \
  --allow-blob-public-access false

Legacy-Authentifizierung in Entra ID

Legacy-Protokolle (Basic Auth, Exchange ActiveSync) umgehen MFA vollständig. Eine Conditional-Access-Policy blockiert sie zuverlässig:

New-MgConditionalAccessPolicy -BodyParameter @{
  displayName = "Block Legacy Authentication"
  state = "enabled"
  conditions = @{
    clientAppTypes = @("exchangeActiveSync", "other")
    users = @{ includeUsers = @("All") }
    applications = @{ includeApplications = @("All") }
  }
  grantControls = @{
    operator = "OR"
    builtInControls = @("block")
  }
}

Fehlende Resource Locks auf kritischen Ressourcen

Produktionsdatenbanken ohne Lock können versehentlich durch Skripte oder falsch konfigurierte IaC-Pipelines gelöscht werden:

az lock create \
  --name "prod-db-lock" \
  --resource-group production-rg \
  --resource-name prod-postgres-server \
  --resource-type "Microsoft.DBforPostgreSQL/servers" \
  --lock-type CanNotDelete

Cloud Security Posture Management (CSPM)

Manuelle Prüfungen ergänzen CSPM-Tools, ersetzen sie aber nicht. AWS Security Hub aggregiert Findings aus Config, GuardDuty, Inspector und Macie und prüft gegen den CIS AWS Foundations Benchmark (100+ Checks):

aws securityhub enable-security-hub --enable-default-standards
aws securityhub batch-enable-standards \
  --standards-subscription-requests \
    StandardsArn="arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"

Microsoft Defender for Cloud liefert einen Secure Score (0–100) und bildet ISO 27001, NIS2 und DSGVO direkt im Regulatory Compliance Dashboard ab.

Schnell-Checkliste AWS (CLI-Commands):

Prüfpunkt	Befehl
Root-MFA aktiviert?	aws iam get-account-summary
CloudTrail aktiv (alle Regionen)?	aws cloudtrail list-trails
GuardDuty aktiviert?	aws guardduty list-detectors
S3 Block Public Access?	aws s3control get-public-access-block
EBS-Encryption by default?	aws ec2 get-ebs-encryption-by-default
VPC Flow Logs aktiviert?	aws ec2 describe-flow-logs

---

Cloud Workload Protection und Tooling-Landschaft

Klassische EDR-Lösungen auf dem Host reichen in Container-Umgebungen nicht mehr aus: Angreifer targeten Container-Images, Lambda-Funktionen und Kubernetes-APIs direkt. Cloud Workload Protection Platforms (CWPP) und Cloud Access Security Broker (CASB) schließen diese Lücken.

CWPP: Container- und Workload-Schutz

CWPP-Lösungen decken sieben Schutzschichten ab — von CIS-Benchmark-Compliance über eBPF-basiertes Syscall-Profiling bis zur forensischen Container-Terminierung bei Laufzeitangriffen.

Führende Lösungen im Vergleich:

Lösung	Schwerpunkt	Besonderheit
Aqua Security	End-to-End Container (Build→Run)	Dynamic Threat Analysis in isolierter Sandbox; Drift-Prevention verhindert Schreibzugriffe auf Image-Layer
Prisma Cloud	CNAPP (CSPM + CWPP + CIEM)	OPA/Rego-Policies, Serverless-Schutz (Lambda), Net-Effective-Permissions-Analyse
Sysdig / Falco	Detection & Response	eBPF-Syscall-Überwachung, Falco-Regelwerk für Container-Escape und Crypto-Mining

Falco-Regel für Container-Escape-Erkennung:

- rule: Terminal shell in container
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
    and container_entrypoint
  output: >
    Shell in Container (user=%user.name container=%container.name
     image=%container.image.repository cmd=%proc.cmdline)
  priority: NOTICE

- rule: Container escape via nsenter
  condition: spawned_process and proc.name = "nsenter" and container
  output: "nsenter in Container - möglicher Escape-Versuch!"
  priority: CRITICAL

CWPP vs. CNAPP:

Ansatz	Fokus	Typische Produkte
CWPP	Container/VM/Serverless Schutz, Runtime Detection	Aqua Security, Sysdig
CNAPP	CWPP + Cloud-Konfiguration (Code-to-Cloud)	Prisma Cloud, Wiz, Lacework, Orca Security

Für Unternehmen, die erstmals CWPP einführen: Agentless-Tools (Wiz, Orca) liefern schnelle Visibility ohne DaemonSet-Rollout — decken aber keine Laufzeit-Container-Escapes ab. Agentbasierte Lösungen (Aqua, Sysdig) bieten vollständige Laufzeit-Telemetrie auf Kosten von ~1–3 % CPU-Overhead.

CASB: Shadow-IT und Cloud-Datenverlust

Mitarbeiter nutzen im Durchschnitt 80–100 Cloud-Services — IT-Abteilungen kennen oft weniger als 20 davon. Cloud Access Security Broker schließen diese Kontrollücke über vier Funktionsbereiche:

1. Shadow-IT-Discovery: Welche Cloud-Services werden genutzt? Cloud-App-Inventar mit Risikobewertung.
2. Data Loss Prevention (DLP): Sensible Daten in der Cloud erkennen (PII, Kreditkarten, geistiges Eigentum) und Uploads in nicht genehmigte Apps blockieren.
3. Threat Protection: Anomalie-Erkennung (Impossible Travel, Bulk-Download), Malware-Scanning vor Upload/Download.
4. Compliance: DSGVO, HIPAA und PCI-DSS in Cloud-Konfigurationen durchsetzen.

CASB-Deployment-Modelle:

Modell	Funktionsprinzip	Ideal für
API-basiert	Direkte Integration mit Cloud-Provider (M365, Google Workspace)	DLP in genehmigten SaaS-Apps, kein Proxy-Overhead
Forward-Proxy	Client-Traffic → CASB → Internet	Shadow-IT-Discovery, granulare App-Steuerung
Reverse-Proxy	IdP leitet Auth zu CASB um (agentless)	BYOD, externe Partner

Microsoft Defender for Cloud Apps (MDCA) ist die empfohlene Lösung für M365-Umgebungen: tiefste Entra ID-Integration, Shadow-IT via Microsoft Defender for Endpoint (ohne Proxy), Teil von M365 E5. Netskope ermöglicht Instance-Level-Kontrolle — "Unternehmens-Google-Drive erlaubt, privates Google Drive: Upload blockiert" — und eignet sich für SASE-Architekturen.

KQL-Abfrage für DLP-Alert-Monitoring in Sentinel:

CloudAppEvents
| where ActionType == "DlpRuleMatch"
| where PolicyName contains "PII" or PolicyName contains "IBAN"
| summarize MatchCount = count() by AccountDisplayName, ApplicationName
| where MatchCount > 5
| order by MatchCount desc

---

Cloud Incident Response

Cloud-Sicherheitsvorfälle folgen anderen Regeln als On-Premise-Incidents: Infrastruktur kann in Sekunden verschwinden, Logs löschen sich nach Retention-Perioden automatisch, und forensisches Containment bedeutet API-Calls statt physisches Abkabeln. Gleichzeitig bieten Cloud-Umgebungen durch native Logging-Capabilities oft bessere Forensik-Möglichkeiten.

On-Premise vs. Cloud IR

Aspekt	On-Premise	Cloud (AWS/Azure/GCP)
Festplatte sichern	dd-Image physisch erstellen	EBS/Disk-Snapshot via API-Call (Minuten)
Netzwerkverkehr	SPAN-Port capture	VPC/NSG Flow Logs (bereits vorhanden)
Isolation	Kabel ziehen	Security Group / NSG-Regel ändern
Zeitbedarf Containment	Stunden bis Tage	Minuten

AWS Incident Response

Detection: GuardDuty erkennt automatisch Crypto-Mining (CryptoCurrency:EC2/BitcoinTool), IAM-Missbrauch (UnauthorizedAccess:IAMUser/TorIPCaller) und S3-Anomalien. CloudTrail protokolliert jede API-Aktion — die wichtigsten Events bei einem Incident:

• AssumeRole — welche Rolle wurde angenommen?
• CreateAccessKey — neuer API-Key = mögliche Persistenz
• PutBucketPolicy — S3-Policy geändert
• RunInstances — neue EC2 gestartet (Mining?)
• DeleteTrail — CloudTrail deaktiviert (Anti-Forensik!)

Containment-Playbook AWS:

# 1. Kompromittierten Access-Key deaktivieren (nicht löschen — Forensik braucht den ARN):
aws iam update-access-key \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive \
  --user-name compromised-user

# 2. IAM-User in Quarantäne (Deny-All):
aws iam put-user-policy \
  --user-name compromised-user \
  --policy-name QuarantinePolicy \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*"}]}'

# 3. EC2-Instanz isolieren (Forensik-Security-Group ohne In/Outbound):
FORENSIC_SG=$(aws ec2 create-security-group \
  --group-name forensic-isolation \
  --description "Forensic isolation" \
  --vpc-id $VPC_ID \
  --query 'GroupId' --output text)
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --groups $FORENSIC_SG

# 4. EBS-Snapshot VOR Termination erstellen:
aws ec2 create-snapshot \
  --volume-id vol-1234567890abcdef0 \
  --description "FORENSIC-$(date +%Y%m%d) - Incident ABC-2026-001"

# 5. IMDSv2 enforzen (verhindert SSRF→Metadata-Service→Credentials):
aws ec2 modify-instance-metadata-options --http-tokens required

CloudTrail Athena-Query zur Kompromittierungs-Analyse:

SELECT userIdentity.arn, eventName, sourceIPAddress, eventTime
FROM cloudtrail_logs
WHERE eventTime > '2026-01-01'
  AND sourceIPAddress NOT LIKE '10.%'
  AND eventName IN ('AssumeRole', 'CreateAccessKey', 'PutUserPolicy')
ORDER BY eventTime DESC
LIMIT 100;

Häufige AWS-Angriffsszenarien:

• IAM-Key in Git committed: Innerhalb von Minuten nach Commit scannt Automatisierung GitHub nach Keys. Erkennung: CloudTrail zeigt S3-GetObject-Flood von fremder Datacenter-IP.
• Crypto-Mining via SSRF: SSRF-Schwachstelle → Metadata-Service (169.254.169.254) → EC2-IAM-Role → RunInstances in fremder Region. GuardDuty erkennt CryptoCurrency-Finding.
• Root-Account-Nutzung: Root sollte nie für tägliche Arbeit genutzt werden. CloudWatch Alarm auf ConsoleLogin für Root konfigurieren.

Azure Incident Response

Containment-Playbook Azure:

# 1. Alle aktiven Sessions invalidieren:
az ad user revoke-sign-in-sessions --id compromised@company.com

# 2. VM mit Forensik-NSG isolieren:
az network nsg create -g MyRG -n forensic-isolation
az network nic update \
  --resource-group MyRG \
  --name compromised-vm-NIC \
  --network-security-group forensic-isolation

# 3. VM-Disk-Snapshot:
az snapshot create \
  --resource-group MyRG \
  --name forensic-snap-$(date +%Y%m%d) \
  --source /subscriptions/.../disks/compromised-vm-osdisk

KQL-Abfrage in Sentinel (Activity Log):

AzureActivity
| where TimeGenerated > ago(7d)
| where Caller == "suspicious@company.com"
| where OperationNameValue contains "write" or OperationNameValue contains "delete"
| project TimeGenerated, OperationNameValue, ResourceGroup, CallerIpAddress
| order by TimeGenerated desc

Häufige Azure-Angriffsszenarien:

• Illicit Consent Grant: Angreifer registriert böswillige OAuth-App → Phishing → User erteilt Consent → App liest E-Mails/Dateien. Erkennung: Entra ID → Enterprise Apps → Unusual Consent.
• Service-Principal-Credential-Leak: SP-Client-Secret in Git/CI-CD exponiert → Contributor-Rechte → Resource-Erstellung in fremder Region.

GCP Incident Response

# Service-Account-Key deaktivieren:
gcloud iam service-accounts keys disable KEY_ID \
  --iam-account=compromised-sa@project.iam.gserviceaccount.com

# VM-Instanz isolieren:
gcloud compute firewall-rules create forensic-isolation \
  --network=default --action=DENY --direction=INGRESS \
  --rules=all --target-tags=forensic-isolated
gcloud compute instances add-tags compromised-vm \
  --tags=forensic-isolated --zone=europe-west3-a

# Disk-Snapshot:
gcloud compute disks snapshot compromised-vm-boot \
  --snapshot-names=forensic-$(date +%Y%m%d) \
  --zone=europe-west3-a

Cloud-IR-Zeitplan (Kurzreferenz)

Zeitpunkt	Maßnahmen
T+0 (Entdeckung)	Alert validieren, Severity einschätzen, IR-Team informieren, Ticket eröffnen
T+15 min	Kompromittierte Identität identifizieren, Blast Radius kartieren, Logs exportieren
T+30 min	Credentials deaktivieren, Ressourcen isolieren, Snapshots erstellen, CI/CD pausieren
T+1 h	API-Logs auf Exfiltration prüfen, Persistenz-Mechanismen identifizieren, Initial-Access-Vektor bestimmen
T+4 h	Alle Credentials rotieren, Root Cause beheben, kompromittierte Ressourcen terminieren
T+24 h	Monitoring verschärfen, Datenpanne prüfen (DSGVO-Meldepflicht: 72 h!)

DSGVO-Hinweis: Bei Cloud-Incidents mit personenbezogenen Daten greift die 72-Stunden-Meldepflicht nach Art. 33 DSGVO. Das gilt auch wenn die Daten bei einem Cloud-Anbieter liegen — die Verantwortung bleibt beim Kunden.

---

FAQ

Benötige ich eine Genehmigung des Cloud-Anbieters für einen Pentest? Für Tests gegen kundeneigene Ressourcen - EC2-Instanzen, S3-Buckets, eigene VMs - ist in der Regel keine gesonderte Genehmigung erforderlich. AWS, Azure und GCP erlauben diese Tests in ihren Nutzungsbedingungen. DoS-Tests und Tests gegen geteilte Infrastruktur sind jedoch bei allen Anbietern verboten.

Was ist der Unterschied zwischen einem Cloud-Pentest und einem Cloud-Security-Audit? Ein Pentest simuliert aktiv Angriffe gegen die Umgebung und versucht, Schwachstellen auszunutzen. Ein Security-Audit überprüft Konfigurationen, Richtlinien und Berechtigungskonzepte ohne aktive Exploitation. Beide Ansätze ergänzen sich; AWARE7 kombiniert je nach Anforderung beide Methoden.

Kann ein Cloud-Pentest die Verfügbarkeit meiner Dienste beeinträchtigen? Bei korrekter Abstimmung und Einhaltung der Anbieter-Richtlinien ist das Risiko minimal. DoS-Tests werden grundsätzlich nicht durchgeführt. Dennoch empfiehlt sich die Durchführung außerhalb der Hauptgeschäftszeiten und mit definierten Rollback-Plänen.

Wie lange dauert ein Cloud-Penetrationstest? Die Dauer hängt vom Scope ab. Ein fokussierter AWS-Test einer mittelgroßen Umgebung (10-20 Services) dauert typischerweise 3-5 Tage. Ein umfassendes Cloud-Security-Assessment inklusive Kubernetes-Cluster kann 1-2 Wochen in Anspruch nehmen.

Was kostet ein Cloud-Pentest? Die Kosten variieren erheblich je nach Scope, Tiefe und Anzahl der zu testenden Services. Für eine konkrete Einschätzung Ihrer Cloud-Umgebung empfehlen wir eine kostenlose Erstberatung.

Welche Cloud-Plattformen testet AWARE7? AWARE7 führt Penetrationstests für AWS, Azure, GCP sowie Kubernetes-Cluster durch - unabhängig ob On-Premise (K3s, OpenShift), in der Cloud (EKS, GKE, AKS) oder in hybriden Umgebungen. Mehr Informationen unter Cloud Security.