Cloud IAM Privilege Escalation nutzt übermäßige Berechtigungen und Fehlkonfigurationen, um von eingeschränkten Zugriffsrechten zur vollständigen Cloud-Kontrolle zu eskalieren.
AWS IAM — Privilege Escalation Chains & IMDS-Exploitation
AWS IAM ist ein Policy-basiertes Berechtigungssystem mit Identity Policies (an User/Role/Group angeheftet), Resource Policies (an S3/SQS/Lambda angeheftet) und Permission Boundaries. Die Komplexität dieses Systems — insbesondere die Evaluation Logic (Explicit Deny > SCP > Permission Boundary > Identity Policy) — führt zu zahlreichen Fehlkonfigurationen, die Privilege Escalation ermöglichen. Das Tool Pacu (Rhino Security Labs) automatisiert die Erkennung und Ausnutzung dieser Schwachstellen.
- iam:PassRole + Service Exploitation: Die gefährlichste AWS-Privilege-Escalation nutzt
iam:PassRolein Kombination mit Service-Erstellungsberechtigungen: Ein Benutzer mitiam:PassRoleundlambda:CreateFunction+lambda:InvokeFunctionkann eine Lambda-Funktion erstellen, die eine hochprivilegierte Rolle annimmt — und dann beliebige Aktionen in deren Kontext ausführen. Gleiches gilt füriam:PassRole+ec2:RunInstances(EC2-Instanz mit Admin-Role starten),iam:PassRole+glue:CreateDevEndpoint(Glue-Endpoint mit priveligierter Rolle),iam:PassRole+ecs:RegisterTaskDefinition(ECS-Task mit Rolle). Pacu erkennt diese Kombinationen automatisch mit dem Moduliam__privesc_scan. Verteidigung: iam:PassRole auf spezifische Rollen-ARNs einschränken — niemalsResource: "*"verwenden. - iam:CreatePolicyVersion & Policy-Manipulation: Ein Benutzer mit
iam:CreatePolicyVersionkann eine neue Version einer bestehenden IAM-Policy erstellen und als Default setzen — effektiv beliebige Berechtigungen hinzufügen:aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/MyPolicy --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' --set-as-default. Verwandte Techniken:iam:AttachUserPolicy(AWS-Managed-Admin-Policy anhängen),iam:PutUserPolicy(Inline-Policy mit*:*erstellen),iam:AttachGroupPolicy/iam:AttachRolePolicy(indirekte Eskalation über Gruppen/Rollen). sts:AssumeRole Chains: Rolle A darf Rolle B annehmen, Rolle B darf Rolle C annehmen — transitive Eskalation über mehrere Konten hinweg. AWS Access Analyzer erkennt Cross-Account-Zugriffsberechtigungen, findet aber nicht alle transitiven Pfade. - IMDS v1 Credential Theft & SSRF: Der Instance Metadata Service (IMDS) unter
http://169.254.169.254liefert temporäre Credentials der an eine EC2-Instanz angehefteten IAM-Rolle. IMDS v1 ist per einfachem HTTP-GET erreichbar — jede Server-Side Request Forgery (SSRF)-Schwachstelle in einer Webanwendung auf EC2 kann diese Credentials exfiltrieren:curl http://169.254.169.254/latest/meta-data/iam/security-credentials/RoleNameliefert AccessKeyId, SecretAccessKey und SessionToken. Berühmtester Fall: Capital One Breach 2019 (100 Millionen Datensätze via SSRF + IMDS v1). IMDS v2 erfordert einen PUT-Request mit TTL-Header zum Erhalt eines Session-Tokens — dies blockiert die meisten SSRF-Angriffe, da SSRF typischerweise keine Custom-Header setzen kann. Maßnahme: IMDS v1 deaktivieren mitaws ec2 modify-instance-metadata-options --instance-id i-xxx --http-tokens required. - Cross-Account-Angriffe & Organization-Exploitation: In AWS Organizations mit vielen Accounts eröffnet die Kompromittierung eines einzelnen Accounts oft laterale Bewegung:
sts:AssumeRolemit Cross-Account-Trust-Policies ermöglicht den Wechsel in andere Accounts. OrganizationAccountAccessRole — die Default-Rolle, die AWS beim Account-Erstellen über Organizations anlegt — hat AdministratorAccess und vertraut dem Management-Account: Kompromittierung des Management-Accounts = Zugriff auf alle Member-Accounts. SCPs (Service Control Policies) können Eskalation einschränken, werden aber oft umgangen, wenniam:CreatePolicyVersionnicht explizit denied wird. Terraform/CloudFormation State Files in S3 enthalten häufig Secrets und IAM-Keys im Klartext — ein oft übersehener Angriffsvektor. Empfehlung: S3-Bucket-Policies mits3:GetObject-Deny für State Files, Encryption at Rest, und State Locking mit DynamoDB.
Azure & GCP — RBAC & Service Account Abuse
Azure RBAC und GCP IAM verwenden rollenbasierte Zugriffskontrolle mit feingranularen Berechtigungen, die auf verschiedenen Ebenen (Management Group, Subscription, Resource Group bzw. Organization, Folder, Project) zugewiesen werden können. Beide Plattformen haben spezifische Eskalationspfade, die sich fundamental von AWS unterscheiden — insbesondere durch Managed Identities (Azure) und Service Account Impersonation (GCP). Die Tools ROADtools (Azure AD Enumeration), AzureHound (BloodHound für Azure), MicroBurst und ScoutSuite (Multi-Cloud) automatisieren die Erkennung.
- Azure RBAC Privilege Escalation: Die drei gefährlichsten Azure-Rollen: Owner (Vollzugriff + Rollenzuweisung), Contributor (Vollzugriff ohne Rollenzuweisung — kann aber über Automation Accounts, Function Apps oder Custom Script Extensions eskalieren), User Access Administrator (kann sich selbst Owner-Rechte zuweisen). Eskalationspfad: Contributor erstellt eine Azure Function mit System-Assigned Managed Identity → weist dieser Identity über ARM-Template die Owner-Rolle zu → nutzt die Function zum Ausführen privilegierter Aktionen. Custom-Role-Abuse: Ein Benutzer mit
Microsoft.Authorization/roleDefinitions/writekann eine Custom-Role erstellen, die beliebige Berechtigungen enthält. AzureHound/BloodHound visualisiert diese Eskalationspfade als Graphen — kürzester Pfad von kompromittiertem Benutzer zu Global Admin. - Managed Identity & Automation Account Abuse: System-Assigned Managed Identities sind an Azure-Ressourcen gebunden und erhalten IAM-Tokens über den IMDS-Endpunkt (
http://169.254.169.254/metadata/identity/oauth2/token): Jede Code-Ausführung auf der Ressource (VM, Function App, App Service) kann das Token abrufen und dessen Berechtigungen nutzen. Automation Accounts mit RunAs-Konten (Service Principals mit Zertifikat) haben oft übermäßige Berechtigungen — Contributor auf Subscription-Ebene ist üblich. Ein Angreifer mit Zugriff auf den Automation Account kann Runbooks erstellen, die im Kontext des RunAs-Accounts ausgeführt werden. PIM-Abuse (Privileged Identity Management): Wenn ein Benutzer eine eligible Global-Admin-Rolle hat, kann er diese aktivieren — ohne Approval, wenn MFA die einzige Anforderung ist und der Angreifer bereits MFA-Zugriff hat (z. B. über AitM-Phishing mit Evilginx2). Gegenmaßnahme: PIM mit Approval-Workflow, Conditional Access mit Compliant Device als Anforderung. - GCP IAM & Service Account Exploitation: GCP IAM verwendet Rollen (Predefined + Custom) die auf Resources (Organization, Folder, Project, einzelne Ressource) gebunden werden. Kritischste Berechtigungen:
iam.serviceAccounts.getAccessToken(Token eines Service Accounts anfordern — direkte Impersonation),iam.serviceAccounts.signBlob(beliebige Daten im Namen des SAs signieren — ermöglicht OAuth-Token-Erstellung),resourcemanager.projects.setIamPolicy(IAM-Policy des Projekts ändern — sich selbst Owner geben). Service Account Key Theft: Heruntergeladene JSON-Keys haben keine Ablaufzeit und sind äquivalent zu Langzeit-Credentials. Impersonation Chains: SA-A darf SA-B impersonaten, SA-B darf SA-C impersonaten — transitive Eskalation, die IAM Analyzer nicht vollständig erkennt. Default Service Accounts (Compute Engine, App Engine) haben oft die Rolle Editor auf Projektebene — viel zu weit gefasst. - Cross-Cloud-Angriffe & OIDC Federation: Moderne Multi-Cloud-Umgebungen nutzen Workload Identity Federation: GCP-Workloads authentifizieren sich bei AWS über OIDC, Azure-Pipelines erhalten GCP-Tokens über WIF. Ein Angreifer, der einen Cloud-Provider kompromittiert, kann über Federation in den nächsten eskalieren: Kompromittiertes AWS-Konto → OIDC-Token erstellen → GCP Service Account annehmen → GCP-Ressourcen kompromittieren. GitHub Actions OIDC zu AWS/Azure/GCP ist besonders kritisch: Ein Angreifer mit Push-Zugriff auf ein Repository kann den Workflow modifizieren und damit Cloud-Credentials erhalten. CloudTrail/Azure Activity Log Evasion: Einige API-Calls werden nicht geloggt (z. B.
s3:GetObjectin Data Events, die separat aktiviert werden müssen), und Log-Manipulation ist möglich, wenn der Angreifercloudtrail:StopLoggingodercloudtrail:DeleteTrailausführen kann. Empfehlung: CloudTrail Organization Trail mit S3 Object Lock (WORM) und CloudTrail Log File Integrity Validation.
Cloud Security Monitoring & Hardening — Eskalation verhindern
Cloud Security Posture Management (CSPM) und Cloud Infrastructure Entitlement Management (CIEM) sind die zentralen Verteidigungssäulen gegen IAM-Privilege-Escalation. CSPM-Tools wie Prowler, ScoutSuite und CloudSploit scannen kontinuierlich nach Fehlkonfigurationen, während CIEM-Plattformen wie Ermetic und CloudKnox übermäßige Berechtigungen identifizieren und Least-Privilege-Empfehlungen aussprechen. Die Kombination aus präventiven Controls (SCPs, Permission Boundaries, Conditional Access) und detektiven Controls (CloudTrail, GuardDuty, Azure Sentinel) bildet eine effektive Defense-in-Depth-Strategie.
- AWS-Hardening & Least Privilege: IAM Access Analyzer generiert Least-Privilege-Policies basierend auf CloudTrail-Logs:
aws accessanalyzer generate-policy --policy-generation-details '{"principalArn":"arn:aws:iam::123456789012:role/MyRole"}'— analysiert 90 Tage CloudTrail und erstellt eine Policy mit nur den tatsächlich genutzten Berechtigungen. SCPs (Service Control Policies) auf OU-Ebene verhindern gefährliche Aktionen organisationsweit:{"Effect":"Deny","Action":["iam:CreateUser","iam:CreateAccessKey","iam:CreatePolicyVersion"],"Resource":"*"}. Permission Boundaries begrenzen die maximalen Berechtigungen, die ein Benutzer delegieren kann — selbst wenn eriam:PassRolehat. Prowler (Open Source) scannt AWS-Accounts gegen CIS Benchmark, NIST 800-53, PCI-DSS und identifiziert über 300 Fehlkonfigurationen. GuardDuty erkennt IAM-Anomalien: ungewöhnliche API-Calls, Credential-Nutzung aus unüblichen Regionen, bekannte Angreifer-IPs. - Azure Security Hardening: Conditional Access Policies sind die erste Verteidigungslinie: Compliant Device als Anforderung für privilegierte Rollen (blockiert Token-Theft-Angriffe), Named Locations (nur aus Firmennetzwerk), Sign-in Risk Policy (blockiert Anmeldungen mit hohem Risiko-Score). PIM Best Practices: Alle privilegierten Rollen als eligible (nicht permanent) konfigurieren, Approval-Workflow für Global Admin / Privileged Role Admin, maximale Aktivierungsdauer von 4 Stunden, Access Reviews alle 30 Tage. Microsoft Defender for Cloud (CSPM-Modul) bewertet den Security Score und identifiziert übermäßige Berechtigungen. Entra ID Workload Identity: Service Principals mit Federated Credentials statt Client Secrets (keine langlebigen Credentials). Azure Policy:
Deny-Policies für Custom-Role-Erstellung und Managed-Identity-Zuweisung auf sensiblen Ressourcen. - Multi-Cloud-Monitoring mit SIEM-Integration: CloudTrail (AWS), Azure Activity Log (Azure) und Cloud Audit Logs (GCP) müssen zentral in einem SIEM (Splunk, Microsoft Sentinel, Elastic) aggregiert werden. Kritische Detection Rules:
iam:CreatePolicyVersionmitEffect:Allow, Action:*(Privilege Escalation Attempt),sts:AssumeRolevon ungewöhnlichen Quell-Accounts,ConsoleLoginohne MFA,CreateAccessKeyfür fremde Benutzer,StopLogging/DeleteTrail(Anti-Forensik). ScoutSuite (NCC Group) führt Multi-Cloud-Audits durch und generiert HTML-Reports mit priorisierten Findings. Cartography (Lyft) erstellt einen Graphen aller Cloud-Assets und Beziehungen in Neo4j — ermöglicht Cypher-Queries wie „Finde alle IAM-Rollen, die indirekt s3:* erlauben“. CloudQuery synchronisiert Cloud-Assets in PostgreSQL für SQL-basierte Sicherheitsanalysen. - Infrastructure as Code Security: Terraform/CloudFormation-Templates sind der Ursprung vieler IAM-Fehlkonfigurationen — Security muss im CI/CD-Pipeline ansetzen, nicht erst nach dem Deployment. Checkov (Bridgecrew/Palo Alto) scannt Terraform/CloudFormation/Kubernetes-Manifeste auf über 1.000 Security-Policies:
checkov -d ./terraform --check CKV_AWS_61prüft, ob IAM-Policies*:*enthalten. tfsec (Aqua Security) ist spezialisiert auf Terraform und erkennt IAM-Misconfigurations: wildcard Actions, fehlende Permission Boundaries, offene S3-Buckets. OPA/Rego (Open Policy Agent) ermöglicht Custom-Policies:deny[msg] { input.resource.aws_iam_policy.policy contains "Action\": \"*\"" }. Shift-Left-Strategie: IDE-Plugins (VS Code Checkov Extension) zeigen IAM-Probleme bereits beim Schreiben des Codes. Sentinel (HashiCorp) erzwingt Policies direkt im Terraform-Workflow und blockiertterraform applybei Verstößen.
← Vorheriger Artikel
Malware-Analyse & Reverse Engineering
Nächster Artikel →
Kernel Exploitation & Rootkits
Sie benötigen Unterstützung?
Cloud IAM Privilege Escalation ist der häufigste Angriffsvektor in modernen Cloud-Umgebungen. Wir führen Cloud-Security-Assessments durch, identifizieren übermäßige Berechtigungen und implementieren Least-Privilege-Architekturen — über AWS, Azure und GCP hinweg.
Security & Firewall ansehen →
