Google sieht den Rückgang bei der Ausnutzung schwacher Zugangsdaten als Folge der eigenen Sicherheitsstrategie. „Wir gehen davon aus, dass diese Verhaltensänderung der Bedrohungsakteure möglicherweise darauf zurückzuführen ist, dass Googles Strategie der sicheren Standardeinstellungen und verbesserte Schutzmechanismen für Zugangsdaten die traditionellen, leichter ausnutzbaren Wege erfolgreich verschlossen und die Einstiegshürde für Angreifer erhöht haben“, heißt es im Bericht.

Staatlich unterstützte wie finanziell motivierte Angreifer setzten dennoch überwiegend auf kompromittierte Identitäten – etwa über Phishing und Vishing, bei dem sich die Täter als IT-Support ausgaben, um Zugang zur Cloud-Plattform einer Zielorganisation zu erlangen. In den meisten untersuchten Fällen ging es den Angreifern um die unauffällige Exfiltration großer Datenmengen ohne sofortige Erpressung und um langfristige Persistenz.

Google hebt mehrere Spionagekampagnen von Akteuren mit Verbindungen zu Iran und China hervor, die teils weit über anderthalb Jahre Zugang zur Opferumgebung hielten. Der iranisch verbundene Akteur UNC1549 hatte über mehr als zwei Jahre Zugriff auf eine Zielumgebung – mithilfe gestohlener VPN-Zugangsdaten und der MiniBike-Malware – und entwendete dabei fast ein Terabyte proprietärer Daten. Der china-gestützte Akteur UNC5221 nutzte die Malware BrickStorm, um mindestens 18 Monate lang Zugang zu VMware-vCenter-Servern eines Opfers zu behalten und Quellcode zu stehlen.

Drei Prozent der in der zweiten Jahreshälfte 2025 analysierten Eindringversuche schreibt Google nordkoreanischen IT-Arbeitern (UNC5267) zu, die sich mit gefälschten Identitäten Anstellungen verschafften, um Einnahmen für ihren Staat zu generieren. Ein weiterer nordkoreanischer Akteur, UNC4899, kompromittierte Cloud-Umgebungen gezielt, um digitale Vermögenswerte zu stehlen. In einem Fall brachte UNC4899 einen Entwickler unter dem Vorwand einer Open-Source-Zusammenarbeit dazu, ein bösartiges Archiv herunterzuladen. Dieser übertrug die Datei per Airdrop vom privaten Rechner auf den Firmenarbeitsplatz und öffnete sie in einer KI-gestützten Entwicklungsumgebung. Im Archiv befand sich Python-Schadcode, der eine als Kubernetes-Kommandozeilenwerkzeug getarnte Binärdatei einschleuste. Diese fungierte laut Google als Backdoor und verschaffte den Angreifern Zugang zum Firmennetz. UNC4899 bewegte sich anschließend in die Cloud-Umgebung, erlangte einen Token für ein hochprivilegiertes CI/CD-Dienstkonto, brach aus dem Container aus und gelangte schließlich an Datenbankzugangsdaten samt Kundeninformationen – genug, um mehrere Millionen US-Dollar in Kryptowährung zu erbeuten.

Bei einem Angriff über das kompromittierte npm-Paket QuietVault stahl der Angreifer das GitHub-Token eines Entwicklers und erstellte über das Vertrauensverhältnis zwischen GitHub und AWS per OpenID Connect (OIDC) ein neues Admin-Konto in der Cloud-Umgebung. Innerhalb von nur drei Tagen erlangte QuietVault unter Einsatz lokaler KI-Kommandozeilenwerkzeuge die GitHub- und NPM-API-Schlüssel, missbrauchte die CI/CD-Pipeline für die AWS-Schlüssel, stahl Daten aus dem S3-Speicher und zerstörte sie anschließend. Der Vorfall war Teil des Lieferketten-Angriffs „s1ngularity“, bei dem ein Angreifer kompromittierte npm-Pakete des Open-Source-Build-Systems Nx veröffentlichte; sensible Daten aus 2.180 Konten und 7.200 Repositories wurden in öffentlichen GitHub-Repositories offengelegt.

Die Forscher beobachten zudem, dass Innentäter zur Datenexfiltration zunehmend Cloud-Dienste wie AWS, Google Cloud, Microsoft Azure, Google Drive, Apple iCloud, Dropbox und Microsoft OneDrive nutzen. Eine Analyse von 1.002 Insider-Datendiebstählen ergab, dass 771 davon während des bestehenden Arbeitsverhältnisses stattfanden und 255 nach dessen Beendigung. Google erwartet, dass Cloud-Dienste die E-Mail bald als bevorzugten Exfiltrationsweg ablösen. In einer wachsenden Zahl von Fällen löschen Angreifer Backups, Logdateien und forensische Artefakte. Da die Angriffsgeschwindigkeit – mitunter Auslieferung der Schadlast binnen einer Stunde nach Erstellung einer neuen Instanz – manuelle Reaktionsschemata übersteigt, drängt Google auf automatisierte Incident Response.