Krypto-Mining-Attacke auf AWS-Plattform aufgedeckt

Massive Mining-Operation belastet Cloud-Infrastruktur

Sicherheitsspezialisten von Amazon Web Services haben eine umfangreiche Angriffswelle identifiziert, bei der Cyberkriminelle die Cloud-Plattform für illegales Kryptowährungs-Mining missbrauchen. Die seit Anfang November andauernde Operation zielt auf die Dienste Elastic Compute Cloud und Elastic Container Service ab und verursacht erhebliche Kosten für betroffene Kunden sowie zusätzliche Belastungen für die AWS-Infrastruktur.

Die GuardDuty Extended Threat Detection ermöglichte die Aufdeckung der koordinierten Kampagne durch Korrelation verschiedener Sicherheitssignale. Dabei zeigte sich ein hochprofessionelles Vorgehen der Angreifer, die ihre Taktiken kontinuierlich weiterentwickeln und anpassen.

Grafik Quelle: Amazon

Kompromittierte Zugangsdaten als Einfallstor

Die Attacke basiert nicht auf technischen Schwachstellen der AWS-Plattform selbst. Stattdessen verschaffen sich die Täter durch erbeutete Identity and Access Management-Anmeldeinformationen Zugang zu Kundenkonten. Mit diesen legitimen Zugangsdaten starten sie rechenintensive Mining-Prozesse auf fremde Rechnung.

Amazon betont ausdrücklich, dass keine Sicherheitslücke in den eigenen Diensten ausgenutzt wurde. Die Angriffe fallen in den Verantwortungsbereich der Kunden innerhalb des Shared Responsibility Model. Dennoch stellt AWS umfangreiche Erkenntnisse und Handlungsempfehlungen bereit, um Betroffene bei der Abwehr zu unterstützen.

Die Angreifer implementierten einen Mechanismus zur dauerhaften Verankerung im System, der Sicherheitsmaßnahmen gezielt umgeht und die Beseitigung der schädlichen Aktivitäten verzögert. Ein auf Docker Hub bereitgestelltes Container-Image, erstellt Ende Oktober, verzeichnete bereits über 100.000 Downloads, bevor es entfernt wurde. Die Täter könnten jedoch ähnliche Images unter anderen Bezeichnungen erneut veröffentlichen.

Systematisches Vorgehen in mehreren Phasen

Die Cyberkriminellen agieren hochprofessionell und methodisch. Innerhalb der ersten zehn Minuten nach Zugriff auf ein Kundenkonto sind die Mining-Operationen bereits aktiv. Diese Geschwindigkeit deutet auf ausgefeilte Automatisierungsskripte hin, die den gesamten Angriffsprozess beschleunigen.

Zunächst ermitteln die Angreifer verfügbare Ressourcenkontingente und Berechtigungen, bevor sie die Mining-Infrastruktur ausrollen. Sie prüfen systematisch die EC2-Servicekontingente mittels GetServiceQuota-Anfragen, um das maximale Ausmaß ihrer Operationen zu kalkulieren. Anschließend testen sie ihre Berechtigungen mit mehrfachen RunInstances-API-Aufrufen unter Verwendung des DryRun-Flags.

Diese DryRun-Technik ist besonders bemerkenswert: Sie ermöglicht die Überprüfung von Berechtigungen ohne tatsächliche Ressourcenerstellung, wodurch Kosten vermieden und Entdeckungsrisiken minimiert werden. Organisationen, die normalerweise keine DryRun-Flags einsetzen, sollten diese API-Muster als Frühwarnsignal betrachten und entsprechend überwachen.

Ein charakteristisches Merkmal des Angriffs: Die Täter nutzen die ModifyInstanceAttribute-Funktion, um den API-Terminierungsschutz zu aktivieren. Dadurch müssen betroffene Unternehmen zusätzliche Schritte durchführen, bevor sie kompromittierte Ressourcen entfernen können. Diese Technik stellt eine Weiterentwicklung bekannter Persistenzmethoden dar und erschwert sowohl manuelle als auch automatisierte Bereinigungsversuche erheblich.

Technische Indikatoren und Angriffsmuster

Das GuardDuty-Team identifizierte mehrere charakteristische Erkennungsmerkmale der Kampagne, die Sicherheitsteams zur Identifizierung nutzen können. Allerdings warnen die Experten, dass Angreifer ihre Taktiken kontinuierlich anpassen, weshalb sich diese Indikatoren im Zeitverlauf wandeln können.

Das schädliche Container-Image yenik65958/secret enthielt eine SBRMiner-MULTI-Binärdatei für das Schürfen von Kryptowährungen. Nach der Bereitstellung führt das Image automatisch ein Skript namens run.sh aus, das den Mining-Algorithmus randomvirel startet und dabei sämtliche verfügbaren Prozessorkerne ausnutzt.

Drei Mining-Domains in verschiedenen Regionen (Asien, Europa, Nordamerika) unter der Top-Level-Domain xyz dienten als Zielserver für die Mining-Pools. Die Aufteilung auf mehrere geografische Standorte erhöht die Ausfallsicherheit der Operation und erschwert die vollständige Unterbindung.

Die automatisierten Skripte der Angreifer verwendeten Python-basierte Tools mit charakteristischen Boto3-User-Agent-Mustern, die auf das AWS SDK für Python hinweisen. Bei der Infrastrukturbereitstellung folgten Auto-Scaling-Gruppen bestimmten Namenskonventionen: SPOT-us-east-1-G mit angehängter Kennung für Spot-Instanzen sowie OD-us-east-1-G für On-Demand-Ressourcen, wobei G die jeweilige Gruppennummer bezeichnet.

Detaillierte Analyse der Angriffskette

Die GuardDuty-Ingenieure identifizierten die Kampagne zunächst durch Ähnlichkeiten in den Angriffstechniken über mehrere Kundenkonten hinweg. Dies deutete auf eine koordinierte Operation gegen Organisationen mit kompromittierten IAM-Credentials hin.

Der initiale Zugriff erfolgte von einem externen Hosting-Provider aus, wobei die Angreifer Administratorrechte besaßen. Die Nutzung von anomalen Netzwerken und Standorten löste die Anomalieerkennung von GuardDuty aus und lieferte erste Hinweise auf verdächtige Aktivitäten.

Während der Vorbereitungsphase riefen die Täter gezielt zwei APIs zur Rollenerstellung auf: CreateServiceLinkedRole für Auto Scaling-Gruppen sowie CreateRole für AWS Lambda-Funktionen. Der Lambda-Rolle fügten sie anschließend die AWSLambdaBasicExecutionRole-Richtlinie hinzu. Diese beiden Rollen bildeten später die Grundlage für die Impact- und Persistenz-Phasen des Angriffs.

Ausnutzung von Container- und Rechendiensten

Für den ECS-Angriff erstellten die Täter zunächst Dutzende Cluster-Instanzen, teilweise über 50 in einem einzigen Vorgang. Die massive Anzahl verteilt die Mining-Last und maximiert die ausgebeuteten Ressourcen.

Anschließend registrierten sie Task-Definitionen mit dem schädlichen Docker-Image, wobei sie identische Zeichenfolgen wie bei der Cluster-Erstellung verwendeten. Mit maximaler CPU-Zuweisung von 16.384 Einheiten pro Task-Definition starteten sie Fargate-Tasks mit einer gewünschten Anzahl von zehn Instanzen pro Dienst für das Mining.

Bei EC2 setzten die Angreifer auf Auto-Scaling-Gruppen mit aggressiven Parametern: maximale Größe von 999 Instanzen, gewünschte Kapazität von 20 Einheiten. Sie erstellten insgesamt zwei Launch-Templates und 14 Auto-Scaling-Gruppen, die UserData-Anweisungen zum Start der Mining-Operationen enthielten.

Die Täter kombinierten dabei geschickt Spot-Instanzen für hochleistungsfähige GPU- und Machine-Learning-Hardware (g4dn, g5, p3, p4d, inf1) mit On-Demand-Instanzen für Standard-Rechenkapazitäten (c5, c6i, r5, r5n, m5a, m5, m5n). Während Spot-Instanzen mit kapazitätsoptimierter Strategie und null Prozent On-Demand-Zuweisung konfiguriert wurden, setzten die On-Demand-Gruppen auf hundertprozentige Zuweisung.

Nachdem die Auto-Scaling-Kontingente erschöpft waren, starteten die Angreifer zusätzlich direkte EC2-Instanzen mittels RunInstances, um auch die verbleibenden Ressourcenkontingente vollständig auszuschöpfen. Diese Mehrfachstrategie maximiert den Ressourcenverbrauch und damit die Mining-Leistung.

Etablierung dauerhafter Zugangsmöglichkeiten

Zur Sicherung ihres Zugriffs schufen die Angreifer mehrere Hintertüren. Eine Lambda-Funktion mit öffentlichem Endpunkt und umgangener IAM-Authentifizierung ermöglichte externen Zugriff ohne weitere Authentifizierungsschritte. Die Konfiguration setzte den AuthType auf „NONE“, wodurch jeder Prinzipal die Funktion aufrufen kann.

Zusätzlich legten sie einen neuen IAM-Benutzer mit der Bezeichnung user-x1x2x3x4 an und statteten diesen mit AmazonSESFullAccess-Berechtigungen aus. Für diesen Benutzer erstellten sie sowohl einen Zugriffsschlüssel als auch ein Login-Profil. Die SES-Rolle deutet darauf hin, dass die Angreifer möglicherweise Phishing-Aktivitäten über Amazon Simple Email Service planten.

Die Kombination aus Beendigungsschutz, öffentlichen Lambda-Endpunkten und zusätzlichen Benutzerkonten erschwert die vollständige Bereinigung kompromittierter Systeme erheblich. Selbst nach Entfernung der Mining-Ressourcen verbleiben Zugangskanäle, über die Angreifer erneut eindringen können.

Mehrschichtige Erkennungsmechanismen

Das GuardDuty-System identifizierte die Angriffskette durch verschiedene komplementäre Mechanismen, die zusammenwirken und ein vollständiges Lagebild erstellen.

Bedrohungsinformationen für EC2, die Teil des grundlegenden Schutzplans sind, erkannten Verbindungen zu bekannten Mining-Domains durch Threat Intelligence von Drittanbietern sowie interne Quellen wie Active Threat Defense und MadPot. Die spezifischen Findings CryptoCurrency:EC2/BitcoinTool.B und die DNS-Variante detektierten die in der Kampagne genutzten Indikatoren.

Anomalieerkennung auf IAM-Ebene registrierte ungewöhnliche Zugriffe von fremden Netzwerken und Standorten. Die IAMUser/AnomalousBehavior-Findings über verschiedene Taktikkategorien hinweg (PrivilegeEscalation, Impact, Discovery) zeigten maschinelles Lernen in Aktion: GuardDuty erkannte Abweichungen vom normalen Nutzerverhalten, insbesondere bei API-Aufrufen, die für die betroffenen Konten atypisch waren.

Die Runtime-Überwachung lieferte Erkenntnisse auf Host- und Container-Ebene, einschließlich der Ausführung verdächtiger Prozesse. Diese Komponente analysiert Systemebenen-Protokolle und erweitert die Erkennungsabdeckung erheblich. Findings wie CryptoCurrency:Runtime/BitcoinTool.B und Impact:Runtime/CryptoMinerExecuted identifizierten Mining-Programme direkt auf den Workloads.

Die kürzlich auf der re:Invent 2025 vorgestellte Extended Threat Detection korrelierte Signale aus mehreren Quellen zu einem Gesamtbild. Die AttackSequence:EC2/CompromisedInstanceGroup-Erkennung nutzt KI- und ML-Algorithmen zur automatischen Korrelation von Sicherheitssignalen aus verschiedenen Datenquellen, um komplexe Angriffsmuster von Ressourcengruppen zu identifizieren.

Schutzmaßnahmen und präventive Strategien

Unternehmen sollten einen mehrschichtigen Sicherheitsansatz implementieren, der Prävention, Erkennung und Reaktion umfasst.

Bei den Identitäts- und Zugriffskontrollenmüssen langfristige Zugriffsschlüssel durch temporäre Credentials ersetzt werden. Multi-Faktor-Authentifizierung für sämtliche Benutzer ist essentiell und sollte ohne Ausnahmen durchgesetzt werden. Das Least-Privilege-Prinzip beschränkt Berechtigungen auf das notwendige Minimum, wodurch der potenzielle Schaden bei Kompromittierung begrenzt wird.

CloudTrail-Protokollierung über alle Services hinweg ermöglicht zentrale Überwachung und forensische Analysen. Die Protokolle sollten in einem zentralen Konto aggregiert werden, auf das Sicherheitsteams Zugriff haben. CloudWatch-Alarme, EventBridge oder Drittanbieter-Tools können auf verdächtige API-Muster aufmerksam machen.

Besondere Aufmerksamkeit verdient die Verwendung von DryRun-Flags in API-Aufrufen, die auf Erkundungsaktivitäten hindeuten können. Organisationen, die diese Funktion nicht regulär nutzen, sollten entsprechende Monitoring-Regeln implementieren.

GuardDuty sollte in allen Konten und Regionen aktiviert sein, idealerweise mit Runtime-Monitoring für umfassende Abdeckung. Die Laufzeitüberwachung liefert kritische Host-Level-Signale und ermöglicht die Korrelation von Angriffssequenzen. Integration mit Security Hub und EventBridge ermöglicht automatisierte Reaktionsabläufe und schnelle Behebung kritischer Findings.

Service Control Policies können die Erstellung öffentlicher Lambda-URLs mit deaktivierter Authentifizierung verhindern. Eine entsprechende SCP sollte Aktionen verweigern, die Lambda-URLs mit AuthType „NONE“ erstellen oder aktualisieren.

Bei Container-Sicherheit sollten systematische Image-Scans implementiert werden. Ungewöhnliche CPU-Anforderungen in ECS-Task-Definitionen, insbesondere maximale Zuweisungen, bedürfen besonderer Prüfung und Genehmigungsprozesse.

Incident-Response-Verfahren müssen dokumentierte Schritte für den Umgang mit geschützten Instanzen enthalten, da der API-Terminierungsschutz zusätzliche Bereinigungsschritte erfordert. Teams sollten Prozesse etablieren, die sowohl die Deaktivierung des Schutzes als auch die anschließende Terminierung umfassen.

Ausblick und Empfehlungen

Die identifizierte Kampagne demonstriert die kontinuierliche Evolution von Angriffstechniken im Cloud-Umfeld. Die Kombination aus skriptgesteuerter Automatisierung, neuartigen Persistenzmechanismen und der gezielten Ausnutzung mehrerer Rechendienste markiert eine Weiterentwicklung gegenüber früheren Crypto-Mining-Operationen.

Sicherheitsteams müssen sich darauf einstellen, dass Angreifer ihre Methoden anpassen werden. Die in diesem Vorfall identifizierten Indikatoren bieten einen Ausgangspunkt, sollten jedoch nicht als abschließende Liste betrachtet werden. Kontinuierliche Wachsamkeit und adaptive Erkennungsmechanismen sind erforderlich.

Die Aktivierung umfassender Sicherheitsfunktionen wie GuardDuty mit Runtime-Monitoring sowie die Implementierung präventiver Kontrollen bilden die Grundlage für einen robusten Schutz. Nur durch die Kombination technischer Maßnahmen mit etablierten Prozessen und geschultem Personal lässt sich das Risiko derartiger Angriffe minimieren.

„Die in diesem Beitrag bereitgestellten Informationen wurden sorgfältig recherchiert, erheben jedoch keinen Anspruch auf Vollständigkeit oder absolute Richtigkeit. Sie dienen ausschließlich der allgemeinen Orientierung und ersetzen keine professionelle Beratung. Die Redaktion übernimmt keine Haftung für eventuelle Fehler, Auslassungen oder Folgen, die aus der Nutzung der Informationen entstehen.“