HazyBeacon-Campagne nutzt AWS für heimliche Kommunikation

Als primäres Vehikel dient dabei Amazon Web Services (AWS), eine der weltweit am meisten genutzten Plattformen. Besonders charakteristisch für diese Kampagne ist die Verbindungsmethode zu infizierten Endgeräten. Die Täter kompromittieren AWS-Konten dort serverlose Funktionen als unsichtbare Relay-Punkte.

Für Sicherheitsteams, die den Datenverkehr überwachen, erscheinen diese Kommunikationen zunächst als routinemäßige, verschlüsselte HTTPS-Verbindungen zu Amazons eigener Infrastruktur. Die Analyse wurde ührt und basiert auf einem Bericht, der ursprünglich im Juli 2025 42 dokumentiert wurde.

Nach der Installation auf einem Windows-System des Opfers fungiert HazyBeacon als leichtgewichtiges Backdoor-Tool. Es sammelt zunächst Systemdetails wie Hostname, IP-Adresse und Benutzerrechte. Anschließend empfängt es verschlüsselte Befehle, um Shell-Befehle auszuführen oder weitere Schadsoftware herunterzuladen.

Sicherheitslage und Risiko

Zudem wird gestohlene Dokumente sowie aufgezeichnete Tastatureingaben an die Angreifer übermittelt. Wichtig ist hierbei, dass die Kampagne keine Schwachstellen in der AWS-Infrastruktur selbst ausnutzt. Stattdessen stehlen die Täter statische IAM-Zugangsschlüssel aus exponierten GitHub-Repositorien oder durch Phishing-Kampagnen.

Diese Schlüssel nutzen sie, um ein Relay innerhalb eines kompromittierten Cloud-Kontos aufzubauen. Der Kern des Angriffs liegt im Missbrauch, die im April 2022 eingeführt wurden. Diese URLs stellen serverlose Funktionen direkt dem Internet zur Verfügung, ohne dass Zwischendienste wie API Gateway notwendig sind.

Während diese Einfachheit für Entwickler vorteilhaft ist, lässt sie sich leicht missbrauchen. Lambda Function URLs bieten zwei Authentifizierungsmodi: Entweder müssen sich Aufrufer mit gültigen IAM-Credentials ausweisen, oder im Modus „AuthType: NONE" können Anfragen werden.

Technik und Auswirkungen

Die Angreifer wählen den zweiten Modus, um innerhalb weniger Sekunden eine öffentliche HTTPS-Relaisverbindung innerhalb der AWS-Infrastruktur zu etablieren. Da sich die Domain des Endpunkts auf „on.aws" endet, vermischen sich die Datenströme mit vertrauenswürdigen Amazon-Diensten.

Das Relay fungiert als stiller Mittelsmann: Die Schadsoftware sendet einen verschlüsselten HTTP-POST an eine Lambda-URL innerhalb eines anderen kompromittierten AWS-Kontos. Diese Funktion entfernt die Header und leitet das Payload an den eigentlichen Backend-Server der Angreifer weiter, der über denselben Pfad antwortet.

Sowohl die Opfer der Schadsoftware als auch die Inhaber des kompromittierten AWS-Kontos bemerken in der Regel nichts Auffälliges, bis eine Missbrauchsmitteilung oder eine unerwartete Rechnung eintrifft. Der Angriff folgt einer vorhersehbaren Kill Chain, die auf mangelnder Identitäts-Hygiene basiert.

Technischer Hintergrund

Die Angreifer validieren die gestohlenen Schlüssel zunächst über diskrete API-Aufrufe. Anschließend laden sie ein zip-archiviertes Python- oder Node.js-Payload als Lambda-Funktion mit einem harmlos wirkenden Namen, beispielsweise „UpdateWorker", hoch. Diese Funktionen werden in AWS-Regionen mit geringer Überwachung bereitgestellt, um Entdeckung zu vermeiden.

Um sich gegen solche Lambda-basierten Kommandorelay-Systeme zu verteidigen, sollten Organisationen zunächst eine strenge IAM-Hygiene etablieren. Dazu gehört das Deaktivieren ungenutzter Zugangsdaten, die regelmäßige Rotation der Multi-Faktor-Authentifizierung für alle Cloud-Konten.

Diese Maßnahmen schließen den primären Einstiegspunkt ab, auf den die Kampagne angewiesen ist. Zusätzlich ist die Aktivierung entscheidend. CloudTrail dokumentiert jeden API-Aufruf zur Erstellung und macht unbefugte Bereitstellungen sichtbar, selbst in selten überwachten Regionen.

Technik und Auswirkungen

Die Erkennung anomaler Aktivitäten während der Aufklärung kann kompromittierte Zugangsdaten aufdecken, bevor das Relay live geht. Organisationen können Service Control Policies auf Ebene der AWS Organization anwenden, um Lambda Function URLs mit der Einstellung „AuthType: NONE" zu blockieren, es sei denn, diese wurden explizit durch Tagging genehmigt.

Dies verhindert, dass ein öffentlicher Relay auch mit gültigen, gestohlenen Zugangsdaten bereitgestellt wird. Das Routing über eine Virtual Private Cloud (VPC) fügt eine zusätzliche Erkennungsebene hinzu. Relay-Verkehr erzeugt dabei ein eindeutiges Muster aus einer-zu-einer Zuordnung in Flow Logs. Die Überwachung rundet die Abwehrstrategie ab.

Ein Relay, das viele infizierte Maschinen bedient, erzeugt enorme Aufrufvolumina, die als plötzliche Kostenanstiege sichtbar werden, insbesondere in Nicht-Produktionsregionen. Granulare Budgetwarnungen können dieses Missbrauchsmuster erkennen, bevor es sich weiter ausweitet.