Unter AWS-Bedrohungserkennung versteht man die Identifizierung und Priorisierung böswilliger oder verdächtiger Aktivitäten in AWS durch die Analyse cloud auf Anzeichen für Angreiferverhalten. Anstatt einzelne Ereignisse isoliert zu bewerten, untersucht dieser Ansatz, welche Aktivitäten ein Akteur über Identitäten, Rollen und Dienste hinweg ausführt. Angesichts der Tatsache, dass 80 % der Unternehmen im vergangenen Jahr mindestens einen cloud erlebt haben und die Kosten cloud öffentlichen cloud im Durchschnitt bei 5,17 Millionen US-Dollar pro Vorfall liegen, wird eine effektive AWS-Bedrohungserkennung immer wichtiger.
AWS-Umgebungen erzeugen große Mengen an Protokollen und Metadaten, die für sich genommen schwer zu interpretieren sind. Durch die Verknüpfung dieser Telemetriedaten mit Verhaltenssignalen lassen sich die Bewegungen von Angreifern im Verlauf eines cloud besser aufdecken. Dies ist von Bedeutung, da nicht miteinander in Zusammenhang stehende Aktivitäten die Untersuchung und Reaktion verzögern können.
In der Praxis verknüpft die AWS-Bedrohungserkennung verwandte Aktionen zu Verhaltensmustern, die untersucht und priorisiert werden können. Anstatt cloud als eine Sammlung unabhängiger Warnmeldungen zu behandeln, interpretiert sie Aktivitäten als Hinweise auf eine mögliche Angriffssequenz. Diese Unterscheidung ist wichtig, da viele AWS-Aktionen technisch legitim sind, aber dennoch einen Missbrauch von Zugriffsrechten, Rollen oder Diensten darstellen.
Aktivitätsarten, die Absichten über einen längeren Zeitraum und verschiedene Dienste hinweg aufzeigen:
AWS bietet mehrere native Sicherheitsdienste an, die die Grundlage einer Strategie zur Erkennung von cloud bilden. Wenn Teams verstehen, welche Funktionen die einzelnen Tools erfüllen – und wo noch Lücken bestehen –, können sie eine effektive Erfassungsabdeckung aufbauen.
Amazon GuardDuty ist der wichtigste AWS-Dienst zur Erkennung von Bedrohungen. Er analysiert kontinuierlich CloudTrail-Verwaltungsereignisse, VPC-Flow-Protokolle, DNS-Abfrageprotokolle und Laufzeit-Telemetriedaten mithilfe von maschinellem Lernen, Anomalieerkennung und integrierten Bedrohungsinformationen. Im Dezember 2025 führte AWS „Extended Threat Detection“ für EC2 und ECS ein, das mithilfe von KI/ML Signale aus mehreren Datenquellen miteinander in Beziehung setzt und mehrstufige Angriffsabläufe abbildet, um MITRE ATT&CK -Taktiken abzugleichen.
Security Hub fasst die Ergebnisse von GuardDuty, Amazon Inspector, AWS Config und Tools von Drittanbietern in einem einheitlichen Dashboard zusammen. Es bietet Compliance-Prüfungen anhand von Standards wie CIS AWS Foundations und unterstützt die automatisierte Behebung von Problemen durch Integrationen mit AWS Lambda und Amazon EventBridge.
Detective ergänzt GuardDuty durch detailliertere investigative Analysen. Wenn GuardDuty einen Befund mit hohem Schweregrad identifiziert, hilft Detective dabei, den Ursprung, den Umfang und die Zusammenhänge der verdächtigen Aktivität über verschiedene Ressourcen hinweg nachzuvollziehen.
Tabelle: Vergleich der nativen AWS-Dienste zur Erkennung von Bedrohungen
Diese nativen Tools bieten zwar eine grundlegende Abdeckung, konzentrieren sich jedoch auf Aktivitäten innerhalb von AWS. Angriffe, die außerhalb von AWS ihren Ursprung haben – über kompromittierte Identitätsanbieter, lokale Netzwerke oder SaaS-Anwendungen –, erfordern eine zusätzliche Korrelation über hybride Umgebungen hinweg, um die gesamte Angriffskette aufzudecken.
Bei der logbasierten Überwachung in AWS bleibt das Verhalten von Angreifern oft unentdeckt, da Ereignisse als isolierte Datensätze analysiert werden. Die Zuordnung endet häufig bei der zuletzt verwendeten Rolle oder den zuletzt verwendeten temporären Anmeldedaten, was dazu führt, dass sich die Untersuchungen auf die falsche Abstraktionsebene konzentrieren. Infolgedessen können Sicherheitsverantwortliche den ursprünglichen Angreifer möglicherweise nicht rechtzeitig identifizieren, um die Aktivitäten vor dem Eintreten von Schäden einzudämmen.
Fehlerarten bei der Bewertung von AWS-Aktivitäten als isolierte Ereignisse:
Um zu verstehen, wie sich Angreifer innerhalb von AWS bewegen, muss man über einzelne Service-Aktionen hinausblicken. Eine verhaltensorientierte Erkennung macht Fortschrittsmuster sichtbar, wie beispielsweise Rollenverkettung, Umgehung der Protokollierung und lateraler Servicezugriff, die isoliert betrachtet legitim erscheinen können.
Verlaufsmuster:
Nicht alle Signale in AWS haben denselben Ermittlungswert. Bei der Erkennung werden Indikatoren priorisiert, die ungewöhnliches oder mehrstufiges Verhalten im Zusammenhang mit einem bestimmten Akteur widerspiegeln. Frühe Indikatoren können subtil und verteilt sein, während Signale im Spätstadium oft erst dann auftreten, wenn bereits erheblicher Schaden entstanden ist.
Wichtige Signale:
Jüngste Vorfälle zeigen, warum die Erkennung von Verhaltensmustern wichtiger ist als die reine Überwachung auf Protokollebene.
Der Codefinger ransomware -Gruppe nutzte kompromittierte AWS-Anmeldedaten aus, um S3-Daten mithilfe von serverseitiger Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln (SSE-C) zu verschlüsseln. Da die Angreifer legitime AWS-Verschlüsselungsfunktionen anstelle von malware nutzten, wurden die Aktivitäten von herkömmlichen signaturbasierten Erkennungstools übersehen. Nur eine Verhaltensüberwachung – die Erkennung ungewöhnlicher Massenverschlüsselungsvorgänge in Verbindung mit einer verdächtigen Anmeldedatenkette – konnte den Angriff aufdecken, bevor die Daten unwiederherstellbar wurden.
Amazon Threat Intelligence dokumentierte eine Kampagne, bei der ein russischsprachiger, finanziell motivierter Angreifer kommerzielle generative KI-Dienste nutzte, um zwischen dem 11. Januar und dem 18. Februar 2026 über 600 FortiGate-Geräte in mehr als 55 Ländern zu kompromittieren. Die Angreifer nutzten KI, um ihre Operationen zu skalieren, was zeigt, dass KI-gestützte Bedrohungen das Angriffsvolumen sowohl bei erfahrenen als auch bei unerfahrenen Angreifern in die Höhe treiben.
Im Februar 2026 nutzte ein Angreifer eine nicht gepatchte React-Frontend-Anwendung, die auf AWS lief, um sich einen ersten Zugriff zu verschaffen, und missbrauchte anschließend eine zu großzügig konfigurierte ECS-Task-Rolle mit weitreichenden Lesezugriffsrechten auf den AWS Secrets Manager. Dies ermöglichte die Exfiltration von Redshift-Anmeldedaten, VPC-Zuordnungen und Millionen von Datenbankdatensätzen. Der Vorfall lässt sich mit MITRE ATT&CK wie T1190 (Ausnutzen öffentlich zugänglicher Anwendungen), T1078 (gültige Konten) und T1530 (Daten aus cloud ) in Verbindung bringen – was verdeutlicht, warum die Überwachung des Verhaltens von Identitäten und Rollen für die Erkennung von Bedrohungen in AWS unerlässlich ist.
Diese Vorfälle weisen ein gemeinsames Muster auf: Die Angreifer nutzten legitime AWS-Mechanismen (Verschlüsselungsfunktionen, gültige Rollen, temporäre Anmeldedaten), um böswillige Aktivitäten durchzuführen, die auf Ereignisebene normal erschienen, sich jedoch durch eine Verhaltensanalyse offenbarten.
Die Erkennung von Bedrohungen in AWS hat nach wie vor ihre Grenzen. Zwar kann verdächtiges Verhalten identifiziert werden, doch die Erkennung von Bedrohungen verhindert oder behebt cloud nicht automatisch. Das bedeutet, dass Teams weiterhin auf Reaktionsabläufe und das Urteilsvermögen von Analysten angewiesen sind. Die Verwechslung von Erkennung und Prävention kann zu blinden Flecken führen, die die Eindämmung verzögern.
Tabelle: Irrtümer vs. Richtigstellungen
Mehrere Trends verändern derzeit die Art und Weise, wie Unternehmen die Erkennung von Bedrohungen in AWS-Umgebungen angehen.
Um die Erkennung von Bedrohungen in AWS zu unterstützen, muss das Verhalten von Angreifern über Identitäts-, Netzwerk- und cloud hinweg als ein einziges Kontinuum betrachtet werden. Die Vectra AI löst dieses Problem, indem sie Aktionen miteinander in Zusammenhang bringt, anstatt AWS-Ereignisse als isolierte Warnmeldungen zu behandeln. Dies verringert die Unsicherheit in Fällen, in denen Rollen, temporäre Anmeldedaten und Aktivitäten über mehrere Dienste hinweg die Zuordnung erschweren. Cloud and Response (CDR) Cloud Vectra AI für AWS erweitert die Erkennung über native Tools hinaus, indem sie Verhaltensmuster über hybride Angriffsflächen hinweg analysiert.
Funktionen der Plattform:
Erleben Sie das Verhalten von AWS-Angreifern hautnah in einer geführten Angriffstour
CloudTrail-Überwachung zeichnet einzelne Ereignisse auf, während die AWS-Bedrohungserkennung darauf abzielt, Ereignisse über Identitäten, Rollen, Dienste und Zeiträume hinweg miteinander zu verknüpfen, um das Verhalten von Angreifern aufzudecken. Isolierte Protokollereignisse können zwar zeigen, was passiert ist, aber sie zeigen oft nicht die Absicht oder den Verlauf, insbesondere wenn Angreifer temporäre Anmeldedaten und übernommene Rollen verwenden. Der praktische Unterschied liegt in der Untersuchung: Die Bedrohungserkennung priorisiert mehrstufige Verhaltensmuster, die zugeordnet und bearbeitet werden können, anstatt es den Analysten zu überlassen, die Zusammenhänge aus den Rohprotokollen manuell zusammenzusetzen.
Nein. Die AWS-Bedrohungserkennung verhindert oder behebt architektonische oder konfigurationsbezogene Probleme nicht von selbst. Das Fehlkonfigurationsmanagement konzentriert sich auf die Identifizierung unsicherer Einstellungen und Gefährdungsbedingungen, während die Bedrohungserkennung sich auf die Identifizierung bösartiger oder verdächtiger Aktivitäten innerhalb einer AWS-Umgebung konzentriert. Diese Funktionen zu verwechseln ist problematisch, da Teams möglicherweise davon ausgehen, dass die Erkennung die Konfigurationssicherheit ersetzt, wodurch primäre Einstiegspunkte unberücksichtigt bleiben, während sie erwarten, dass die Bedrohungserkennung dies kompensiert.
Identität und Rollen sind von zentraler Bedeutung, da Angreifer nach der ersten Kompromittierung häufig legitime Zugriffsmechanismen nutzen, darunter auch angenommene Rollen und temporäre Anmeldedaten. Aktionen können auf API-Ebene gültig erscheinen, auch wenn sie einen Missbrauch darstellen. Daher ist die Zuordnung unerlässlich, um zu verstehen, wer eine Sequenz initiiert hat und ob diese Sequenz mit dem erwarteten Verhalten übereinstimmt. Dies ist wichtig, da die Rollenkette den ursprünglichen Akteur verschleiern kann und Untersuchungen fehlschlagen können, wenn sie bei der zuletzt verwendeten temporären Rolle enden.
Mehrstufiges Verhalten, das legitime AWS-Mechanismen nutzt, ist am schwierigsten zu erkennen, wenn es Ereignis für Ereignis bewertet wird. Rollenkettungen, temporäre Anmeldedatensequenzen und Aktionen, die isoliert betrachtet normal erscheinen, erfordern oft eine Korrelation zwischen Diensten und Identitäten, um aussagekräftig zu sein. Diese Muster sind schwierig, da sie über mehrere AWS-Dienste und Zeitfenster verteilt sein können und da die zuletzt verwendeten Anmeldedaten möglicherweise nicht den ursprünglichen Akteur widerspiegeln. Dies ist von Bedeutung, da subtiles Verhalten in der Frühphase übersehen werden kann, bis Indikatoren in der Spätphase auftreten.
Ja, aber nur, wenn der Ansatz Aktivitäten über verschiedene Umgebungen hinweg miteinander verbindet, anstatt AWS als isolierte Domäne zu behandeln. Hybride Angriffe können über kompromittierte Laptops oder Identitätsanbieter erfolgen und später mithilfe vertrauenswürdiger Identitätsbeziehungen und übernommener Rollen auf AWS übergreifen. Ohne Korrelation zwischen Identität und zugehöriger Telemetrie können AWS-Aktivitäten vom ursprünglichen Kompromittierungspfad losgelöst erscheinen. Dies ist wichtig, da Verteidiger verstehen müssen, wie cloud mit früheren Zugriffen zusammenhängen, um den Umfang der Reaktion und die Zuordnung korrekt einschätzen zu können.
Amazon GuardDuty führt eine aktive Bedrohungserkennung durch, indem es CloudTrail-Ereignisse, VPC-Flow-Protokolle und DNS-Protokolle mithilfe von maschinellem Lernen analysiert, um böswilliges Verhalten zu identifizieren. AWS Security Hub ist ein zentraler Aggregator für Sicherheitsbefunde, der Warnmeldungen von GuardDuty, Amazon Inspector, AWS Config und Tools von Drittanbietern sammelt und priorisiert. GuardDuty erkennt Bedrohungen. Security Hub organisiert und verwaltet sie. Die meisten Unternehmen nutzen beide zusammen – GuardDuty als Erkennungs-Engine und Security Hub als operatives Dashboard zur Priorisierung von Reaktionen über Konten und Regionen hinweg.
Aktivieren Sie zunächst Amazon GuardDuty für alle AWS-Konten und alle Regionen – einschließlich der Regionen, die nicht aktiv genutzt werden, da Angreifer unüberwachte Regionen für Aktivitäten wie Cryptomining ins Visier nehmen. Leiten Sie die Ergebnisse von GuardDuty an AWS Security Hub weiter, um einen zentralen Überblick zu erhalten. Fügen Sie Amazon Detective hinzu, um Befunde mit hohem Schweregrad zu untersuchen. Konfigurieren Sie anschließend EventBridge-Regeln mit Lambda-Funktionen, um die Reaktion auf kritische Warnmeldungen zu automatisieren. Dieser mehrschichtige Ansatz umfasst Erkennung, Aggregation, Untersuchung und automatisierte Reaktion.
Angreifer nutzen zunehmend kommerzielle generative KI-Dienste, um ihre Angriffe auf cloud auszuweiten. Anfang 2026 dokumentierte Amazon Threat Intelligence eine Kampagne, bei der Angreifer mithilfe von KI über 600 Netzwerkgeräte in mehr als 55 Ländern kompromittierten und anschließend in cloud vordrangen. KI hilft Angreifern dabei, die Erkundung zu automatisieren, Exploit-Code zu generieren und Fehlkonfigurationen schneller zu identifizieren, als dies mit manuellen Methoden möglich ist. Dieser Trend macht die Verhaltenserkennung umso wichtiger, da KI-gestützte Angriffe ein höheres Aktivitätsvolumen erzeugen, das regelbasierte Erkennungssysteme überfordern kann.
„Extended Threat Detection“ ist eine im Dezember 2025 eingeführte Funktion, die mithilfe von KI und maschinellem Lernen mehrstufige Angriffsabläufe über verschiedene AWS-Dienste hinweg identifiziert. Anstatt für jedes verdächtige Ereignis separate Ergebnisse zu generieren, korreliert sie Signale – wie den Missbrauch von Anmeldedaten, die Ausweitung von Berechtigungen und die Exfiltration von Daten – zu einer einzigen Angriffssequenz, die MITRE ATT&CK zugeordnet ist. Dies verkürzt die Triage-Zeit, da der gesamte Angriffsverlauf dargestellt wird, anstatt dass Analysten einzelne Ergebnisse manuell miteinander verknüpfen müssen.