Living off the Cloud: legitime Cloud-Dienste im Missbrauch erkennen

Living off the Cloud ist die Weiterentwicklung einer Idee, die das Blue Team vom Endpunkt kennt. Der Beitrag zu den LOLBins beschreibt, wie Angreifer lokale Windows-Bordmittel missbrauchen, um ohne eigene Schadsoftware zu agieren; in der Cloud tun sie dasselbe mit den Bordmitteln der Cloud. Der Fachbegriff, der sich 2026 dafür etabliert hat, ist Living off the Cloud oder Living off the XaaS. Der Reiz für den Angreifer ist derselbe wie am Endpunkt: Wer die legitimen Werkzeuge der Umgebung nutzt, fällt nicht auf, weil kein bösartiges Programm, keine fremde IP und keine unbekannte Domain ins Bild kommt. Dieser Beitrag beschreibt die wichtigsten Techniken, warum die klassische Erkennung an ihnen scheitert, und wie das Blue Team sie trotzdem findet. Er baut auf dem Beitrag zur Cloud-Sicherheit auf und vertieft dessen Grundgedanken: In der Cloud ist Erkennung ein Korrelationsproblem.

Die Techniken

• Native Fernausführung. AWS Systems Manager (SSM) und Azure Run Command sind legitime, in die Plattform eingebaute Werkzeuge, um Befehle auf virtuellen Maschinen auszuführen. Der Agent ist auf vielen Standard-Images vorinstalliert und spricht nur ausgehend mit dem Dienst, sodass keine eingehende Firewallregel nötig ist. Ein Angreifer mit der Berechtigung, Befehle zu senden, führt damit Code auf jeder erreichbaren Instanz aus, ohne SSH oder RDP zu berühren, also ohne die Wege, die das Blue Team üblicherweise überwacht. Benannte Gruppen haben genau das in echten Vorfällen für seitliche Bewegung und Persistenz genutzt.
• Geheimnisse über die API abfragen. Statt Zugangsdaten aus dem Speicher eines Endpunkts zu stehlen, fragt der Angreifer sie direkt über die API des Geheimnis-Dienstes ab, etwa den Secrets Manager oder den Key Vault. Das umgeht den Endpunktschutz vollständig und verlagert den Angriff an eine Stelle, die viele Teams weniger genau beobachten.
• Serverlose Aufklärung. Angreifer nutzen serverlose Funktionen wie AWS Lambda oder Azure Functions, um das Netz zu scannen. Statt von einem einzelnen kompromittierten Server aus zu scannen, dessen IP sofort blockiert wird, starten sie tausende kurzlebige Funktionen, von denen jede einen kleinen Teil des Ziels absucht.
• C2 über legitime Dienste. Command-and-Control läuft über vertrauenswürdige Dienste, die niemand blockieren kann: verschlüsselte Befehle in den Beschreibungsfeldern von Google-Calendar-Terminen, C2-Seiten auf Azure Web Apps, Nutzlasten auf GitHub. Das Opfer sieht nur legitime Cloud-Infrastruktur, und eine IP eines großen Anbieters zu sperren ist meist untragbar, weil es kritische Dienste mittrifft.
• Vertrauensbeziehungen missbrauchen. Moderne Cloud-Umgebungen verknüpfen Identitätssysteme über Vertrauensbeziehungen, etwa OpenID Connect zwischen einer Code-Plattform und der Cloud. Ein Angreifer, der ein Entwickler-Token stiehlt, kann eine solche Vertrauensbeziehung missbrauchen, um sich in der Cloud eine Administratorrolle zu erstellen, ganz ohne klassischen Einbruch.
• Exfiltration über Cloud-Speicher. Der Datenabfluss läuft über legitime Cloud-Speicher, unternehmenseigene wie fremde, weil dieser Weg unauffällig ist und schnell wächst. Er ist auf dem Weg, der dominierende Exfiltrationspfad zu werden.

Warum die klassische Erkennung scheitert

Jede dieser Techniken zielt auf eine Annahme der traditionellen Erkennung. Die IP-basierte Erkennung versagt, weil der Verkehr von den Adressbereichen der großen Anbieter kommt, die man nicht sperren kann. Die URL-basierte Erkennung versagt, weil das Opfer nur legitime Anbieter-Domains sieht. Der Endpunktschutz versagt, weil der Angriff gar nicht auf dem Endpunkt stattfindet, sondern auf der Steuerungsebene der Cloud. Und die signaturbasierte Erkennung versagt, weil kein bösartiges Programm im Spiel ist, sondern nur legitime API-Aufrufe. Es ist dieselbe Sackgasse wie bei den LOLBins am Endpunkt, nur eine Ebene höher: Das Werkzeug ist legitim, verdächtig ist nur, wer es wofür benutzt.

Wie das Blue Team es findet

Die Antwort ist dieselbe wie im Beitrag zur Cloud-Sicherheit: die Control-Plane-Protokolle, also CloudTrail, das Azure Activity Log und die Cloud Audit Logs, die jeden API-Aufruf mit der handelnden Identität festhalten. Die Erkennung zielt nicht auf das Werkzeug, sondern auf seinen Missbrauch im Kontext.

• Fernausführung überwachen. Jeder Aufruf von SSM SendCommand oder Azure Run Command gehört protokolliert und bewertet: Welche Identität führt auf welchen Instanzen Befehle aus, und passt das zu ihrer normalen Rolle? Eine Erschwernis: Beide Dienste schwärzen den eigentlichen Befehlsinhalt in ihren primären Protokollen, sodass die Analyse den Aufruf selbst und die Artefakte auf dem Zielsystem zusammenführen muss.
• Geheimnis-Zugriffe im Blick. Ein massenhafter oder ungewöhnlicher Zugriff auf den Geheimnis-Dienst durch eine Identität, die das sonst nicht tut, ist ein starkes Signal. Das setzt voraus, dass die Data-Access-Protokolle aktiviert sind, was oft nicht der Fall ist.
• Auf Anomalien in der Identität achten. Der rote Faden ist die Identität: eine neue Rolle, die plötzlich entsteht, eine Berechtigung, die sich ausweitet, ein Token, das von einem ungewohnten Ort genutzt wird, eine Vertrauensbeziehung, die zum ersten Mal missbraucht wird. Das ist die Cloud-Variante der seitlichen Bewegung.
• Datenabfluss erkennen. Ungewöhnlich große Lesezugriffe auf Speicher, Zugriffe auf Speicher, die eine Identität nie berührt hat, und ausgehende Übertragungen an fremde Cloud-Ziele, wie im Beitrag zu den Ransomware-Trends beschrieben, wo der Datendiebstahl den Kern der Erpressung bildet.
• Korrelieren statt einzeln betrachten. Wie bei jeder Cloud-Erkennung entsteht der Wert erst, wenn die Signale auf dieselbe Identität und Zeitspanne bezogen werden: eine Rollenänderung, gefolgt von einem Geheimnis-Zugriff, gefolgt von einer Fernausführung, ist ein Vorfall; jedes Ereignis für sich ist Rauschen.

Vorbeugen

Wie bei den LOLBins ist die Erkennung nur die halbe Antwort; die andere ist, den Missbrauch zu erschweren. Minimale Rechte sind der wichtigste Hebel: Wer die Berechtigung zur Fernausführung und zum Geheimnis-Zugriff eng hält, entzieht den Techniken die Voraussetzung. Die Vertrauensbeziehungen zwischen Identitätssystemen gehören regelmäßig geprüft, weil sie unbemerkt zu Angriffspfaden werden. Ausgehende Verbindungen von Cloud-Ressourcen lassen sich über Dienst-Perimeter einschränken, sodass eine kompromittierte Ressource nicht mit beliebigen externen Zielen sprechen kann. Und die Data-Access-Protokolle, die viele Techniken erst sichtbar machen, gehören aktiviert und ins SIEM gebracht. Das ist dieselbe Disziplin wie die Radiusbegrenzung aus dem Beitrag zum Supply-Chain-Angriff.

Fazit

Living off the Cloud verlagert die alte Idee der LOLBins auf die Steuerungsebene der Cloud: legitime Verwaltungswerkzeuge, APIs und Vertrauensbeziehungen statt eigener Schadsoftware, sodass IP-, URL- und Endpunkt-Erkennung ins Leere laufen. Was trägt, ist die Korrelation der Control-Plane-Protokolle mit dem Blick auf die Identität: wer tut was, von wo, und passt das zu seiner Rolle? Wer die Fernausführung und die Geheimnis-Zugriffe überwacht, die Vertrauensbeziehungen prüft und die Rechte eng hält, findet und verhindert einen Großteil dieser Techniken. Für ein Blue Team ist Living off the Cloud die Erinnerung, dass jede Verlagerung der Infrastruktur die Angreifer mitnimmt, und dass die Verteidigung dorthin folgen muss, wo die Umgebung heute liegt: in die Steuerungsebene der Cloud.