In Aws: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Purple Teaming in AWS ist kein klassischer Cloud-Pentest und auch kein reines Red-Team-Szenario. Der Kern liegt darin, offensive Techniken kontrolliert gegen reale oder realitätsnahe AWS-Workloads auszuführen und parallel zu prüfen, ob Telemetrie, Erkennung, Alarmierung und Reaktionsprozesse tatsächlich greifen. Genau an diesem Punkt scheitern viele Teams: Es werden einzelne Angriffe nachgestellt, aber weder Hypothesen formuliert noch Detection-Gaps sauber dokumentiert. Das Ergebnis sind isolierte Findings statt belastbarer Verbesserungen.

In AWS ist dieser Ansatz besonders wertvoll, weil Angriffe oft nicht mit Malware oder Exploits beginnen, sondern mit Identitäten, Rollen, API-Aufrufen und Fehlkonfigurationen. Ein kompromittierter IAM-User, ein zu weit gefasster Trust-Policy-Eintrag, ein öffentlich erreichbarer S3-Bucket oder ein EC2-Instance-Profile mit übermäßigen Rechten reichen häufig aus, um sich lateral zu bewegen. Purple Teaming muss deshalb Cloud-spezifisch gedacht werden. Wer nur klassische Endpoint-Techniken auf EC2 betrachtet, übersieht den eigentlichen Angriffsraum.

Ein sauberer Einstieg beginnt mit einer klaren Zieldefinition. Typische Ziele sind: Erkennung von Credential-Missbrauch, Sichtbarkeit bei Privilege Escalation über IAM, Alarmierung bei verdächtigen S3-Zugriffen, Erkennung von Persistenz über neue Access Keys oder Nachweis, dass CloudTrail, GuardDuty und SIEM-Korrelationen zusammen funktionieren. Die operative Umsetzung orientiert sich häufig an Und Mitre Attack, muss aber an AWS-Techniken angepasst werden. Besonders hilfreich ist dabei ein enger Bezug zu Und Detection Engineering, weil in der Cloud nicht nur der Angriffspfad zählt, sondern vor allem die Qualität der Signale.

Ein belastbares Purple-Teaming-Szenario in AWS beantwortet immer vier Fragen: Welche Technik wird simuliert, welche Datenquellen müssen sie sichtbar machen, welche Detection soll auslösen und welche Reaktion wird erwartet? Ohne diese Kette bleibt die Übung unvollständig. Ein Beispiel: Wenn ein Angreifer mit gestohlenen Access Keys aus einem ungewöhnlichen Land API-Calls gegen IAM und S3 ausführt, dann müssen CloudTrail-Events vorhanden, GuardDuty-Findings plausibel, SIEM-Regeln abgestimmt und Eskalationswege getestet sein. Erst wenn diese Kette funktioniert, entsteht echter Sicherheitsgewinn.

Im Unterschied zu generischen Übungen in In Cloud Umgebungen ist AWS stark API-zentriert. Das verändert die Methodik. Statt nur Hosts zu scannen oder Webanwendungen zu testen, wird auf Rollenannahme, Policy-Missbrauch, Service-Interaktionen, Event-basierte Persistenz und Datenabfluss über native Dienste geschaut. Wer Purple Teaming in AWS ernsthaft betreibt, arbeitet deshalb nicht nur mit Pentest-Werkzeugen, sondern auch mit CloudTrail-Analysen, IAM-Simulationen, EventBridge-Triggern, VPC Flow Logs, DNS-Logs, S3 Data Events und den Findings aus GuardDuty oder Security Hub.

Viele Sicherheitsprogramme fokussieren in AWS zu stark auf Netzwerkgrenzen. In der Praxis entstehen die meisten kritischen Risiken jedoch in der Kontroll-Ebene und im Identitätsmodell. IAM ist das Herzstück fast jedes Angriffswegs. Sobald ein Angreifer gültige Zugangsdaten besitzt oder eine Rolle übernehmen kann, verschiebt sich der Fokus von Exploitation zu Berechtigungsanalyse. Purple Teaming muss deshalb mit einem präzisen Verständnis für IAM-Policies, Resource Policies, SCPs, Permission Boundaries und Trust Relationships arbeiten.

Ein typischer Angriffsweg beginnt mit kompromittierten Zugangsdaten. Diese stammen aus geleakten Repositories, falsch gesicherten CI/CD-Systemen, SSRF auf EC2-Workloads mit Zugriff auf die Instance Metadata oder aus lokalen Entwicklerumgebungen. Danach folgt die Frage: Welche Aktionen sind mit diesen Rechten möglich? In AWS ist nicht nur relevant, was direkt erlaubt ist, sondern auch, welche indirekten Eskalationspfade existieren. Wer etwa iam:PassRole, lambda:CreateFunction oder ec2:RunInstances missbrauchen kann, erreicht oft mehr als es auf den ersten Blick scheint.

Ein zweiter Schwerpunkt ist Storage. S3 bleibt einer der häufigsten Risikobereiche, nicht nur wegen öffentlicher Buckets, sondern wegen unklarer Bucket Policies, fehlender Data Events, unzureichender Verschlüsselungskontrollen und mangelnder Überwachung ungewöhnlicher Zugriffe. Purple Teaming sollte hier nicht bei der Frage stehen bleiben, ob ein Bucket öffentlich ist. Wichtiger ist, ob Massen-Downloads, Zugriffe von neuen Principals, Änderungen an Bucket Policies oder das Abschalten von Logging erkannt werden.

Ein dritter Bereich ist die Metadaten- und Laufzeitebene. Auf EC2 sind SSRF-Szenarien gegen IMDS weiterhin relevant, insbesondere wenn IMDSv1 noch aktiv ist oder Anwendungen unkontrolliert externe URLs abrufen. In Container-Umgebungen auf ECS oder EKS verschiebt sich das Risiko auf Task Roles, Service Accounts und falsch segmentierte Berechtigungen. Wer bereits Erfahrungen mit In Kubernetes gesammelt hat, erkennt schnell Parallelen: Nicht der einzelne Container ist das Hauptproblem, sondern die Kombination aus Identität, Orchestrierung und unzureichender Telemetrie.

Für Purple Teaming in AWS lohnt sich eine strukturierte Betrachtung der Angriffsfläche:

• Identitäten: IAM-User, Rollen, Federation, Access Keys, STS, Cross-Account-Trusts
• Compute: EC2, Lambda, ECS, EKS, Build-Systeme, Instance Profiles, Runtime-Artefakte
• Daten und Steuerung: S3, Secrets Manager, Parameter Store, KMS, CloudTrail, EventBridge, Organizations

Diese Einteilung hilft, Szenarien nicht nur nach Services, sondern nach Wirkung zu planen. Ein Angriff auf Lambda ist selten nur ein Lambda-Thema. Oft geht es um die Rolle der Funktion, um Zugriff auf Secrets, um Event-Trigger oder um die Möglichkeit, Code unauffällig zu verändern. Genau diese Zusammenhänge müssen in Purple-Team-Übungen sichtbar gemacht werden.

Die Qualität einer Purple-Teaming-Übung in AWS entscheidet sich vor dem ersten API-Call. Ohne klaren Scope entstehen entweder operative Risiken oder wertlose Ergebnisse. Ein produktionsnahes Setup ist sinnvoll, aber nur mit technischen Guardrails. Dazu gehören dedizierte Test-Accounts oder sauber abgegrenzte OUs, definierte Rollback-Mechanismen, Limits für Datenzugriffe, Freigaben für potenziell disruptive Aktionen und ein abgestimmtes Zeitfenster mit SOC, Cloud Operations und Plattformverantwortlichen.

Ebenso wichtig ist die Logging-Basis. Wer Angriffe simuliert, bevor CloudTrail organisationsweit konsistent aktiviert ist, S3 Data Events fehlen oder VPC Flow Logs nur teilweise vorhanden sind, testet nicht Detection, sondern dokumentiert erwartbare Blindstellen. Das kann sinnvoll sein, wenn genau diese Lücken nachgewiesen werden sollen. Dann muss es aber bewusst geschehen. In reifen Umgebungen sollte vorab geprüft werden, ob mindestens Management Events, relevante Data Events, GuardDuty, Config, Security Hub und zentrale Log-Aggregation verfügbar sind. Für viele Teams ist außerdem die Anbindung an Und Siem entscheidend, weil dort Korrelation, Priorisierung und Incident-Handling zusammenlaufen.

Ein häufiger Fehler ist ein zu unscharfer Scope. „IAM testen“ ist kein Szenario. Besser ist eine konkrete Hypothese wie: „Wenn ein kompromittierter Entwickler-Access-Key versucht, über iam:CreateAccessKey, iam:AttachUserPolicy oder sts:AssumeRole seine Rechte auszuweiten, dann erzeugen CloudTrail und GuardDuty verwertbare Signale, das SIEM korreliert diese und das SOC eskaliert innerhalb von 15 Minuten.“ Solche Hypothesen machen Ergebnisse messbar und anschlussfähig für Metriken und Reporting.

Vor dem Start sollten mindestens folgende Punkte geklärt sein:

• Welche Techniken werden simuliert und welche AWS-Services sind betroffen?
• Welche Logs, Findings und Alerts müssen dabei entstehen?
• Welche Aktionen sind ausdrücklich erlaubt, eingeschränkt oder verboten?
• Wer beobachtet live, wer reagiert operativ und wer dokumentiert die Ergebnisse?

In der Praxis bewährt sich ein gemeinsames Runbook. Darin stehen Testschritte, erwartete Telemetrie, Abbruchkriterien, Ansprechpartner und Nachweise. Das reduziert Missverständnisse zwischen Red- und Blue-Perspektive erheblich. Gerade in AWS, wo ein einzelner API-Call weitreichende Folgen haben kann, ist diese Disziplin kein Formalismus, sondern Risikokontrolle. Wer den organisatorischen Teil ignoriert, produziert unnötige Störungen oder unvollständige Erkenntnisse.

Ein weiterer Punkt ist die Baseline. Vor jeder Übung sollte bekannt sein, wie normales Verhalten aussieht. Welche Rollen werden regelmäßig angenommen? Welche Regionen sind üblich? Welche S3-Buckets erzeugen legitime Data Events in hoher Zahl? Ohne diese Baseline sind False Positives und Fehlinterpretationen vorprogrammiert. Purple Teaming ist deshalb eng mit Und Log Analyse und sauberer Kontextbildung verbunden.

Gute AWS-Szenarien orientieren sich an realen Angreiferzielen. Dazu gehören Zugangsdaten beschaffen, Rechte ausweiten, dauerhaft Zugriff behalten und Daten abziehen. Diese Phasen lassen sich in AWS sehr konkret simulieren. Ein Beispiel für Credential Access ist das Auslesen temporärer Credentials über SSRF gegen eine EC2-Anwendung mit Zugriff auf IMDS. Ein anderes Beispiel ist das Auffinden versehentlich veröffentlichter Access Keys in Build-Artefakten oder Repositories. Entscheidend ist nicht nur, ob der Zugriff gelingt, sondern ob die Nutzung dieser Credentials auffällt.

Privilege Escalation ist in AWS oft subtil. Ein User ohne Administratorrechte kann trotzdem gefährlich sein, wenn er Policies anpassen, Rollen weiterreichen oder neue Compute-Ressourcen mit privilegierten Rollen starten darf. Besonders kritisch sind Kombinationen aus iam:PassRole, ec2:RunInstances, lambda:UpdateFunctionCode, glue:CreateDevEndpoint oder cloudformation:CreateStack. Solche Rechte wirken harmlos, ermöglichen aber indirekt die Ausführung mit höheren Privilegien. Purple Teaming sollte diese Pfade gezielt prüfen, statt nur nach offensichtlichen Administratorrechten zu suchen.

Persistenz in AWS wird häufig unterschätzt. Anders als auf klassischen Hosts geht es nicht primär um Registry-Keys oder geplante Tasks, sondern um neue Access Keys, zusätzliche Trust-Beziehungen, manipulierte Lambda-Funktionen, EventBridge-Regeln, Backdoor-Policies oder neue Benutzer in föderierten Identitätsquellen. Ein Angreifer, der unauffällig eine Rolle so verändert, dass ein externes Konto sie übernehmen kann, hat eine sehr robuste Persistenz geschaffen. Wenn solche Änderungen nicht alarmiert werden, bleibt der Zugriff oft lange unentdeckt.

Exfiltration in AWS ist ebenfalls servicegetrieben. Daten werden nicht zwingend über auffällige Netzwerkverbindungen abgezogen. Häufiger sind API-basierte Downloads aus S3, Snapshots, Exporte aus Datenbanken, Kopien in andere Regionen oder Cross-Account-Sharing. Genau deshalb reicht reine Netzwerküberwachung nicht aus. CloudTrail Data Events, S3 Server Access Logging, GuardDuty S3 Protection und SIEM-Korrelationen sind hier entscheidend.

Ein kompaktes Beispiel für einen kontrollierten Testablauf:

1. Nutzung eines bereitgestellten Low-Privilege-Access-Keys
2. Enumerierung von IAM, STS, S3 und Lambda über erlaubte API-Calls
3. Prüfung auf mögliche Rollenannahme oder PassRole-Missbrauch
4. Simulierte Rechteausweitung über eine freigegebene Testrolle
5. Zugriff auf einen Test-S3-Bucket mit Data Events aktiviert
6. Validierung von CloudTrail, GuardDuty, SIEM-Alert und SOC-Reaktion

Solche Szenarien lassen sich gut mit Mitre Attack Mapping verbinden. Wichtig ist aber, nicht nur Techniken abzuhaken. Ein realistisches Szenario bewertet immer auch die operative Kette: Wurde der Angriff erkannt, richtig priorisiert, korrekt interpretiert und sauber eingedämmt? Genau dort trennt sich eine technische Demo von echter Purple-Team-Arbeit.

Detection in AWS scheitert selten daran, dass gar keine Daten vorhanden sind. Häufiger sind die Daten unvollständig, falsch priorisiert oder nicht auf konkrete Angriffshypothesen abgestimmt. CloudTrail ist die zentrale Quelle für Management-Plane-Aktivitäten, aber ohne Data Events bleiben viele S3- oder Lambda-bezogene Aktionen unsichtbar. GuardDuty liefert wertvolle Managed Detections, ersetzt aber keine eigenen Regeln. VPC Flow Logs zeigen Netzwerkbeziehungen, helfen jedoch nur begrenzt bei IAM-Missbrauch. Config erkennt Drift und Fehlkonfigurationen, ist aber kein Echtzeit-Detektor. Security Hub aggregiert Findings, erzeugt aber nicht automatisch gute Korrelationen.

Ein reifes Purple-Team-Programm in AWS betrachtet deshalb jede Technik aus Sicht der benötigten Telemetrie. Wenn eine Rolle unerwartet angenommen wird, braucht es CloudTrail-Events für AssumeRole, Kontext zur Quelle, idealerweise Geo- oder Anomalieinformationen und eine Regel, die legitime Automatisierung von verdächtigem Verhalten trennt. Wenn S3-Daten massenhaft gelesen werden, müssen Data Events aktiv sein. Wenn ein Angreifer eine Lambda-Funktion manipuliert, müssen UpdateFunctionCode- oder UpdateFunctionConfiguration-Events überwacht werden. Wenn neue Access Keys erzeugt werden, darf das nicht als Routine untergehen.

Besonders problematisch sind blinde Flecken an den Übergängen zwischen Diensten. Ein Beispiel: Ein Angreifer nutzt eine kompromittierte CI/CD-Rolle, liest Secrets aus Parameter Store, aktualisiert eine Lambda-Funktion und exfiltriert Daten aus S3. Jeder Schritt erzeugt einzelne Signale, aber ohne Korrelation bleibt das Bild fragmentiert. Genau hier setzt Und Threat Detection an. Purple Teaming muss prüfen, ob aus mehreren schwachen Signalen ein belastbarer Incident entsteht.

In der Praxis haben sich folgende Detection-Felder als besonders relevant erwiesen:

• Ungewöhnliche Nutzung von STS und Rollenannahme, insbesondere Cross-Account und aus atypischen Regionen
• Änderungen an IAM, KMS, CloudTrail, GuardDuty, Config, Security Hub und Logging-Konfigurationen
• Zugriffe auf sensible S3-Buckets, Secrets, Snapshots und Datenbank-Exporte außerhalb normaler Muster

Ein häufiger Denkfehler ist die Annahme, Managed Services würden Detection automatisch lösen. GuardDuty erkennt viel, aber nicht alles. Security Hub sammelt Findings, aber priorisiert nicht im Kontext des eigenen Geschäfts. Ein SIEM kann korrelieren, aber nur mit sauber normalisierten Daten. Purple Teaming deckt diese Lücken auf, weil es nicht nur fragt, ob ein Event existiert, sondern ob daraus eine verwertbare Entscheidung entsteht. Genau deshalb ist die Verbindung zu Und Alerting und Und Soc so wichtig.

Ein gutes Ergebnis einer Übung ist nicht nur „Alert ausgelöst“, sondern zum Beispiel: „AssumeRole aus neuer Region wurde erkannt, aber wegen fehlender Kontextanreicherung nicht priorisiert; S3-Data-Events waren vorhanden, aber nicht an die gleiche Identität korreliert; SOC konnte den Vorfall erst nach manueller CloudTrail-Suche einordnen.“ Solche Erkenntnisse sind operativ wertvoll, weil sie direkt in Detection-Regeln, Enrichment und Playbooks übersetzt werden können.

Der häufigste Fehler ist ein Tool-getriebener Ansatz. Es werden Frameworks, Skripte oder Cloud-Angriffswerkzeuge eingesetzt, ohne vorher festzulegen, welche Sicherheitsannahme geprüft werden soll. Das führt zu Aktivität, aber nicht zu Erkenntnis. In AWS ist dieser Fehler besonders teuer, weil die Zahl möglicher API-Kombinationen hoch ist. Ohne Hypothese verzetteln sich Teams schnell in Enumerierung und Einzelbeobachtungen.

Ein zweiter Fehler ist die Verwechslung von Fehlkonfigurationsscan und Purple Teaming. Natürlich sind IAM-Analysen, Config-Regeln und CSPM-Befunde wichtig. Aber Purple Teaming beginnt dort, wo kontrolliert geprüft wird, wie sich eine Schwäche tatsächlich ausnutzen lässt und ob Detection und Reaktion greifen. Ein offener S3-Bucket ist ein Finding. Ein Purple-Team-Szenario prüft zusätzlich, ob Policy-Änderungen, Massenzugriffe, Cross-Account-Reads oder das Abschalten von Logging erkannt werden.

Sehr verbreitet ist auch ein zu enger Fokus auf EC2. Viele Teams behandeln AWS wie ein klassisches Rechenzentrum mit virtuellen Maschinen. Dadurch bleiben serverlose und identitätsbasierte Pfade unterbelichtet. Lambda, Step Functions, EventBridge, Glue, CodeBuild, ECR, Secrets Manager und Organizations werden oft erst betrachtet, wenn bereits ein Incident stattgefunden hat. Ein reifes Vorgehen orientiert sich daher an der tatsächlichen Cloud-Nutzung des Unternehmens und nicht an gewohnten On-Prem-Mustern.

Weitere typische Fehler sind unvollständige Logs, fehlende Data Events, kein organisationsweites CloudTrail, unklare Zuständigkeiten zwischen Cloud-Plattform und SOC, fehlende Rollback-Pläne und mangelnde Dokumentation. Gerade letzteres ist kritisch. Wenn nach einer Übung nicht klar ist, welche Technik getestet wurde, welche Events entstanden, welche Detection fehlte und welche Maßnahme beschlossen wurde, dann wiederholt sich der gleiche Fehler beim nächsten Durchlauf. Wer tiefer in wiederkehrende Probleme einsteigen will, findet ergänzende Perspektiven unter Typische Fehler Beim Purple Teaming und Fehler.

Ein weiterer Praxisfehler ist die fehlende Trennung zwischen Sicherheitskontrollen und Geschäftslogik. Beispiel: Ein Data-Lake-Team führt regelmäßig große S3-Reads aus. Wenn Purple Teaming nun Exfiltration simuliert, erzeugt dieselbe Aktivität vielleicht keinen Alarm, weil die Detection nur auf Volumen schaut. Das Problem liegt dann nicht in S3 selbst, sondern in einer zu groben Regel. Gute Übungen zwingen dazu, Identität, Kontext, Zeitfenster, Region, Zielkonto und Sensitivität der Daten gemeinsam zu bewerten.

Schwach ist auch ein Ansatz, bei dem nur erfolgreiche Angriffe dokumentiert werden. In AWS sind gescheiterte Aktionen oft genauso wertvoll. Ein denied AssumeRole, ein blockierter PutBucketPolicy oder ein durch SCP verhinderter CloudTrail-Stop zeigt, dass Kontrollen wirken. Diese positiven Befunde gehören in die Auswertung, weil sie die tatsächliche Resilienz sichtbar machen und spätere Regressionen erkennbar machen.

In AWS funktionieren Purple-Team-Übungen nur dann gut, wenn die beteiligten Rollen klar getrennt und gleichzeitig eng abgestimmt sind. Das offensive Team simuliert Techniken kontrolliert und nachvollziehbar. Das defensive Team bewertet Telemetrie, Detection und Reaktion. Die Cloud-Plattform liefert Kontext zu Architektur, Berechtigungsmodellen und Betriebsgrenzen. Das SOC prüft, ob Alarme in der realen Prozesskette ankommen und handhabbar sind. Fehlt eine dieser Perspektiven, bleiben Ergebnisse lückenhaft.

Ein praxistauglicher Workflow beginnt mit einer gemeinsamen Planungsphase. Dort werden Hypothesen, Scope, betroffene Konten, Testidentitäten, erwartete Events und Abbruchkriterien festgelegt. Danach folgt die technische Vorbereitung: Logging validieren, Testrollen bereitstellen, Guardrails setzen, Dashboards und Suchabfragen vorbereiten. Erst dann startet die eigentliche Übung. Während der Durchführung ist ein Live-Kanal sinnvoll, aber nicht für permanente Hilfestellung. Sonst wird aus Purple Teaming eine geführte Demo. Besser ist ein abgestuftes Modell: erst verdeckte Beobachtung, dann kontrollierte Offenlegung einzelner Schritte, anschließend gemeinsame Analyse.

Nach der Durchführung beginnt der wichtigste Teil: die Auswertung. Jede getestete Technik sollte in einer standardisierten Form dokumentiert werden. Dazu gehören Ziel, Vorbedingungen, ausgeführte Aktionen, betroffene Services, erzeugte Logs, ausgelöste Alerts, Reaktionszeit, Fehlinterpretationen und konkrete Verbesserungsmaßnahmen. Diese Struktur lässt sich gut in einen übergreifenden Workflow oder Prozess einbetten.

Besonders wertvoll ist eine Trennung in drei Ebenen der Verbesserung. Erstens technische Korrekturen wie zusätzliche CloudTrail Data Events, neue SIEM-Regeln oder härtere IAM-Policies. Zweitens operative Anpassungen wie bessere Eskalationspfade, Runbooks oder Kontextanreicherung. Drittens strategische Maßnahmen wie Account-Segmentierung, stärkere Federation-Kontrollen oder Reduktion langlebiger Access Keys. Nur wenn alle drei Ebenen betrachtet werden, entsteht nachhaltiger Fortschritt.

Ein bewährtes Format für die Nachbereitung ist eine kurze Maßnahmenmatrix:

Technik: Missbrauch von AssumeRole
Beobachtung: CloudTrail vorhanden, kein priorisierter Alert
Ursache: fehlende Baseline für legitime Rollenannahme
Maßnahme: Regel für neue Quelle/Region + Enrichment mit Account-Kontext
Verantwortlich: Detection Engineering
Frist: 14 Tage
Retest: im nächsten Purple-Team-Zyklus

Genau diese Retests machen den Unterschied. Ohne Wiederholung bleibt unklar, ob eine Maßnahme wirklich wirkt. Deshalb ist Purple Teaming eng mit Iteration, Collaboration und Communication verbunden. In AWS ändern sich Architekturen schnell. Detection und Playbooks müssen mit dieser Dynamik Schritt halten.

Ein realistisches Szenario beginnt mit einem kompromittierten Access Key eines Entwicklers in einem Nicht-Produktionskonto. Der Key besitzt keine Administratorrechte, darf aber S3-Buckets auflisten, bestimmte Lambda-Funktionen lesen und STS-Informationen abrufen. Ziel der Übung ist nicht maximale Ausnutzung, sondern die Prüfung, ob verdächtige Nutzung erkannt und richtig eingeordnet wird.

Schritt eins ist die Initialnutzung des Keys aus einer ungewöhnlichen Quelle. Bereits hier sollte geprüft werden, ob Geo-Anomalien, neue User-Agents oder atypische Regionen sichtbar werden. Schritt zwei ist die Enumerierung: sts:GetCallerIdentity, iam:ListRoles, s3:ListAllMyBuckets, lambda:ListFunctions. Diese Aktionen sind oft legitim und erzeugen einzeln kaum Alarm. In Kombination und aus ungewohnter Quelle können sie jedoch ein starkes Signal sein. Schritt drei ist der Versuch, eine Rolle zu übernehmen, deren Trust-Policy zu breit gefasst ist. Gelingt dies, folgt Schritt vier: Zugriff auf einen Test-Bucket mit sensiblen, aber künstlichen Daten.

Die Auswertung betrachtet nicht nur Erfolg oder Misserfolg. Angenommen, die Rollenannahme gelingt, CloudTrail protokolliert alles, GuardDuty erzeugt aber keinen relevanten Finding-Typ, und das SIEM alarmiert erst beim S3-Zugriff. Dann ist die Frage: Warum wurde die frühere Phase nicht erkannt? Fehlt eine Regel für ungewöhnliche AssumeRole-Muster? Gibt es keine Baseline für legitime Cross-Role-Nutzung? Werden STS-Events im SIEM nicht ausreichend angereichert? Genau diese Fragen liefern den Mehrwert.

Ein mögliches technisches Artefakt aus der Übung könnte so aussehen:

{
  "eventSource": "sts.amazonaws.com",
  "eventName": "AssumeRole",
  "awsRegion": "eu-central-1",
  "sourceIPAddress": "203.0.113.10",
  "userAgent": "aws-cli/2.x",
  "requestParameters": {
    "roleArn": "arn:aws:iam::111122223333:role/TestReadRole"
  }
}

Dieses Event ist für sich genommen nicht zwingend verdächtig. Verdächtig wird es durch Kontext: Quelle bisher unbekannt, Rolle selten genutzt, nachfolgend S3-Reads auf sensible Buckets, Zeitfenster außerhalb normaler Arbeitszeiten. Purple Teaming in AWS bedeutet deshalb immer auch Kontextarbeit. Wer nur Signaturen baut, verliert gegen legitime Cloud-Aktivität mit missbräuchlicher Absicht.

Solche Übungen lassen sich gut mit weiteren Formaten kombinieren, etwa mit Beispiele, Szenarien oder einem strukturierten Playbook. Entscheidend ist, dass jede Übung in konkrete Änderungen übersetzt wird: neue Detection, bessere IAM-Härtung, klarere Eskalation, schnellere Triage und ein geplanter Retest.

Einzelne Übungen bringen nur begrenzten Nutzen, wenn sie nicht in einen wiederholbaren Verbesserungszyklus eingebettet sind. Reife Purple-Teaming-Programme in AWS arbeiten mit festen Metriken. Dazu gehören nicht nur klassische Zeiten wie Time to Detect oder Time to Triage, sondern auch cloud-spezifische Kennzahlen: Anteil kritischer Accounts mit vollständigem CloudTrail, Abdeckung von S3 Data Events für sensible Buckets, Erkennungsrate für IAM-Änderungen, Zahl der getesteten Eskalationspfade pro Quartal oder Anteil der Findings mit erfolgreichem Retest.

Wichtig ist dabei die richtige Interpretation. Eine hohe Zahl an Alerts ist kein Erfolg, wenn das SOC sie nicht priorisieren kann. Eine niedrige Zahl an Findings ist kein Erfolg, wenn nur triviale Szenarien getestet wurden. Aussagekräftig sind Metriken erst im Zusammenhang mit Scope, Kritikalität und Wiederholbarkeit. Deshalb sollten Übungen entlang eines festen Lifecycle geplant werden: Hypothese, Vorbereitung, Ausführung, Auswertung, Maßnahmen, Retest.

Automatisierung kann helfen, darf aber den Erkenntnisprozess nicht ersetzen. Wiederkehrende Prüfungen wie das Auslösen definierter IAM-Änderungen in Testkonten, das Simulieren von S3-Zugriffen oder das Validieren von Alert-Pipelines lassen sich gut automatisieren. Schwieriger sind kontextabhängige Szenarien, etwa Missbrauch legitimer Build-Rollen oder komplexe Cross-Account-Pfade. Dort bleibt manuelle Analyse unverzichtbar. Gute Teams kombinieren beides: automatisierte Basistests für Regressionen und manuelle, hypothesengetriebene Übungen für neue Risiken.

Langfristig sollte Purple Teaming in AWS nicht isoliert laufen, sondern mit Architektur-Reviews, Threat Modeling und DevSecOps verzahnt sein. Neue Plattformdienste, neue Accounts oder geänderte Federation-Modelle müssen früh in die Sicherheitsprüfung einfließen. Gerade in dynamischen Cloud-Umgebungen ist die Halbwertszeit von Detection-Regeln kurz. Was heute selten ist, kann morgen Standard sein. Deshalb braucht es regelmäßige Anpassung, enge Rückkopplung mit Engineering und eine belastbare Dokumentation.

Wer den Reifegrad systematisch erhöhen will, orientiert sich an wenigen Prinzipien: reale Angriffspfade testen, Telemetrie vollständig machen, Kontext anreichern, Maßnahmen nachverfolgen und Verbesserungen erneut validieren. Genau daraus entsteht ein belastbares Programm, das über punktuelle Übungen hinausgeht und AWS-Sicherheit messbar stärkt. Ergänzend lohnt sich der Blick auf Best Practices, Strategie und Methodik, wenn das Vorgehen organisationsweit standardisiert werden soll.