Datenabfluss in ein fremdes Cloud-Konto erkennen

Kurzfassung: Daten müssen die Umgebung nicht über das Netz verlassen, um gestohlen zu sein. In der Cloud reicht ein Teilen: Ein Snapshot, ein Maschinenabbild oder ein Speicher wird einem fremden Konto zugänglich gemacht - die Daten bleiben, wo sie sind, und gehören doch dem Angreifer. Solche Freigaben laufen über benannte Cloud-Befehle, und die sind in der Prozess-Telemetrie sichtbar. Drei sigma-cli-validierte Sigma-Regeln nehmen sie. Dazu Härtung und der Test im Lab. Serie "Angriff erkennen".

Klassische Exfiltration schiebt Daten durch einen Kanal nach außen - FTP, ein C2-Tunnel, ein USB-Stick. In der Cloud gibt es einen leiseren Weg: Der Angreifer kopiert nichts, er teilt. Ein Volumen-Snapshot, ein Maschinenabbild oder ein Speicher-Container wird einem Konto freigegeben, das der Angreifer kontrolliert. Von dort entnimmt er die Daten in Ruhe, ganz ohne auffälligen Datenstrom aus der eigentlichen Umgebung. Für die Verteidigung ist das tückisch, weil keine große Übertragung auffällt - wohl aber der Befehl, der die Freigabe einrichtet. Dieser Beitrag bleibt auf der Erkennungsseite und zeigt, woran sich die Freigabe an ein fremdes Konto erkennen lässt, nicht, wie man Daten abzieht.

Einordnung in ATT&CK: Transfer Data to Cloud Account (T1537) in der Taktik Exfiltration; in dieser Serie steht die Technik in der Spalte Exfiltration. Sie grenzt sich vom Datenabfluss über Cloud-Speicher und von den Netz-Protokollen dadurch ab, dass hier nichts übertragen, sondern eine vorhandene Ressource einem anderen Konto zugänglich gemacht wird.

Was der Angreifer tut

Der Transfer in ein fremdes Konto folgt - auf der Ebene des Prinzips, nicht als Anleitung - einigen wiederkehrenden Wegen, die alle einen benannten Cloud-Befehl aufrufen:

  • Einen Snapshot teilen. Eine Volumen-Schattenkopie wird per Berechtigung für ein anderes Konto freigegeben; das fremde Konto erstellt daraus ein eigenes Volumen und liest die Daten.
  • Ein Abbild teilen. Ein Maschinenabbild wird mit einer Startberechtigung an ein anderes Konto gegeben, das es startet und die enthaltenen Daten entnimmt.
  • Einen Speicher freigeben. Ein zeitlich begrenztes Zugriffstoken macht einen Speicher-Container für Dritte lesbar, ohne dass ein Konto geteilt werden muss.
  • In Ruhe entnehmen. Der eigentliche Abfluss passiert dann im fremden Konto - außerhalb der Sicht der betroffenen Umgebung.

Für die Erkennung ist entscheidend: Jeder Weg nennt einen benannten Cloud-Befehl mit einem Freigabe-Parameter. Nicht der spätere Zugriff im fremden Konto ist der erste Ansatzpunkt, sondern der Befehl, der die Freigabe setzt.

Welche Logquellen die Technik zeigt

  • Prozess-Telemetrie zuerst. Event 4688 zeigt die Cloud-CLI-Aufrufe samt vollständiger Befehlszeile, wenn die Verwaltung von einem Windows-Host aus erfolgt - die wichtigste Endpunkt-Quelle für diese Technik.
  • Befehlszeilen-Kontext. Parameter wie modify-snapshot-attribute, create-volume-permission, LaunchPermission oder generate-sas machen die Freigabe sichtbar.
  • Cloud-Audit-Logs. Auf der Plattform selbst sind die Freigaben in den Audit- und Aktivitätsprotokollen zu finden - die wichtigste Quelle, wenn die Verwaltung nicht über einen Endpunkt läuft, und eine wertvolle Ergänzung zur Prozess-Sicht.
  • Werkzeug-Kontext. Die Cloud-CLIs sind legitime Verwaltungswerkzeuge; erst Parameter, Konto und Zielkonto machen den Unterschied. Grundlagen zum Missbrauch legitimer Werkzeuge unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist die AWS-CLI mit modify-snapshot-attribute und create-volume-permission, also das Freigeben einer Schattenkopie an ein anderes Konto. Das zweite ist die AWS-CLI mit modify-image-attribute und einer LaunchPermission, das Teilen eines Maschinenabbilds. Das dritte ist die Azure-CLI mit storage und generate-sas, das Erzeugen eines teilbaren Zugriffstokens. Die ersten beiden stehen auf hoher Stufe, weil eine kontoübergreifende Freigabe von Snapshots oder Abbildern selten und folgenreich ist; das SAS-Token steht auf mittlerer Stufe, weil es auch legitim für Backups und Freigaben genutzt wird. Entscheidend ist der Kontext: Legitime Treffer stammen aus bekannten Multi-Account-Abläufen, von Automatisierung und mit bekannten Zielkonten. Auffällig wird es, wenn das Zielkonto unbekannt ist, der Aufruf von einem untypischen Konto stammt oder außerhalb geregelter Abläufe liegt. Eine einzelne Zeile ist schwach; die Freigabe an ein unbekanntes Zielkonto ist das eigentliche Signal.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: die geteilte Schattenkopie, das geteilte Abbild und das erzeugte SAS-Token. Alle drei werten die Prozess-Telemetrie der Cloud-CLIs aus.

1. AWS-Snapshot an ein anderes Konto freigegeben (T1537). modify-snapshot-attribute mit create-volume-permission. Wegen der Tragweite auf level: high.

Sigma
title: AWS-Snapshot an ein anderes Konto freigegeben
id: 4b8c2e71-3d96-4b52-a7f1-6c9b5d8e2a44
status: experimental
description: |
  Erkennt die AWS-CLI beim Freigeben einer EBS-Volumen-Schattenkopie an ein anderes Konto ueber
  modify-snapshot-attribute mit create-volume-permission. Angreifer teilen so Datenttraeger-Abbilder mit
  einem von ihnen kontrollierten Cloud-Konto, um Daten abzuziehen (Transfer Data to Cloud Account).
references:
  - https://attack.mitre.org/techniques/T1537/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1537
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\aws.exe'
  sel_cmd:
    CommandLine|contains: 'modify-snapshot-attribute'
  sel_perm:
    CommandLine|contains: 'create-volume-permission'
  condition: sel_img and sel_cmd and sel_perm
falsepositives:
  - Legitime kontouebergreifende Freigaben in Multi-Account-Umgebungen - bekannte Konten, Automatisierung und Zielkonten als Baseline ausnehmen
level: high

2. AWS-Abbild (AMI) an ein anderes Konto freigegeben (T1537). modify-image-attribute mit einer LaunchPermission. Ebenfalls level: high.

Sigma
title: AWS-Abbild (AMI) an ein anderes Konto freigegeben
id: 7e1c4a93-2d86-4b52-9f51-5a3b8c7d6e25
status: experimental
description: |
  Erkennt die AWS-CLI beim Freigeben eines Maschinenabbilds (AMI) ueber modify-image-attribute mit einer
  LaunchPermission. Angreifer teilen ein Abbild mitsamt seiner Daten an ein fremdes Konto, um es dort zu
  starten und die Daten zu entnehmen (Transfer Data to Cloud Account).
references:
  - https://attack.mitre.org/techniques/T1537/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1537
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\aws.exe'
  sel_cmd:
    CommandLine|contains: 'modify-image-attribute'
  sel_perm:
    CommandLine|contains: 'LaunchPermission'
  condition: sel_img and sel_cmd and sel_perm
falsepositives:
  - Legitime Verteilung freigegebener Abbilder in Multi-Account-Umgebungen - bekannte Konten und Zielkonten als Baseline ausnehmen
level: high

3. Azure-SAS-Token für Speicher erzeugt (T1537). storage zusammen mit generate-sas. Wegen der legitimen Nutzung auf level: medium.

Sigma
title: Azure-SAS-Token fuer Speicher erzeugt
id: 9a2d6c48-5e72-4b93-a6f1-3c7b4d8e2f16
status: experimental
description: |
  Erkennt die Azure-CLI beim Erzeugen eines SAS-Tokens fuer einen Speicher ueber storage ... generate-sas.
  Ein SAS-Token gibt zeitlich begrenzten Zugriff auf Speicherdaten und laesst sich an Dritte weitergeben.
  Angreifer nutzen das, um Daten an ein fremdes Konto zugaenglich zu machen (Transfer Data to Cloud Account).
references:
  - https://attack.mitre.org/techniques/T1537/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1537
logsource:
  product: windows
  category: process_creation
detection:
  sel_cmd:
    CommandLine|contains: 'storage'
  sel_sas:
    CommandLine|contains: 'generate-sas'
  condition: sel_cmd and sel_sas
falsepositives:
  - Legitime Nutzung von SAS-Tokens fuer Backups oder Freigaben - bekannte Konten, Skripte und Zielspeicher als Baseline ausnehmen
level: medium

Härtung: der Angriff, der ins Leere läuft

  • Kontoübergreifende Freigaben einschränken. Das Teilen von Snapshots und Abbildern mit externen Konten per Richtlinie unterbinden oder auf eine kurze Liste erlaubter Zielkonten begrenzen.
  • Freigaben überwachen. Die Cloud-Audit-Logs auf Freigabe-Aktionen auswerten und bei unbekannten Zielkonten alarmieren - idealerweise automatisiert.
  • Verwaltungszugänge absichern. Cloud-Verwaltungskonten mit starker Mehrfaktor-Anmeldung und minimalen Rechten versehen; ein übernommenes Konto ist die Voraussetzung für die Freigabe.
  • Öffentliche und geteilte Ressourcen prüfen. Regelmäßig inventarisieren, welche Snapshots, Abbilder und Speicher geteilt sind, und unbekannte Freigaben zurücknehmen.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem Verwaltungs-Host mit aktivem Sysmon und Command-Line-Auditing:

  • Für Regel 1 mit der AWS-CLI modify-snapshot-attribute und create-volume-permission gegen ein Testkonto aufrufen und prüfen, dass Event 4688 die Befehlszeile zeigt und die Regel greift.
  • Für Regel 2 modify-image-attribute mit einer LaunchPermission testen und kontrollieren, dass die Regel anspringt.
  • Für Regel 3 mit der Azure-CLI ein SAS-Token über storage ... generate-sas erzeugen und prüfen, dass die Regel erkennt.
  • Breiter wird der Test mit den Fällen zu T1537 aus Atomic Red Team.

Fehlalarme und Tuning

  • Multi-Account-Umgebungen. Kontoübergreifende Freigaben sind dort Alltag. Die bekannten Zielkonten, Automatisierungen und Konten als Baseline aufnehmen, bevor alarmiert wird.
  • SAS-Token im Betrieb. generate-sas kommt bei Backups und Freigaben vor; Regel 3 nach Konto, Zielspeicher und Gültigkeitsdauer priorisieren statt pauschal zu alarmieren.
  • Auf das Zielkonto schauen. Entscheidend ist, wem freigegeben wird: ein bekanntes internes Konto ist harmlos, ein unbekanntes externes nicht - das Zielkonto in die Bewertung aufnehmen.
  • Kette schlägt Einzelzeile. Eine Freigabe an ein unbekanntes Konto, gefolgt von einem Zugriff aus diesem Konto, ist weit aussagekräftiger als ein Treffer allein - die Korrelation über die Cloud-Logs schärft die Bewertung.

Fazit

Der Transfer in ein fremdes Cloud-Konto ist die leise Exfiltration: Nicht ein Datenstrom verlässt die Umgebung, sondern eine Ressource wird geteilt - ein Snapshot, ein Abbild, ein Speicher. Die Daten bleiben liegen und gehören doch dem Angreifer. Gerade weil keine große Übertragung auffällt, ist der Befehl die beste Spur: am Endpunkt in der Prozess-Telemetrie und auf der Plattform in den Audit-Logs. Die verlässlichen Signale sind die geteilte Schattenkopie, das geteilte Abbild und das erzeugte SAS-Token. Weil Multi-Account-Umgebungen dieselben Befehle legitim nutzen, liegt die Stärke in der Abgrenzung: das Zielkonto, das handelnde Konto und die Verkettung entscheiden. Die wirksamste Härtung ist, kontoübergreifende Freigaben einzuschränken und sie konsequent zu überwachen. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Exfiltration.

NH

$ whoami

Norbert Hofmann

Cyber Defense Analyst im Security Operations Center eines Managed Security Service Providers. Red und Blue Teaming, Malware-Analyse, Incident Response und Security-Awareness-Trainings. Finalist bei „Deutschlands bester Hacker“ 2022, mehrere CVE-Einträge für WordPress-Plugins.