Präambel

Willkommen zu einer weiteren Folge von AWS Detection Engineering mit Elastic. Sie können den vorherigen Teil von STS AssumeRoot hier lesen.

In diesem Artikel werden wir untersuchen, wie Bedrohungsakteure die Server-Side Encryption mit von Kunden bereitgestellten Schlüsseln (SSE-C) von Amazon S3 für Lösegeld- und Erpressungsoperationen nutzen. Diese moderne Missbrauchstaktik zeigt, wie Angreifer native Cloud-Dienste ausnutzen können, um ihre finanziellen Ziele zu erreichen.

Als Leser erhalten Sie Einblicke in die Funktionsweise von S3, SSE-C-Workflows und Buckets-Konfigurationen. Wir werden auch die Schritte dieser Technik durchgehen, Best Practices für die Sicherung von S3-Buckets besprechen und umsetzbare Anleitungen zur Erstellung von Erkennungslogik zur Identifizierung von SSE-C-Missbrauch in Ihrer Umgebung geben.

Diese Studie baut auf einer aktuellen Veröffentlichung des Halcyon Research Teams auf, die den ersten öffentlich bekannten Fall von Missbrauch von SSE-C durch Ransomware dokumentierte. Begleiten Sie uns, während wir diese aufkommende Bedrohung genauer untersuchen und Ihnen demonstrieren, wie Sie Angreifern einen Schritt voraus bleiben können.

Wir haben eine Zusammenfassung mit dem Terraform-Code und dem Emulationsskript veröffentlicht, auf die in diesem Blog verwiesen wird. Dieser Inhalt wird ausschließlich für Bildungs- und Forschungszwecke bereitgestellt. Bitte verwenden Sie es verantwortungsvoll und gemäß den geltenden Gesetzen und Richtlinien. Elastic übernimmt keine Haftung für unbeabsichtigte Folgen oder Missbrauch.

Genießen Sie es!

Grundlegendes zu AWS S3: Wichtige Sicherheitskonzepte und -funktionen

Bevor wir direkt in die Emulation und diese Taktiken, Techniken und Prozesse (TTPs) eintauchen, lassen Sie uns kurz überprüfen, was AWS S3 umfasst.

S3 ist der allgemeine Speicherdienst von AWS, der es den Benutzern ermöglicht, beliebige unstrukturierte oder strukturierte Daten in „Buckets“ zu speichern. Diese Buckets ähneln Ordnern, die Sie lokal auf Ihrem Computersystem finden würden. Die in diesen Buckets gespeicherten Daten werden Objekte genannt, und jedes Objekt wird durch einen Objektschlüssel eindeutig identifiziert, der wie ein Dateiname fungiert. S3 unterstützt viele Datenformate, von JSON bis zu Mediendateien und vielem mehr, was es ideal für eine Vielzahl von organisatorischen Anwendungsfällen macht.

Buckets können eingerichtet werden, um Objekte aus verschiedenen AWS S3-Diensten zu speichern, sie können jedoch je nach Anwendungsfall auch manuell oder programmgesteuert befüllt werden. Zusätzlich können Buckets die Versionierung verwenden, um mehrere Versionen von Objekten zu pflegen, was Schutz gegen versehentliches Löschen oder Überschreiben bietet. Allerdings ist die Versionierung nicht immer standardmäßig aktiviert, wodurch die Daten für bestimmte Arten von Angriffen anfällig werden, wie etwa durch Ransomware oder Massenlöschungen. Buckets können zum Speichern von Objekten aus verschiedenen AWS S3-Diensten eingerichtet werden, sie können jedoch je nach Anwendungsfall auch manuell oder programmgesteuert befüllt werden. Zusätzlich können Buckets die Versionierung verwenden, um mehrere Versionen von Objekten zu pflegen, was Schutz gegen versehentliches Löschen oder Überschreiben bietet. Allerdings ist die Versionierung nicht immer standardmäßig aktiviert, wodurch die Daten für bestimmte Arten von Angriffen anfällig sind, wie etwa Ransomware oder Massenlöschungen.

Der Zugriff auf diese Buckets hängt stark von ihren Zugriffsrichtlinien ab, die typischerweise bei der Erstellung festgelegt werden. Diese Richtlinien umfassen Einstellungen wie das Deaktivieren des öffentlichen Zugriffs, um eine unbeabsichtigte Offenlegung der Inhalte von Buckets zu verhindern. Die Konfiguration endet hier jedoch nicht; Buckets besitzen auch ihre eigenen eindeutigen Amazon Resource Name (ARN), die es ermöglichen, weitere granulare Zugriffsrichtlinien über Identitäts- und Zugriffsmanagement (IAM)-Rollen oder -Richtlinien zu definieren. Wenn beispielsweise der Nutzer „Alice“ Zugriff auf einen Bucket und dessen Objekte benötigt, müssen seiner IAM-Rolle spezifische Berechtigungen wie s3:GetObject zugewiesen werden. Diese Rolle kann entweder direkt auf Alice als Berechtigungsrichtlinie angewendet werden oder auf eine zugehörige Gruppe, zu der sie gehört.

Obwohl diese Mechanismen narrensicher erscheinen, sind Fehlkonfigurationen bei Zugriffskontrollen (z. B. zu freizügige Bucket-Richtlinien oder Zugriffskontrolllisten) eine häufige Ursache für Sicherheitsvorfälle. Zum Zeitpunkt dieses Schreibens sind beispielsweise laut buckets.grayhatwarfare.com ungefähr 325.800 Buckets öffentlich verfügbar. Elastic Security Labs beobachtete im Elastic Global Threat Report 2024 auch, dass 30 % der fehlgeschlagenen AWS-Posture-Checks mit S3 verbunden waren.

Serverseitige Verschlüsselung in S3
S3 bietet mehrere Verschlüsselungsoptionen zur Sicherung ruhender Daten. Dazu gehören:

• SSE-S3: Die Verschlüsselungsschlüssel werden vollständig von AWS verwaltet.
• SSE-KMS: Schlüssel werden über den AWS Key Management Service (KMS) verwaltet, was benutzerdefinierte Schlüsselrichtlinien und Zugriffskontrollen ermöglicht – sehen Sie, wie diese in Elastic implementiert werden.
• SSE-C: Kunden stellen ihre eigenen Verschlüsselungsschlüssel zur Verfügung, um mehr Kontrolle zu haben. Diese Option wird häufig für Compliance- oder spezifische Sicherheitsanforderungen verwendet, führt jedoch zu zusätzlichem Betriebsaufwand, wie z. B. der sicheren Verwaltung und Speicherung von Schlüsseln. Wichtig ist, dass AWS keine SSE-C-Schlüssel speichert; stattdessen wird der HMAC (hash-basierter Nachrichtenauthentifizierungscode) eines Schlüssels zu Überprüfungszwecken geloggt.

Im Fall von SSE-C kann die falsche Verwaltung der Verschlüsselungsschlüssel oder vorsätzlicher Missbrauch (z. B. Ransomware) dazu führen, dass Daten dauerhaft unzugänglich werden.

Lebenszyklus-Richtlinien

S3-Buckets können auch Lebenszyklusrichtlinien nutzen, die Aktionen wie das Überführen von Objekten in kostengünstigere Speicherklassen (z. B. Glacier) oder das Löschen von Objekten nach einer festgelegten Zeit automatisieren. Obwohl diese Richtlinien typischerweise zur Kostenoptimierung verwendet werden, können sie von Angreifern ausgenutzt werden, um die Löschung kritischer Daten zu planen, was den Druck bei einem Lösegeldvorfall erhöht.

Speicherklassen

Amazon S3 bietet mehrere Speicherklassen, die jeweils für unterschiedliche Zugriffsmuster und Zugriffshäufigkeiten konzipiert sind. Obwohl Speicherklassen in der Regel zur Kostenoptimierung ausgewählt werden, ist es entscheidend, sie zu verstehen, wenn man bedenkt, wie Verschlüsselung und Sicherheit mit der Datenspeicherung interagieren.

Zum Beispiel gewährleisten S3 Standard und Intelligent-Tiering einen häufigen Zugriff mit minimaler Latenz, was sie für Live-Anwendungen geeignet macht. Andererseits kommt es bei Archivierungsklassen wie Glacier Flexible Retrieval und Deep Archive zu Verzögerungen, bevor auf Daten zugegriffen werden kann, was die Incident-Response in Sicherheits-Szenarien erschweren kann.

Dies wird besonders relevant, wenn eine Verschlüsselung eingeführt wird. Server-Side Encryption (SSE) funktioniert für alle Speicherklassen, aber SSE-C (vom Kunden bereitgestellte Schlüssel) überträgt die Verantwortung für die Schlüsselverwaltung auf den Nutzer oder Angreifer. Im Gegensatz zur von AWS verwalteten Verschlüsselung (SSE-S3, SSE-KMS) erfordert SSE-C, dass bei jedem Abrufvorgang der ursprüngliche Verschlüsselungsschlüssel bereitgestellt wird – und wenn dieser Schlüssel verloren geht oder von einem Angreifer nicht weitergegeben wird, sind die Daten dauerhaft nicht wiederherstellbar.

Mit diesem Verständnis stellt sich eine kritische Frage zu den Auswirkungen des in der Praxis beobachteten SSE-C-Missbrauchs: Was passiert, wenn ein Angreifer Zugriff auf öffentlich zugängliche oder falsch konfigurierte S3-Buckets erhält und sowohl die Speicherrichtlinie als auch die Verschlüsselungsschlüssel kontrolliert?

So beginnt: Missbrauch von SSE-C für Erpressungsoperationen

Im folgenden Abschnitt werden wir einen praktischen Ansatz zur Emulation dieses Verhaltens in unserer AWS-Sandbox-Umgebung vorstellen, indem wir Folgendes ausführen:

1. Bereitstellen anfälliger Infrastruktur über den Infrastructure-as-Code (IaC)-Anbieter Terraform
2. Erkunden Sie, wie man SSE-C-Anfragen in Python erstellt
3. Ausführen eines benutzerdefinierten Skripts, um das im Halcyon-Blog beschriebene Erpressungsverhalten zu simulieren

Voraussetzungen

Dieser Artikel behandelt die Nachbildung eines spezifischen Szenarios für die Erkennungstechnik. Dazu müssen Sie zunächst Folgendes festlegen.

• Terraform muss lokal installiert sein
• Python 3.9+ muss ebenfalls lokal installiert sein, um in der virtuellen Umgebung verwendet zu werden und ein Emulationsskript auszuführen.
• Das AWS CLI-Profil muss mit Administratorrechten eingerichtet werden, damit es von Terraform während der Bereitstellung der Infrastruktur verwendet werden kann.

Bereitstellung von anfälliger Infrastruktur

Für unsere Whitebox-Emulation ist es wichtig, eine S3-Konfiguration zu replizieren, die ein Unternehmen in einem praktischen Szenario haben könnte. Im Folgenden finden Sie eine Zusammenfassung der bereitgestellten Infrastruktur:

• Region: us-east-1 (Standard-Deployment-Region)
• S3 Bucket: Ein eindeutig benannter Abrechnungsdaten-Bucket, der sensible Daten enthält und eine von Angreifern kontrollierte Verschlüsselung zulässt
• Bucket Ownership Controls: Erzwingt „BucketOwnerEnforced“, um ACL-basierte Berechtigungen zu verhindern.
• Öffentliche Zugangsbeschränkungen: Der öffentliche Zugang ist vollständig gesperrt, um eine versehentliche Offenlegung zu verhindern.
• IAM User: Ein kompromittierter, von einem Angreifer kontrollierter IAM-Nutzer mit übermäßigen S3-Berechtigungen; es ist kein Anmeldeprofil zugewiesen, da Zugangsschlüssel programmgesteuert an anderer Stelle für automatisierte Aufgaben verwendet werden
• IAM Policy: Auf sowohl Buckets- als auch Objektebene haben Angreifer die Berechtigung zu Folgendem:
  • s3:GetObject
  • s3:PutObject
  • s3:DeleteObject
  • s3:PutLifecycleConfiguration
  • s3:ListObjects
  • s3:ListBucket
• Wird sowohl auf Buckets- als auch auf Objektebene angewendet
• IAM Access Keys: Zugriffsschlüssel werden für den feindlichen Nutzer generiert und ermöglichen den programmgesteuerten Zugriff
• Dummy Data: Simulierte sensible Daten (customer_data.csv) werden in den Bucket hochgeladen.

Das Verständnis der Infrastruktur ist entscheidend, um zu beurteilen, wie sich diese Art von Angriff entfaltet. Der Halcyon-Blog beschreibt die Angriffsmethodik, liefert jedoch nur wenige Details zur spezifischen AWS-Konfiguration der betroffenen Organisationen. Diese Details sind von entscheidender Bedeutung, um die Durchführbarkeit eines solchen Angriffs und die für eine erfolgreiche Ausführung erforderlichen Schritte zu bestimmen.

Zugänglichkeit und Exposition von Buckets

Damit ein Angriff dieser Art stattfinden kann, muss ein Angreifer über eine der beiden Hauptmethoden Zugang zu einem S3 Bucket erlangen:

Öffentlich zugängliche Buckets: Wenn ein Bucket mit einer öffentlichen Zugriffsrichtlinie falsch konfiguriert ist, kann ein Angreifer direkt darauf zugreifen, vorausgesetzt, die Berechtigungsrichtlinie des Buckets erlaubt Aktionen wie s3:PutObject, s3:DeleteObject oder s3:PutLifecycleConfiguration. Diese Berechtigungen werden häufig fälschlicherweise mit einem Platzhalter (*) als Hauptbenutzer vergeben, was bedeutet, dass jeder diese Operationen ausführen kann.

Kompromittierte Anmeldeinformationen: Wenn ein Angreifer AWS-Anmeldeinformationen erhält (durch Anmeldeinformationslecks, Phishing oder Malware), kann er sich als legitimer IAM-Nutzer authentifizieren und mit S3 interagieren, als wäre er der vorgesehene Kontoinhaber.

In unserer Emulation nehmen wir an, dass der Bucket nicht öffentlich ist, was bedeutet, dass der Angriff auf kompromittierten Anmeldeinformationen beruht. Dazu muss der Angreifer gültige AWS-Zugriffsschlüssel erhalten haben und eine Cloud-Infrastruktur-Erkundung durchgeführt haben, um zugängliche S3-Buckets zu identifizieren. Dies wird üblicherweise mit AWS-API-Aufrufen wie s3:ListAllMyBuckets, s3:ListBuckets oder s3:ListObjects durchgeführt, die Buckets und deren Inhalte in bestimmten Regionen offenlegen.

Erforderliche IAM-Berechtigungen für die Durchführung eines Angriffs: Um Dateien mit SSE-C zu verschlüsseln und eine Löschrichtlinie erfolgreich durchzusetzen, muss der Angreifer über die entsprechenden IAM-Berechtigungen verfügen. In unserer Emulation haben wir explizite Berechtigungen für den kompromittierten IAM-Nutzer konfiguriert, aber in einem realen Szenario könnten mehrere Berechtigungsmodelle diesen Angriff ermöglichen:

• Benutzerdefinierte, übermäßig permissive Richtlinien: Organisationen könnten unwissentlich weitreichende S3-Berechtigungen ohne strenge Einschränkungen gewähren.
• AWS-verwaltete Richtlinien: Der Angreifer hat möglicherweise Anmeldeinformationen erhalten, die einem user oder einer Rolle zugeordnet sind, die über AmazonS3FullAccess oder AdministratorAccessverfügt.
• Partielle Berechtigungen auf Objektebene: Wenn der IAM-Nutzer AllObjectActions hätte, würde dies nur Aktionen auf Objektebene erlauben, aber keine Änderungen an Lebenszyklusrichtlinien oder Bucket-Listings ermöglichen, die notwendig sind, um Objekte abzurufen und dann zu iterieren, um sie zu verschlüsseln und zu überschreiben.

Der Halcyon-Blog gibt nicht an, welche Berechtigungen missbraucht wurden, aber unsere Whitebox-Emulation stellt sicher, dass die minimal erforderlichen Berechtigungen vorhanden sind, damit der Angriff wie beschrieben funktioniert.

Die Rolle des kompromittierten IAM-Nutzers
Ein weiterer kritischer Faktor ist die Art des IAM-Nutzers, dessen Zugangsdaten kompromittiert wurden. In AWS benötigt ein Angreifer nicht unbedingt die Anmeldedaten eines Nutzers, der ein interaktives Anmeldeprofil besitzt. Viele IAM-Nutzer werden ausschließlich für den programmatischen Zugriff erstellt und benötigen kein Passwort für die AWS-Managementkonsole oder eine Multi-Faktor-Authentifizierung (MFA), die beide als zusätzliche Sicherheitsbarrieren dienen könnten.

Das bedeutet, dass, wenn die gestohlenen Zugangsdaten eines IAM-Nutzers für die Automatisierung oder Serviceintegration verwendet werden, es dem Angreifer leichter fallen würde, API-Anfragen ohne zusätzliche Authentifizierungsherausforderungen auszuführen.

Der Halcyon-Blog dokumentiert zwar effektiv die bei diesem Angriff verwendete Technik, enthält jedoch keine Details zur zugrunde liegenden AWS-Konfiguration des Opfers. Das Verständnis der Infrastruktur hinter den Angriffen – wie etwa Bucket-Zugang, IAM-Berechtigungen und Nutzerrollen – ist entscheidend, um zu beurteilen, wie diese Lösegeldoperationen in der Praxis ablaufen. Da diese Einzelheiten nicht bereitgestellt werden, müssen wir fundierte Annahmen treffen, um die Bedingungen, die den Erfolg des Angriffs ermöglichten, besser zu verstehen.

Unsere Emulation ist darauf ausgelegt, die minimal notwendigen Bedingungen für diese Art von Angriff nachzubilden, um eine realistische Bewertung der Abwehrstrategien und der Fähigkeiten zur Bedrohungserkennung sicherzustellen. Indem wir die technischen Aspekte der Infrastruktur untersuchen, können wir tiefere Einblicke in potenzielle Abhilfemaßnahmen geben und wie Unternehmen sich proaktiv vor ähnlichen Bedrohungen schützen können.

Einrichten der Infrastruktur

Für die Bereitstellung unserer Infrastruktur verwenden wir Terraform als unser IaC-Framework. Um diese Veröffentlichung übersichtlich zu halten, haben wir sowohl die Terraform-Konfiguration als auch das Atom-Emulationsskript in einer herunterladbaren Zusammenfassung für einen einfachen Zugriff gespeichert. Nachfolgend finden Sie die erwartete lokale Dateistruktur, sobald diese Dateien heruntergeladen sind.

Nachdem Sie die erforderlichen Dateien lokal eingerichtet haben, können Sie eine virtuelle Python-Umgebung für dieses Szenario erstellen und die notwendigen Abhängigkeiten installieren. Sobald die Umgebung konfiguriert ist, wird der folgende Befehl Terraform initialisieren und die Infrastruktur bereitstellen:

Command: python3 s3\_sse\_c\_ransom.py deploy

Sobald das Deployment abgeschlossen ist, steht die erforderliche AWS-Infrastruktur zur Verfügung, um mit der Emulation und Ausführung des Angriffs fortzufahren. Es ist wichtig zu beachten, dass der öffentliche Zugriff gesperrt ist und die IAM-Richtlinie aus Sicherheitsgründen nur auf den dynamisch generierten IAM-Nutzer angewendet wird. Wir empfehlen Ihnen jedoch dringend, die Infrastruktur abzubauen, sobald die Tests abgeschlossen sind oder nachdem die erforderlichen Daten erfasst wurden.

Falls Sie sich zufällig bei Ihrer AWS-Konsole anmelden oder die CLI verwenden, können Sie überprüfen, ob der Bucket in der Region us-east-1 existiert und customer_data.csv, enthält, die, wenn sie heruntergeladen werden, im Klartext vorliegen. Sie werden auch feststellen, dass keine „ransom.note“ existiert.

Erkunden Sie, wie man S3 SSE-C-Anfragen in Python erstellt

Vor der Ausführung der atomaren Emulation ist es wichtig, die zugrundeliegende Technik zu untersuchen, die es einem Angreifer ermöglicht, diesen Angriff erfolgreich ItW auszuführen.

Für diejenigen, die mit AWS vertraut sind, sind S3-Operationen – wie der Zugriff auf Buckets, das Auflisten von Objekten oder das Verschlüsseln von Daten – bei Verwendung der AWS SDKs oder der AWS CLI in der Regel einfach. Diese Tools abstrahieren einen Großteil der Komplexität und ermöglichen es den Nutzern, Vorgänge auszuführen, ohne die zugrunde liegende API-Mechanik tiefgehend verstehen zu müssen. Dies senkt auch die Wissensbarriere für einen Gegner, der versucht, diese Funktionalitäten zu missbrauchen.

Der Halcyon-Blog weist jedoch auf ein wichtiges technisches Detail zur Durchführung des Angriffs hin:

„Der Angreifer startet den Verschlüsselungsprozess, indem er den Header x-amz-server-side-encryption-customer-algorithm aufruft und dabei einen AES-256-Verschlüsselungsschlüssel verwendet, den er selbst generiert und lokal speichert.“

Der wesentliche Unterschied hier ist die Verwendung des x-amz-server-side-encryption-customer-algorithm-Headers, der für Verschlüsselungsoperationen in diesem Angriff erforderlich ist. Gemäß der AWS-Dokumentation wird dieser SSE-C-Header üblicherweise angegeben, wenn vorsignierte URLs erstellt und SSE-C in S3 verwendet werden. Dies bedeutet, dass der Angreifer nicht nur die Daten des Opfers verschlüsselt, sondern dies auf eine Weise tut, bei der AWS selbst den Verschlüsselungsschlüssel nicht speichert, was eine Wiederherstellung ohne die Mitwirkung des Angreifers unmöglich macht.

Vorsignierte URLs und ihre Rolle beim Missbrauch von SSE-C

Was sind vorab signierte URLs?
Vorsignierte URLs sind signierte API-Anfragen, die es den Nutzern ermöglichen, bestimmte S3-Operationen für eine begrenzte Zeit durchzuführen. Diese URLs werden häufig verwendet, um Objekte sicher zu teilen, ohne AWS-Anmeldeinformationen preiszugeben. Eine vorsignierte URL gewährt temporären Zugriff auf ein S3-Objekt und kann über einen Browser aufgerufen oder programmgesteuert in API-Anfragen verwendet werden.

In einer typischen AWS-Umgebung nutzen die Nutzer SDKs oder CLI-Wrapper für vorsignierte URLs. Allerdings erfordert AWS bei der Verwendung von SSE-C zusätzliche Header für die Verschlüsselung oder Entschlüsselung.

SSE-C und erforderliche HTTP-Header
Bei SSE-C-Anfragen – entweder über das AWS SDK oder direkte S3 REST-API-Aufrufe – müssen die folgenden Header einbezogen werden:

• x-amz-server-side-encryption-customer-algorithm: Geben Sie den Verschlüsselungsalgorithmus an, aber er muss AES256 sein (in Halcyons Bericht vermerkt)
• x-amz-server-side-encryption-customer-key: Stellt einen 256-Bit, base64-kodierten Verschlüsselungsschlüssel bereit, den S3 zum Verschlüsseln oder Entschlüsseln Ihrer Daten verwenden kann
• x-amz-server-side-encryption-customer-key-MD5: Stellt eine Base64-kodierte 128-Bit-MD5-Prüfsumme des Verschlüsselungsschlüssels bereit; S3 verwendet diesen Header für eine Nachrichtenintegritätsprüfung, um sicherzustellen, dass der Verschlüsselungsschlüssel ohne Fehler oder Manipulation übertragen wurde.

Bei der Suche nach Erkennungsmöglichkeiten sind diese Details entscheidend.

AWS Signature Version 4 (SigV4) und ihre Rolle

Anfragen an S3 sind entweder authentifiziert oder anonym. Da die SSE-C-Verschlüsselung mit vorsignierten URLs eine Authentifizierung erfordert, müssen alle Anfragen kryptografisch signiert werden, um ihre Legitimität zu beweisen. Hier kommt AWS Signature Version 4 (SigV4) ins Spiel.

AWS SigV4 ist ein Authentifizierungsmechanismus, der sicherstellt, dass API-Anfragen an AWS-Dienste signiert und verifiziert werden. Dies ist besonders wichtig für SSE-C-Operationen, da das Ändern von Objekten in S3 authentifizierte API-Aufrufe erfordert.

Für diesen Angriff muss jede Verschlüsselungsanforderung signiert werden von:

1. Erstellen einer kryptografischen Signatur mit AWS SigV4
2. Einbindung der Signatur in die Anfrage-Header
3. Anhängen der erforderlichen SSE-C-Verschlüsselungsheader
4. Senden Sie die Anfrage an S3, um das Objekt mit der verschlüsselten Version zu überschreiben.

Ohne ordnungsgemäße SigV4-Signierung würde AWS diese Anfragen ablehnen. Angriffe wie der von Halcyon beschriebene beruhen auf kompromittierten Anmeldeinformationen, und wir wissen das, weil die Anfragen in unseren Tests nicht zurückgewiesen wurden. Es deutet auch darauf hin, dass die Angreifer wissen, dass sie AWS S3-Fehlkonfigurationen wie falsche Signaturanforderungen ausnutzen können und die Feinheiten von Buckets und deren Zugriffskontrollen für Objekte verstehen. Dies verstärkt die Annahme, dass der Angriff auf kompromittierten AWS-Anmeldeinformationen beruhte und nicht auf einem exponierten, öffentlich zugänglichen S3-Bucket, und dass die Angreifer geschickt genug waren, um die Nuancen nicht nur von S3-Buckets und -Objekten, sondern auch von Authentifizierung und Verschlüsselung in AWS zu verstehen.

Zündung unserer atomaren Emulation

Unsere atomare Emulation wird die „kompromittierten“ Anmeldeinformationen des IAM-Nutzers ohne Anmeldeprofil verwenden, dem eine Berechtigungsrichtlinie zugeordnet ist, die mehrere S3-Aktionen für unseren Ziel-Bucket erlaubt. Zur Erinnerung: Die Infrastruktur und die Umgebung, in der wir dies durchführen, wurden im Abschnitt „Einrichten der Infrastruktur“ unter Bezugnahme auf unsere freigegebene Zusammenfassung bereitgestellt.

Im Folgenden finden Sie einen schrittweisen Workflow der Emulation.

1. Gestohlene AWS-Anmeldeinformationen laden (aus Umgebungsvariablen abgerufen)
2. S3-Client mit kompromittierten Zugangsdaten einrichten
3. S3-Endpoint-URL generieren (URL des Buckets konstruieren)
4. S3-Objekte auflisten → s3:ListObjectsV2 (Objektliste abrufen)
5. AES-256-Verschlüsselungsschlüssel erzeugen (lokal erstellt)
6. Startschleife (für jedes Objekt in den Buckets)
   1. GET-Anfrage generieren und mit AWS SigV4 signieren (Anfrage authentifizieren)
   2. Objekt von S3 abrufen → s3:GetObject (Abrufen unverschlüsselter Daten)
   3. PUT-Anfrage generieren und mit AWS SigV4 signieren (SSE-C-Header anhängen)
   4. Objekt in S3 verschlüsseln und überschreiben → s3:PutObject (mit SSE-C verschlüsseln)
7. Schleife beenden
8. Wenden Sie die 7-Tage-Löschrichtlinie an → s3:PutLifecycleConfiguration (zeitlich begrenzte Datenvernichtung)
9. Lösegeldforderung auf S3 hochladen → s3:PutObject (Erpressernachricht für das Opfer hinterlassen)

Nachfolgend sehen Sie eine visuelle Darstellung dieses Emulations-Workflows:

In unserem Python-Skript haben wir absichtlich Aufforderungen hinzugefügt, die eine Interaktion des Nutzers erfordern, um zu bestätigen, dass Sie damit einverstanden sind, dieses Skript nicht zu missbrauchen. Eine weitere Eingabeaufforderung, die während der Detonation generiert wird und die Ausführung anhält, damit der Nutzer Zeit für eine AWS-Untersuchung hat, bevor er die S3-Objekte löscht. Da SSE-C verwendet wird, werden die Objekte mit einem Schlüssel verschlüsselt, auf den Terraform keinen Zugriff hat, und daher würde der Vorgang fehlschlagen.

Command: python s3\_sse\_c\_ransom.py detonate

Nach der Detonation werden die Objekte in unserem S3-Bucket mit SSE-C verschlüsselt sein, eine Lösegeldforderung wird hochgeladen worden sein, und ein Ablauflebenszyklus wird hinzugefügt worden sein.

Wenn Sie versuchen, auf das customer_data.csv-Objekt zuzugreifen, wird AWS die Anforderung ablehnen, da es mit serverseitiger Verschlüsselung gespeichert wurde. Um das Objekt abzurufen, ist eine signierte Anfrage erforderlich, die den korrekten AES-256-Verschlüsselungsschlüssel enthält.

Bereinigung

Die Bereinigung dieser Emulation ist relativ einfach. Wenn Sie die S3-Objekte behalten möchten, beginnen Sie mit Schritt 1, andernfalls gehen Sie direkt zu Schritt 5.

1. Gehen Sie zur Region us-east-1
2. Navigieren Sie zu S3
3. Lokalisieren Sie s3-sse-c-ransomware-payroll-XX bucket
4. Entfernen Sie alle Objekte
5. Command: python s3\_sse\_c\_ransom.py cleanup

Nach Abschluss des Vorgangs werden alle ursprünglich bereitgestellten Elemente entfernt.

Erkennungs- und Hunting-Strategien

Nach unserer atomaren Emulation ist es von entscheidender Bedeutung, darzulegen, wie wir dieses Ransomware-Verhalten anhand der von AWS CloudTrail bereitgestellten API-Ereignisprotokolle effektiv erkennen können. Beachten Sie, dass wir Elastic Stack für die Datenaufnahme und die Entwicklung anfänglicher Abfragen nutzen werden; jedoch sollten die Abfragelogik und der Kontext in das SIEM Ihrer Wahl übersetzbar sein. Es ist auch wichtig zu beachten, dass Datenereignisse für S3 in Ihrer CloudTrail-Konfiguration auf „Alle Ereignisse loggen“ eingestellt sein sollten.

Ungewöhnliche AWS S3-Objektverschlüsselung mit SSE-C

Das Ziel dieser Erkennungsstrategie ist es, PutObject-Anfragen zu identifizieren, die SSE-C verwenden, da vom Kunden bereitgestellte Verschlüsselungsschlüssel ein starker Indikator für anomale Aktivitäten sein können – insbesondere, wenn ein Unternehmen hauptsächlich die von AWS verwaltete Verschlüsselung über KMS (SSE-KMS) oder die native Verschlüsselung von S3 (SSE-S3) nutzt.

In unserer Emulation wurden PutObject Anforderungen so konfiguriert, dass der x-amz-server-side-encryption-customer-algorithm-Header auf AES256 gesetzt war, um AWS zu signalisieren, dass vom Kunden bereitgestellte Schlüssel für die Verschlüsselung (SSE-C) verwendet wurden.

Glücklicherweise logt AWS CloudTrail diese Verschlüsselungsdetails in den Anforderungsparametern, sodass Sicherheitsteams ungewöhnliche Nutzungen von SSE-C erkennen können. Zu den wichtigsten zu überwachenden CloudTrail-Attributen gehören:

• SignatureVersion: SigV4 → Signalisiert, dass diese Anfrage signiert wurde
• SSEApplied: SSE_C → Signalisiert, dass die serverseitige Verschlüsselung mit dem Kundenschlüssel angewendet wurde
• bucketName: s3-sse-c-ransomware-payroll-96 → Signalisiert, mit welchem Bucket dies geschehen ist
• x-amz-server-side-encryption-customer-algorithm: AES256 → Signalisiert, welcher Algorithmus für den vom Kunden verwalteten Verschlüsselungsschlüssel verwendet wurde
• key: customer_data.csv → Gibt den Namen des Objekts an, auf das dies angewendet wurde

Mit diesen Details können wir bereits eine Abfrage zur Bedrohungserkennung erstellen, die mit diesen Ereignissen und letztlich mit der im ursprünglichen Halcyon-Blog gemeldeten Bedrohung übereinstimmen würde.

Obwohl diese Erkennung umfassend ist, sollten Organisationen sie an ihre Umgebung anpassen, indem sie sich folgende Fragen stellen:

• Erwarten wir vorsignierte URLs mit SigV4 für S3-Bucket- oder Objektoperationen?
• Erwarten wir, dass SSE-C für PutObject -Operationen in S3 oder in diesem speziellen Bucket verwendet wird?

Reduzierung von False Positives mit dem New Term-Regeltyp
Um Fehlalarme (False Positives, FPs) zu minimieren, können wir den New Terms-Regeltyp von Elastic nutzen, der hilft, erstmalige Vorkommen verdächtiger Aktivitäten zu erkennen. Anstatt bei jeder Übereinstimmung ein Alerting auszulösen, verfolgen wir eindeutige Kombinationen von IAM-Nutzern und betroffenen S3-Buckets und generieren nur dann ein Alerting, wenn dieses Verhalten innerhalb eines festgelegten Zeitraums zum ersten Mal beobachtet wird. Dabei achten wir unter anderem auf einige dieser einzigartigen Kombinationen:

• Eindeutige IAM-Nutzer (ARNs), die SSE-C-Verschlüsselung in S3 vornehmen.
• Bestimmte Buckets, bei denen SSE-C angewendet wird.

Diese Warnungen werden nur ausgelöst, wenn diese Aktivität zum ersten Mal in den letzten 14 Tagen beobachtet wurde.

Dieser adaptive Ansatz stellt sicher, dass legitime Anwendungsfälle im Laufe der Zeit erlernt werden, wodurch wiederholte Alerts bei erwarteten Vorgängen verhindert werden. Gleichzeitig werden anomale Erstvorkommen von SSE-C in S3 markiert, was zur frühzeitigen Erkennung von Bedrohungen beiträgt. Bei Bedarf können Ausnahmen für Regeln für spezifische Benutzeridentitäts-ARNs, Buckets, Objekte oder sogar Quell-IPs hinzugefügt werden, um die Erkennungslogik zu verfeinern. Durch die Einbeziehung des historischen Kontexts und der Verhaltensgrundlagen verbessert diese Methode die Signaltreue, was sowohl die Effektivität der Erkennungen als auch die Handlungsfähigkeit der Warnungen erhöht.

Regelreferenzen

Ungewöhnliche AWS S3-Objektverschlüsselung mit SSE-C
Übermäßige AWS S3-Objektverschlüsselung mit SSE-C

Fazit

Wir schätzen es aufrichtig, dass Sie sich die Zeit genommen haben, diese Publikation zu lesen, und, falls Sie es getan haben, die Emulation selbst auszuprobieren. Whitebox-Tests spielen eine entscheidende Rolle in der Cloud-Sicherheit, da sie es uns ermöglichen, reale Bedrohungen zu replizieren, ihre Verhaltensmuster zu analysieren und effektive Erkennungsstrategien zu entwickeln. Da Cloud-basierte Angriffe immer häufiger werden, ist es unerlässlich, die Werkzeuge hinter den Taktiken der Angreifer zu verstehen und Forschungsergebnisse mit der breiteren Sicherheits-Community zu teilen.

Falls Sie daran interessiert sind, unseren AWS Erkennungsregelsatz zu erkunden, können Sie ihn hier finden: Elastic AWS Erkennungsregeln. Wir begrüßen auch Beiträge zur Verbesserung unseres Regelwerks – Ihre Bemühungen tragen zur Stärkung der kollektiven Verteidigung bei, und wir schätzen sie sehr!

Wir empfehlen allen Interessierten, die Veröffentlichung von Halcyon zu lesen und danken Ihnen im Voraus dafür, dass Sie Ihre Forschungsergebnisse mit uns teilen!

Bis bald.

Wichtige Referenzen:

Halcyon Research Blog über SSE-C ItW
Elastic-Emulationscode für SSE-C in AWS
Elastic – Vordefinierter AWS-Regelsatz zur Bedrohungserkennung
Elastic-Repository mit vordefinierten Erkennungsregeln
Regel: Ungewöhnliche AWS S3-Objektverschlüsselung mit SSE-C
Regel: Übermäßige AWS S3-Objektverschlüsselung mit SSE-C