Datenabfluss erkennen: rclone, MEGA und Cloud-Uploads

Datenabfluss erkennen ist die letzte Gelegenheit vor dem Schaden. In modernen Ransomware-Vorfällen ist die Verschlüsselung nur noch die halbe Erpressung; die andere Hälfte ist die Drohung, die gestohlenen Daten zu veröffentlichen. Dafür muss der Angreifer die Daten erst aus dem Netz heraustragen, und dieser Schritt, ATT&CK Exfiltration, ist die letzte Phase, in der sich ein Vorfall noch vor dem öffentlichen Schaden stoppen lässt. Das meistgenutzte Werkzeug ist rclone, ein legitimes Programm zum Synchronisieren mit Cloud-Speichern, das Angreifer zweckentfremden; das Ziel ist oft MEGA, weil es kostenlos, schnell und unauffällig ist. Dieser Beitrag aus der Serie „Angriff erkennen“ zeigt aus Verteidigersicht, woran sich der Abfluss erkennen lässt, warum die Menge wichtiger ist als die Signatur, mit Logquellen, dem Muster, zwei Sigma-Regeln, dem Test im Lab und der Gegenmaßnahme. Was davor passiert, steht im Beitrag zum Ransomware-Vorfall.

Was der Angreifer tut

Der Abfluss läuft fast immer in zwei Schritten ab, und beide hinterlassen Spuren. Die zugehörigen Techniken sind T1567.002 (Exfiltration zu Cloud-Speicher), T1048 (Exfiltration über ein alternatives Protokoll) und, für den ersten Schritt, T1560 (Sammeln und Archivieren). Bewusst nur auf Prinzipebene:

• Sammeln und Archivieren. Zuerst trägt der Angreifer die interessanten Daten zusammen, oft von Dateiservern und Freigaben, und packt sie in ein Archiv in einem temporären Verzeichnis. Das reduziert viele Dateien auf wenige große und macht den Transfer schneller. Dieser Schritt zeigt sich in massenhaften Lesezugriffen und neuen großen Archivdateien.
• Hochladen zum Cloud-Speicher. Dann lädt er das Archiv zu einem Cloud-Dienst hoch. rclone ist dafür beliebt, weil es viele Anbieter unterstützt, mehrere Verbindungen parallel nutzt und über eine eigene Konfiguration läuft. Typische Ziele sind MEGA, aber auch Dropbox, Google Drive, pCloud oder ein vom Angreifer kontrollierter Speicher. Der Upload erzeugt viele ausgehende Verbindungen und ein großes Datenvolumen zu einem Dienst, mit dem das System sonst nicht spricht.
• Alternativen zu rclone. Statt rclone kommen gelegentlich Bordmittel oder andere Werkzeuge zum Einsatz, etwa ein Upload über die Weboberfläche eines Filehosters, WinSCP, MegaCMD oder ein Skript. Das ändert das Werkzeug, nicht das Muster: ein großer ausgehender Datenstrom zu einem Speicherdienst.

Der entscheidende Punkt für die Erkennung: rclone ist ein legitimes Werkzeug und kann auch berechtigt im Einsatz sein. Verdächtig ist nicht das Programm, sondern die Kombination aus ungewöhnlicher Quelle, Cloud-Ziel und großer Menge in kurzer Zeit.

Welche Logquellen die Technik zeigt

Die Tabelle macht den Unterschied zu den übrigen Techniken dieser Serie deutlich: Es gibt kein Windows-Ereignis „Datenabfluss“. Die stärkste Erkennung ist die Menge im Netz, und die Endpoint-Signale (rclone, Cloud-Verbindung) liefern den Kontext, welcher Prozess und welches Ziel dahinterstecken. Ein Zeek-Sensor am Perimeter ist hier wertvoller als jede einzelne Regel. Die Felder zu den Ereignissen stehen in der Referenz zu den Event-IDs.

Das Muster im Log

Drei Fragen trennen den Abfluss vom normalen Cloud-Verkehr, und die wichtigste ist die nach der Menge.

• Die Richtung und die Menge. Arbeitsplätze und Server empfangen im Normalbetrieb mehr, als sie senden. Ein Host, der plötzlich viele Gigabyte nach außen schickt, vor allem zu einem einzelnen Ziel und außerhalb der Arbeitszeit, ist das Kernsignal. Eine Baseline des üblichen ausgehenden Volumens pro Host macht diese Abweichung sichtbar.
• Das Ziel. Verbindungen zu Cloud-Speichern und Filehostern, die in der Organisation nicht freigegeben sind, besonders MEGA, sind für sich schon erklärungsbedürftig. Die DNS-Auflösung in Sysmon 22 und der SNI in den TLS-Verbindungen zeigen das Ziel, auch wenn der Inhalt verschlüsselt ist.
• Der Prozess. Baut nicht der Browser oder ein freigegebener Sync-Client die Verbindung auf, sondern rclone, ein Kommandozeilenwerkzeug oder ein frisch heruntergeladenes Programm, ist der Fall klar. rclone lässt sich an seiner charakteristischen Befehlszeile erkennen, auch wenn die Datei umbenannt wurde.

Jede Frage für sich erzeugt Rauschen; zusammen, und mit einer Liste der erlaubten Cloud-Dienste und Sync-Clients, werden sie trennscharf. Das große ausgehende Volumen zu einem nicht freigegebenen Ziel von einem untypischen Prozess ist ein nahezu sicherer Treffer.

Zwei Sigma-Regeln

Die erste Regel erkennt rclone an Datei und charakteristischer Befehlszeile, die zweite die Verbindung zu bekannten Cloud-Speichern aus einem Kommandozeilenwerkzeug. Die mengenbasierte Erkennung gehört ins Netz-Monitoring und ist unten beschrieben.

title: rclone-Ausfuehrung zur Daten-Exfiltration
id: a1f6c9d2-3e84-4b17-9c05-6d2a8f41b7e3
status: experimental
description: Erkennt den Start von rclone an Dateiname oder charakteristischer
  Befehlszeile. rclone ist legitim; der Treffer ist im Kontext von Quelle,
  Cloud-Ziel und Menge zu bewerten. Ein umbenanntes rclone wird ueber die
  typische Flag-Kombination erfasst.
references:
  - https://attack.mitre.org/techniques/T1567/002/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1567.002
logsource:
  category: process_creation
  product: windows
detection:
  selection_name:
    Image|endswith: '\\rclone.exe'
  selection_cli:
    CommandLine|contains|all:
      - ' copy '
      - ' --config '
    CommandLine|contains:
      - '--transfers'
      - '--multi-thread-streams'
      - '--no-check-certificate'
  selection_flags:
    CommandLine|contains|all:
      - '--transfers'
      - '--multi-thread-streams'
  condition: selection_name or selection_cli or selection_flags
falsepositives:
  - Dokumentierter, freigegebener Einsatz von rclone fuer Backups oder Sync
level: high

title: Verbindung zu Cloud-Speicher aus Kommandozeilenwerkzeug
id: c7e2b5a9-0d41-4f68-8a3c-1b9e6f2d4c80
status: experimental
description: Erkennt ausgehende Verbindungen zu bekannten Cloud-Speicher- und
  Filehosting-Diensten aus Prozessen, die dafuer untypisch sind. Browser und
  freigegebene Sync-Clients werden ausgenommen. Die Zielliste ist an die eigenen
  erlaubten Dienste anzupassen.
references:
  - https://attack.mitre.org/techniques/T1567/002/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1567.002
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationHostname|contains:
      - 'mega.nz'
      - 'mega.io'
      - 'userstorage.mega.co.nz'
      - 'pcloud.com'
      - 'anonfiles'
      - 'gofile.io'
  filter_trusted:
    Image|endswith:
      - '\\chrome.exe'
      - '\\msedge.exe'
      - '\\firefox.exe'
      - '\\OneDrive.exe'
  condition: selection and not filter_trusted
falsepositives:
  - Berechtigte Nutzung eines gelisteten Dienstes ausserhalb des Browsers
level: medium

Die stärkste Erkennung steht in keiner der beiden Regeln, weil sie eine Zählung über das Volumen braucht: Ein Host, der in einem kurzen Fenster mehr als eine festzulegende Schwelle an Daten nach außen sendet, besonders zu einem einzelnen Ziel. Das gehört in das Netz-Monitoring oder als Schwellenwert-Alarm ins SIEM auf die conn.log-Daten von Zeek. Wie die Sigma-Regeln ins eigene SIEM übersetzt werden, steht im Beitrag zu Sigma-Regeln.

Der Test

Dafür genügen ein Windows-System mit Sysmon und ein Zeek-Sensor im Homelab; der Test gehört ausschließlich dorthin, niemals in eine Produktivumgebung, und es werden nur harmlose Testdaten übertragen. Ziel ist nur zu prüfen, ob die erwarteten Ereignisse entstehen und die Regeln treffen. Ein Durchlauf mit rclone, das eine große Testdatei zu einem Testkonto bei einem Cloud-Dienst hochlädt, reicht aus. Erwartet werden Sysmon 1 mit der rclone-Befehlszeile, Sysmon 22 mit der Auflösung des Ziels, Sysmon 3 mit der Verbindung dorthin und im Zeek-Sensor ein conn.log-Eintrag mit großem orig_bytes. Beide Sigma-Regeln müssen treffen, und der mengenbasierte Alarm sollte bei entsprechender Schwelle ebenfalls auslösen. Atomic Red Team hat für T1567.002 Tests, die den Upload zu Cloud-Speichern nachstellen. Ergebnis und Datum in den ATT&CK-Navigator, denn diese Erkennung ist die letzte Bremse vor dem Datenleck und gehört in jede Purple-Team-Übung.

Fehlalarme und Tuning

• Berechtigte Cloud-Nutzung. Freigegebene Sync-Clients (OneDrive, der eigene Backup-Dienst) und erlaubte Filehoster erzeugen ebenfalls ausgehendes Volumen. Sie kommen als bekannte Prozesse und Ziele auf die Ausnahmeliste; alles außerhalb dieser Liste bleibt ein Treffer. Die Liste der erlaubten Dienste ist zugleich eine Richtlinienfrage.
• Legitimes rclone. Manche Teams nutzen rclone selbst für Backups. Dann wird der dokumentierte Einsatz nach Quelle, Konto und Zeitplan ausgenommen, nicht die Regel abgeschaltet; eine rclone-Ausführung von einem Arbeitsplatz oder zu einem unbekannten Ziel bleibt meldepflichtig.
• Große legitime Transfers. Backups, Software-Verteilung und Datenübertragungen zwischen Standorten erzeugen große Volumen. Sie laufen von bekannten Servern, zu bekannten Zielen und oft nach Plan; die Baseline pro Host trennt sie von der Abweichung. Sinnvoll ist, zuerst das normale ausgehende Volumen je System über eine Woche zu messen und die Schwelle knapp darüber zu setzen.
• Die Gegenmaßnahme, die den Abfluss bremst. Ausgehende Kontrolle ist hier die wirksamste Maßnahme: ein Web-Proxy, der nicht freigegebene Cloud-Speicher und Filehoster blockiert, und eine Firewall-Regel, die ausgehende Verbindungen von Servern auf das Nötige beschränkt. Danach scheitert der Upload oder wird am Proxy sichtbar, und jeder Versuch ist ein Alarm. Dazu gehört die Segmentierung, beschrieben unter Netzwerksegmentierung, damit ein kompromittierter Server nicht frei ins Internet spricht.

Fazit

Der Datenabfluss ist der Schritt, der aus einem Einbruch eine Erpressung mit Veröffentlichung macht, und zugleich die letzte Phase, in der sich der Schaden noch abwenden lässt. Anders als die übrigen Techniken dieser Serie hat er kein eigenes Windows-Ereignis; seine Erkennung ist eine Korrelation aus dem Prozess (rclone in Sysmon 1), dem Ziel (Cloud-Speicher in Sysmon 3 und 22) und vor allem der Menge im Netz. Wer das übliche ausgehende Volumen pro Host kennt, die Cloud-Ziele über einen Proxy kontrolliert und die beiden Regeln im Lab gegen einen echten Upload prüft, erkennt den Abfluss, bevor die Daten das Netz verlassen haben. Für ein Blue Team ist das der Unterschied zwischen einem internen Vorfall und einer Schlagzeile.