AWS Threat Detection: So erkennen Sie das Verhalten von Angreifern

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.

Was bedeutet AWS-Bedrohungserkennung in der Praxis?

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:

• Die Nutzung kompromittierter Identitäten, um sich einen ersten Zugriff auf AWS-Ressourcen zu verschaffen.
• Sie schlüpfen in verschiedene Rollen und nutzen vorübergehend zugeteilte Zugangsdaten, um die Identität des ursprünglichen Akteurs zu verschleiern.
• Das Wechseln oder „Springen“ zwischen verschiedenen Rollen, um die Zuordnung über mehrere Konten oder Dienste hinweg zu umgehen.
• Um Abwehrmaßnahmen zu umgehen, indem versucht wird, die Protokollierung zu deaktivieren, zu unterdrücken oder zu umgehen.
• Daten abziehen oder nach der Erweiterung von Berechtigungen zerstörerische Aktionen ausführen.

So funktioniert die AWS-Bedrohungserkennung

Die AWS-Bedrohungserkennung wandelt cloud in eine faktenbasierte Übersicht über das potenzielle Verhalten von Angreifern um. Ein typischer Erkennungsworkflow umfasst sechs Phasen:

1. Erfassen Sie cloud . Zu den relevanten Daten zählen unter anderem AWS CloudTrail-Ereignisse, Amazon VPC Flow Logs, DNS-Abfrageprotokolle, Amazon S3-Aktivitäten, Amazon EKS-Auditprotokolle sowie Laufzeit-Telemetriedaten von unterstützten Workloads.
2. Ermittlung des erwarteten Verhaltens. Erkennungssysteme analysieren, wie Benutzer, Rollen, Workloads und Dienste normalerweise miteinander interagieren. Anhand dieses Kontexts lässt sich ungewöhnliches Verhalten von routinemäßigen Verwaltungsvorgängen unterscheiden.
3. Erkennen Sie verdächtige Aktivitäten. Anomalien wie unerwartete API-Aufrufe, Zugriffe von einem neuen Standort aus, ungewöhnliche Rollenübernahmen oder Kontakte zu bekannter bösartiger Infrastruktur können auf eine mögliche Kompromittierung hindeuten.
4. Stellen Sie Zusammenhänge zwischen verwandten Aktionen her. Einzelne Ereignisse gewinnen an Aussagekraft, wenn sie über Zeiträume, Konten, Regionen und Dienste hinweg miteinander verknüpft werden. So können beispielsweise eine Erkundung, gefolgt von einem „AssumeRole“-Angriff, dem Zugriff auf Geheimnisse und dem Abruf großer Datenmengen eine Angriffssequenz darstellen.
5. Priorisieren Sie die gefährdeten Entitäten. Eine risikobasierte Priorisierung hilft Analysten dabei, sich auf die Identitäten, Rollen, Konten und Ressourcen zu konzentrieren, die mit den dringendsten Vorfällen in Verbindung stehen, anstatt jede Warnmeldung gleichermaßen zu prüfen.
6. Untersuchen und reagieren. Analysten überprüfen die Aktivität, ermitteln deren Umfang und ergreifen Maßnahmen zur Eindämmung, wie beispielsweise das Widerrufen von Sitzungen, das Deaktivieren von Anmeldedaten, das Isolieren von Workloads oder das Einschränken betroffener Rollen.

Dieser Workflow unterscheidet sich von der einfachen Protokollerfassung. Protokolle liefern Aufzeichnungen darüber, was geschehen ist, während die Erkennung von Bedrohungen Verhaltenskontext, Korrelationen und Priorisierungen hinzufügt, um festzustellen, ob die Aktivität auf das Vorgehen eines Angreifers hindeutet.

AWS-Tools und -Dienste zur Erkennung von Bedrohungen

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

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.

AWS Security Hub

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.

Amazon Detective

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 einen grundlegenden Schutz, 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.

Warum logzentrierte AWS-Überwachung das Verhalten von Angreifern übersieht

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:

• Ereignisbezogene Benachrichtigungen, bei denen Aktionen nicht dienst- oder zeitübergreifend verknüpft werden
• Unvollständige Zuordnung, die bei einer angenommenen Rolle endet, anstatt bis zum ursprünglichen Akteur zurückzuverfolgen
• Isolierte Sichtweisen auf Konten, Regionen und Domains, die eine einheitliche Darstellung verhindern
• Der Aufwand für die manuelle Korrelation, der die Reaktion verzögert und die kognitive Belastung erhöht
• Ein hohes Alarmaufkommen, das nicht erkennen lässt, welche Identität oder welches Konto das größte Risiko darstellt

Die Angreifer-Verhaltensweisen, die durch die Erkennung von Bedrohungen aufgedeckt werden

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:

• Infiltration durch Social Engineering und Missbrauch vertrauenswürdiger Identitätsbeziehungen
• Verwendung angenommener Rollen, um Identität zu abstrahieren und direkte Zuschreibung zu vermeiden
• Mehrstufige Rollenverkettung, die die ursprüngliche kompromittierte Identität verbirgt

Signale und Indikatoren, die bei der Erkennung von Bedrohungen in AWS verwendet werden

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:

• Abweichungen von der Basislinie, wie ungewöhnliche API-Aufrufe oder Muster bei der Verwendung von Anmeldedaten
• Frühe Erkundungsverhalten, die auf die Erforschung von Berechtigungen oder Ressourcen hindeuten
• Rollenübernahmeketten und Berechtigungssequenzen, die auf Rollenkettungsaktivitäten hinweisen
• Versuche, die Protokollierung und Überwachung zu deaktivieren, zu reduzieren oder zu umgehen
• Korreliertes Verhalten über Identitäts-, Netzwerk- und cloud hinweg, das auf einen Akteur hinweist
• Indikatoren für fortgeschrittene Phasen, wie beispielsweise Command-and-Control-Kommunikation oder Datenexfiltration

Bewährte Verfahren zur Erkennung von Bedrohungen bei AWS

Eine effektive Erkennung von Bedrohungen in der AWS-Umgebung hängt sowohl von einer umfassenden Telemetrieabdeckung als auch von ausreichenden Identitätskontextinformationen ab, um verdächtige Aktionen dem verantwortlichen Akteur oder der verantwortlichen Workload zuzuordnen.

Zentralisierung der Transparenz über alle Konten und Regionen hinweg

Nutzen Sie AWS Organizations und die delegierte Verwaltung, um Sicherheitsdienste einheitlich in der gesamten Umgebung bereitzustellen. Stellen Sie in jedem aktiven Konto und jeder Region eine umfassende Protokollierung und Erkennung sicher und zentralisieren Sie anschließend die Ergebnisse, damit Analysten nicht verschiedene Konsolen und Datenspeicher durchforsten müssen.

Identitäten und temporäre Zugangsdaten schützen

Verlangen Sie eine Multi-Faktor-Authentifizierung für privilegierten Zugriff, schränken Sie die Nutzung des Root-Benutzers ein und wenden Sie das Prinzip der geringsten Berechtigungen auf Benutzer, Rollen und Workloads an. Überwachen Sie die Aktivitäten des AWS Security Token Service, einschließlich ungewöhnlicher Rolle übernehmen Sequenzen, kontoübergreifender Zugriff und Rollenverkettung, die die ursprüngliche Identität verschleiern können.

Sowohl die Aktivitäten auf der Steuerungsebene als auch die relevanten Datenaktivitäten aufzeichnen

CloudTrail-Verwaltungsereignisse zeigen Änderungen an AWS-Ressourcen und -Berechtigungen an, während Datenereignisse Einblick in Aktivitäten im Zusammenhang mit Diensten wie Amazon S3 und AWS Lambda bieten. Unternehmen sollten den Umfang der Datenereignisabdeckung anhand sensibler Ressourcen, Untersuchungsanforderungen und Kosten festlegen.

Aktivitäten im Zusammenhang mit hochriskanten Wirkstoffen überwachen

Priorisieren Sie Aktivitäten, die Sicherheitskontrollen verändern, eine Persistenz herstellen oder Daten offenlegen können. Beispiele hierfür sind unerwartete Aufrufe von API-Aufrufe zum Erstellen von Zugriffsschlüsseln, zum Zuweisen von Rollenrichtlinien, zum Festlegen von Rollenrichtlinien, zum Aktualisieren von Rollenübernahmerichtlinien, zum Beenden der Protokollierung, zum Löschen von Protokollverläufen, zum Festlegen von Bucket-Richtlinien sowie zum Abrufen von Geheimnissen.,

Ein einzelner Anruf kann legitim sein. Der Ermittlungswert steigt jedoch, wenn er in Verbindung mit ungewöhnlichem Verhalten in Bezug auf Identität, Netzwerk oder Ressourcen auftritt.

Das Prinzip der geringsten Berechtigungen auf Workload-Rollen anwenden

Überprüfen Sie EC2-Instanzprofile, Lambda-Ausführungsrollen, Amazon ECS-Aufgabenrollen und Amazon EKS-Workload-Identitäten. Übermäßige Berechtigungen können dazu führen, dass aus einer Kompromittierung einer Anwendung ein umfassenderer cloud wird, der den Zugriff auf Anmeldedaten, die Ausweitung von Berechtigungen oder den Datendiebstahl umfasst.

cloud mit Identitäts- und Netzwerksignalen in Zusammenhang bringen

AWS-native Telemetriedaten können Aufschluss darüber geben, was innerhalb eines Kontos geschehen ist, ohne dabei den früheren endpoint, Identitätsanbieter oder die SaaS-Sicherheitslücke offenzulegen, die den Angriff ermöglicht haben. Durch die Korrelation von cloud, Identitäts- und Netzwerkverhalten lassen sich hybride Angriffspfade rekonstruieren und der ursprüngliche Angreifer identifizieren.

Maßnahmen zur Reaktion auf einen Vorfall im Voraus vorbereiten

Legen Sie fest, wann Einsatzkräfte Sitzungen widerrufen, Zugriffsschlüssel deaktivieren, Workloads unter Quarantäne stellen, Rollen einschränken oder Konten isolieren dürfen. Amazon EventBridge, AWS Lambda und bestehende Workflows zur Sicherheitsorchestrierung können die Automatisierung unterstützen, doch destruktive Maßnahmen sollten Tests, Genehmigungsregeln und Rollback-Verfahren umfassen.

‍

Tatsächliche Vorfälle zur Erkennung von Bedrohungen bei AWS

Jüngste Vorfälle verdeutlichen, warum die Erkennung von Verhaltensmustern wichtiger ist als die reine Überwachung auf Protokollebene.

ransomware Januar 2025)

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.

Durch KI unterstützte FortiGate-Exploits (Januar–Februar 2026)

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.

Missbrauch von Berechtigungen bei LexisNexis ECS (Februar 2026)

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.

Einschränkungen und Missverständnisse bei der Erkennung von Bedrohungen durch AWS

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

Die Zukunft der AWS-Bedrohungserkennung

Mehrere Trends verändern derzeit die Art und Weise, wie Unternehmen die Erkennung von Bedrohungen in AWS-Umgebungen angehen.

• Angriffe unter Einsatz von KI nehmen zu. Wie die „FortiGate 2026“-Kampagne gezeigt hat, nutzen Angreifer generative KI, um ihre Angriffe in großem Maßstab durchzuführen. Die AWS-Bedrohungserkennung muss hiermit Schritt halten, indem sie Signale schneller korreliert, als Angreifer sie erzeugen können.
• Identität ist die neue Sicherheitsgrenze. Da über 70 % der cloud auf kompromittierte Identitäten zurückzuführen sind und 61 % der Unternehmen Root-Benutzer ohne MFA betreiben, wird die identitätsorientierte Erkennung weiterhin Vorrang vor netzwerkorientierten Ansätzen haben.
• Die Erkennung mehrstufiger Angriffe wird zum Standard. Die erweiterte Bedrohungserkennung von GuardDuty markiert einen Wandel hin zur Korrelation von Aktionen über Dienste und Zeiträume hinweg, anstatt Ereignisse einzeln zu bewerten. Dieses Konzept wird auf weitere AWS-Dienste undcloud ausgeweitet werden.
• Hybride Angriffswege erfordern eine ganzheitliche Übersicht. Da Unternehmen in AWS-, Azure-, lokalen und SaaS-Umgebungen tätig sind, werden bei Strategien zur Erkennung von Bedrohungen, die jeden Bereich isoliert betrachten, die wichtigsten Angriffe übersehen – nämlich jene, die sich lateral über Grenzen hinweg ausbreiten.

Wie die Vectra AI die Erkennung von Bedrohungen durch AWS durch korreliertes Angreiferverhalten unterstützt

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:

• Erkennen von korreliertem Angreiferverhalten über Identitäten, Rollen und cloud hinweg, anstatt isolierte AWS-Ereignisse zu betrachten
• Entscheiden Sie, welche Identität oder welches Konto das höchste Risiko darstellt, indem Sie Dringlichkeit und Kontext gegenüber der Menge priorisieren.
• Verringerung des Risikos einer fehlgeschlagenen Rollenkette-Zuordnung, indem verdächtige Aktivitäten nach Möglichkeit mit dem ursprünglichen Akteur in Verbindung gebracht werden
• Erkennung verdächtiger Abfolgen von Erkundungsaktivitäten, die auf eine Erkundung im Frühstadium hindeuten, bevor die seitliche Bewegung beginnt

Erleben Sie das Verhalten von AWS-Angreifern hautnah in einer geführten Angriffstour