Incident Response in der AWS-Cloud: Wo Sie zuerst suchen

Wenn in einem AWS-Konto ein Alarm ausgeloest wird, entscheidet das Wissen, wo man zuerst suchen muss, ueber den Unterschied zwischen einer zweistuendigen und einer zweiwoechigen Untersuchung. Incident Response in der Cloud ist nicht dasselbe wie die Untersuchung eines Laptops oder eines lokalen Servers: Es gibt keine Festplatte im klassischen Sinne abzubilden, die Steuerungsebene ist eine API, und der wichtigste Beweis ist oft ein Logeintrag, der verfaellt, wenn Sie das Logging nicht vorab aktiviert haben. Dieser Leitfaden richtet sich an Verteidiger. Ziel ist es, die Angriffsflaeche zu verstehen, um Missbrauch zu erkennen und sicher wiederherzustellen, nicht jemandem das Eindringen beizubringen. Wir gehen die relevante AWS-Telemetrie durch, die Signale, die Rauschen von einem echten Einbruch trennen, und wie man Schaden eindaemmt, ohne die benoetigten Beweise zu zerstoeren.

Warum Cloud-Incident-Response anders ist#

In einer klassischen Umgebung reagieren Sie auf einen Host: Sie isolieren ihn, sichern den Speicher und bilden die Festplatte ab. In AWS ist das primaere Untersuchungsobjekt das Konto und seine Identitaeten. Ein Angreifer, der eine gueltige Anmeldeinformation erlangt, kann von ueberall auf der Welt ueber dieselbe API agieren, die Sie nutzen, und seine Aktionen sehen syntaktisch identisch zu legitimer Administration aus. Bei einer Kompromittierung der Steuerungsebene gibt es keine Schadsoftware zu finden, nur eine Folge von API-Aufrufen. Dadurch verlagert sich der Schwerpunkt der Untersuchung von Binaerdateien und Dateien hin zu Identitaet, Berechtigungen und Audit-Logs. Es bedeutet auch, dass Vorbereitung entscheidend ist: Die Beweise, die Sie im Nachhinein sammeln koennen, sind genau die, die Sie vor dem Vorfall konfiguriert haben. War das kontenweite Logging aus, ist die moegliche Rekonstruktion grundsaetzlich begrenzt.

Vor dem Vorfall vorbereiten: Bereitschaft, die sich auszahlt#

Bereitschaft ist die guenstigste Kontrolle, die Sie je erwerben. Bevor etwas passiert, stellen Sie sicher, dass ein mehrregionaler, organisationsweiter CloudTrail-Trail aktiviert ist und in ein dediziertes, nur-schreibbares Logging-Konto liefert, das Responder lesen, aber Dienstkonten nicht loeschen koennen. Aktivieren Sie GuardDuty ueber alle Regionen und Konten, schalten Sie Config ein, um den Ressourcenzustand ueber die Zeit aufzuzeichnen, und sorgen Sie dafuer, dass VPC Flow Logs und relevante Dienstlogs (S3-Zugriffsprotokollierung, Load-Balancer-Logs, DNS-Query-Logging via Route 53 Resolver) zentral erfasst werden. Richten Sie Break-Glass-Rollen mit starker MFA ein und dokumentieren Sie, wer sie annehmen darf. Ein kurzes, eingeuebtes Runbook, das die Logorte, die Isolationsschritte und die Eskalationskontakte nennt, spart im Ernstfall mehr Zeit als jedes Werkzeug.

Die zentralen AWS-Logquellen, auf die Sie sich stuetzen#

Vier Quellen tragen die meisten Cloud-Untersuchungen. CloudTrail ist das Audit-Log der Steuerungsebene: jeder API-Aufruf, wer ihn getaetigt hat, von welcher IP und Identitaet und ob er erfolgreich war. GuardDuty ist ein verwalteter Detektor, der CloudTrail-, DNS- und Flow-Daten zu Findings wie Anmeldedaten-Exfiltration oder anomaler API-Nutzung korreliert. VPC Flow Logs zeichnen Netzwerkgespraeche auf ENI-Ebene auf, wo Sie laterale Bewegung und Datenabfluss rekonstruieren. Config liefert eine Zeitleiste, wie eine Ressource zu jedem Zeitpunkt aussah, unbezahlbar, um zu belegen, wann eine Security Group geoeffnet oder eine Policy geaendert wurde. Darum herum liegen dienstspezifische Logs (S3, RDS, Lambda, CloudFront, WAF), die Kontext zu den beteiligten Workloads liefern.

Wo zuerst suchen: CloudTrail#

CloudTrail ist fast immer die erste Station. Beginnen Sie damit, auf die Identitaet im Alarm zu pivotieren, und stellen Sie drei Fragen: Was tat dieses Prinzipal, von wo, und wann aenderte sich das Verhalten. Filtern Sie nach eventName-Werten, die auf Aufklaerung oder Eskalationsversuche hindeuten, und achten Sie besonders auf Management-Plane-Ereignisse. Signalstarke Ereignisse einer Kompromittierung umfassen Aenderungen an Identitaet und Vertrauen, etwa CreateUser, CreateAccessKey, AttachUserPolicy, PutUserPolicy, UpdateAssumeRolePolicy und CreateLoginProfile. Achten Sie auf ConsoleLogin-Eintraege ohne MFA, auf GetCallerIdentity unmittelbar gefolgt von breiten Auflistungsaufrufen und auf Haeufungen von AccessDenied-Ergebnissen, die einen nach Berechtigungen suchenden Akteur verraten. Korrelieren Sie Quell-IP, User-Agent und ob die Aufrufe ueber temporaere Rollen-Anmeldedaten kamen, was verraet, ob ein Access Key oder eine angenommene Rolle missbraucht wurde.

Signale zu Identitaet und Zugriff#

Da Identitaet das Schlachtfeld ist, investieren Sie in die Berechtigungssicht. Zaehlen Sie kuerzlich erstellte oder geaenderte IAM-Benutzer, -Rollen und -Access-Keys auf und vergleichen Sie sie mit Ihren Aenderungsaufzeichnungen. Ein neu erstellter Access Key auf einem Dienstkonto, eine Rollen-Vertrauensrichtlinie, die ploetzlich ein externes Konto zulaesst, oder eine Inline-Policy, die iam:* gewaehrt, sind starke Indikatoren dafuer, dass ein Angreifer dauerhaften Zugriff etabliert. GuardDuty-Findings der Familien UnauthorizedAccess, CredentialAccess und Persistence sollten sofort triagiert werden. IAM Access Analyzer hilft, Ressourcen zu erkennen, die von ausserhalb erreichbar wurden. Denken Sie durchgehend daran, dass auch legitime Automatisierung Keys und Rollen erstellt; das Signal ist die Abweichung vom Normalzustand, nicht die Aktion fuer sich.

Netzwerk- und Datenebenen-Telemetrie#

Sobald Sie verstehen, was die Identitaet tat, folgen Sie den Daten. VPC Flow Logs zeigen, welche Instanzen mit welchen Endpunkten sprachen und wie viele Bytes flossen, sodass Sie Routineverkehr von Massenabfluss zu einem unbekannten Ziel unterscheiden. DNS-Query-Logs enthuellen oft Command-and-Control- oder Staging-Domains, die reine IP-Flussdaten hinter CDNs verbergen. Auf der Speicherseite zeigen S3-Server-Zugriffslogs und CloudTrail-Data-Events fuer S3 objektbezogene Lesevorgaenge: eine ploetzliche Reihe von GetObject-Aufrufen ueber einen ganzen Bucket oder ein ListBuckets gefolgt von gezielten Downloads ist die klassische Form der Exfiltration. Fuer Datenbanken pruefen Sie RDS-Logs und jede aktivierte Query-Auditierung. Die Frage, die Sie beantworten, ist einfach und folgenreich: Sind Daten abgeflossen, und wenn ja, welche und wie viele.

Signale in Erkennungen ueberfuehren#

Wirksames Hunting bedeutet, die Fragen als wiederholbare Abfragen aufzuschreiben. Bauen Sie mit CloudTrail in Athena oder Ihrem SIEM Erkennungen fuer Konsolenanmeldungen aus neuen Laendern oder ASNs, fuer API-Aufrufe, deren User-Agent nicht zu Ihrem bekannten Tooling passt, fuer jede Nutzung des Root-Kontos und fuer das Deaktivieren von Sicherheitsdiensten wie StopLogging, DeleteTrail, DeleteFlowLogs oder DisableSecurityHub. Alarmieren Sie bei erstmals gesehenen Paarungen von Prinzipal und Region, denn Angreifer operieren oft in Regionen, die Ihre Teams nie nutzen. Priorisieren Sie Findings nach Wirkungsradius: eine Aenderung an einer Identitaet, die andere Rollen annehmen kann, wiegt schwerer als ein einzelner abgelehnter Aufruf. Tunen Sie aggressiv, damit die Alarme, die einen Menschen wecken, wirklich das Wecken rechtfertigen.

Eindaemmung ohne Beweiszerstoerung#

Eindaemmung in der Cloud ist schnell, was Geschenk und Gefahr zugleich ist. Sie koennen eine Session widerrufen, einen Access Key deaktivieren oder eine Policy in Sekunden loesen, aber wenn Sie die kompromittierte Rolle loeschen oder die Instanz beenden, loeschen Sie moeglicherweise noch nicht gesammelte Beweise. Die beweissichere Reihenfolge lautet, zuerst zu sichern und zu bewahren: EBS-Snapshots betroffener Volumes erstellen, Instanz-Metadaten erfassen und die relevanten Logbereiche in Ihren Fallspeicher exportieren. Dann die Identitaet einschraenken, indem Sie ein explizites Deny anhaengen oder Sessions widerrufen, statt das Prinzipal zu loeschen, und Compute isolieren, indem Sie es in eine Quarantaene-Security-Group ohne Egress verschieben. Rotieren Sie offengelegte Anmeldedaten und entwerten Sie temporaere Tokens. Erst nach Sicherung und Eindaemmung gehen Sie zur Beseitigung ueber und bauen aus bekannt-guter Infrastruktur als Code neu auf.

Haeufige Fallstricke#

Mehrere Fehler wiederholen sich. Teams entdecken waehrend des Vorfalls, dass CloudTrail einregional war oder nie in ein isoliertes Konto lieferte, sodass die Aktionen des Angreifers in einer anderen Region unsichtbar sind. Responder beenden Instanzen aus Eile und verlieren Speicher- und Festplattenartefakte. Ermittler vertrauen den Zeitstempeln eines einzelnen Logs, ohne Uhren ueber Quellen hinweg zu korrelieren. Menschen jagen einem boesartigen API-Aufruf nach und uebersehen die Persistenz, die der Angreifer drei Schritte frueher gesetzt hat, etwa einen verbliebenen Access Key oder ein geaendertes Rollenvertrauen. Und ein haeufiger vermeidbarer Fehler ist, das Symptom zu beheben und dann nicht jede Anmeldeinformation zu rotieren, die der Akteur beruehrt haben koennte, was den sofortigen Wiedereintritt einlaedt. Schreiben Sie diese Lehren ins Runbook, damit der naechste Responder sie nicht unter Druck neu lernt.

Blue-Team-Checkliste#

Nutzen Sie dies als Startsequenz. 1. Umfang bestaetigen: welche Konten, Regionen und Identitaeten betroffen sind. 2. Zuerst sichern: CloudTrail-Bereiche exportieren, Volumes snapshotten, Instanz-Metadaten erfassen. 3. Die Identitaets-Zeitleiste aus CloudTrail rekonstruieren, mit Fokus auf IAM- und Vertrauensaenderungen. 4. GuardDuty-Findings ziehen und mit Flow- und DNS-Logs korrelieren. 5. Datenauswirkung aus S3-Data-Events und Egress-Volumen bestimmen. 6. Mit Deny-Policies, Session-Widerruf und Quarantaene-Security-Groups eindaemmen, nicht durch Loeschen. 7. Jede potenziell offengelegte Anmeldeinformation rotieren und temporaere Tokens entwerten. 8. Beseitigen und aus Infrastruktur als Code neu aufbauen. 9. Die Zeitleiste dokumentieren und Erkennungen in Ihr Monitoring zurueckfuehren.

FAQ: Wie lange werden AWS-Logs standardmaessig aufbewahrt?#

Das haengt vom Dienst und Ihrer Konfiguration ab. Die CloudTrail-Konsolen-Ereignishistorie wird 90 Tage aufbewahrt, aber das ersetzt keinen dauerhaften Trail, der nach S3 liefert, den Sie kontrollieren und gemaess Ihrer Richtlinie aufbewahren sollten. GuardDuty-Findings, VPC Flow Logs und Dienstlogs haben jeweils ihre eigene, von Ihnen gesetzte Aufbewahrung. Genau deshalb zaehlt Bereitschaft: Verlassen Sie sich auf die Standard-Konsolenhistorie, findet eine spaet beginnende Untersuchung die fruehesten Beweise moeglicherweise bereits verschwunden. Konfigurieren Sie langlebige, manipulationssichere Logauslieferung, bevor Sie sie brauchen.

FAQ: Muss ich eine EC2-Instanz abbilden, oder ist das in der Cloud ueberholt?#

Fluechtige und Festplattenartefakte zaehlen weiterhin, wenn ein Workload kompromittiert ist, daher ist Imaging fuer Host-Einbrueche nicht ueberholt. Der beweissichere Ansatz ist, einen EBS-Snapshot des betroffenen Volumes zu erstellen und, wo machbar, den Speicher zu erfassen, bevor Sie die Instanz stoppen, dann den Snapshot fuer die Offline-Analyse an eine forensische Workstation anzuhaengen. In der Cloud aendert sich, dass es bei einer reinen Steuerungsebenen-Kompromittierung moeglicherweise gar keinen Host zum Abbilden gibt; die Untersuchung lebt vollstaendig in CloudTrail und Identitaetsaufzeichnungen. Passen Sie die Sammlung an die Art des Vorfalls an, statt ueberall eine Gewohnheit anzuwenden.

Fazit#

Cloud-Incident-Response belohnt Vorbereitung und Disziplin. Die Konten, die sich schnell erholen, sind jene, die organisationsweites, manipulationssicheres Logging vor einem Vorfall aktiviert haben, die wissen, dass CloudTrail, GuardDuty, VPC Flow Logs und Config die vier Saeulen sind, und die Bedrohungen eindaemmen, ohne Beweise zu verbrennen. Behandeln Sie Identitaet als primaeres Schlachtfeld, folgen Sie den Daten zur Frage, ob etwas abfloss, und sichern Sie stets, bevor Sie handeln. Bauen Sie diese Schritte in ein eingeuebtes Runbook, messen Sie, wie schnell Sie eine Identitaets-Zeitleiste rekonstruieren, und fuehren Sie Gelerntes stets in Erkennungen zurueck. Gut gemacht, verwandelt Cloud-Response einen beaengstigenden Alarm in ein methodisches, wiederholbares Verfahren.